For those that are interested, converting all symlinks to be relative (in
/usr/lib in the crossroot) fixes cross linking problems (i.e. when using
--sysroot with ld) when targetting Debian Wheezy or similar systems (e.g
Ubuntu, or in my case, Raspbian):
root@fermi:/usr/lib/arm-linux-gnueabihf# sym
Thanks Jonas, I think I've nailed it with your help. The linker --verbose
reports:
attempt to open
/usr/local/opt/chroot/raspbian/rootfs/usr/lib/arm-linux-gnueabihf//libdl.so
failed
attempt to open
/usr/local/opt/chroot/raspbian/rootfs/usr/lib/arm-linux-gnueabihf//libdl.a
succeeded
(/usr/local/opt
On 24 May 2013, at 13:37, Bruce Tulloch wrote:
I cannot see any reason why arm-linux-ld is trying to link this
statically
on the basis of the arguments used in ppas.sh and the contents of the
link.res based on the output of gcc in my previous email.
You can try passing --verbose to ld, mayb
So this problem is not related to cthreads per se.
I've changed the program to:
program test;
uses
Interfaces;
begin
writeln('DATE ',{$i %DATE%});
writeln('FPCTARGET ',{$i %FPCTARGET%});
writeln('FPCTARGETCPU ',{$i %FPCTARGETCPU%});
writeln('FPCTARGETOS ',{$i %FPCTARGETOS%});
writeln(
So here's what gcc reports when run on the raspbian arm target I'm
trying to cross compile for:
root@beria:/tmp# gcc -### test.c -ldl
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/4.6/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../
Not yet, but I will try this shortly -b
On Fri, May 24, 2013 at 6:47 PM, Jonas Maebe wrote:
>
> On 24 May 2013, at 07:31, Bruce Tulloch wrote:
>
>>
>> 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
>>
On 24 May 2013, at 07:31, Bruce Tulloch wrote:
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): w
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/03
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 q
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
On 23 May 2013, at 15:03, Bruce Tulloch wrote:
On Thu, May 23, 2013 at 10:50 PM, Jonas Maebe >wrote:
On 23 May 2013, at 14:32, Bruce Tulloch wrote:
On Thu, May 23, 2013 at 10:28 PM, Jonas Maebe >
**wrote:
On 23 May 2013, at 14:25, Bruce Tulloch wrote:
Do you have a libdl.so in your lib
Okay, but it is installed:
root@beria:~# apt-file search libdl.so
libc6: /lib/arm-linux-gnueabihf/libdl.so.2
libc6-dev: /usr/lib/arm-linux-gnueabihf/libdl.so
root@beria:~# apt-show-versions libc6-dev
libc6-dev/wheezy uptodate 2.13-38+rpi2
but I noticed that:
root@beria:/usr/lib/arm-linux-gnueab
On 23 May 2013, at 14:32, Bruce Tulloch wrote:
On Thu, May 23, 2013 at 10:28 PM, Jonas Maebe >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 a
Just noticed another INPUT statement also refers to dl as:
/usr/local/lib/fpc/2.7.1/units/arm-linux/rtl/dl.o
This appears ahead of the -ldl statement.
Could this be the problem? -b
On Thu, May 23, 2013 at 10:32 PM, Bruce Tulloch wrote:
> Yes, it's in the search path as:
>
> root@beria:/li
Yes, it's in the search path as:
root@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
It's referred to in an INPUT statement in link.res as:
INPUT(
-lpthread
-ldl
)
and there
On 23 May 2013, at 14:25, Bruce Tulloch wrote:
On Thu, May 23, 2013 at 10:18 PM, Jonas Maebe >wrote:
On 23 May 2013, at 14:10, Bruce Tulloch wrote:
Linking arm-test-threads
/usr/local/lib/fpc/2.7.1/
units/arm-linux/rtl/cthreads.**o: In function
`CTHREADS_$$_LOADPTHREADS$$**BOOLEAN':
cthread
Okay, so I'm not trying to link statically, not intentionally anyway.
Here's the command line from ppas.sh that produces this error:
/usr/local/opt/binutils/bin/arm-linux-ld \
--sysroot=/usr/local/opt/chroot/raspbian/rootfs \
--dynamic-linker=/lib/ld-linux-armhf.so.3 \
-s -L. -o arm-test-threads
On 23 May 2013, at 14:10, Bruce Tulloch wrote:
However, if I simply add this uses clause:
uses
cthreads;
the program compiles fine but fails when linking:
Linking arm-test-threads
/usr/local/lib/fpc/2.7.1/
units/arm-linux/rtl/cthreads.o: In function
`CTHREADS_$$_LOADPTHREADS$$BOOLEAN':
cthr
Starting with a simple test program arm-test.pas:
program test;
begin
writeln('DATE ',{$i %DATE%});
writeln('FPCTARGET ',{$i %FPCTARGET%});
writeln('FPCTARGETCPU ',{$i %FPCTARGETCPU%});
writeln('FPCTARGETOS ',{$i %FPCTARGETOS%});
writeln('FPCVERSION ',{$i %FPCVERSION%});
end.
I can cros
19 matches
Mail list logo
