[fpc-devel] fpc libraries do not work in freeBSD...

[Tomas Hajny]

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 to the modified file (and no
>> other
>> >> reference to dllprt0.o appears in the linker script), or none of the
>> >> search directories listed in the produced linker script contains an
>> >> older
>> >> version of dllprt0.o if dllprt0.o is listed in the linker script
>> without
>> >> path.
>
> OK, libtest.pas compiled with -s.
>
> link.res: =>
>
> ///////////////////////////////
>
> ...
> blablabla
> ...
>
> INPUT(
> /usr/lib/codetyphon/fpc/units/x86_64-freebsd/rtl/dllprt0.o
> test.o
> /usr/lib/codetyphon/fpc/units/x86_64-freebsd/rtl/system.o
> /usr/lib/codetyphon/fpc/units/x86_64-freebsd/rtl/objpas.o
> )
>
> ////////////////////////
>
> So, yes, it is the good dllprt0.o used...
>
> Hum, what is this system.o for ? Nothing to change there ?

Compiled code from the system unit. I don't see any reference to the
missing symbol from there. You could add the symbols there instead of the
loader probably, but that's another story.

However, there's something else (I wonder why there isn't at least a
warning during compilation of the modified dllprt0.as) - the modified
lines refer to symbol 'operatingsystem_parameters'. However, this symbol
is not defined in dllprt0.as (unlike prt0.as - see the lines preceding the
operatingsystem_parameter_* definitions there).

BTW, note that even if you succeed with linking, this wouldn't change the
fact that the values (pointers) are not initialized. This may be OK as
long as your library links to libc itself (directly or indirectly via
other libraries) or your library doesn't need to use any environment
variables, but it would fail at runtime otherwise. One thing which seemed
to be related to potential addressing of this issue which I could find
using Google was the following comment (in GLIBC sources):

------------------------
   46 #ifdef SHARED
   47 /* This function is called to initialize the shared C library.
   48    It is called just before the user _start code from
sh/sh[34]/elf/start.S,
   49    with the stack set up as that code gets it.  */
   50
   51 /* NOTE!  The linker notices the magical name `_init' and sets the
DT_INIT
   52    pointer in the dynamic section based solely on that.  It is
convention
   53    for this function to be in the `.init' section, but the symbol
name is
   54    the only thing that really matters!!  */
   55 /*void _init (int argc, ...) __attribute__ ((unused, section
(".init")));*/
=========================

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 shared libc).

Tomas