I have installed fpc from sources before but it's been a while and I've
forgotten how to get it done, or perhaps something has changed and need
some help.
When i am trying to do is install and run the latest version of fpc from my
home folder. Here is what I did:
# first I got a working version
I am running linux and already have fpc installed but i want to install
side-by-side a newer verson of fpc ...
I downloaded the sources did make all make install PREFIX=/home/username
... and everything's okay.
I made a /home/username/.fpc.cfg file, but when i type fpc in the CLI i
still get
On Mon, Mar 25, 2013 at 11:24 PM, silvioprog silviop...@gmail.com wrote:
Nice.
But there situations that the user does not have the OpenSSL lib.
The routines I sent does not depend on external libs.
--
Silvio Clécio
My public projects - github.com/silvioprog
It's possible to build
On Tue, Mar 26, 2013 at 12:23 AM, silvioprog silviop...@gmail.com wrote:
Don't know why so much work if you can use it directly from the FCL.
Because...
OpenSSL is quite robust, well documented. tested, and proven
OpenSSL provides a full compilement of cryptography and hashing functions
On
On Tue, Mar 26, 2013 at 1:20 AM, silvioprog silviop...@gmail.com wrote:
I don't know if you noticed, but I sent the ALL test cases required by the
RFC 2202 (http://tools.ietf.org/html/rfc2202), i.e., it's enough to check
whether the algorithm it's well implemented or not.
I'll await the
What is causing warnings for crti.o and crtn.o as described below?
I just got the latest fpc and lazarus from svn, and after build everything
I wrote a Hello World Gtk2 test project on Ubuntu 12.04 (32 bit) with the
following messages ...
Options changed, recompiling clean with -B
It would seem that SDL 2.0 is going to be released in May, and is a
complete rewrite which is incompatible with SDL 1.2. It seems to add a lot
of functionality and I believe Valve's steam box is going to be based
on SDL 2.0.
My question is, has anyone done any work on SDL 2.0 with Free Pascal? If
SDL 2.0 was locked down Friday in preparation for release in May, and I
have been working this weekend on converting the SDL 2 headers to Free
Pascal. In addition I have been writing a OpenGL which creates stubs for
loading the correct OpenGL library and loading the OpenGL core functions
and
On Mon, Apr 8, 2013 at 1:59 AM, Sven Barth pascaldra...@googlemail.comwrote:
Am 08.04.2013 01:37 schrieb Anthony Walter sys...@gmail.com:
In addition I have been writing a OpenGL which creates stubs for loading
the correct OpenGL library and loading the OpenGL core functions
So I did a lot of googling and testing and still haven't made progress
fixing these problems.
Problem #1 which prevents me from debugging or running projects which link
to libSDL2.so in the IDE (lazarus) is quite annoying. I've put together a
minimal example. If anyone with access to a 32 bit
I fixed this problem. Apparently settings in my .bashrc are not inherited
by launcher applications. I have a ~/lib folder where I would put shared
object files I built and added that path it in .bashrc
LD_LIBRARY_PATH=~/lib
export LD_LIBRARY_PATH
I copied the above again in the script which
I did some Googling earlier tonight regarding using the RTL and threads
without creating a TThread class. I found some older results from this
mailing list such as...
http://www.hu.freepascal.org/lists/fpc-pascal/2010-October/026712.html
Basically, what I want to know is HOW DO I... ensure the
Thanks for the prompt reply Jonas.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Oh, I just thought of a followup question. If I have to call BeginThread to
make the memory manager/rtl thread aware, do I then have to also have to
check the OS type (and maybe the CPU architecture) and possibly add more
units? Is it safe to call BeginThread on all platforms/architectures using
Oh and yet another question ...
What is the minimum that needs to be done on all platforms/cpus to enabled
thread local storage (aka threadvar)?
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
I had this same problem a week or so ago:
http://free-pascal-general.1045716.n5.nabble.com/Warning-quot-crti-o-quot-and-quot-crtn-o-quot-not-found-td5713867.html
To fix it I searched for those files and added the directory they were in
to the library path. I hadn't had this problem until
I just wanted to get some opinions on this as to whether this is a bug.
Generics in 2.7.x trunk allows units which use a generic class defined in
another unit can access protected members.
Example:
unit A;
type
TFooT = class
protected
Bar: T;
end;
-- snip to next unit --
unit B;
I was looking at threading support in the System unit and also in the
TThread class.
According to the documentation at
http://www.freepascal.org/docs-html/rtl/system/closethread.html
CloseThread must be called on any thread started with BeginThread. It must
be called after the thread has ended
I get your point about Windows + CloseHandle
But I'm still confused with regards to every other platform. You say yes,
affirming the documentation ... that CloseThread must be called ... nowhere
in any of the platform code I've search is CloseThread used, ever. (even
though BeginThread is used)
On Tue, Apr 23, 2013 at 7:13 AM, Marco van de Voort mar...@stack.nl wrote:
True. But that only means that the beginthread interface is relatively
little used because everybody uses tthread.
But on i386-linux TThread does use BeginThread and never calls CloseThread.
So that seems contrary to
On Tue, Apr 23, 2013 at 9:22 AM, Marco van de Voort mar...@stack.nl wrote:
The TThread code was never specified in terms of the procedural api. As
said
the procedural api largely came after tthread was stable.
Probably at some point calls to the threadmanager were substituted with
calls to
Okay, thanks for the replies. I'll stick with what I have know, which is to
use BeginThread, EndThread, CloseThread.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Thanks for so much Sven. I have another question.
Is it okay for a thread to close itself before it's finished? Because I
believe that is what happens when FreeOnTerminate is set to True. Here is a
brief synopsis of what can execute:
In rtl/objpas/classes/classes.inc
Line 168: FreeThread :=
I was read this on MSDN:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms724211(v=vs.85).aspx
Closing a thread handle does not terminate the associated thread or remove
the thread object. Closing a process handle does not terminate the
associated process or remove the process object.
On Wed, Apr 24, 2013 at 3:53 AM, Sven Barth pascaldra...@googlemail.comwrote:
That's ok, because the FHandle is information which is retrieved in the
context of the calling thread (e.g. the main thread). And if we don't need
any more information about the thread we just close it's handle
I've searched the list archives related to the subject of the fpc
warning Constructor should be public and am unsure as to the
resolution of this issue, or would perhaps like to revisit it.
In my opinion the warning should be removed, or at least able to be
suppress through a switch. I beginning
, FileName, LineNumber); // not visible
On Tue, Nov 10, 2009 at 8:56 AM, Graeme Geldenhuys
gra...@mastermaths.co.za wrote:
Anthony Walter wrote:
In my opinion the warning should be removed, or at least able to be
suppress through a switch. I beginning to make the transition to cross
...@gmail.com wrote:
- Original Message - From: Anthony Walter sys...@gmail.com
To: grae...@opensoft.homeip.net; FPC-Pascal users discussions
fpc-pascal@lists.freepascal.org
Sent: Wednesday, November 11, 2009 1:07 AM
Subject: Re: [fpc-pascal] Compiler Warning: Constructor should be public
...@mastermaths.co.za wrote:
Anthony Walter wrote:
In my opinion the warning should be removed, or at least able to be
suppress through a switch. I beginning to make the transition to cross
The compiler is 100% and I think it should actually raise an Error
instead of a Warning.
Your code is flawed. Object
Of course you can't hide methods previously exposed in an inherited
class. But this applies to every member type (fields, properties,
methods), not just constructors. The point of a constructor is not to
new up a class (NewInstance does that), but to execute a block of code
(with checks) before
Hi all. I am new to fpc and linux in general, though I do have a long
time experience with Delphi.
I was writing some code basic system (using the libc library) when I
ran across the following problem .. some code:
const
libc = 'libc.so.6';
type
TTimeSpec = record
Sec: Cardinal; {
, Michael Van Canneyt
mich...@freepascal.org wrote:
On Sun, 15 Nov 2009, Anthony Walter wrote:
Hi all. I am new to fpc and linux in general, though I do have a long
time experience with Delphi.
I was writing some code basic system (using the libc library) when I
ran across the following problem
I assume you replied so quickly you did not get the chance to read my
crafted and tested reply. You may have been typing the same time I was
:)
Please go back and read my message and note the tests section.
Jonas, why is FPC emulating C when it could simply follow the Delphi
way and prevent
, there is an incompatibility. Fix it.
On Mon, Nov 16, 2009 at 9:03 AM, Jonas Maebe jonas.ma...@elis.ugent.be wrote:
On 16 Nov 2009, at 15:01, Anthony Walter wrote:
Jonas, why is FPC emulating C when it could simply follow the Delphi
way and prevent these incompatibilities?
I think that FPC's behaviour
I probably should, but I've never worked on a community project
before. I don't know the ins and outs of hooking up to the developer
repository, getting the build environment working, discussing and
submitting my changes, testing those changes, and moving them into the
official version.
If anyone
them?
On Mon, Nov 16, 2009 at 9:41 AM, Michael Van Canneyt
mich...@freepascal.org wrote:
On Mon, 16 Nov 2009, Anthony Walter wrote:
As I said in my introduction. I am new to Linux and FPC. I've used
them both for maybe 8 years, but not seriously.
On the Linux side for years I've just used
On Mon, Nov 16, 2009 at 10:19 AM, Marco van de Voort mar...@stack.nl wrote:
The fpc-devel group and/or irc.
On freenode I've been to #fpc a few times over the years. My handle is sysRPL.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
On Mon, Nov 16, 2009 at 10:35 AM, Eduardo Morras emor...@xroff.net wrote:
One question, why do you reimplement libc-fpc wrapping lib? This function
is in the BaseUnix unit as fpnanosleep.
I am redoing my game engine is which based on a simple concept. Bare
bones code. The library is called
On Mon, Nov 16, 2009 at 12:37 PM, Jürgen Hestermann
juergen.hesterm...@gmx.de wrote:
I hate it if bugs or illogical things are copied from Delphi. It may be the
case that Delphi vanishes one day. Then we still would have all these bugs
in FPC/Lazarus cast in stone forever. I think we should not
On Mon, Nov 16, 2009 at 1:39 PM, Jonas Maebe jonas.ma...@elis.ugent.be wrote:
For this reason, I think the Delphi operator naming decision is actually
better than FPC's. Limiting them to classes is another matter.
Jonas
Jonas,
Delphi doesn't limit operator overloading to classes. You can
I haven't used generics in FPC, but really have to ask, is they
keyword generic really necessary? Shouldn't generics be declared like
this:
type
TListT = class
private
...
public
function Add: T;
procedure Remove(Item: T);
property Item[Index: Integer]: T read Get write
On Sun, Nov 22, 2009 at 6:15 AM, Jonas Maebe jonas.ma...@elis.ugent.be wrote:
Generics were developed in parallel in FPC and in Delphi, and both came up
with a different syntax.
The incompatibility was there from the start, it wasn't created afterwards.
Jonas,
I am not trying to be a jerk
On Sun, Nov 22, 2009 at 10:27 AM, Marco van de Voort mar...@stack.nl wrote:
Apparantly it didn't sink in:-)
Oh it has sunk in, and I've come to expect it. I was/am only trying to
move the discussion beyond that point (which seems like a brick wall).
IMO a discussion would serve us better than
On Sun, Nov 22, 2009 at 12:03 PM, Michael Van Canneyt
mich...@freepascal.org wrote:
Well, in
Var
A : Integer;
The 'Var' is strictly speaking also redundant, as the : is used only in
variable declarations. But the 'var' makes it easier to read, and Pascal is
a verbose language.
As a follow up, here are a few generic type declaration examples
lifted directly out of the CodeGear pdf Jonas was thoughtful enough to
link:
*Please Note* These examples do not include generic constraints which
I believe are needed to work effectively with generics. Generic
constraints can be
I improperly replied. Let me try that again.
As a follow up, here are a few generic type declaration examples
lifted directly out of the CodeGear pdf Jonas was thoughtful enough to
link:
*Please Note* These examples do not include generic constraints which
I believe are needed to work
procedure InitMyVariable(Value: T);
function MyVariable: T;
implementation
var
PrivateMyVariable: T;
PrivateMyVariableSet: Boolean;
procedure InitMyVariable(Value: T);
begin
if not PrivateMyVariableSet then
PrivateMyVariable := Value;
PrivateMyVariableSet := True;
end;
function
PrivateMyVariableSet is not intialised, so will have an undefined
(random) value when InitMyVariable is first called.
Mattias' code given earlier avoids this problem.
Bzzzt. Wrong.
Global variables (even in the implementation section) are always
initialized to 0.
This is not guaranteed in any way. It happens to be so most of the time,
but your code should never assume this is so, except for global Ansistring
variables.
If all globals weren't initialized to 0 a lot of code from lots of
people would potentially be in trouble. I've been using
That should be removed, actually.
I'll take that as an admission that you were wrong. It's in the
specification, lot's of code uses the feature, and it works the way I
described.
Changing the specification to match your argument is stupid.
___
Okay, I am going to call bullshit on you. This is the second time (in
a few weeks) where you've replied to something I've written with wrong
information.
This first time concerning the topic const records passed
incorrectly you said, It is nowhere written in the Delphi specs that
const
Jonas,
Thank you. I certainly will make an attempt to tone down a few of my
remarks which I admit were inflammatory. I assure everyone here
though, my purpose in conversing on these lists is to help improve
FPC, so far by discussing easy to resolve and reproduce technical
points. I personally
FPC currently initialises the global data to 0 on platforms that do not do
this by themselves. When it turns global variables into register variables,
it will also initialise such registers with 0.
Ah, okay. So it is working as expected. Thanks for the reply.
So it seems that passing them by value actually corresponds to what the
Delphi docs say.
Jonas, I agree, the documentation definitely does address the issue,
which was where that conversation was derailed.
Regarding actual implementation, I previously posted the full source
to a test program
On Tue, Dec 1, 2009 at 11:58 AM, Bruce Bauman
bruce.bau...@andesaservices.com wrote:
I’m trying to port/debug some ugly Pascal code.
Is there a way I can tell if an arbitrary address is within the heap or
stack?
Without hooking/replacing the memory manager, I don't believe you can
handle
Oh and for querying stack pointers, there should be an OS function
somewhere to give you the base stack pointer address and available
stack size, though I don't know the names of functions off the top of
my head.
___
fpc-pascal maillist -
With Delphi/FPC you have a few choices:
Fixed length arrays, dynamic length arrays, and variant type arrays
Fixed length arrays cannot be resized and their lower and upper bounds are
immutable. The lower and upper bounds can start at any ordinal position. The
upper bound can ever be less than
No, the compiler will not fill in the array length based on your element
list. It does compute the length while compiling and *you* need to match it
in your declaration.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
Sure, I agree.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
I read the user changes document which seemed to consist of a list of
subtle changes. My question is does 2.4.0 put forward any major
changes and if so in what document are those changes described. I am
interested in reading about changes such as official generic support,
changes to support COM
On Sat, Jan 2, 2010 at 5:44 AM, Paul Ishenin webpi...@mail.ru wrote:
Jonas Maebe wrote:
http://edn.embarcadero.com/article/6
Note that even Delphi doesn't have them yet (it might also turn up in
Delphi in the future).
Looks as something related to:
I'll just repeat what I said in the FPC 2.4.0 release thread.
* See the good news note at the bottom of this message
Something I've really found useful in C#/.NET is lambda functions and
capturing locals (closures). This feature solves asynchronous design
for me in so many ways. If you can
Yup!
Of course, there are pros and cons to all this. Our once simple,
straightforward language is not littered with convenience features that
are not necessary at all. For example, what is the big advantage of class
methods over simple functions and procedures?
Class methods can be
I am not too sure why GetProcAddress is returning nil, but a few points:
1) you do not need to typecast string literals as PChar
FGetAsText := GetProcAddress (FHandle, 'clipboard_getastext');
2) You really should not return strings as PChar, passing them is fine, but
return, nope
result :=
Don't call accept() on the incoming connection, call close() instead.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
On Thu, Jan 21, 2010 at 7:50 AM, Justin Smyth
delph...@smythconsulting.netwrote:
Any one know how to get the Active Handle from the current Form from
TApplication ? Delphi has something for this but i cant see it.
I'm in the progress of getting JVCL working under FPC / lazarus ( FPC 2.5.1
1) Format('%.3f', [A / B]);
2) It depends on you GUI framework/library, but in Delphi and Lazarus it
would be Color := 0;
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
No, the assignment shouldn't be allowed. The assignment to procedure of
object should only be allowed from instances.
SizeOf(TNotifyProc) = SizeOf(Pointer) * 2
See also: the TMethod record
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
As Michael Van Canneyt says, you cannot use a method as a window message
handler. This assumed implicit Self variable will most likely break the
return pointer on the stack.
Here is my code for a user defined window class. Note, window messages are
processed through TObject.Dispatch
threadvar
SetWindowLong(Wnd, GWL_USERDATA, Integer(BaseWindow));
Not 64-bits safe. An integer is not a long. Ptruint probably.
Ah well, there is a new API to fix this in 64 bit Windows. Use
SetWindowLongPtr/GetWindowLongPtr instead.
___
fpc-pascal
I've written some XML classes which expose themselves as interfaces.
Usage goes something like this:
procedure SaveSettings(const Settings: string);
var
Document: IDocument;
Filer: IFiler;
begin
Document := CreateDocument;
Filer := Document.ForceRoot('test') as IFiler;
I though I'd share this and as for any feedback.
Today I was experimenting with a borrowing a Delphi concept and
implementing it in C#. I wanted to be able to do this in C#:
procedure WMMouseMove(var Message: TWMMouseMove); message WM_MOUSEMOVE;
And I believe I came up with a similar yet
Like so:
(iBitmap:0; idCommand: 0; fsState:0; fsStyle:0; bReserved: (0,0);
dwData: nil; iString: nil)
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
I don't understand. Would you care to explain what restrictions
SourceForge places on its users? I am curious.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
The syntax that Prism uses is a lot cleaner in many respects - especially
removing the procedure/function conundrum and using instead method.
However, in other ways it is horrible and so I can also see why it is not
something worth discussing further.
Matt,
I am no Prism fan (I prefer native
I was on freenode irc #fpc earlier and asked some questions but not enough
people were online to get an answer.
My question was/is:
Will there ever again come a point where FPC attempts to bring in more
compatibility with Delphi? Specifically, in regards to operator overloading
and generic
When I google search for FPC generics tohe top result links here:
http://wiki.freepascal.org/Generics
Two cases:
1) type generic TListT = class // ... as is now, the word generic is
redundant
2) type TListT = class // ... better and in line with Delphi
It seems both were on the suggested
Technical limitations aside, at this point what would be needed from the
community to get the generic syntax changed? Supposing I had the soruce code
changes to accommodate the change to remove the generic keyword, what
would be needed from the community to approve moving that change into the
Graeme:
To be honest, this is a slightly unfair case, saying Free Pascal must
become Delphi compatible, when Free Pascal had generics support
*before* Delphi did. Maybe Delphi should become more Free Pascal
compatible.
I've preemptively disabled this argument so many times in the past. It's
Technical limitations aside, at this point what would be needed from the
community to get the generic syntax changed?:
: Patches.
I believe there would first need to be some sort ofg consensus within the
community about the changing the syntax.
___
Is the keyword generic really needed here:
type generic TEnumeratorTValue, TIterator = class
- should be -
type TEnumeratorTValue, TIterator = class
It looks completely unnecessary and I've never seen a situation in pascal
where anything but an identifier follows the keyword type. Whomever
On Mon, Jul 26, 2010 at 4:40 AM, Graeme Geldenhuys
graemeg.li...@gmail.comwrote:
In short - Delphi in-compatibility is not a
problem here, just like Generics or Compiler Modes or . FPC doesn't do
everything like Delphi, sometimes it does things _better_ than Delphi. FPC
Namespaces would
Like so:
procedure Test;
var
SomeType: TClass;
SomeObject: TObject;
begin
SomeType := TStringList;
SomeObject := SomeType.Create;
(SomeObject as TStrings).Add('Hello World');
ShowMessage((SomeObject as TStrings)[0]);
SomeObject.Free;
end;
On Mon, Aug 23, 2010 at 7:05 PM, Frank
Paul,
Thanks for working on adding methods and visibility to record types. Could
you also look into fixing generics? That is, to allow for generic
constraints and remove the redundant generic and specialize keywords. For
example:
{code}
type
TListT = class { ... interface code ... } end;
Hello all. I implemented a new type of multicast events in Delphi based on
generics. I thought someone could maybe consider and convert this
implementation to Free Pascal. Here is a link to an article describing the
implementation, its benefits and usage, and well as the full source code.
Let me
Yeah, I just added the code highlighter, which build the highlights using
javascript. I set to display: none while the page loads which isn't
effecting the print version. The workaround is that you can print the code
blocks by clicking the print icon in each code section. I'll fix it later.
Just an update ... I fixed the print feature at the bottom.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
By the way, does Free Pascal generic support generic constraints yet? Also,
this format seems more natural to me:
TCollectionT: TCollectionItem = class
property Count: Integer;
property Items[Index: Integer]: T;
end;
TStatusPanels = class(TCollectionTStatusPanel);
rather than ...
generic
Have you used ListT, DictionaryK,V, or IEnumerableT in C# much? How
about EventHandlerT? They are pretty useful.
Even in Delphi, TListT, TObjectListT, and TCompareT are more than
handy IMO. No longer do I have to write TMyObject(FList[I]) all over the
place. When using if
Over at stackoverflow someone
askedhttp://stackoverflow.com/questions/4913178/javascript-in-delphi-applications,
Is it possible to utilize javascript in the making of windows desktop
applications. I wrote up a pascal based solution to add javascript access
to your desktop programs. If you have any
For drawing lines, shapes, fills, on Linux I'd recommend using cairo. On
Windows I'd say you should use GDI or GDI+. You can find pascal files
importing the functions for those libraries using google. Some of them may
come with FPC.
For widgets, if you are using Lazarus, it comes with a widget
Oh, you want a retained mode graphics system. That should be pretty easy to
write yourself.
Just write a class like TDrawable with a Paint(), HitTest(Point), and
Intersects(Rect) methods and derive from that to have your different drawn
types.
Keep a list of those items in your drawing surface.
Is this true? I'd really like to see generics that with a mode where it is
possible to say with the following syntax (compatible with Delphi):
type
IDelegateT = interface
procedure Add(const Handler: T);
procedure Remove(const Handler: T);
end;
And then specialize using the following
Can someone point me in the right direction towards solving this problem?
I built a static libraries on Linux based on some open source c and h
files. I can compile things fine with gcc/mingw-265 and use ar to turn the
object files into a static lib (libtess.a). The problem is when I try to
Okay, had tried ...
{$linklib msvcrt} // libmsvcrt.a copied from Linux /usr/i686-mingw-w64/lib
{$linklib tess} // my static lib
Then I installed dependency walker (per your advice) and inspected
msvcrt.dll. That dll seems to have the missing functions but with the names
a bit different in places
I got it. I found all the required static libraries by going searching
through nm *.a on Linux and looking for which library had the missing
functions, then I linked to that lib which gave me a whole new set of
missing functions and I repeated the process until nothing was missing.
Also,
I am trying to come up with an embedded binary resource system and was
considering placing data in object files when I found this question on
stack overflow:
http://stackoverflow.com/questions/4158900/embedding-resources-in-exe-using-gcc
I see that it's possible to directly turn any file into an
Wow, thanks for all the interesting replies. In the mean time here is what
I came up with:
ld -r -b binary -o binary.o helloworld.txt
#include stdint.h
extern char _binary_helloworld_txt_start[];
extern char _binary_helloworld_txt_end[];
void* helloworld(uintptr_t* i) {
uintptr_t a =
I think I'll use Rainer's example:
{$ir file.dat mydata}
I just hope the final exe won't get bloated if resource are included in
this manner and never used and also that it does slow down compilation
every time unless I add to new resources or change code in the unit
containing the resource.
Okay I found some interesting results after a bit of testing...
When using bin2obj you get a byte of array typed constant which you can
include in your sources. The compiler will always include the resource
whether it is referenced from code or not. Stripping the app (strip -s -g
appname) does
1 - 100 of 358 matches
Mail list logo
