[fpc-pascal] CThreads problem when cross-compiling to ARM/RPi.

Bruce Tulloch pascal at causal.com
Fri May 24 07:31:31 CEST 2013


Raspbian is a Debian Wheezy derived distribution for ARMHF on
Raspberry Pi. My attempts to replicate the exactly same setup for a
Wheezy based i386 target (so I could compare with this one) ran into
problems when cross compiled and linked:

  http://lists.freepascal.org/lists/fpc-pascal/2013-May/038241.html

In that case the cross compile did not pull in libgcc but I found a
temporary hack to work around it. Perhaps they are related? They are
both Wheezy based crossroots.

The key question for my ARM cross compile is why does it report:

    /usr/local/lib/fpc/2.7.1/units/arm-linux/rtl/cthreads.o: In function
    `CTHREADS_$$_LOADPTHREADS$$BOOLEAN': cthreads.pp:
    (.text.n_cthreads_$$_loadpthreads$$boolean+0xc): warning: Using
    'dlopen' in statically linked applications requires at runtime the shared
    libraries from the glibc version used for linking

when linking. I've checked the linker script and arguments and nowhere
am I (or FPC) asking for a static link, so why is this message
reported?

What else can cause ld to attempt a static link?

Bruce.

On Thu, May 23, 2013 at 11:48 PM, Bruce Tulloch <pascal at causal.com> wrote:
> I have to pack it in for about 8 hours (I'm "down under") but I can provide
> more feedback then.
>
> By way of background, I have cross-compilation set up and working well for
> Linux i386 and Windows i385 and x86_64 targets from this x86_64 development
> system.
>
> I debootstrapped a raspbian system using qemu to add the ARM/RPi as a new
> target when I ran into this problem.
>
> The setup I've used for this target is very similar to the Linux i386 cross
> setup which works just fine. I've compared the linker arguments and link.res
> between the i386 and ARM cross builds and cannot see a difference which
> looks material to the problem.
>
> Any suggestions as to what else I can try or where else I can look for a
> solution are welcome!
>
> Thanks for all your advice so far, it's most appreciated. -b
>
>
> On Thu, May 23, 2013 at 11:34 PM, Bruce Tulloch <pascal at causal.com> wrote:
>>
>> Okay, I understand the reason for the two file locations, thanks.
>>
>> The problem occurs ONLY when cross-compiling to ARM. Native (and cross to
>> i386) is fine.
>>
>> The files I referred to are on the crossroot not the host despite
>> appearances; the crossroot is at /usr/local/opt/chroot/raspbian/rootfs but I
>> reported these files in my previous email from within a qemu enabled chroot
>> (so they looked like they were native). The machine name "beria" is the
>> chroot and "fermi" is the host.
>>
>> My apologies for the confusion.
>>
>> -b
>>
>>
>> On Thu, May 23, 2013 at 11:19 PM, Jonas Maebe <jonas.maebe at elis.ugent.be>
>> wrote:
>>>
>>>
>>> On 23 May 2013, at 15:03, Bruce Tulloch wrote:
>>>
>>>> On Thu, May 23, 2013 at 10:50 PM, Jonas Maebe
>>>> <jonas.maebe at elis.ugent.be>wrote:
>>>>
>>>>>
>>>>> On 23 May 2013, at 14:32, Bruce Tulloch wrote:
>>>>>
>>>>> On Thu, May 23, 2013 at 10:28 PM, Jonas Maebe
>>>>> <jonas.maebe at elis.ugent.be>
>>>>>>
>>>>>> **wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On 23 May 2013, at 14:25, Bruce Tulloch wrote:
>>>>>>>
>>>>>>> Do you have a libdl.so in your library search path? And what kind of
>>>>>>> reference to libdl does link.res contain?
>>>>>>>
>>>>>>> Yes, it's in the search path as:
>>>>>>
>>>>>>
>>>>>> root at beria:/lib/arm-linux-gnueabihf# ls -l libdl*
>>>>>> -rw-r--r-- 1 root root 9812 Feb 23 00:37 libdl-2.13.so
>>>>>> lrwxrwxrwx 1 root root   13 Feb 23 00:37 libdl.so.2 -> libdl-2.13.so
>>>>>>
>>>>>
>>>>> You don't have libdl.so, only libdl.so.2. The latter is for use at run
>>>>> time, the former for use at link/compile time. Install the libc-dev or
>>>>> similar package in your crossroot to get it along with other missing
>>>>> symlinks. Do not start creating those manually, it will only lead to
>>>>> errors
>>>>> and confusion down the line.
>>>>>
>>>> Okay, but it is installed:
>>>>
>>>> root at beria:~# apt-file search libdl.so
>>>> libc6: /lib/arm-linux-gnueabihf/libdl.so.2
>>>> libc6-dev: /usr/lib/arm-linux-gnueabihf/libdl.so
>>>
>>>
>>> The topic of this thread is about cross-compiling, but those are the
>>> files on the native system. Are you getting this error while cross-compiling
>>> or while compiling natively? If you are compiling natively, try compiling
>>> something with "gcc -### x.c -ldl" to see what parameters gcc passes to
>>> linker (create an empty x.c file first).
>>>
>>>
>>>> root at beria:~# apt-show-versions libc6-dev
>>>> libc6-dev/wheezy uptodate 2.13-38+rpi2
>>>>
>>>> but I noticed that:
>>>>
>>>> root at beria:/usr/lib/arm-linux-gnueabihf# ls -l libdl*
>>>> -rw-r--r-- 1 root root 9042 Feb 23 00:38 libdl.a
>>>> lrwxrwxrwx 1 root root   35 Feb 23 00:38 libdl.so ->
>>>> /lib/arm-linux-gnueabihf/libdl.so.2
>>>>
>>>> which means they're the same file.
>>>
>>>
>>> Yes, they are the same file. Why that is the case and why nevertheless
>>> need both is what I tried to explain in my previous message.
>>>
>>>
>>>
>>> Jonas
>>> _______________________________________________
>>> fpc-pascal maillist  -  fpc-pascal at lists.freepascal.org
>>> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>>
>>
>



More information about the fpc-pascal mailing list