I've solved the problem (in my case at least).
http://lists.freepascal.org/lists/fpc-pascal/2013-May/038254.html
Thanks for your suggestions Marco (and also thanks to Jonas!).
Bruce.
On Fri, May 24, 2013 at 6:27 PM, Marco van de Voort wrote:
> In our previous episode, Bruce Tulloch said:
> >
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(
Jonas Maebe wrote:
I understand this is well-intended, but please don't overdo it. The
person apologised and acknowledged what his mistake was. Adding a long
extra message on this topic does not really add anything useful to the
discussion and does not help with creating a friendly atmosphere e
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: ../
Yes, that's what thought, but why the difference between the cross
compiled squeeze/i386 case (which works) and the cross compiled
wheezy/i386 one (which does not)?
That is, both are cross builds, both are building the same code in the
same way, the only difference is the crossroot against which t
m...@rpzdesign.com wrote:
Oops,
Looks like there is an internal list coded identifier that links the
thread of emails together.
Yes, that's been in email since the earliest days- 30 years or so. Look:
-8<-
References:
<519cb0e8.1000...@rpzdesign.com> <519cb1cc.8020...@epidata.
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
In our previous episode, Bruce Tulloch said:
> This indicates libgcc is not being pulled in (the Wheezy case).
That's what I would expect yes.
My guess is that the default glibc references the gcc and it gets pulled in,
and it doesn't in the cross situation (so you have to manually add a
referenc
Hi Stephano,
I have been having a number of problems that look similar to this in
several ways.
I'm trying to chase down what's going wrong and I'll let you know what
I discover.
First up I noticed in your log that the linker reports:
/home/me/Programs/fpc/fpsrc/exported/2.7.1/rtl/linux/../unix
13 matches
Mail list logo
