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

[Bruce Tulloch]

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<fpc-pascal at lists.freepascal.org>
>> http://lists.freepascal.org/**mailman/listinfo/fpc-pascal<http://lists.freepascal.org/mailman/listinfo/fpc-pascal>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20130523/38f1cd21/attachment.html>