Re: [fpc-pascal] cthreads
Sven Barth wrote: On 26.07.2014 19:50, leledumbo wrote: Because then all apps are linked to it, also the ones that don't need threads. Same for clocale and cwstrings. If the widestring manager could be made by ourselves, is it possible for thread manager as well? Principiall yes, but the problem here would be external code that the program links to. E.g. Wine did something like this some time ago (before they switched to pthreads) and needed to simulate some structures so that libc switches to multithreaded mode... So if we have Pascal only code (like the compiler) this would work without big problems (if someone implements it of course ;) ), but if you have 3rd party code not written in FPC then problems might arise... On the other hand, if somebody's linking in alien code then he should make himself aware of aware of the prerequisites, particularly since the threads are more likely to be in the main program (i.e. stuff that he's written) than in the library he's pulling in. Going back to something less labour intensive, would it be possible to have s directive which has the effect that if a procedure isn't eliminated by smartlinking then the linker should warn if a specific library hasn't been linked? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] cthreads
In our previous episode, leledumbo said: Because then all apps are linked to it, also the ones that don't need threads. Same for clocale and cwstrings. If the widestring manager could be made by ourselves, is it possible for thread manager as well? You could make an own threadmanager in theory. I have some doubts about the usability and practicality though. If it ever emerges I think it will remain for specific cases, not a general replacement. The difference with the unicode manager is that you per definition need OS support for the general threadmanager case. With unicode you have the choice to go via the OS (and be light on bulky tables in every binary) or implement it yourself based on the liberally licensed Unicode consortium's tables. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] cthreads
In our previous episode, Mark Morgan Lloyd said: Going back to something less labour intensive, would it be possible to have s directive which has the effect that if a procedure isn't eliminated by smartlinking then the linker should warn if a specific library hasn't been linked? ELF binaries generally don't require to associate a symbol with a library name to link, like on Windows. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] cthreads
On 27.07.2014 11:39, Mark Morgan Lloyd wrote: Sven Barth wrote: On 26.07.2014 19:50, leledumbo wrote: Because then all apps are linked to it, also the ones that don't need threads. Same for clocale and cwstrings. If the widestring manager could be made by ourselves, is it possible for thread manager as well? Principiall yes, but the problem here would be external code that the program links to. E.g. Wine did something like this some time ago (before they switched to pthreads) and needed to simulate some structures so that libc switches to multithreaded mode... So if we have Pascal only code (like the compiler) this would work without big problems (if someone implements it of course ;) ), but if you have 3rd party code not written in FPC then problems might arise... On the other hand, if somebody's linking in alien code then he should make himself aware of aware of the prerequisites, particularly since the threads are more likely to be in the main program (i.e. stuff that he's written) than in the library he's pulling in. That's not true. E.g. the Qt libraries happily create threads for various background stuffs. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] cthreads
On Sun, Jul 27, 2014 at 02:39:58PM +0200, Sven Barth wrote: On 27.07.2014 11:39, Mark Morgan Lloyd wrote: Sven Barth wrote: On 26.07.2014 19:50, leledumbo wrote: Because then all apps are linked to it, also the ones that don't need threads. Same for clocale and cwstrings. If the widestring manager could be made by ourselves, is it possible for thread manager as well? Principiall yes, but the problem here would be external code that the program links to. E.g. Wine did something like this some time ago (before they switched to pthreads) and needed to simulate some structures so that libc switches to multithreaded mode... So if we have Pascal only code (like the compiler) this would work without big problems (if someone implements it of course ;) ), but if you have 3rd party code not written in FPC then problems might arise... On the other hand, if somebody's linking in alien code then he should make himself aware of aware of the prerequisites, particularly since the threads are more likely to be in the main program (i.e. stuff that he's written) than in the library he's pulling in. That's not true. E.g. the Qt libraries happily create threads for various background stuffs. Ha, I had a library that started a thread and it took me ages to figure out why my pascal program was crashing on callbacks from external threads. I had to start a dummy thread right at the start of the program, even though I included cthreads. Not a good experience all in all. Henry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] cthreads
On 27.07.2014 17:01, Henry Vermaak wrote: On Sun, Jul 27, 2014 at 02:39:58PM +0200, Sven Barth wrote: On 27.07.2014 11:39, Mark Morgan Lloyd wrote: Sven Barth wrote: On 26.07.2014 19:50, leledumbo wrote: Because then all apps are linked to it, also the ones that don't need threads. Same for clocale and cwstrings. If the widestring manager could be made by ourselves, is it possible for thread manager as well? Principiall yes, but the problem here would be external code that the program links to. E.g. Wine did something like this some time ago (before they switched to pthreads) and needed to simulate some structures so that libc switches to multithreaded mode... So if we have Pascal only code (like the compiler) this would work without big problems (if someone implements it of course ;) ), but if you have 3rd party code not written in FPC then problems might arise... On the other hand, if somebody's linking in alien code then he should make himself aware of aware of the prerequisites, particularly since the threads are more likely to be in the main program (i.e. stuff that he's written) than in the library he's pulling in. That's not true. E.g. the Qt libraries happily create threads for various background stuffs. Ha, I had a library that started a thread and it took me ages to figure out why my pascal program was crashing on callbacks from external threads. I had to start a dummy thread right at the start of the program, even though I included cthreads. Not a good experience all in all. Yes, the FPC RTL is normally running in singlethreaded mode and at least one FPC thread (besides the main one) needs to be started to switch it in multithreaded mode. I thought that we had some improvements there at least in 2.7.1, but I'd need to check that again. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] cthreads
Because then all apps are linked to it, also the ones that don't need threads. Same for clocale and cwstrings. If the widestring manager could be made by ourselves, is it possible for thread manager as well? -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/cthreads-tp5719795p5719804.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] cthreads
On 26.07.2014 19:50, leledumbo wrote: Because then all apps are linked to it, also the ones that don't need threads. Same for clocale and cwstrings. If the widestring manager could be made by ourselves, is it possible for thread manager as well? Principiall yes, but the problem here would be external code that the program links to. E.g. Wine did something like this some time ago (before they switched to pthreads) and needed to simulate some structures so that libc switches to multithreaded mode... So if we have Pascal only code (like the compiler) this would work without big problems (if someone implements it of course ;) ), but if you have 3rd party code not written in FPC then problems might arise... Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] cthreads
I was asked why a threaded application compiles on Linux without uses cthreads but it does not work. cthreads must _always_ be added to uses section. I had no answer to that. IMO such errors should be trapped at compile-time, not at run-time. Could it be fixed somehow? Many people experience the same run-time error about too many concurrent threads. They must search the net and ask questions while (I guess) the problem could be solved by forcing a compilation error. Juha ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] cthreads
On Fri, 25 Jul 2014, Juha Manninen wrote: I was asked why a threaded application compiles on Linux without uses cthreads but it does not work. cthreads must _always_ be added to uses section. I had no answer to that. IMO such errors should be trapped at compile-time, not at run-time. Could it be fixed somehow? No, because there is no way to detect that threads are actually used in the program. The TThread class is a class like any other, with no special treatment. It is in the classes unit. The fact that it is there does not mean it is actually used. That goes for a lot of code. You don't even need to use the TThread class; you can perfectly program threads with just the threadmanager. In retrospect, Borland made an error declaring tthread in the classes unit. It should have been put in a separate unit. That would have made detection easier. Many people experience the same run-time error about too many concurrent threads. They must search the net and ask questions while (I guess) the problem could be solved by forcing a compilation error. Or - for once in their life - people could read the documentation. http://www.freepascal.org/docs-html/prog/progse43.html It is remarked TWICE that you must include the cthreads unit. I will add a remark in the classes unit TThread class documentation, to make it even more obvious. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] cthreads
Michael Van Canneyt wrote: On Fri, 25 Jul 2014, Juha Manninen wrote: I was asked why a threaded application compiles on Linux without uses cthreads but it does not work. cthreads must _always_ be added to uses section. I had no answer to that. IMO such errors should be trapped at compile-time, not at run-time. Could it be fixed somehow? No, because there is no way to detect that threads are actually used in the program. I will add a remark in the classes unit TThread class documentation, to make it even more obvious. Is there scope for improving the error message? Is there a scenario in which a program that sometimes uses threads (e.g. if it realises it's being asked to do a big job which can be parallelised) could start without giving the error message? This would make the situation more serious, since it would require that the programmer did some /real/ testing before shipping his code :-) -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] cthreads
On Fri, 25 Jul 2014, Mark Morgan Lloyd wrote: Michael Van Canneyt wrote: On Fri, 25 Jul 2014, Juha Manninen wrote: I was asked why a threaded application compiles on Linux without uses cthreads but it does not work. cthreads must _always_ be added to uses section. I had no answer to that. IMO such errors should be trapped at compile-time, not at run-time. Could it be fixed somehow? No, because there is no way to detect that threads are actually used in the program. I will add a remark in the classes unit TThread class documentation, to make it even more obvious. Is there scope for improving the error message? Is there a scenario in which a program that sometimes uses threads (e.g. if it realises it's being asked to do a big job which can be parallelised) could start without giving the error message? This would make the situation more serious, since it would require that the programmer did some /real/ testing before shipping his code :-) Not sure what you mean. The error only appears if you call a function that relies on the threading manager, never at the start of the program. It's slightly more complicated than this, but it boils down to that. So the fact that the program started doesn't mean there won't be an error further down the line. But that is IMHO no different from many other programming errors, such as trying to save preferences in a file in a directory that doesn't exist. You should always test all cases. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] cthreads
The same question that I posted on bugtracker: Linux, BSD, Unix, has another threaddriver than cthreads? If no, why not make cthreads unit the default threaddriver for Unix? 2014-07-25 7:33 GMT-03:00 Michael Van Canneyt mich...@freepascal.org: On Fri, 25 Jul 2014, Mark Morgan Lloyd wrote: Michael Van Canneyt wrote: On Fri, 25 Jul 2014, Juha Manninen wrote: I was asked why a threaded application compiles on Linux without uses cthreads but it does not work. cthreads must _always_ be added to uses section. I had no answer to that. IMO such errors should be trapped at compile-time, not at run-time. Could it be fixed somehow? No, because there is no way to detect that threads are actually used in the program. I will add a remark in the classes unit TThread class documentation, to make it even more obvious. Is there scope for improving the error message? Is there a scenario in which a program that sometimes uses threads (e.g. if it realises it's being asked to do a big job which can be parallelised) could start without giving the error message? This would make the situation more serious, since it would require that the programmer did some /real/ testing before shipping his code :-) Not sure what you mean. The error only appears if you call a function that relies on the threading manager, never at the start of the program. It's slightly more complicated than this, but it boils down to that. So the fact that the program started doesn't mean there won't be an error further down the line. But that is IMHO no different from many other programming errors, such as trying to save preferences in a file in a directory that doesn't exist. You should always test all cases. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal -- The best regards, Fabio Luis Girardi PascalSCADA Project http://sourceforge.net/projects/pascalscada http://www.pascalscada.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] cthreads
On 07/25/2014 03:04 PM, Fabio Luis Girardi wrote: The same question that I posted on bugtracker: Linux, BSD, Unix, has another threaddriver than cthreads? If no, why not make cthreads unit the default threaddriver for Unix? I read somewhere some time ago that the main reason for this was that FPC has no dependency to libc under normal circumstances. Making cthreads the default thread manager would thus add a dependency to libc. -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] cthreads
2014-07-25 10:10 GMT-03:00 Ewald ew...@yellowcouch.org: On 07/25/2014 03:04 PM, Fabio Luis Girardi wrote: The same question that I posted on bugtracker: Linux, BSD, Unix, has another threaddriver than cthreads? If no, why not make cthreads unit the default threaddriver for Unix? I read somewhere some time ago that the main reason for this was that FPC has no dependency to libc under normal circumstances. Making cthreads the default thread manager would thus add a dependency to libc. -- Ewald -- The best regards, Fabio Luis Girardi PascalSCADA Project http://sourceforge.net/projects/pascalscada http://www.pascalscada.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] cthreads
Am 25.07.2014 15:11 schrieb Ewald ew...@yellowcouch.org: On 07/25/2014 03:04 PM, Fabio Luis Girardi wrote: The same question that I posted on bugtracker: Linux, BSD, Unix, has another threaddriver than cthreads? If no, why not make cthreads unit the default threaddriver for Unix? I read somewhere some time ago that the main reason for this was that FPC has no dependency to libc under normal circumstances. Making cthreads the default thread manager would thus add a dependency to libc. This is correct. It's the same reason for the widestring manager provided by cwstrings unit. Though 2.7.1 now has a Pascal only widestring manager as well. :) Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] cthreads
In our previous episode, Fabio Luis Girardi said: The same question that I posted on bugtracker: Linux, BSD, Unix, has another threaddriver than cthreads? No. If no, why not make cthreads unit the default threaddriver for Unix? Because then all apps are linked to it, also the ones that don't need threads. Same for clocale and cwstrings. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] cthreads and cSemaphoreTimedWait
Hi, the TThreadManager class has only the SemaphoreWait procedure and it lacks the SemaphoreTimedWait function. But in the cthreads unit exists a cSemaphoreTimedWait implementation. Is there a problem with that function and didn't included in the TThreadManager class ? I have some existed code to port and it uses semaphores. I would like to avoid change it too much. regards, -- Dimitrios Chr. Ioannidis http://www.nephelae.eu signature.asc Description: This is a digitally signed message part ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] cthreads and cSemaphoreTimedWait
On Tue, 11 Feb 2014, Dimitrios Chr. Ioannidis wrote: Hi, the TThreadManager class has only the SemaphoreWait procedure and it lacks the SemaphoreTimedWait function. But in the cthreads unit exists a cSemaphoreTimedWait implementation. Is there a problem with that function and didn't included in the TThreadManager class ? No particular problem. I have some existed code to port and it uses semaphores. I would like to avoid change it too much. I guess we can add it. In fact, it makes no sense to have a function without timeout, you can always specify -1 or some such value if you don't want a timeout. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CThreads problem when cross-compiling to ARM/RPi.
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): 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? I don't know. Have you already tried with gcc? Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CThreads problem when cross-compiling to ARM/RPi.
Not yet, but I will try this shortly -b On Fri, May 24, 2013 at 6:47 PM, Jonas Maebe jonas.ma...@elis.ugent.be 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 `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? I don't know. Have you already tried with gcc? Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CThreads problem when cross-compiling to ARM/RPi.
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: ../src/configure -v --with-pkgversion='Debian 4.6.3-14+rpi1' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --disable-sjlj-exceptions --with-arch=armv6 --with-fpu=vfp --with-float=hard --enable-checking=release --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf Thread model: posix gcc version 4.6.3 (Debian 4.6.3-14+rpi1) COLLECT_GCC_OPTIONS='-march=armv6' '-mfloat-abi=hard' '-mfpu=vfp' /usr/lib/gcc/arm-linux-gnueabihf/4.6/cc1 -quiet -imultilib . -imultiarch arm-linux-gnueabihf test.c -quiet -dumpbase test.c -march=armv6 -mfloat-abi=hard -mfpu=vfp -auxbase test -o /tmp/ccTepGGB.s COLLECT_GCC_OPTIONS='-march=armv6' '-mfloat-abi=hard' '-mfpu=vfp' as -march=armv6 -mfloat-abi=hard -mfpu=vfp -meabi=5 -o /tmp/ccUcKZI2.o /tmp/ccTepGGB.s COMPILER_PATH=/usr/lib/gcc/arm-linux-gnueabihf/4.6/:/usr/lib/gcc/arm-linux-gnueabihf/4.6/:/usr/lib/gcc/arm-linux-gnueabihf/:/usr/lib/gcc/arm-linux-gnueabihf/4.6/:/usr/lib/gcc/arm-linux-gnueabihf/ LIBRARY_PATH=/usr/lib/gcc/arm-linux-gnueabihf/4.6/:/usr/lib/gcc/arm-linux-gnueabihf/4.6/../../../arm-linux-gnueabihf/:/usr/lib/gcc/arm-linux-gnueabihf/4.6/../../../:/lib/arm-linux-gnueabihf/:/lib/:/usr/lib/arm-linux-gnueabihf/:/usr/lib/ COLLECT_GCC_OPTIONS='-march=armv6' '-mfloat-abi=hard' '-mfpu=vfp' /usr/lib/gcc/arm-linux-gnueabihf/4.6/collect2 --sysroot=/ --build-id --no-add-needed --eh-frame-hdr -dynamic-linker /lib/ld-linux-armhf.so.3 -X --hash-style=both -m armelf_linux_eabi /usr/lib/gcc/arm-linux-gnueabihf/4.6/../../../arm-linux-gnueabihf/crt1.o /usr/lib/gcc/arm-linux-gnueabihf/4.6/../../../arm-linux-gnueabihf/crti.o /usr/lib/gcc/arm-linux-gnueabihf/4.6/crtbegin.o -L/usr/lib/gcc/arm-linux-gnueabihf/4.6 -L/usr/lib/gcc/arm-linux-gnueabihf/4.6/../../../arm-linux-gnueabihf -L/usr/lib/gcc/arm-linux-gnueabihf/4.6/../../.. -L/lib/arm-linux-gnueabihf -L/usr/lib/arm-linux-gnueabihf /tmp/ccUcKZI2.o -ldl -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/arm-linux-gnueabihf/4.6/crtend.o /usr/lib/gcc/arm-linux-gnueabihf/4.6/../../../arm-linux-gnueabihf/crtn.o ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CThreads problem when cross-compiling to ARM/RPi.
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('FPCVERSION ',{$i %FPCVERSION%});
end.
and built it as:
fpc -Tlinux -Parm \
-Fu/home/bruce/lazarus/lcl/units/arm-linux/gtk2 \
-Fu/home/bruce/lazarus/lcl/units/arm-linux \
-Fu/home/bruce/lazarus/components/lazutils/lib/arm-linux \
-s test.pas
where relevant part of /etc/fpc.cfg is:
-Sgic
-viwn
-Xs
-Fu/usr/local/lib/fpc/$fpcversion/units/$fpctarget/*
#IFDEF FPC_CROSSCOMPILING
-XP$FPCTARGET-
#IFDEF LINUX
#IFDEF CPUARMHF
-Xd
-k--sysroot=/usr/local/opt/chroot/raspbian/rootfs
-Fl/usr/local/opt/chroot/raspbian/rootfs/usr/lib/gcc/arm-linux-gnueabihf/4.6
-Fl/usr/local/opt/chroot/raspbian/rootfs/usr/lib/arm-linux-gnueabihf
-Fl/usr/local/opt/chroot/raspbian/rootfs/usr/lib
-Fl/usr/local/opt/chroot/raspbian/rootfs/lib/arm-linux-gnueabihf
-Fl/usr/local/opt/chroot/raspbian/rootfs/lib
-FD/usr/local/opt/binutils/bin
#ENDIF
#ENDIF
#ENDIF
this produces ppas.sh:
#!/bin/sh
DoExitAsm ()
{ echo An error occurred while assembling $1; exit 1; }
DoExitLink ()
{ echo An error occurred while linking $1; exit 1; }
echo Assembling test
/usr/local/opt/binutils/bin/arm-linux-as -mfloat-abi=hard -meabi=5
-march=armv7-a -mfpu=vfpv3-d16 -o test.o test.s
if [ $? != 0 ]; then DoExitAsm test; fi
rm test.s
echo Linking test
OFS=$IFS
IFS=
/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 test link.res
if [ $? != 0 ]; then DoExitLink test; fi
IFS=$OFS
This assembles but the link fails on missing library dependencies.
The original (unmodified) INPUT statement in link.res is:
INPUT(
-ldl
-lpthread
-lX11
-lgdk_pixbuf-2.0
-lgtk-x11-2.0
-lgdk-x11-2.0
-lgobject-2.0
-lglib-2.0
-lgthread-2.0
-lgmodule-2.0
-lpango-1.0
-lcairo
-latk-1.0
)
To which I have to manually add these libraries:
-lrt
-lgcc_s
-lpcre
to fix these dependency problems, but the link then produces:
$ ./ppas.sh
Assembling test
Linking test
/usr/local/opt/binutils/bin/arm-linux-ld: warning: link.res contains
output sections; did you forget -T?
/usr/local/lib/fpc/2.7.1/units/arm-linux/rtl/dynlibs.o: In function
`DYNLIBS_$$_LOADLIBRARY$ANSISTRING$$LONGINT':
dynlibs.pas:(.text.n_dynlibs_$$_loadlibrary$ansistring$$longint+0x1c):
warning: Using 'dlopen' in statically linked applications requires at
runtime the shared libraries from the glibc version used for linking
/usr/local/opt/chroot/raspbian/rootfs/usr/lib/arm-linux-gnueabihf//libdl.a(dlopen.o):
In function `dlopen':
(.text+0xc): undefined reference to `__dlopen'
/usr/local/opt/chroot/raspbian/rootfs/usr/lib/arm-linux-gnueabihf//libdl.a(dlclose.o):
In function `dlclose':
(.text+0x0): undefined reference to `__dlclose'
/usr/local/opt/chroot/raspbian/rootfs/usr/lib/arm-linux-gnueabihf//libdl.a(dlsym.o):
In function `dlsym':
(.text+0xc): undefined reference to `__dlsym'
/usr/local/opt/chroot/raspbian/rootfs/usr/lib/arm-linux-gnueabihf//libdl.a(dlerror.o):
In function `dlerror':
(.text+0x0): undefined reference to `__dlerror'
/usr/local/opt/chroot/raspbian/rootfs/usr/lib/arm-linux-gnueabihf//libdl.a(dladdr.o):
In function `dladdr':
(.text+0x0): undefined reference to `__dladdr'
An error occurred while linking test
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.
I've tried comparing the linker arguments used with those produced by
gcc and there some differences at assembly time. Is this important?
Prima facie is looks like it might be.
For example gcc on the target says:
-march=armv6
but FPC directs the assembler to use:
-march=armv7-a
FYI, below is the full content of the (amended) link.res file...
SEARCH_DIR(/usr/local/opt/chroot/raspbian/rootfs/lib/)
SEARCH_DIR(/usr/local/opt/chroot/raspbian/rootfs/lib/arm-linux-gnueabihf/)
SEARCH_DIR(/usr/local/opt/chroot/raspbian/rootfs/usr/lib/)
SEARCH_DIR(/usr/local/opt/chroot/raspbian/rootfs/usr/lib/arm-linux-gnueabihf/)
SEARCH_DIR(/usr/local/opt/chroot/raspbian/rootfs/usr/lib/gcc/arm-linux-gnueabihf/4.6/)
SEARCH_DIR(/home/bruce/lazarus/lcl/units/arm-linux/gtk2/)
SEARCH_DIR(/home/bruce/lazarus/lcl/units/arm-linux/)
SEARCH_DIR(/home/bruce/lazarus/components/lazutils/lib/arm-linux/)
SEARCH_DIR(/usr/local/lib/fpc/2.7.1/units/arm-linux/httpd22/)
SEARCH_DIR(/usr/local/lib/fpc/2.7.1/units/arm-linux/cdrom/)
SEARCH_DIR(/usr/local/lib/fpc/2.7.1/units/arm-linux/jni/)
SEARCH_DIR(/usr/local/lib/fpc/2.7.1/units/arm-linux/imagemagick/)
SEARCH_DIR(/usr/local/lib/fpc/2.7.1/units/arm-linux/fcl-fpcunit/)
SEARCH_DIR(/usr/local/lib/fpc/2.7.1/units/arm-linux/tcl/)
Re: [fpc-pascal] CThreads problem when cross-compiling to ARM/RPi.
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, maybe that will tell you something more. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CThreads problem when cross-compiling to ARM/RPi.
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/chroot/raspbian/rootfs/usr/lib/arm-linux-gnueabihf//libdl.a)dlopen.o /usr/local/lib/fpc/2.7.1/units/arm-linux/rtl/dynlibs.o: In function `DYNLIBS_$$_LOADLIBRARY$ANSISTRING$$LONGINT': dynlibs.pas:(.text.n_dynlibs_$$_loadlibrary$ansistring$$longint+0x1c): warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking That is, the attempt to open libdl.so failed so libdl.a was opened instead which is the immediate reason why the link tries to link statically; the linker did not find the .so! The library libdl.so on the crossroot is in fact an absolute symlink: libdl.so - /lib/arm-linux-gnueabihf/libdl.so.2 so arm-linux-ld ends up looking for the target of symlink (/lib/arm-linux-gnueabihf/libdl.so.2) on the host and not on the crossroot. Hmm. To solve this I've replaced the symlink with a linker script of the same name containing: OUTPUT_FORMAT(elf32-littlearm) GROUP ( /lib/arm-linux-gnueabihf/libdl.so.2 /usr/lib/arm-linux-gnueabihf/libdl.a AS_NEEDED ( /lib/arm-linux-gnueabihf/ld-linux-armhf.so.3 ) ) which seems to solve the problem; with a linker script the --sysroot prefix is applied correctly and the link completes successfully. Thanks for all your pointers, I'm learning a lot about how ld actually works :-) So this raises some questions perhaps you can answer or comment on for me: 1) it seems to me that the use of absolute symlinks to resolve library files (as opposed to relative links or linker scripts) is bad practice (at least insofar as one may want to use them for cross compilation) but it appears many libraries (as packaged for Debian at least) do this (use absolute links). Is there a reason one might need to use absolute links? If so, is there a way (other than hacking the library files on the crossroot as I've done here) to make cross compiling work? On the other hand, if there is no reason to use absolute symlinks then I'm thinking this may be worth me filing a bug report or two with Debian! It seems one Gentoo developer think so: http://dev.gentoo.org/~zmedico/portage/doc/ch06s06.html 2) is there any reason linker scripts should be preferred to relative symlinks? 3) there remains one problem; dependencies on librt.so, libgcc_s.so and libpcre.so are not found by FPC (it does not put them in the link.res file). However, inspecting the crossroot I can see all these libraries are in fact absolute symlinks too so I'm guessing FPC cannot find them (when cross compiling) for the same reason; I will replace them with linker scripts too and try again. Thanks for all your help and advice. Bruce. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] CThreads problem when cross-compiling to ARM/RPi.
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 cross-compile:
Free Pascal Compiler version 2.7.1 [2013/05/20] for arm
Copyright (c) 1993-2013 by Florian Klaempfl and others
Target OS: Linux for ARMHF
Compiling arm-test.pas
Assembling test
Linking arm-test
8 lines compiled, 0.1 sec
successfully producing this:
arm-test: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically
linked, for GNU/Linux 2.0.0, stripped
which when executed produces:
DATE 2013/05/23
FPCTARGET arm
FPCTARGETCPU arm
FPCTARGETOS Linux
FPCVERSION 2.7.1
All good, the ARM cross-compiler is working.
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':
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
/usr/local/opt/chroot/raspbian/rootfs/usr/lib/arm-linux-gnueabihf//libdl.a(dlopen.o):
In function `dlopen':
(.text+0xc): undefined reference to `__dlopen'
/usr/local/opt/chroot/raspbian/rootfs/usr/lib/arm-linux-gnueabihf//libdl.a(dlclose.o):
In function `dlclose':
(.text+0x0): undefined reference to `__dlclose'
/usr/local/opt/chroot/raspbian/rootfs/usr/lib/arm-linux-gnueabihf//libdl.a(dlsym.o):
In function `dlsym':
(.text+0xc): undefined reference to `__dlsym'
/usr/local/opt/chroot/raspbian/rootfs/usr/lib/arm-linux-gnueabihf//libdl.a(dladdr.o):
In function `dladdr':
(.text+0x0): undefined reference to `__dladdr'
An error occurred while linking arm-test-threads
When compiling the same code native (x86_64) or cross compiled to Linux
i386, this does not happen (i.e the program links and executes fine). The
ARM linux system against which I'm linking is raspbian for RPi.
The relevant compiler configuration is:
#IFDEF CPUARM
-Xd
-k--sysroot=/usr/local/opt/chroot/raspbian/rootfs
-Fl/usr/local/opt/chroot/raspbian/rootfs/lib/arm-linux-gnueabihf
-Fl/usr/local/opt/chroot/raspbian/rootfs/usr/lib/arm-linux-gnueabihf
-FD/usr/local/opt/binutils/bin
-XP$FPCTARGET-
#ENDIF
What am I doing wrong?
Thanks, Bruce.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CThreads problem when cross-compiling to ARM/RPi.
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': 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 Why/how are you trying to create a statically linked binary? As the message above explains, statically linking libdl relies on a bunch of library magic. At the very least you'll probably also have to link libc explicitly, but I would really recommend to link dynamically instead. Support for binaries statically linked against C libraries is generally very much untested, and known not to work on certain platforms (e.g. Linux/x86-64). Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CThreads problem when cross-compiling to ARM/RPi.
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 link.res and the dynamic linker referred to is: root@beria:/lib# file ld-linux-armhf.so.3 ld-linux-armhf.so.3: symbolic link to `arm-linux-gnueabihf/ld-2.13.so' root@beria:/lib# file arm-linux-gnueabihf/ld-2.13.so arm-linux-gnueabihf/ld-2.13.so: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked, BuildID[sha1]=0x40caad061df15685e213cec1e4dfe1ba5f67701c, stripped Any clues? -b On Thu, May 23, 2013 at 10:18 PM, Jonas Maebe jonas.ma...@elis.ugent.bewrote: 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': 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 Why/how are you trying to create a statically linked binary? As the message above explains, statically linking libdl relies on a bunch of library magic. At the very least you'll probably also have to link libc explicitly, but I would really recommend to link dynamically instead. Support for binaries statically linked against C libraries is generally very much untested, and known not to work on certain platforms (e.g. Linux/x86-64). Jonas __**_ fpc-pascal maillist - fpc-pascal@lists.freepascal.**orgfpc-pascal@lists.freepascal.org http://lists.freepascal.org/**mailman/listinfo/fpc-pascalhttp://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CThreads problem when cross-compiling to ARM/RPi.
On 23 May 2013, at 14:25, Bruce Tulloch wrote: On Thu, May 23, 2013 at 10:18 PM, Jonas Maebe jonas.ma...@elis.ugent.be 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': 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 Why/how are you trying to create a statically linked binary? As the message above explains, statically linking libdl relies on a bunch of library magic. At the very least you'll probably also have to link libc explicitly, but I would really recommend to link dynamically instead. Support for binaries statically linked against C libraries is generally very much untested, and known not to work on certain platforms (e.g. Linux/x86-64). Okay, so I'm not trying to link statically, not intentionally anyway. Do you have a libdl.so in your library search path? And what kind of reference to libdl does link.res contain? Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CThreads problem when cross-compiling to ARM/RPi.
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 are two search statements: SEARCH_DIR(/usr/local/opt/chroot/raspbian/rootfs/usr/lib/arm-linux-gnueabihf/) SEARCH_DIR(/usr/local/opt/chroot/raspbian/rootfs/lib/arm-linux-gnueabihf/) at the top of the file which suggest it should be found okay. On Thu, May 23, 2013 at 10:28 PM, Jonas Maebe jonas.ma...@elis.ugent.bewrote: On 23 May 2013, at 14:25, Bruce Tulloch wrote: On Thu, May 23, 2013 at 10:18 PM, Jonas Maebe jonas.ma...@elis.ugent.be **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': 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 Why/how are you trying to create a statically linked binary? As the message above explains, statically linking libdl relies on a bunch of library magic. At the very least you'll probably also have to link libc explicitly, but I would really recommend to link dynamically instead. Support for binaries statically linked against C libraries is generally very much untested, and known not to work on certain platforms (e.g. Linux/x86-64). Okay, so I'm not trying to link statically, not intentionally anyway. Do you have a libdl.so in your library search path? And what kind of reference to libdl does link.res contain? Jonas __**_ fpc-pascal maillist - fpc-pascal@lists.freepascal.**orgfpc-pascal@lists.freepascal.org http://lists.freepascal.org/**mailman/listinfo/fpc-pascalhttp://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CThreads problem when cross-compiling to ARM/RPi.
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 pas...@causal.com wrote: 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 are two search statements: SEARCH_DIR(/usr/local/opt/chroot/raspbian/rootfs/usr/lib/arm-linux-gnueabihf/) SEARCH_DIR(/usr/local/opt/chroot/raspbian/rootfs/lib/arm-linux-gnueabihf/) at the top of the file which suggest it should be found okay. On Thu, May 23, 2013 at 10:28 PM, Jonas Maebe jonas.ma...@elis.ugent.bewrote: On 23 May 2013, at 14:25, Bruce Tulloch wrote: On Thu, May 23, 2013 at 10:18 PM, Jonas Maebe jonas.ma...@elis.ugent.be **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': 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 Why/how are you trying to create a statically linked binary? As the message above explains, statically linking libdl relies on a bunch of library magic. At the very least you'll probably also have to link libc explicitly, but I would really recommend to link dynamically instead. Support for binaries statically linked against C libraries is generally very much untested, and known not to work on certain platforms (e.g. Linux/x86-64). Okay, so I'm not trying to link statically, not intentionally anyway. Do you have a libdl.so in your library search path? And what kind of reference to libdl does link.res contain? Jonas __**_ fpc-pascal maillist - fpc-pascal@lists.freepascal.**orgfpc-pascal@lists.freepascal.org http://lists.freepascal.org/**mailman/listinfo/fpc-pascalhttp://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CThreads problem when cross-compiling to ARM/RPi.
On 23 May 2013, at 14:32, Bruce Tulloch wrote: On Thu, May 23, 2013 at 10:28 PM, Jonas Maebe jonas.ma...@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@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. It's referred to in an INPUT statement in link.res as: INPUT( -lpthread -ldl ) and there are two search statements: SEARCH_DIR(/usr/local/opt/chroot/raspbian/rootfs/usr/lib/arm-linux- gnueabihf/) SEARCH_DIR(/usr/local/opt/chroot/raspbian/rootfs/lib/arm-linux- gnueabihf/) at the top of the file which suggest it should be found okay. The linker will only look for libdl.so and resolve it to its target in case it's a symlink, so that the symlink is no longer required at run time. It will not look for libdl.so.something, that one is used by the programs at run time (since the symlinks at compile/link time pointed to it and the linker will write the name of this symlink target into the binary's list of linked libraries). 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. That is the object file of the Pascal dl unit. It is unrelated to your library issue. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CThreads problem when cross-compiling to ARM/RPi.
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-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. Checking my host x86_64 system we have: bruce@fermi:/usr/lib/x86_64-linux-gnu$ ls -l libdl* -rw-r--r-- 1 root root 13074 Dec 31 02:36 libdl.a lrwxrwxrwx 1 root root32 Dec 31 02:36 libdl.so - /lib/x86_64-linux-gnu/libdl.so.2 bruce@fermi:/usr/lib/x86_64-linux-gnu$ but building native on the host does not produce this problem. Still confused :-) -b On Thu, May 23, 2013 at 10:50 PM, Jonas Maebe jonas.ma...@elis.ugent.bewrote: On 23 May 2013, at 14:32, Bruce Tulloch wrote: On Thu, May 23, 2013 at 10:28 PM, Jonas Maebe jonas.ma...@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@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. It's referred to in an INPUT statement in link.res as: INPUT( -lpthread -ldl ) and there are two search statements: SEARCH_DIR(/usr/local/opt/**chroot/raspbian/rootfs/usr/** lib/arm-linux-gnueabihf/) SEARCH_DIR(/usr/local/opt/**chroot/raspbian/rootfs/lib/** arm-linux-gnueabihf/) at the top of the file which suggest it should be found okay. The linker will only look for libdl.so and resolve it to its target in case it's a symlink, so that the symlink is no longer required at run time. It will not look for libdl.so.something, that one is used by the programs at run time (since the symlinks at compile/link time pointed to it and the linker will write the name of this symlink target into the binary's list of linked libraries). 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. That is the object file of the Pascal dl unit. It is unrelated to your library issue. Jonas __**_ fpc-pascal maillist - fpc-pascal@lists.freepascal.**orgfpc-pascal@lists.freepascal.org http://lists.freepascal.org/**mailman/listinfo/fpc-pascalhttp://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CThreads problem when cross-compiling to ARM/RPi.
On 23 May 2013, at 15:03, Bruce Tulloch wrote: On Thu, May 23, 2013 at 10:50 PM, Jonas Maebe jonas.ma...@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.ma...@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@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@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@beria:~# apt-show-versions libc6-dev libc6-dev/wheezy uptodate 2.13-38+rpi2 but I noticed that: root@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@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CThreads problem when cross-compiling to ARM/RPi.
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.ma...@elis.ugent.bewrote: On 23 May 2013, at 15:03, Bruce Tulloch wrote: On Thu, May 23, 2013 at 10:50 PM, Jonas Maebe jonas.ma...@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.ma...@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@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@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@beria:~# apt-show-versions libc6-dev libc6-dev/wheezy uptodate 2.13-38+rpi2 but I noticed that: root@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@lists.freepascal.**orgfpc-pascal@lists.freepascal.org http://lists.freepascal.org/**mailman/listinfo/fpc-pascalhttp://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CThreads problem when cross-compiling to ARM/RPi.
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 pas...@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.ma...@elis.ugent.bewrote: On 23 May 2013, at 15:03, Bruce Tulloch wrote: On Thu, May 23, 2013 at 10:50 PM, Jonas Maebe jonas.ma...@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.ma...@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@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@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@beria:~# apt-show-versions libc6-dev libc6-dev/wheezy uptodate 2.13-38+rpi2 but I noticed that: root@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@lists.freepascal.**orgfpc-pascal@lists.freepascal.org http://lists.freepascal.org/**mailman/listinfo/fpc-pascalhttp://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CThreads problem when cross-compiling to ARM/RPi.
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 pas...@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 pas...@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.ma...@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.ma...@elis.ugent.bewrote: On 23 May 2013, at 14:32, Bruce Tulloch wrote: On Thu, May 23, 2013 at 10:28 PM, Jonas Maebe jonas.ma...@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@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@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@beria:~# apt-show-versions libc6-dev libc6-dev/wheezy uptodate 2.13-38+rpi2 but I noticed that: root@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@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] CThreads for linked C library?
Hi! libusb(x) links to libpthread: $ ldd /lib/x86_64-linux-gnu/libusb-1.0.so.0 linux-vdso.so.1 = librt.so.1 = /lib/x86_64-linux-gnu/librt.so.1 libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0 libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 /lib64/ld-linux-x86-64.so.2 If I'm linking to libusb(x), the resulting executable also links to libpthread. Looking at the libusbx source code (and API documentation) reveals, that they don't use threading, they only use the mutexes (pthread_mutex_*) and condition variables (pthread_cond_*). Is it necessary to have the unit CThreads in my Uses clause? Thanks Hansi ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CThreads for linked C library?
2012/10/1 Johann Glaser johann.gla...@gmx.at: Is it necessary to have the unit CThreads in my Uses clause? No, only if you use threads in your pascal code. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] cthreads unit
Hello, I'm trying to use the pthread_self function that supposed to be existed at cthreads unit. However the compiler tell me that it does not know pthread_self. I'm using Linux 64 bit (so I can't use libc), using fpc 2.2.0 . Looking at the source of cthreads.pp, it does have an include for pthread.inc file, that does contain dynamic/static linking of the function, so what am I missing ? Ido -- http://ik.homelinux.org/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] cthreads unit
On 17 Feb 2008, at 19:42, ik wrote: I'm trying to use the pthread_self function that supposed to be existed at cthreads unit. However the compiler tell me that it does not know pthread_self. It's only imported into that unit (in the implementation), it's not exported. The cthreads unit only installs a thread manager, it does not expose any implementation details (that's the whole point of that unit). I'm using Linux 64 bit (so I can't use libc), using fpc 2.2.0 . Looking at the source of cthreads.pp, it does have an include for pthread.inc file, that does contain dynamic/static linking of the function, so what am I missing ? If you want to use the RTL support for threading, use the generic RTL routines and not OS-specific ones. There is e.g. a GetCurrentThreadId function (but don't count on it returning the same value as pthread_self). If you want to program with pthreads directly, use the pthreads unit instead. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] cthreads unit
Thanks, that works. On Feb 17, 2008 8:50 PM, Jonas Maebe [EMAIL PROTECTED] wrote: On 17 Feb 2008, at 19:42, ik wrote: I'm trying to use the pthread_self function that supposed to be existed at cthreads unit. However the compiler tell me that it does not know pthread_self. It's only imported into that unit (in the implementation), it's not exported. The cthreads unit only installs a thread manager, it does not expose any implementation details (that's the whole point of that unit). I'm using Linux 64 bit (so I can't use libc), using fpc 2.2.0 . Looking at the source of cthreads.pp, it does have an include for pthread.inc file, that does contain dynamic/static linking of the function, so what am I missing ? If you want to use the RTL support for threading, use the generic RTL routines and not OS-specific ones. There is e.g. a GetCurrentThreadId function (but don't count on it returning the same value as pthread_self). If you want to program with pthreads directly, use the pthreads unit instead. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal -- http://ik.homelinux.org/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
