Hallo List,

I try to crosscompile one of my projects to the arm based USB9263 from Calao Systems
(http://www.calao-systems.com/articles.php?lng=en&pg=5932)

I get the following linking error:

/usr/local/bin/ppcrossarm -CfFPA -dUSB92 -CaARMEB -CpARMV5 -darm -dFPC_ARMEL -gl -Fu../webserver -Fu../PhysMach
-Fu../divLibs/pwu-1.6.0.2-src/main/
-FL/usr/xtools/arm-unknown-linux-uclibc/arm-unknown-linux-uclibc/lib/ld-uClibc.so.0 -Fl/usr/local/xtools/arm-unknown-linux-uclibc/arm-unknown-linux-uclibc/lib/ -XParm-unknown-linux-uclibc- -Xd
-Xr/usr/local/xtools/arm-unknown-linux-uclibc/ DeviceServer.pas Free Pascal Compiler version 2.4.0rc1 [2009/12/07] for arm Copyright (c) 1993-2009 by Florian Klaempfl
Target OS: Linux for ARM
Compiling DeviceServer.pas
DeviceServer.pas(538,10) Warning: Function result does not seem to be set Assembling deviceserver
Linking DeviceServer
/usr/local/lib/fpc/2.4.0/units/arm-linux/rtl/cprt0.o: In function `_start': (.text+0x4c): undefined reference to `__libc_start_main' /usr/local/lib/fpc/2.4.0/units/arm-linux/rtl/cprt0.o: In function `_haltproc_eabi':
(.text+0x88): undefined reference to `_fini'
/usr/local/lib/fpc/2.4.0/units/arm-linux/rtl/cprt0.o: In function `_haltproc_eabi':
(.text+0x90): undefined reference to `_init'
DeviceServer.pas(609,2) Error: Error while linking DeviceServer.pas(609,2) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted

I have built my own crosscompiler with fpc 2.2.2. Here are the steps I did:

+ download the toolchain from
http://free-electrons.com/labs/tools/arm-unknown-linux-uclibc-gcc-4.3.2.tar.bz2 and uncompress it as root in /.
Then, add the cross-compiler directory to the PATH export PATH=/usr/local/xtools/arm­unknown­linux­-uclibcgnueabi/bin:$PATH

+ download a recent version of fpc
svn checkout http://svn.freepascal.org/svn/fpc/tags/release_2_4_0_rc1 ./fpc240
+ compile the compiler
patch sdl mixer to avoid error, so no sdl lib is included cd ./fpc240
vi packages/sdl/src/sdl_mixer.pas

change lines starting at 450

       {$IFNDEF DARWIN}
       5 : ( mp3 : PSMPEG );
       {$ENDIF}

with these lines, the sdl lib is removed !

       {$IFNDEF DARWIN}
       {$IFNDEF no_smpeg}
       5 : ( mp3 : PSMPEG );
       {$ENDIF}
       {$ENDIF}

make clean
make crosszipinstall CPU_TARGET=arm CROSSOPT='-CfFPA -dUSB92 -darm -dno_smpeg -dFPC_ARMEL -O- -gl'
CROSSBINDIR=/usr/local/xtools/arm-unknown-linux-uclibc/bin/ BINUTILSPREFIX=arm-unknown-linux-uclibc-

+ Installation of the binaries
cd /usr/local/
tar -xzvf /home/ubuntu/fpc240/fpc-2.4.0rc1.arm-linux.tar.gz cd /usr/local/bin
ln -s /usr/local/lib/fpc/2.4.0/ppcrossarm ppcrossarm

Compiling programs:

/usr/local/bin/ppcrossarm -CfFPA -dUSB92 -CaARMEB -CpARMV5 -darm -dFPC_ARMEL -gl -Fu../webserver -Fu../PhysMach
-Fu../divLibs/pwu-1.6.0.2-src/main/
-FL/usr/xtools/arm-unknown-linux-uclibc/arm-unknown-linux-uclibc/lib/ld-uClibc.so.0 -Fl/usr/local/xtools/arm-unknown-linux-uclibc/arm-unknown-linux-uclibc/lib/ -XParm-unknown-linux-uclibc- -Xd
-Xr/usr/local/xtools/arm-unknown-linux-uclibc/ DeviceServer.pas

Can anybody give me hints what to do or check what I did wrong. Especially the steps building the crosscompiler.
I also tried to use the -k ... with sys-root but the the linker complains that he couldn't find the dl lib. I guess I have something wrong with the pathes of the -F* parameters.

/usr/local/bin/ppcrossarm -CfFPA -dUSB92 -CaARMEB -CpARMV5 -darm -dFPC_ARMEL -gl -Fu../webserver -Fu../PhysMach
-Fu../divLibs/pwu-1.6.0.2-src/main/
-FL/usr/xtools/arm-unknown-linux-uclibc/arm-unknown-linux-uclibc/lib/ld-uClibc.so.0 -Fl/lib/ -XParm-unknown-linux-uclibc- -Xd
-Xr/usr/local/xtools/arm-unknown-linux-uclibc/ -Fi /usr/local/xtools/arm-unknown-linux-uclibc/arm-unknown-linux-uclibc/include/c++/4.3.2/ -k"--sysroot=/usr/local/xtools/arm-unknown-linux-uclibc/arm-unknown-linux-uclibc/include/c++/4.3.2/sys-root/" DeviceServer.pas
Warning: Only one source file supported, changing source file to compile from "/usr/local/xtools/arm-unknown-linux-uclibc/arm-unknown-linux-uclibc/include/c++/4.3.2/" into "DeviceServer.pas"
Free Pascal Compiler version 2.4.0rc1 [2009/12/07] for arm Copyright (c) 1993-2009 by Florian Klaempfl
Target OS: Linux for ARM
Compiling DeviceServer.pas
DeviceServer.pas(538,10) Warning: Function result does not seem to be set Assembling deviceserver
Linking DeviceServer
/usr/local/xtools/arm-unknown-linux-uclibc/bin/arm-unknown-linux-uclibc-ld: cannot find -ldl
DeviceServer.pas(609,2) Error: Error while linking DeviceServer.pas(609,2) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted

Thanks for your help
regards
Hartmut

In our previous episode, Hartmut Eilers said:

^^^^

cprt0 is afaik for libc1 systems

I have built my own crosscompiler with fpc 2.2.2. Here are the steps I did:

(very old, use something newer)

+ download the toolchain from http://free-electrons.com/labs/tools/arm-unknown-linux-uclibc-gcc-4.3.2.tar.bz2

^^^^^^^

Here you are talking uclibc, that doesn't match with the cprt0

The way the Linux compiler choose libc type iirc depends on existance of certain paths and files, which sometimes works badly in crosscompile and bi-arch situations, afaik there is no certain override mechanism.

Best is to examine the sourcecode of t_linux to see what the exact criteria are.

-Xr only passes -rpath-link to the linker. See "man ld" and search for "rpath-link" to see what this does exactly (it's a long and complicated explanation). As Marco already said, the problem above is that the compiler is not finding the uclibc files, and hence assumes glibc. Add -XR/usr/local/xtools/arm-unknown-linux-uclibc/ to also make the compiler look in the right place.

However, note that uclibc support has not been maintained since a long time, is completely untested with ARM/EABI by FPC developers, and is known not to work without manually patching the the RTL startup code in case you link against C libraries (see the thread "change default start function in cprt0.o" at http://lists.freepascal.org/lists/fpc-devel/2009-December/thread.html) . Since I didn't see a follow-up yet to the last messages in that thread, I don't know whether it works afterwards.

I have built my own crosscompiler with fpc 2.2.2.

Note that building the next release or current development trunk is always only supported when starting the compilation using the previous release (in this case: use FPC 2.2.4 to compiler 2.4.0rc1). Using a previous release might also work, but is untested and unsupported (although in case that is unlikely to have anything to do with the issues you are encountering).

Especially the steps building the crosscompiler.

Those look fine.

Even if your compilation work, your resulting binary would not run, because this would write "/usr/xtools/arm-unknown-linux-uclibc/arm- unknown-linux-uclibc/lib/ld-uClibc.so.0" as dynamic linker in your binary. Since that file is unlikely to exist on your device, it wouldn't work (although as far as I can tell from cursory inspection, the compiler completely ignores the -FL setting for Linux, which does not seem to be documented anywhere nor even mentioned in a comment).

-Fl/lib/

Why do you pass /lib as a library search path when cross-compiling?

Note this warning. It's due to the space between -Fi and /usr/local/ xtools/arm-unknown-linux-uclibc/arm-unknown-linux-uclibc/include/c++/ 4.3.2/. On the other hand, FPC cannot read C(++) include files, so for the actual compilation it does not matter.

I guess this is due to the missing -XR parameter.

Jonas

Hallo List,

thanks for your first and fast response. According to the suggestions from Marco and Jonas I try it this way:

/usr/local/bin/ppcrossarm -CfFPA -dUSB92 -CaARMEB -CpARMV5 -darm -dFPC_ARMEL -gl -Fu../webserver -Fu../PhysMach
-Fu../divLibs/pwu-1.6.0.2-src/main/
-FL/usr/xtools/arm-unknown-linux-uclibc/arm-unknown-linux-uclibc/lib/ld-uClibc.so.0 -Fl/usr/local/xtools/arm-unknown-linux-uclibc/arm-unknown-linux-uclibc/lib/ -XParm-unknown-linux-uclibc- -Xd
-Xr/usr/local/xtools/arm-unknown-linux-uclibc/
-XR/usr/local/xtools/arm-unknown-linux-uclibc/arm-unknown-linux-uclibc/sys-root/lib/ DeviceServer.pas
Free Pascal Compiler version 2.4.0rc1 [2009/12/07] for arm Copyright (c) 1993-2009 by Florian Klaempfl
Target OS: Linux for ARM
Compiling DeviceServer.pas
DeviceServer.pas(538,10) Warning: Function result does not seem to be set Assembling deviceserver
Linking DeviceServer
/usr/local/xtools/arm-unknown-linux-uclibc/bin/arm-unknown-linux-uclibc-ld: cannot find -ldl
DeviceServer.pas(609,2) Error: Error while linking DeviceServer.pas(609,2) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted

If I run the above command with strace I see:
access("/usr/local/lib/fpc/2.4.0/units/arm-linux/rtl/ucprt0.o", F_OK) = 0

so I assume that the compiler is aware of compiling for a uclibc system. therefor I tried to pass the lib path to the linker:

/usr/local/bin/ppcrossarm -CfFPA -dUSB92 -CaARMEB -CpARMV5 -darm -dFPC_ARMEL -gl -Fu../webserver -Fu../PhysMach
-Fu../divLibs/pwu-1.6.0.2-src/main/
-FL/usr/xtools/arm-unknown-linux-uclibc/arm-unknown-linux-uclibc/lib/ld-uClibc.so.0 -Fl/usr/local/xtools/arm-unknown-linux-uclibc/arm-unknown-linux-uclibc/lib/ -XParm-unknown-linux-uclibc- -Xd
-Xr/usr/local/xtools/arm-unknown-linux-uclibc/
-XR/usr/local/xtools/arm-unknown-linux-uclibc/arm-unknown-linux-uclibc/ -k"-L/usr/local/xtools/arm-unknown-linux-uclibc/arm-unknown-linux-uclibc/lib" DeviceServer.pas
Free Pascal Compiler version 2.4.0rc1 [2009/12/07] for arm Copyright (c) 1993-2009 by Florian Klaempfl
Target OS: Linux for ARM
Compiling DeviceServer.pas
DeviceServer.pas(538,10) Warning: Function result does not seem to be set Assembling deviceserver
Linking DeviceServer
/usr/local/xtools/arm-unknown-linux-uclibc/bin/arm-unknown-linux-uclibc-ld: cannot find -ldl
DeviceServer.pas(609,2) Error: Error while linking DeviceServer.pas(609,2) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted

ls
/usr/local/xtools/arm-unknown-linux-uclibc/arm-unknown-linux-uclibc/lib ldscripts libgomp.a libmudflap.la libnsl.so.0 libssp_nonshared.la libsupc++.a ld-uClibc-0.9.30.so libgomp.la libmudflap.so libpthread-0.9.30.so libssp.so libsupc++.la ld-uClibc.so.0 libgomp.so libmudflap.so.0 libpthread.so.0 libssp.so.0 libthread_db-0.9.30.so libcrypt-0.9.30.so libgomp.so.1 libmudflap.so.0.0.0 libresolv-0.9.30.so libssp.so.0.0.0 libthread_db.so.1 libcrypt.so.0 libgomp.so.1.0.0 libmudflapth.a libresolv.so.0 libstdc++.a libuClibc-0.9.30.so libc.so.0 libgomp.spec libmudflapth.la librt-0.9.30.so libstdc++.la libutil-0.9.30.so libdl-0.9.30.so libiberty.a libmudflapth.so librt.so.0 libstdc++_pic.a libutil.so.0 libdl.so.0 libm-0.9.30.so libmudflapth.so.0 libssp.a libstdc++.so
libgcc_s.so libm.so.0 libmudflapth.so.0.0.0 libssp.la libstdc++.so.6
libgcc_s.so.1 libmudflap.a libnsl-0.9.30.so libssp_nonshared.a libstdc++.so.6.0.10

From my point of view the -k"-L..." is the correct path and libdl is

located there.

Can anybody enlighten me in this ?
After one weekend fiddeling with all this I'm very confused. Thanks for your help

Hartmut

This is not specific to ARM or Linux. When you compile on a Unix platform and you want to link to a library, then normally you have to have the "development" variant of the package to which that library belongs installed. This development package will then normally install a symlink in /lib or /usr/lib called lib<name>.so, which points to the latest version of that library on your system.

When you specify to the linker that you want to link against a library, you tell the linker -l<name>, and the linker will than look for lib<name>.so in all library search paths. You only have a libdl.so. 0, so it's normal that the linker does not find it.

I don't know whether this means that you are missing some development package, whether this means that you should never explicitly link any program against libdl on uclibc systems, or something else.

Jonas

In our previous episode, Jonas Maebe said:

I don't know whether this means that you are missing some development package, whether this means that you should never explicitly link any program against libdl on uclibc systems, or something else.

The libc+dl separation might be a glibcism, try if compiling with an additional param (in OPT=" ")

-XLAdl=c

works.

Hartmut Eilers pisze:

try

-Xr/usr/local/xtools/arm-unknown-linux-uclibc/arm-unknown-linux-uclibc/lib

can you post
ls

/usr/local/xtools/arm-unknown-linux-uclibc/arm-unknown-linux-uclibc/bin

and
file link.res after
ppcrossarm -Cn -CfFPA ......

@Marco

I recompiled the crosscompiler with the OPT ... parameter the result is the same, linker complains that he couldn't find libdl

@Dariusz
I added lib to the Xr Param with no effort

ls
/usr/local/xtools/arm-unknown-linux-uclibc/arm-unknown-linux-uclibc/bin -la
insgesamt 7884
dr-xr-xr-x 2 ubuntu ubuntu 4096 2009-05-10 12:06 . dr-xr-xr-x 6 ubuntu ubuntu 4096 2009-05-10 12:06 .. -r-xr-xr-x 2 ubuntu ubuntu 703681 2009-05-10 11:48 ar -r-xr-xr-x 2 ubuntu ubuntu 1167387 2009-05-10 11:48 as -r-xr-xr-x 2 ubuntu ubuntu 260738 2009-05-10 12:06 c++ -r-xr-xr-x 2 ubuntu ubuntu 260738 2009-05-10 12:06 g++ -r-xr-xr-x 1 ubuntu ubuntu 256607 2009-05-10 12:06 gcc -r-xr-xr-x 2 ubuntu ubuntu 1170229 2009-05-10 11:48 ld -r-xr-xr-x 2 ubuntu ubuntu 685506 2009-05-10 11:48 nm -r-xr-xr-x 2 ubuntu ubuntu 876640 2009-05-10 11:48 objcopy -r-xr-xr-x 2 ubuntu ubuntu 1036007 2009-05-10 11:48 objdump -r-xr-xr-x 2 ubuntu ubuntu 703712 2009-05-10 11:48 ranlib -r-xr-xr-x 2 ubuntu ubuntu 876639 2009-05-10 11:48 strip

ls
/usr/local/xtools/arm-unknown-linux-uclibc//bin -la insgesamt 12188
dr-xr-xr-x 2 ubuntu ubuntu 4096 2009-05-10 12:13 . dr-xr-xr-x 8 ubuntu ubuntu 4096 2009-05-10 12:13 .. -r-xr-xr-x 1 ubuntu ubuntu 674923 2009-05-10 11:48 arm-unknown-linux-uclibc-addr2line
-r-xr-xr-x 2 ubuntu ubuntu 703681 2009-05-10 11:48 arm-unknown-linux-uclibc-ar -r-xr-xr-x 2 ubuntu ubuntu 1167387 2009-05-10 11:48 arm-unknown-linux-uclibc-as -r-xr-xr-x 2 ubuntu ubuntu 260738 2009-05-10 12:06 arm-unknown-linux-uclibc-c++ lrwxrwxrwx 1 ubuntu ubuntu 28 2009-05-10 12:06 arm-unknown-linux-uclibc-cc -> arm-unknown-linux-uclibc-gcc -r-xr-xr-x 1 ubuntu ubuntu 674384 2009-05-10 11:48 arm-unknown-linux-uclibc-c++filt
-r-xr-xr-x 1 ubuntu ubuntu 256638 2009-05-10 12:06 arm-unknown-linux-uclibc-cpp -r-xr-xr-x 1 ubuntu ubuntu 2190 2009-05-10 11:42 arm-unknown-linux-uclibc-ct-ng.config
-r-xr-xr-x 2 ubuntu ubuntu 260738 2009-05-10 12:06 arm-unknown-linux-uclibc-g++ -r-xr-xr-x 2 ubuntu ubuntu 256607 2009-05-10 12:06 arm-unknown-linux-uclibc-gcc -r-xr-xr-x 2 ubuntu ubuntu 256607 2009-05-10 12:06 arm-unknown-linux-uclibc-gcc-4.3.2
-r-xr-xr-x 1 ubuntu ubuntu 16579 2009-05-10 12:06 arm-unknown-linux-uclibc-gccbug
-r-xr-xr-x 1 ubuntu ubuntu 38729 2009-05-10 12:06 arm-unknown-linux-uclibc-gcov
-r-xr-xr-x 1 ubuntu ubuntu 746363 2009-05-10 11:48 arm-unknown-linux-uclibc-gprof
-r-xr-xr-x 2 ubuntu ubuntu 1170229 2009-05-10 11:48 arm-unknown-linux-uclibc-ld -r-xr-xr-x 1 ubuntu ubuntu 9868 2009-05-10 12:07 arm-unknown-linux-uclibc-ldd -r-xr-xr-x 2 ubuntu ubuntu 685506 2009-05-10 11:48 arm-unknown-linux-uclibc-nm -r-xr-xr-x 2 ubuntu ubuntu 876640 2009-05-10 11:48 arm-unknown-linux-uclibc-objcopy
-r-xr-xr-x 2 ubuntu ubuntu 1036007 2009-05-10 11:48 arm-unknown-linux-uclibc-objdump
-r-xr-xr-x 1 ubuntu ubuntu 6368 2009-05-10 12:13 arm-unknown-linux-uclibc-populate
-r-xr-xr-x 2 ubuntu ubuntu 703712 2009-05-10 11:48 arm-unknown-linux-uclibc-ranlib
-r-xr-xr-x 1 ubuntu ubuntu 315412 2009-05-10 11:48 arm-unknown-linux-uclibc-readelf
-r-xr-xr-x 1 ubuntu ubuntu 675670 2009-05-10 11:48 arm-unknown-linux-uclibc-size
-r-xr-xr-x 1 ubuntu ubuntu 674978 2009-05-10 11:48 arm-unknown-linux-uclibc-strings
-r-xr-xr-x 2 ubuntu ubuntu 876639 2009-05-10 11:48 arm-unknown-linux-uclibc-strip

cat link.res
SEARCH_DIR(/home/ubuntu/OpenLabTools/webserver/)
SEARCH_DIR(/home/ubuntu/OpenLabTools/PhysMach/)
SEARCH_DIR(/home/ubuntu/OpenLabTools/divLibs/pwu-1.6.0.2-src/main/) SEARCH_DIR(/usr/local/lib/fpc/2.4.0/units/arm-linux/rtl/) SEARCH_DIR(/usr/local/lib/fpc/2.4.0/)
INPUT(
/usr/local/lib/fpc/2.4.0/units/arm-linux/rtl/ucprt0.o DeviceServer.o
/usr/local/lib/fpc/2.4.0/units/arm-linux/rtl/system.o /usr/local/lib/fpc/2.4.0/units/arm-linux/rtl/lineinfo.o /usr/local/lib/fpc/2.4.0/units/arm-linux/rtl/exeinfo.o /usr/local/lib/fpc/2.4.0/units/arm-linux/rtl/strings.o /usr/local/lib/fpc/2.4.0/units/arm-linux/rtl/objpas.o /usr/local/lib/fpc/2.4.0/units/arm-linux/rtl/cthreads.o /home/ubuntu/OpenLabTools/PhysMach/PhysMach.o
/home/ubuntu/OpenLabTools/webserver/webserver.o
telnetserver.o
/usr/local/lib/fpc/2.4.0/units/arm-linux/rtl/classes.o /usr/local/lib/fpc/2.4.0/units/arm-linux/rtl/crt.o /usr/local/lib/fpc/2.4.0/units/arm-linux/rtl/baseunix.o /usr/local/lib/fpc/2.4.0/units/arm-linux/rtl/unix.o /usr/local/lib/fpc/2.4.0/units/arm-linux/rtl/unixtype.o /usr/local/lib/fpc/2.4.0/units/arm-linux/rtl/initc.o /usr/local/lib/fpc/2.4.0/units/arm-linux/rtl/dl.o
/usr/local/lib/fpc/2.4.0/units/arm-linux/rtl/unixutil.o /usr/local/lib/fpc/2.4.0/units/arm-linux/rtl/syscall.o /usr/local/lib/fpc/2.4.0/units/arm-linux/rtl/ctypes.o /usr/local/lib/fpc/2.4.0/units/arm-linux/rtl/linux.o /home/ubuntu/OpenLabTools/PhysMach/dil_io_access.o /home/ubuntu/OpenLabTools/PhysMach/lp_io_access.o
/home/ubuntu/OpenLabTools/PhysMach/pio_io_access.o /home/ubuntu/OpenLabTools/PhysMach/joy_io_access.o /home/ubuntu/OpenLabTools/PhysMach/rnd_io_access.o /home/ubuntu/OpenLabTools/PhysMach/http_io_access.o /home/ubuntu/OpenLabTools/PhysMach/funk_io_access.o /home/ubuntu/OpenLabTools/PhysMach/exec_io_access.o /usr/local/lib/fpc/2.4.0/units/arm-linux/rtl/sysutils.o /home/ubuntu/OpenLabTools/PhysMach/CommonHelper.o
/home/ubuntu/OpenLabTools/divLibs/pwu-1.6.0.2-src/main/http.o /usr/local/lib/fpc/2.4.0/units/arm-linux/rtl/errors.o /usr/local/lib/fpc/2.4.0/units/arm-linux/rtl/sysconst.o /home/ubuntu/OpenLabTools/divLibs/pwu-1.6.0.2-src/main/hostname.o /usr/local/lib/fpc/2.4.0/units/arm-linux/rtl/sockets.o /home/ubuntu/OpenLabTools/divLibs/pwu-1.6.0.2-src/main/substrings.o /home/ubuntu/OpenLabTools/divLibs/pwu-1.6.0.2-src/main/pwutypes.o /usr/local/lib/fpc/2.4.0/units/arm-linux/rtl/termio.o /home/ubuntu/OpenLabTools/webserver/inetaux.o
/usr/local/lib/fpc/2.4.0/units/arm-linux/rtl/dos.o /usr/local/lib/fpc/2.4.0/units/arm-linux/rtl/types.o /usr/local/lib/fpc/2.4.0/units/arm-linux/rtl/typinfo.o /usr/local/lib/fpc/2.4.0/units/arm-linux/rtl/rtlconsts.o )
INPUT(
-ldl
)
GROUP(
-lc
)
ENTRY(_start)
SECTIONS
{
PROVIDE (__executable_start = 0x010000); . = 0x010000 + SIZEOF_HEADERS;
.interp : { *(.interp) }
.hash : { *(.hash) }
.dynsym : { *(.dynsym) }
.dynstr : { *(.dynstr) }
.gnu.version : { *(.gnu.version) }
.gnu.version_d : { *(.gnu.version_d) }
.gnu.version_r : { *(.gnu.version_r) }
.rel.dyn :
{
*(.rel.init)
*(.rel.text .rel.text.* .rel.gnu.linkonce.t.*)
*(.rel.fini)
*(.rel.rodata .rel.rodata.* .rel.gnu.linkonce.r.*) *(.rel.data.rel.ro*)
*(.rel.data .rel.data.* .rel.gnu.linkonce.d.*)
*(.rel.tdata .rel.tdata.* .rel.gnu.linkonce.td.*)
*(.rel.tbss .rel.tbss.* .rel.gnu.linkonce.tb.*)
*(.rel.got)
*(.rel.bss .rel.bss.* .rel.gnu.linkonce.b.*)
}
.rela.dyn :
{
*(.rela.init)
*(.rela.text .rela.text.* .rela.gnu.linkonce.t.*)
*(.rela.fini)
*(.rela.rodata .rela.rodata.* .rela.gnu.linkonce.r.*) *(.rela.data .rela.data.* .rela.gnu.linkonce.d.*)
*(.rela.tdata .rela.tdata.* .rela.gnu.linkonce.td.*) *(.rela.tbss .rela.tbss.* .rela.gnu.linkonce.tb.*) *(.rela.got)
*(.rela.bss .rela.bss.* .rela.gnu.linkonce.b.*)
}
.rel.plt : { *(.rel.plt) }
.rela.plt : { *(.rela.plt) }
.init :
{
KEEP (*(.init))
} =0x90909090
.plt : { *(.plt) }
.text :
{
*(.text .stub .text.* .gnu.linkonce.t.*)
KEEP (*(.text.*personality*))
*(.gnu.warning)
} =0x90909090
.fini :
{
KEEP (*(.fini))
} =0x90909090

  PROVIDE (_etext = .);
  .rodata         :
  {
    *(.rodata .rodata.* .gnu.linkonce.r.*)
  }
  . = ALIGN (0x1000) - ((0x1000 - .) & (0x1000 - 1));
  .dynamic        : { *(.dynamic) }
  .got            : { *(.got) }
  .got.plt        : { *(.got.plt) }
  .data           :
  {
    *(.data .data.* .gnu.linkonce.d.*)
    KEEP (*(.fpc .fpc.n_version .fpc.n_links))
    KEEP (*(.gnu.linkonce.d.*personality*))
  }
  PROVIDE (_edata = .);
  PROVIDE (edata = .);
  .threadvar : { *(.threadvar .threadvar.* .gnu.linkonce.tv.*) }
  __bss_start = .;
  .bss            :
  {
   *(.dynbss)
   *(.bss .bss.* .gnu.linkonce.b.*)
   *(COMMON)
   . = ALIGN(32 / 8);
  }
  . = ALIGN(32 / 8);
  PROVIDE (_end = .);
  PROVIDE (end = .);
  .stab          0 : { *(.stab) }
  .stabstr       0 : { *(.stabstr) }

}

I'm trying hard for 5 days now and I'm really frustrated, can anybody give me advice which toolchain may work or how my error can be resolved?

The toolchain I use is from free electron an embedded company which uses this toolchain to build kernels for the USB9263. From my point of view it must be possible to link against this toolchain.

Thank you for your help
regards
Hartmut

It's apparently "free electrons", not free electron. And they distribute a bunch of makefiles. And as far as I can tell from the description, it's just a bunch of scripts to build (and possibly install) a toolchain. I think that you simply installed it wrongly, so you only have the libraries required for running but not an environment required for compiling.

Have you tried compiling a C program that links against libdl with the toolchain you installed? I guess that will fail in exactly the same way.

Jonas

Hallo,

Sorry for the typo.
I installed the toolchain! they refer to and use in their cross compiling kernel howto at: "http://free-electrons.com/doc/kernel-cross-compiling-lab.pdf"

"Otherwise, download the toolchain from http://freeelectrons. com/labs/tools/arm-unknown-linux-uclibc-gcc-
4.3.2.tar.bz2 and uncompress it as root in /. Then, add the crosscompiler directory to the PATH as shown above."

Have you tried compiling a C program that links against libdl with the toolchain you installed? I guess that will fail in exactly the same way.

No I haven't done that, but I will do, can you give me a hint what I should try to crosscompile?

Thanks and regards
Hartmut

Hartmut Eilers pisze:

try
  omit -XP

-Xr/usr/local/xtools/arm-unknown-linux-uclibc/arm-unknown-linux-uclibc/ lib or

-XParm-unknown-linux-uclibc-
-Xr/usr/local/xtools/arm-unknown-linux-uclibc/lib
-XR/usr/local/xtools/arm-unknown-linux-uclibc/

or
-XP/usr/local/xtools/arm-unknown-linux-uclibc/arm-unknown-linux-uclibc/bin -Xr/usr/local/xtools/arm-unknown-linux-uclibc/arm-unknown-linux-uclibc/lib -XR/usr/local/xtools/arm-unknown-linux-uclibc/arm-unknown-linux-uclibc/

my params:
-XP/home/darek2008/fpcarm/arm-linux-uclibc/bin/
-Xr/home/darek2008/fpcarm/arm-linux-uclibc/lib
-XR/home/darek2008/fpcarm/arm-linux-uclibc/
-darm
-CfSOFT
-CaEABI
-Tlinux

after compile with -Cn param
make linking by hand

.../bin/ld --verbose link.res
add softlink libdl.so to libdl.so.0

add softlink libdl.so to libdl.so.0

I have purposely not suggested this because this will either a) result in other problems
b) work until the next library for which no .so link is missing is required (most of the above libraries don't have a .so link).

That's why I suggested to look into the way the cross-compilation toolkit was installed, because the above setup is almost certainly intended for installation on the actual device, rather than for a compilation environment (in which case who know how many more things are missing, and we can keep mailing forever in this thread for no good reason).

Jonas

Hartmut Eilers wrote

No I haven't done that, but I will do, can you give me a hint what I should try to crosscompile?

A "hello world" program compiled using something like

arm-unknown-linux-uclib-gcc -o hello hello.c -ldl

is enough. And it will probably fail with the same linker error.

Jonas

Jonas Maebe pisze:

Yes, You have right
I download mentioned toolchain and try to compile simple program as i notice libdl.so exists, but in other path ( its /sys-root/usr/lib)

I combine several directives and at last linker pass through first phase -XP../xtools/arm-unknown-linux-uclibc/arm-unknown-linux-uclibc/bin/ -XR.../xtools/arm-unknown-linux-uclibc/arm-unknown-linux-uclibc/ -Fl.../xtools/arm-unknown-linux-uclibc/arm-unknown-linux-uclibc/sys-root/usr/lib

no others Xr, k,
I also not modify $PATH

By the way:
when XR path is set then XP should be default, but its not FPC search arm-linux-as
maybe better search also "as" in <XR path>/bin/as

Dariusz Mazur wrote

By the way: when XR path is set then XP should be default, but its not

-XP is set by /etc/fpc.cfg if the source cpu is different from the target CPU, and if the source and target OS are not both Darwin (because on Mac OS X, the default as/ld can assemble/link for all supported architectures). -XR has nothing to do with the naming of the assembler/linker.

FPC search arm-linux-as maybe better search also "as" in <XR path>/bin/as

No, that would cause confusion. If you want the compiler to use as/ld there, then use -XP -FD<XR path>/bin (-XP without anything else will set the prefix to "nothing").

Jonas

Jonas Maebe pisze:

-XR is need to resolve part to uclibc or others, FPC is looking <XR>/lib/uclibc.o
then FPC can assume that -XP is equal <XR>/bin

that not solve problem.
Its not for me, I pass through crosscompiling, but I want to make it simpler,
FPC can make some test to achieve the same result as with full directives (I use only two, but one should be enough) but if You think its bad way, no problem

-XP defines the prefix for the binutils utility names, such as "arm- linux-gnueabi-" (in order to generate utility names such as arm-linux- gnueabi-as). The -FD parameter is what specifies the location of the binutils. Additionally, setting the binutils directory like that is not necessarily correct. E.g., on Mac OS X that would be wrong in most cases, because the cross-compiling libraries are often in a completely different place than the utilities.

You can of course then add a special case for Mac OS X, but this will then make things confusing for people using multiple platforms (and complicate code and/or configuration files).

Adding "intelligence" like that to a compiler in the long run almost always makes things more complex, because
a) people /will/ introduce bugs when modifying the compiler later on, because they forgot or didn't know about these indirect effects. It makes it almost impossible to modify the compiler in the long run without changing/breaking some previous behaviour. b) it requires special code to correctly handle the case when people specify both -XR and -FD parameters, and possibly different behaviour depending on the order in which the -XR and -FD parameter are passed

Jonas

In our previous episode, Dariusz Mazur said:

Its not for me, I pass through crosscompiling, but I want to make it simpler,

As this thread clearly demonstrates, the problem with crosscompiling is understand what happens, and diagnose problems. Not typing when adding parameters.

On the contrary, hidden logic can make the process less clear, which again can be seen in this thread with the logic to decide the libc type (glibc1,glibc2,uclibc) on Linux.

2009/12/9 Marco van de Voort :

I can't agree more. People should read the buildfaq.

Henry

Hallo Henry,

you're absolutely right, but it's easy to read over the one important sentence in the whole buildfaq. I've read it several times and missed all the time the essential stuff. Thanks to all helping me.
Since crosscompiling is a long runner on my list and I found a lot of totally outdated information ( especially for ARM ) I have compiled what I have did to get it running. Special thanks to Daruisz and Jonas for their help and patience.
see:
http://www.eilers.net/index.php?option=com_content&view=article&id=78&Itemid=55

regards Hartmut