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
While trying to debug my ARM cross-compile problems (in another email
thread) I decided to replicate the cross-compiler setup to i386 (to
compare it for clues) but I've run into another problem with x86_64 ->
i386 cross compiling which seems related to this thread.
My cross built fpc 2.7.1 works j
Oops,
Looks like there is an internal list coded identifier that links the
thread of emails together.
The moral of the story is to create a completely new email to start
another discussion thread
and stay away from "Reply" button for convenience.
Sorry about the hijacking, it was not intend
Is it just me or is this Fedora stuff hijacking the Android Galaxy S4 thread?
If it is not a problem of my mail client, PLEASE stop this sh!t.
R.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc
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
2013/5/23 Reinier Olislagers
> On 23-5-2013 3:11, silvioprog wrote:
> > How to get the error code of a data base error? I'm using the
> > PostgreSQL.
>
> You can catch db specific errors (descendends of EDatabaseError IIRC) in
> an exception - the postgresql descendent was extended with more
> pr
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
Yes, you may have built the rpms on the platform, but where was the
ultimate destination for the executables
after you RAN the RPM to install the program?
It seems that Fedora 18 unified /bin -> /usr->bin using symbolic links
and so the compiler is not ready to run
on a system where it install
On 23 May 2013, at 07:38, Bruce Tulloch wrote:
despite the fact the ld.so configuration file:
/usr/local/opt/chroot/raspbian/rootfs/etc/ld.so.conf.d/arm-linux-
gnueabihf.conf
specifies both paths as:
# Multiarch support
/lib/arm-linux-gnueabihf
/usr/lib/arm-linux-gnueabihf
For the record
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
On 23 May 2013, at 14:03, Bruce Tulloch wrote:
So it looks like -XR is not the solution for cross-compiling, at
least in
my case.
The compiler option I used:
-XR/usr/local/opt/chroot/raspbian/rootfs
seems to break when the linker encounters a linker script that
specifies a
new path for t
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
So it looks like -XR is not the solution for cross-compiling, at least in
my case.
The compiler option I used:
-XR/usr/local/opt/chroot/raspbian/rootfs
seems to break when the linker encounters a linker script that specifies a
new path for the actual library object required; these generated path
On 23-5-2013 13:46, Michael Van Canneyt wrote:
> On Thu, 23 May 2013, Reinier Olislagers wrote:
>> On 23-5-2013 13:18, Michael Van Canneyt wrote:
> Hm. Yes, we should move it for the time being.
> The original idea was that each package would have its own documentation
> included.
> fpmake can hand
On Thu, 23 May 2013, Reinier Olislagers wrote:
On 23-5-2013 13:18, Michael Van Canneyt wrote:
On Thu, 23 May 2013, Reinier Olislagers wrote:
Noticed that fcl-res has documentation in an XML subfolder of
$(fpcdir)\packages\fcl-res
Shouldn't these be moved into the general fpcdocs repository
On 23-5-2013 13:18, Michael Van Canneyt wrote:
> On Thu, 23 May 2013, Reinier Olislagers wrote:
>
>> Noticed that fcl-res has documentation in an XML subfolder of
>> $(fpcdir)\packages\fcl-res
>>
>> Shouldn't these be moved into the general fpcdocs repository (and
>> generated as part of the fcl d
On Thu, 23 May 2013, Reinier Olislagers wrote:
Noticed that fcl-res has documentation in an XML subfolder of
$(fpcdir)\packages\fcl-res
Shouldn't these be moved into the general fpcdocs repository (and
generated as part of the fcl docs)?
(I know that not all xml files will apply to all platfo
Noticed that fcl-res has documentation in an XML subfolder of
$(fpcdir)\packages\fcl-res
Shouldn't these be moved into the general fpcdocs repository (and
generated as part of the fcl docs)?
(I know that not all xml files will apply to all platforms; IMO it's
easier here to indicate some doc is sp
> "m...@rpzdesign.com" hat am 22. Mai 2013 um 17:18
> geschrieben:
>
>
> Anybody successful putting Freepascal 2.6.2 / Lazarus 1.0.8 on Fedora 18.
I built successfully the 64bit rpms on a FC 18 64bit and had no such problems.
Mattias
___
fpc-pascal ma
On 5/22/13, m...@rpzdesign.com wrote:
> Which package did you download? (Source package or other?)
fpc-2.6.2.i386-linux.tar
E.g. form http://freepascal.org/down/i386/linux-netherlands.var
Bart
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.
27 matches
Mail list logo
