crosscompiling from win32 to i386-linux and libc linking

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

crosscompiling from win32 to i386-linux and libc linking

Dominique Leducq-2
Hi,

I have linking problems when cross-compiling from win32 to i386-linux
and linking with libc (dynamically).
I use FPC 2.0.2, the libs are from a Debian Sarge (glibc-2.3.6, I tried
with glibc 2.3.2 with same results),
cross ld is :
ld.exe -V
GNU ld version 2.15
   Supported emulations:
    elf_i386
    i386linux

I get the following errors :
fpc -Mdelphi -Tlinux test.pas -Fl'c:\FPC\2.0.2\lib\i386-linux'
Free Pascal Compiler version 2.0.2 [2005/11/26] for i386
Copyright (c) 1993-2005 by Florian Klaempfl
Target OS: Linux for i386
Compiling test.pas
Linking test
C:\FPC\2.0.2\lib\i386-linux\/libdl.so: undefined reference to
`_rtld_global@GLIBC_PRIVATE'
C:\FPC\2.0.2\lib\i386-linux\/libc.so: undefined reference to
`__libc_enable_secure@GLIBC_PRIVATE'
C:\FPC\2.0.2\lib\i386-linux\/libc.so: undefined reference to
`__libc_stack_end@GLIBC_2.1'
C:\FPC\2.0.2\lib\i386-linux\/libdl.so: undefined reference to
`_rtld_global_ro@GLIBC_PRIVATE'
C:\FPC\2.0.2\lib\i386-linux\/libc.so: undefined reference to
`_dl_out_of_memory@GLIBC_PRIVATE'
C:\FPC\2.0.2\lib\i386-linux\/libc.so: undefined reference to
`___tls_get_addr@GLIBC_2.3'
C:\FPC\2.0.2\lib\i386-linux\/libc.so: undefined reference to
`_r_debug@GLIBC_2.0'
C:\FPC\2.0.2\lib\i386-linux\/libc.so: undefined reference to
`_dl_argv@GLIBC_PRIVATE'
C:\FPC\2.0.2\lib\i386-linux\/libdl.so: undefined reference to
`_dl_rtld_di_serinfo@GLIBC_PRIVATE'
testthreads.pas(37,1) Error: Error while linking
Error: c:\FPC\2.0.2\bin\i386-Win32\ppc386.exe returned an error exitcode
(normal if you did not specify a source file to be compiled)


while

  nm -D ld-linux.so.2
0000e6a0 T ___tls_get_addr
00015f1c D __libc_enable_secure
000101b0 W __libc_memalign
00015f18 D __libc_stack_end
0000de70 T __tls_get_addr
0000e610 T _dl_allocate_tls
0000e3f0 T _dl_allocate_tls_init
00015e8c D _dl_argv
0000e640 T _dl_deallocate_tls
0000c450 T _dl_debug_state
0000e330 T _dl_get_tls_static_info
0000ec60 T _dl_make_stack_executable
0000db30 T _dl_mcount
00012258 R _dl_out_of_memory
00006840 T _dl_rtld_di_serinfo
0000e1f0 T _dl_tls_setup
000164e4 B _r_debug
00016020 D _rtld_global
00015cc0 D _rtld_global_ro
000103d0 W calloc
0000fda0 W free
00000000 A GLIBC_2.0
00000000 A GLIBC_2.1
00000000 A GLIBC_2.3
00000000 A GLIBC_PRIVATE
000102f0 W malloc
00010320 W realloc

the difference in the symbols is only the '@GLIBC...' part.
I have no problem linking the same code on Linux, on the very same
system the libs came from.

I can link statically ( with -Xt), however.

Dominique.


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: crosscompiling from win32 to i386-linux and libc linking

Marco van de Voort
On Fri, Jul 28, 2006 at 11:54:07AM +0200, Dominique Leducq wrote:

>
> I have linking problems when cross-compiling from win32 to i386-linux
> and linking with libc (dynamically).
> I use FPC 2.0.2, the libs are from a Debian Sarge (glibc-2.3.6, I tried
> with glibc 2.3.2 with same results),
> cross ld is :
> ld.exe -V
> GNU ld version 2.15
>   Supported emulations:
>    elf_i386
>    i386linux

I don't have time to debug this fully, but have a look at my notes when I
was trying this:

http://www.stack.nl/~marcov/crossnotes.txt

 Note that
I set it the dynlinker explicitely in point 11


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: crosscompiling from win32 to i386-linux and libc linking

Dominique Leducq-2
Marco van de Voort a écrit :

> On Fri, Jul 28, 2006 at 11:54:07AM +0200, Dominique Leducq wrote:
>> I have linking problems when cross-compiling from win32 to i386-linux
>> and linking with libc (dynamically).
>> I use FPC 2.0.2, the libs are from a Debian Sarge (glibc-2.3.6, I tried
>> with glibc 2.3.2 with same results),
>> cross ld is :
>> ld.exe -V
>> GNU ld version 2.15
>>   Supported emulations:
>>    elf_i386
>>    i386linux
>
> I don't have time to debug this fully, but have a look at my notes when I
> was trying this:
>
> http://www.stack.nl/~marcov/crossnotes.txt
>
>  Note that
> I set it the dynlinker explicitely in point 11
>
>
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Thank you for your prompt answer.
I tried to set the dynamic linker whith the -FL option too, but it
didn't help. Anyway, it seems to be a runtime hint, as you give a target
  path as an argument, and I don't get the chance to reach this step, as
I can't produce any executable.

I read your doc, and didn't see anything else that could improve the
matters.

Dominique.


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: crosscompiling from win32 to i386-linux and libc linking

Marco van de Voort
> >
> > _______________________________________________
> > fpc-pascal maillist  -  [hidden email]
> > http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>
> Thank you for your prompt answer.
> I tried to set the dynamic linker whith the -FL option too, but it
> didn't help. Anyway, it seems to be a runtime hint, as you give a target
>   path as an argument, and I don't get the chance to reach this step, as
> I can't produce any executable.
>
> I read your doc, and didn't see anything else that could improve the
> matters.

Also note step 8 it is very treacherous.

The 10th step can nowdays (all versions after medium july) be done by
passing  -XLAc=c,dl and -XLAgtk=gmodule,gtk  or so. Same for step 12.

Note that in the 10th step I do three things, IIRC
- The -FL sets the place where the loader on the target should look for the
dnyamic linker.
- The -Xr causes it to also search /usr/lib for anything it needs.
- The -Fl points to the directory where I stored the copies of the libs.
Note that I sometimes renamed the copied libs a bit to match the names it
searches.

Also note this remark:

----
Making mistakes with renaming is not that bad, there will be chances to fix
it. Make sure all crt* and a file "libc.so" are available, otherwise
generating link.res will go wrong. (Yes, Peter, that was my fault :-)
----

In case you added parameter by parameter, clean, and try to build again with
all relevant parameters. The compiler on Linux makes some decisions based on
the existance of some of these files.


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: crosscompiling from win32 to i386-linux and libc linking

Dominique Leducq-2
Marco van de Voort a écrit :

>>> _______________________________________________
>>> fpc-pascal maillist  -  [hidden email]
>>> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>> Thank you for your prompt answer.
>> I tried to set the dynamic linker whith the -FL option too, but it
>> didn't help. Anyway, it seems to be a runtime hint, as you give a target
>>   path as an argument, and I don't get the chance to reach this step, as
>> I can't produce any executable.
>>
>> I read your doc, and didn't see anything else that could improve the
>> matters.
>
> Also note step 8 it is very treacherous.
>

Did not change anything... What are precisely the respective purposes of
cprt0.o & cprt21.o ?

> The 10th step can nowdays (all versions after medium july) be done by
> passing  -XLAc=c,dl and -XLAgtk=gmodule,gtk  or so. Same for step 12.
>
> Note that in the 10th step I do three things, IIRC
> - The -FL sets the place where the loader on the target should look for the
> dnyamic linker.
> - The -Xr causes it to also search /usr/lib for anything it needs.

OK, that has runtime effect, it won't break linking, then.

> - The -Fl points to the directory where I stored the copies of the libs.
> Note that I sometimes renamed the copied libs a bit to match the names it
> searches.
>

I did that already, and the linker seems to find anything it searches for.

> Also note this remark:
>
> ----
> Making mistakes with renaming is not that bad, there will be chances to fix
> it. Make sure all crt* and a file "libc.so" are available, otherwise
> generating link.res will go wrong. (Yes, Peter, that was my fault :-)
> ----
>
> In case you added parameter by parameter, clean, and try to build again with
> all relevant parameters. The compiler on Linux makes some decisions based on
> the existance of some of these files.
>
>
I tried all this, unsuccessfully, alas.

Clearly all symbols that ld claims are undefined are defined in
ld-linux.so.2 (ld-2.3.6.so), but somehow ld doesn't find them....
But it does on Linux ! It is a priori the same, except this one is from
the cross-binutils (Well, indeed on linux I have ld 2.16.91 20060413
Debian Gnu/Linux; perhaps I should try to compile this one as cross-tool...)

Here is the link.res, if you can see some strange things from it.

SEARCH_DIR(C:\FPC\2.0.2\lib\i386-linux\)
SEARCH_DIR(C:\FPC\2.0.2\units\i386-linux\rtl\)
SEARCH_DIR(C:\FPC\2.0.2\units\i386-linux\zvt\)
SEARCH_DIR(C:\FPC\2.0.2\units\i386-linux\zlib\)
SEARCH_DIR(C:\FPC\2.0.2\units\i386-linux\x11\)
SEARCH_DIR(C:\FPC\2.0.2\units\i386-linux\uuid\)
SEARCH_DIR(C:\FPC\2.0.2\units\i386-linux\utmp\)
SEARCH_DIR(C:\FPC\2.0.2\units\i386-linux\unzip\)
SEARCH_DIR(C:\FPC\2.0.2\units\i386-linux\unixutil\)
SEARCH_DIR(C:\FPC\2.0.2\units\i386-linux\tcl\)
SEARCH_DIR(C:\FPC\2.0.2\units\i386-linux\syslog\)
SEARCH_DIR(C:\FPC\2.0.2\units\i386-linux\svgalib\)
SEARCH_DIR(C:\FPC\2.0.2\units\i386-linux\sqlite\)
SEARCH_DIR(C:\FPC\2.0.2\units\i386-linux\regexpr\)
SEARCH_DIR(C:\FPC\2.0.2\units\i386-linux\pthreads\)
SEARCH_DIR(C:\FPC\2.0.2\units\i386-linux\postgres\)
SEARCH_DIR(C:\FPC\2.0.2\units\i386-linux\paszlib\)
SEARCH_DIR(C:\FPC\2.0.2\units\i386-linux\pasjpeg\)
SEARCH_DIR(C:\FPC\2.0.2\units\i386-linux\oracle\)
SEARCH_DIR(C:\FPC\2.0.2\units\i386-linux\opengl\)
SEARCH_DIR(C:\FPC\2.0.2\units\i386-linux\odbc\)
SEARCH_DIR(C:\FPC\2.0.2\units\i386-linux\newt\)
SEARCH_DIR(C:\FPC\2.0.2\units\i386-linux\netdb\)
SEARCH_DIR(C:\FPC\2.0.2\units\i386-linux\ncurses\)
SEARCH_DIR(C:\FPC\2.0.2\units\i386-linux\mysql\)
SEARCH_DIR(C:\FPC\2.0.2\units\i386-linux\md5\)
SEARCH_DIR(C:\FPC\2.0.2\units\i386-linux\libpng\)
SEARCH_DIR(C:\FPC\2.0.2\units\i386-linux\libgd\)
SEARCH_DIR(C:\FPC\2.0.2\units\i386-linux\libc\)
SEARCH_DIR(C:\FPC\2.0.2\units\i386-linux\libasync\)
SEARCH_DIR(C:\FPC\2.0.2\units\i386-linux\imlib\)
SEARCH_DIR(C:\FPC\2.0.2\units\i386-linux\ibase\)
SEARCH_DIR(C:\FPC\2.0.2\units\i386-linux\gtk2\)
SEARCH_DIR(C:\FPC\2.0.2\units\i386-linux\gtk\)
SEARCH_DIR(C:\FPC\2.0.2\units\i386-linux\gnome\)
SEARCH_DIR(C:\FPC\2.0.2\units\i386-linux\ggi\)
SEARCH_DIR(C:\FPC\2.0.2\units\i386-linux\gdbm\)
SEARCH_DIR(C:\FPC\2.0.2\units\i386-linux\gdbint\)
SEARCH_DIR(C:\FPC\2.0.2\units\i386-linux\gconf\)
SEARCH_DIR(C:\FPC\2.0.2\units\i386-linux\fv\)
SEARCH_DIR(C:\FPC\2.0.2\units\i386-linux\fpgtk\)
SEARCH_DIR(C:\FPC\2.0.2\units\i386-linux\forms\)
SEARCH_DIR(C:\FPC\2.0.2\units\i386-linux\fcl\)
SEARCH_DIR(C:\FPC\2.0.2\units\i386-linux\cdrom\)
SEARCH_DIR(C:\FPC\2.0.2\units\i386-linux\bfd\)
SEARCH_DIR(C:\FPC\2.0.2\units\i386-linux\)
SEARCH_DIR(C:\FPC\2.0.2\bin\i386-Win32\)
INPUT(
C:\FPC\2.0.2\units\i386-linux\rtl\cprt21.o
C:\FPC\2.0.2\lib\i386-linux\crtbegin.o
C:\FPC\2.0.2\lib\i386-linux\crti.o
testthreads.o
C:\FPC\2.0.2\units\i386-linux\rtl\system.o
C:\FPC\2.0.2\units\i386-linux\rtl\objpas.o
C:\FPC\2.0.2\units\i386-linux\rtl\sysutils.o
C:\FPC\2.0.2\units\i386-linux\rtl\initc.o
C:\FPC\2.0.2\units\i386-linux\rtl\cthreads.o
C:\FPC\2.0.2\units\i386-linux\rtl\unix.o
C:\FPC\2.0.2\units\i386-linux\rtl\errors.o
C:\FPC\2.0.2\units\i386-linux\rtl\sysconst.o
C:\FPC\2.0.2\units\i386-linux\rtl\unixtype.o
C:\FPC\2.0.2\units\i386-linux\rtl\baseunix.o
C:\FPC\2.0.2\units\i386-linux\rtl\unixutil.o
C:\FPC\2.0.2\units\i386-linux\rtl\strings.o
C:\FPC\2.0.2\units\i386-linux\rtl\syscall.o
C:\FPC\2.0.2\units\i386-linux\rtl\dl.o
)
INPUT(
-ldl
-lc
)
INPUT(
C:\FPC\2.0.2\lib\i386-linux\crtend.o
C:\FPC\2.0.2\lib\i386-linux\crtn.o
)



_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: crosscompiling from win32 to i386-linux and libc linking

Dominique Leducq-2
In reply to this post by Dominique Leducq-2
Dominique Leducq a écrit :

> Hi,
>
> I have linking problems when cross-compiling from win32 to i386-linux
> and linking with libc (dynamically).
> I use FPC 2.0.2, the libs are from a Debian Sarge (glibc-2.3.6, I tried
> with glibc 2.3.2 with same results),
> cross ld is :
> ld.exe -V
> GNU ld version 2.15
>   Supported emulations:
>    elf_i386
>    i386linux
>

OK, I solved this by replacing 2.15 cross-binutils by 2.17

> I get the following errors :
> fpc -Mdelphi -Tlinux test.pas -Fl'c:\FPC\2.0.2\lib\i386-linux'
> Free Pascal Compiler version 2.0.2 [2005/11/26] for i386
> Copyright (c) 1993-2005 by Florian Klaempfl
> Target OS: Linux for i386
> Compiling test.pas
> Linking test
> C:\FPC\2.0.2\lib\i386-linux\/libdl.so: undefined reference to
> `_rtld_global@GLIBC_PRIVATE'
> C:\FPC\2.0.2\lib\i386-linux\/libc.so: undefined reference to
> `__libc_enable_secure@GLIBC_PRIVATE'
> C:\FPC\2.0.2\lib\i386-linux\/libc.so: undefined reference to
> `__libc_stack_end@GLIBC_2.1'
> C:\FPC\2.0.2\lib\i386-linux\/libdl.so: undefined reference to
> `_rtld_global_ro@GLIBC_PRIVATE'
> C:\FPC\2.0.2\lib\i386-linux\/libc.so: undefined reference to
> `_dl_out_of_memory@GLIBC_PRIVATE'
> C:\FPC\2.0.2\lib\i386-linux\/libc.so: undefined reference to
> `___tls_get_addr@GLIBC_2.3'
> C:\FPC\2.0.2\lib\i386-linux\/libc.so: undefined reference to
> `_r_debug@GLIBC_2.0'
> C:\FPC\2.0.2\lib\i386-linux\/libc.so: undefined reference to
> `_dl_argv@GLIBC_PRIVATE'
> C:\FPC\2.0.2\lib\i386-linux\/libdl.so: undefined reference to
> `_dl_rtld_di_serinfo@GLIBC_PRIVATE'
> testthreads.pas(37,1) Error: Error while linking
> Error: c:\FPC\2.0.2\bin\i386-Win32\ppc386.exe returned an error exitcode
> (normal if you did not specify a source file to be compiled)
>
>
> while
>
>  nm -D ld-linux.so.2
> 0000e6a0 T ___tls_get_addr
> 00015f1c D __libc_enable_secure
> 000101b0 W __libc_memalign
> 00015f18 D __libc_stack_end
> 0000de70 T __tls_get_addr
> 0000e610 T _dl_allocate_tls
> 0000e3f0 T _dl_allocate_tls_init
> 00015e8c D _dl_argv
> 0000e640 T _dl_deallocate_tls
> 0000c450 T _dl_debug_state
> 0000e330 T _dl_get_tls_static_info
> 0000ec60 T _dl_make_stack_executable
> 0000db30 T _dl_mcount
> 00012258 R _dl_out_of_memory
> 00006840 T _dl_rtld_di_serinfo
> 0000e1f0 T _dl_tls_setup
> 000164e4 B _r_debug
> 00016020 D _rtld_global
> 00015cc0 D _rtld_global_ro
> 000103d0 W calloc
> 0000fda0 W free
> 00000000 A GLIBC_2.0
> 00000000 A GLIBC_2.1
> 00000000 A GLIBC_2.3
> 00000000 A GLIBC_PRIVATE
> 000102f0 W malloc
> 00010320 W realloc
>
> the difference in the symbols is only the '@GLIBC...' part.
> I have no problem linking the same code on Linux, on the very same
> system the libs came from.
>
> I can link statically ( with -Xt), however.
>
> Dominique.
>
>
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal



_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal