Yp, Michal, your tip does the trick... :-)
According to your patch (i do not know how to apply), i have changed in:
/rtl/freebsd/x86_64/dllprt0.as :
.weak operatingsystem_parameter_argc
.weak operatingsystem_parameter_argv .weak
Date: Wed, 6 Aug 2014 15:37:19 -0500
From: michal.wall...@gmail.com
To: fpc-devel@lists.freepascal.org
Subject: Re: [fpc-devel] fpc libraries do not work in freeBSD...
It looks like my old post had an error when I tried to copy and paste the
text.The last line that is repeated 3 times should
Date: Wed, 6 Aug 2014 15:37:19 -0500
From: michal.wall...@gmail.com
To: fpc-devel@lists.freepascal.org
Subject: Re: [fpc-devel] fpc libraries do not work in freeBSD...
It looks like my old post had an error when I tried to copy and paste the
text.The last line that is repeated 3 times should
On Wed, August 6, 2014 03:36, Fred van Stappen wrote:
Hello.
Changed that in prt0.as =:
.weak operatingsystem_parameter_argc
.weak operatingsystem_parameter_argv
.weak operatingsystem_parameter_envp
with that :
.global operatingsystem_parameter_envp
.global
Yep, Many thanks to take care Tomas.
I assume that you should have changed dllprt0.as rather than prt0.as?
Yes, of course (sorry for bad copy).
Moreover - remind me, do you target FreeBSD under x86_64 or x86 (if you
change the wrong one, it wouldn't have any effect, of course)? The snippet
On Wed, August 6, 2014 12:16, Fred van Stappen wrote:
Yep, Many thanks to take care Tomas.
I assume that you should have changed dllprt0.as rather than prt0.as?
Yes, of course (sorry for bad copy).
I'd suggest checking if the file you have changed (dllprt0.o) is really
the one used during
I'd suggest checking if the file you have changed (dllprt0.o) is really
the one used during linking. For that purpose, compile your library with
parameter '-s' (avoid linking) and carefully check the created script.res
file to make sure that either dllprt0.o is listed with a full path and the
For that purpose, compile your library with
parameter '-s' (avoid linking) and carefully check the created script.res
file to make sure that either dllprt0.o is listed with a full path and the
full path specification corresponds to the modified file (and no other
reference to dllprt0.o
On Wed, August 6, 2014 14:30, Fred van Stappen wrote:
For that purpose, compile your library with
parameter '-s' (avoid linking) and carefully check the created
script.res
file to make sure that either dllprt0.o is listed with a full path and
the
full path specification corresponds to the
You should not use that parameter for compiling fpc, but only for
compiling your library. This shouldn't require any complicated script,
IMHO.
Tomas
Ha, ok, i will compile the test library with -s parameter (mine is too
compilcated, i begin with a hyper-simple to be sure im not the guilty
For that purpose, compile your library with
parameter '-s' (avoid linking) and carefully check the created
script.res
file to make sure that either dllprt0.o is listed with a full path and
the
full path specification corresponds to the modified file (and no other
reference to
On Wed, August 6, 2014 16:13, Fred van Stappen wrote:
For that purpose, compile your library with
parameter '-s' (avoid linking) and carefully check the created
script.res
file to make sure that either dllprt0.o is listed with a full path
and
the
full path specification corresponds
I know virtually nothing about FreeBSD, but if this comment (about linker
behaving in special way to 'magical name _init') still applies for the
linker used under FreeBSD, this could be the potential solution for
initialization of these values for FPC RTL in shared libraries (rather
then for
It looks like my old post had an error when I tried to copy and paste the
text.
The last line that is repeated 3 times should be three separate lines with
an
have an offset for each variable.
For what it's worth, here is the actual patch I used. (I haven't re-tested
it
today. If it doesn't work,
Hello everybody.
I have posted this question in fpc-mailing list but... no answers, so i try
here...
Fpc libraries compiled on freeBSD 64 bit are unusable. (32 bit not tested)
Python, Java, C and even fpc applications can not use them in freeBSD...
Look at that (works on Linux 32/64): =
In our previous episode, Fred van Stappen said:
I have posted this question in fpc-mailing list but... no answers, so i try
here...
Fpc libraries compiled on freeBSD 64 bit are unusable. (32 bit not tested)
Python, Java, C and even fpc applications can not use them in freeBSD...
I
Am 05.08.2014 15:35 schrieb Marco van de Voort mar...@stack.nl:
But the FPC version has these symbols in the main program, maybe you must
make sure that those (operatingsystem*) systems are available from the
mainprogram too and preloaded with the proper values.
The main program should not
05.08.2014 22:02, Sven Barth пишет:
Am 05.08.2014 15:35 schrieb Marco van de Voort mar...@stack.nl
mailto:mar...@stack.nl:
But the FPC version has these symbols in the main program, maybe you must
make sure that those (operatingsystem*) systems are available from the
mainprogram too and
The main program should not need to do anything here.
It's more likely that there is a problem in our FreeBSD startup files for
libraries.
Regards,
Sven
Many thanks to take care on freeBSD + fpc libraries...
Please, read that topic, it talks about the same problem and it has a solution:
I.e. fixing the issue requires changes to startup files/link scripts and
means that
no support for versions 9.2 will be available.
Does it mean that actual fpc libraries could be used by freeBSD 9.2 ?
If a script to support freeBSD =9.2 is done, could it be possible to add, for
fpc
Am 05.08.2014 20:37 schrieb Sergei Gorelkin sergei_gorel...@mail.ru:
05.08.2014 22:02, Sven Barth пишет:
Am 05.08.2014 15:35 schrieb Marco van de Voort mar...@stack.nl
mailto:mar...@stack.nl:
But the FPC version has these symbols in the main program, maybe you
must
make sure that those
In our previous episode, Sven Barth said:
FreeBSD loader does not pass argc,argv and envp to shared library
initialization procedure, like it happens on Linux. Since FPC does not have
a shared RTL, such hack with exporting symbols from executable is likely an
only way to initialize RTLs
Because they essentially have a shared RTL in libc, yes.
But note that with a hypothetical shared FPC lib, the problem would be the
same if one of the parts was not written in pascal.
IOW the libc case only works for C programs, and programs that build on
that.
Hello.
In a old topic,
In our previous episode, Fred van Stappen said:
But... It seems like the original .weak version was done quite
deliberately, so I suspect that if I submit a patch, it would break
things for other people. OTOH, I'd like to get a fix for my issue
into trunk.
Probably fpc-fpc linking then fails.
Could it be feasible to compile a custom fpc, so i could compile libraries
for freeBSD 10 ?
Startup files can be exchanged without recompiling everything. Just
overwrite the .o with the newly assembled ones.
Ok, many thanks Marco. ;-)
So, according with Michal Wallace solution (hope i
On 6 Aug 14, at 0:03, Fred van Stappen wrote:
Could it be feasible to compile a custom fpc, so i could compile
libraries for freeBSD 10 ?
Startup files can be exchanged without recompiling everything. Just
overwrite the .o with the newly assembled ones.
Ok, many thanks Marco. ;-)
.global operatingsystem_parameter_envp
.global operatingsystem_parameter_argc
.global operatingsystem_parameter_argv
.set operatingsystem_parameter_envp,operatingsystem_parameters+0
.set operatingsystem_parameter_envp,operatingsystem_parameters+0
.set
Hello.
Changed that in prt0.as =:
.weak operatingsystem_parameter_argc
.weak operatingsystem_parameter_argv
.weak operatingsystem_parameter_envp
with that :
.global operatingsystem_parameter_envp
.global operatingsystem_parameter_argc
.global operatingsystem_parameter_argv
28 matches
Mail list logo
