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 '
C:\FPC\2.0.2\lib\i386-linux\/libc.so: undefined reference to '
C:\FPC\2.0.2\lib\i386-linux\/libc.so: undefined reference to '
C:\FPC\2.0.2\lib\i386-linux\/libdl.so: undefined reference to '
C:\FPC\2.0.2\lib\i386-linux\/libc.so: undefined reference to '
C:\FPC\2.0.2\lib\i386-linux\/libc.so: undefined reference to '
C:\FPC\2.0.2\lib\i386-linux\/libc.so: undefined reference to '
C:\FPC\2.0.2\lib\i386-linux\/libc.so: undefined reference to '
C:\FPC\2.0.2\lib\i386-linux\/libdl.so: undefined reference to '
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.

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

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.

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.

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

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.

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
)

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