[fpc-devel] assumed bug in the RTL with ARM v5 regarding loading dynamic libraries
Hi fpc RTL experts.
My project uses Synapse but features link problems and crashes when I
resolve same.
Tracking this down:
Synapse uses the unit dynlibs
dynlibs uses the unit dl
dl does not have a uses clause, so the problem seems to be here.
When in a dedicated test project I just do uses dl, I get the linker
message about _fini and _init, that I feature with any use of Synapse.
This can be resolved by
{$I crti.o}
and copying crti.o from /lib in my system to the project directory.
crti.o supposedly came with the libc-devel package that had been fetched
when installing gcc.
But now the compiled program results in a segfault before the first line
of user code (a writeln) is executed, and before a line of code in
Synapse had been executed. .
In fact I have neither any clue why Synapse wants to access a dynamic
library called libiconv, (a converter between multiple ASCII and ANSI
codes) nor why the code that loads dynamic libraries needs any CRT
stuff. But Synapse is not easily modified avoiding the initialization of
dynamic library access. (Maybe I should try to do dummy a dl.pp. )
In /rtl/unix/dl.pp there is:
{$if defined(linux) and defined(cpuarm)}
{ arm-linux seems to require this }
{$linklib c}
{$endif}
So in may testing program, instead of
uses dland
{$I crti.o}
I do
{$linklib c}
This results in the linker message about _fini and _init
This can be cured by adding
{$I crti.o}
And I have the segfault again
It looks like a bug in the RTL file /rtl/unix/dl.pp
It would be great if anybody could fix this issue.
If anybody confirms that this might be a bug and not a result of my
silliness, I will do a Mantis entry.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] assumed bug in the RTL with ARM v5 regarding loadingdynamic libraries
From: Michael Schnell mschn...@lumino.de Hi fpc RTL experts. My project uses Synapse but features link problems and crashes when I resolve same. Tracking this down: Synapse uses the unit dynlibs dynlibs uses the unit dl dl does not have a uses clause, so the problem seems to be here. When in a dedicated test project I just do uses dl, I get the linker message about _fini and _init, that I feature with any use of Synapse. It seems you have libdl statically linked to your executable. That's why you have such linker errors. Probably the linker is unable to find libdl.so but finds only libdl.a Anyway static linking should work too, but you need to link with libc. If you get segfaults when linking to libc, then cprt0.as for arm-linux is buggy. Yury Sidorov. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] assumed bug in the RTL with ARM v5 regarding loading dynamic libraries
Michael Schnell wrote: Hi fpc RTL experts. Non-expert here. My project uses Synapse but features link problems and crashes when I resolve same. Tracking this down: Synapse uses the unit dynlibs dynlibs uses the unit dl dl does not have a uses clause, so the problem seems to be here. In trunk it uses ctypes. I think in a lot of cases people using this will also be pulling in cmem, which could fix/hide some problems. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] assumed bug in the RTL with ARM v5 regarding loading dynamic libraries
Hi,
[topic is about a compilation problem specific to qnap ARM/linux based
NASes using the heavily modded stock OS]
On Wed, 2013-01-23 at 09:33 +0100, Michael Schnell wrote:
My project uses Synapse but features link problems and crashes when I
resolve same.
Tracking this down:
Synapse uses the unit dynlibs
dynlibs uses the unit dl
dl does not have a uses clause, so the problem seems to be here.
When in a dedicated test project I just do uses dl, I get the
linker message about _fini and _init, that I feature with any use of
Synapse.
This can be resolved by
{$I crti.o}
and copying crti.o from /lib in my system to the project directory.
crti.o supposedly came with the libc-devel package that had been
fetched when installing gcc.
when you install libc-dev using ipkg on qnap (or install anything
using ipkg), *everything* is installed into the /opt subdirectory.
So if you copy and use some random crti.o from somewhere it won't work.
On my qnap, there is no crti.o in /lib for example.
You can specify the path where the linker searches for libraries (and
crt* files) using the -Fl command line parameter too. So you don't need
to copy around files at all.
On my arm qnap, after installing libc-dev, crti.o and friends are
located in /opt/arm-none-linux-gnueabi/lib
So, to compile your test program successfully, try the following
program:
program test;
uses cmem, dynlibs;
begin
writeln('Hello');
end.
Compile with:
ppcarm -Fl/opt/arm-none-linux-gnueabi/lib test.pas
Hth,
Thomas
P.S.: It might be useful to start a bug report with the used compiler
version and platform, maybe with a compilable test program as simple as
the one above. Everything that you think might be needed to understand
the context and reproduce the issue.
Especially if you start a new thread, so that other readers not
following your qnap problems from the beginning in already X different
threads have a chance to understand and comment without reading 50 or so
emails.
Thanks.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] assumed bug in the RTL with ARM v5 regarding loading dynamic libraries
Hi,
On Wed, 2013-01-23 at 10:20 +0100, Thomas Schatzl wrote:
Hi,
[topic is about a compilation problem specific to qnap ARM/linux based
NASes using the heavily modded stock OS]
On Wed, 2013-01-23 at 09:33 +0100, Michael Schnell wrote:
This can be resolved by
{$I crti.o}
and copying crti.o from /lib in my system to the project directory.
crti.o supposedly came with the libc-devel package that had been
fetched when installing gcc.
when you install libc-dev using ipkg on qnap (or install anything
using ipkg), *everything* is installed into the /opt subdirectory.
That may be different in your ipkg installation - your firmware is
likely different/newer. Still, there should be no need to directly link
to crti.o.
Try searching for a different lib directory, preferably in the directory
where ipkg/optware installs its stuff.
Otherwise I cannot help any further. It's definitely an issue with a
wrong linker resources.
Thomas
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] assumed bug in the RTL with ARM v5 regarding loading dynamic libraries
On Wed, Jan 23, 2013 at 10:20:50AM +0100, Thomas Schatzl wrote: Compile with: ppcarm -Fl/opt/arm-none-linux-gnueabi/lib test.pas I had to do something similar when ubuntu moved to multiarch for arm, but the path was later added in the compiler. Henry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] assumed bug in the RTL with ARM v5 regarding loadingdynamic libraries
On 01/23/2013 10:00 AM, Yury Sidorov wrote:
It seems you have libdl statically linked to your executable.
Is this what
{$linklib c}
does ?
I just copied it from dl.pp in the svn.
That's why you have such linker errors. Probably the linker is unable
to find libdl.so but finds only libdl.a
I can't believe that the linker should automatically search for
potentially usable dynamic libraries: in fact it does not know on which
machine the program is supposed to run.
Anyway static linking should work too, but you need to link with libc.
If you get segfaults when linking to libc, then cprt0.as for arm-linux
is buggy.
I installed the TAR distribution of fpc and the libraries, so I assume
a compiled version of cprt0.as came from same.
the svc version of /linux/arm/cprt0.as contains this
.type _init,%function
.type _fini,%function
.weak _init
.weak _fini
So it does not seem to _require_ the symbols to be provided.
Anyway, there is nothing I can do about cprt0 :-( .
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] assumed bug in the RTL with ARM v5 regarding loading dynamic libraries
In our previous episode, Mark Morgan Lloyd said: Non-expert here. My project uses Synapse but features link problems and crashes when I resolve same. Tracking this down: Synapse uses the unit dynlibs dynlibs uses the unit dl dl does not have a uses clause, so the problem seems to be here. In trunk it uses ctypes. I think in a lot of cases people using this will also be pulling in cmem, which could fix/hide some problems. Afaik the correct way is: 1. Avoid any explicit linking commands ($L/$linklib) to libc related files. 2. to force linking to libc, USES unit initc, it should contain a $linklib C, or whatever else. (linklib root on beos iirc). It also contains access to the threadsafe C errno. 3. Anything else is up to the compiler t_* code that creates the linker script. This code should recognize the need for the switch from prt0 to cprt0 (linkliblist contains c), and prepare everything that is needed. There are two problems with this: 1) the t_* code might assume that it only need to link a certain file, and that the linker will add other needed files. (2) The trouble is that there are multiple such scenarios for Linux. In the past multiple glibc versions with different and differently named startups, more recently uclibc, our own si_ stuff etc. It might be that the hardcoded scenario for the platform deviates from what it really is. In the past this was even made worse by doing runtime checks. So the availability (or not) of a certain file might trigger a different linking scenario. Be wary with the embedded Linuxes of filers. They often base on highly customers (and old) MontaVista linux. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] assumed bug in the RTL with ARM v5 regarding loadingdynamic libraries
Am 23.01.2013 10:50, schrieb Michael Schnell: That's why you have such linker errors. Probably the linker is unable to find libdl.so but finds only libdl.a I can't believe that the linker should automatically search for potentially usable dynamic libraries: in fact it does not know on which machine the program is supposed to run. That's normal on ELF based systems: all libraries need to be known at link time (at least as long as you don't load them dynamically at runtime). Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] assumed bug in the RTL with ARM v5 regarding loading dynamic libraries
On 01/23/2013 10:20 AM, Thomas Schatzl wrote:
[topic is about a compilation problem specific to qnap ARM/linux based
NASes using the heavily modded stock OS]
Yep, but I don't see how this is related to the problem.
I understand the program crashes before it tries to do system depending
things like accessing an .so.
when you install libc-dev using ipkg on qnap (or install anything
using ipkg), *everything* is installed into the /opt subdirectory.
I do know this. This is why I needed to copy crti.o from there in the
project directory to make the linker see it (of course there are other
ways, but for this single file it seemed to be the easiest). The linker
does not request more files that might be missing because of the
non-standard layout of the OS files. So the project does not seem to
need anything else. (I tried to compile and run testing projects that do
use lots of library functions that came with the TAR fpc distribution.
Up to now, I only found problems with the use of dl.
So if you copy and use some random crti.o from somewhere it won't work.
On my qnap, there is no crti.o in /lib for example.
Do you have the gcc ipkg ? Do you suggest this crti provided by Optware
is buggy ? Of course I can't comment on this.
OTOH, I understand that ctri does not do anything complex at all. It
just provides linker symbols to section starts or something like this.
You can specify the path where the linker searches for libraries (and
crt* files) using the -Fl command line parameter too. So you don't need
to copy around files at all.
Why should I provide more files to the linker ? It does not request for
any. and if there are weak externals (only filled if optionally linked
files are provided for other reasons) the code is required to handle the
case they are NIL (not present) appropriately.
On my arm qnap, after installing libc-dev, crti.o and friends are
located in /opt/arm-none-linux-gnueabi/lib
So, to compile your test program successfully, try the following
program:
program test;
uses cmem, dynlibs;
begin
writeln('Hello');
end.
Compile with:
ppcarm -Fl/opt/arm-none-linux-gnueabi/lib test.pas
I'll do this ASAP.
Does it work for you ?
Thanks a lot for testing this for me.
-Michael
P.S.: It might be useful to start a bug report with the used compiler
version and platform, maybe with a compilable test program as simple as
the one above.
Right you are.
The compiler is the one from the current TAR fpc distribution for ARM.
(as you suggested)
I did describe the four line test program but of course it would have
been more polite to provide the complete source.
Everything that you think might be needed to understand
the context and reproduce the issue.
I don't see why the problem should be related to the target (other than
in fact the crti provided is buggy which I esteem rather unlikely).
Thanks again,
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] assumed bug in the RTL with ARM v5 regarding loading dynamic libraries
Michael Schnell wrote: I don't see why the problem should be related to the target (other than in fact the crti provided is buggy which I esteem rather unlikely). Except for the possible case where the OS and standard libraries have been built to not support dynamic linkage. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] assumed bug in the RTL with ARM v5 regarding loadingdynamic libraries
On 01/23/2013 11:12 AM, Sven Barth wrote: That's normal on ELF based systems: all libraries need to be known at link time (at least as long as you don't load them dynamically at runtime). I see. But automatically using a library statically when the dynamic version is not found does not seem to be appropriate. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] assumed bug in the RTL with ARM v5 regarding loading dynamic libraries
On 01/23/2013 10:34 AM, Thomas Schatzl wrote:
That may be different in your ipkg installation - your firmware is
likely different/newer. Still, there should be no need to directly link
to crti.o.
That is what I hope, as in fact the project never access any CRT related
stuff. The binding of CRT is a nasty side-effect of something not too
well done in pl.pp or called by pl.pp
Try searching for a different lib directory, preferably in the directory
where ipkg/optware installs its stuff.
What file am I supposed to find ? The offending line in pl.pp is
{$linklib c}
I compile just doing
fpc test123.pas
I did do a symlink for /usr/lib/fpc to allow for the rtl and fcl files
to be found as (supposedly) denoted in fpc.cfg (which I copied from the
debian package to /etc, as there was none in the TAR distribution)
So where does the linker search for what file when the compiler sees
{$linklib c} ? libc.so ? libc.a ? what else ?
Otherwise I cannot help any further. It's definitely an issue with a
wrong linker resources.
I'll keep trying
Thanks,
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] assumed bug in the RTL with ARM v5 regarding loading dynamic libraries
On 01/23/2013 11:36 AM, Mark Morgan Lloyd wrote:
Except for the possible case where the OS and standard libraries have
been built to not support dynamic linkage.
I seem to remember that there are lots of .so used in this system (I'll
recheck)
Moreover I suppose it then should crash not before trying to load a
library. I understand that Synapse uses the rtl infrastructure to
dynamically load and attach to the library at runtime, when necessary
and not when starting.
My testing program does not even know about any other dynamic library
then what is denoted by {$linklib c} I don't know if this tries to load
an so right when starting.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] assumed bug in the RTL with ARM v5 regarding loading dynamic libraries
Hi,
On Wed, 2013-01-23 at 11:23 +0100, Michael Schnell wrote:
On 01/23/2013 10:20 AM, Thomas Schatzl wrote:
[topic is about a compilation problem specific to qnap ARM/linux
based NASes using the heavily modded stock OS]
Yep, but I don't see how this is related to the problem.
People are using the arm/linux compiler to compile and run a lot more
complex software than your example program, e.g. lazarus. Or build and
run fairly complex Android applications to just mention some I happen to
have heard about from attending the mailing lists.
Additionally, the testsuite examples that test shared libraries also
test basically the same program you described every day.
The OS on the qnap has a very untypical linux user land. Probably it
also has an extremely old kernel too (e.g. some MontaVista 2.6.x as
Marco suggested, whatever the influence of this MontaVista stuff is :).
Other possible differences: ARMel != ARMhf. Trunk != Fixes != release
compiler. Linux 2.6.x Linux Montavista != fairly recent 3.x kernel.
So yes, this information is important to diagnose the problem and
eliminate possibilities more quickly without endless asking for every
bit of information.
Especially for people not following the other embedded mails in the
last month.
So if you copy and use some random crti.o from somewhere it won't
work.
On my qnap, there is no crti.o in /lib for example.
Do you have the gcc ipkg ? Do you suggest this crti provided by
Optware is buggy ? Of course I can't comment on this.
OTOH, I understand that ctri does not do anything complex at all. It
just provides linker symbols to section starts or something like this.
No. The only packages I have installed are binutils and libc-dev,
based from a vanilla installation. I grabbed and installed the 2.6.0
release compiler. I do have some other programs installed that are
unrelated, but they may have installed one additional shared library or
two.
You can specify the path where the linker searches for libraries
(and crt* files) using the -Fl command line parameter too. So you
don't need to copy around files at all.
Why should I provide more files to the linker ? It does not request
for any. and if there are weak externals (only filled if optionally
linked files are provided for other reasons) the code is required to
handle the case they are NIL (not present) appropriately.
You did not state from where exactly you got that cprt0.as file from.
The fpc svn has 20 branches or so. I'd assume trunk, as it's probably
the most commonly used. However, especially arm/linux support has been
changed a lot from top to bottom in trunk. It may differ (from
release/fixes) significantly.
On my arm qnap, after installing libc-dev, crti.o and friends are
located in /opt/arm-none-linux-gnueabi/lib
So, to compile your test program successfully, try the following
program:
program test;
uses cmem, dynlibs;
begin
writeln('Hello');
end.
Compile with:
ppcarm -Fl/opt/arm-none-linux-gnueabi/lib test.pas
I'll do this ASAP.
Does it work for you ?
The program compiles and the program prints Hello. If it did not work,
I'd have mentioned it and asked you to file a bug report.
Note that the use of cmem in that program is not needed, it's just
that I tried first with cmem, then added dynlibs. I tried with only
dynlibs too now. It still works.
Thanks a lot for testing this for me.
-Michael
P.S.: It might be useful to start a bug report with the used
compiler version and platform, maybe with a compilable test program
as simple as the one above.
Right you are.
The compiler is the one from the current TAR fpc distribution for
ARM. (as you suggested)
Again, fixes (2.6.1) or trunk (2.7.0) or official distribution (2.6.0)?
Thomas
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] assumed bug in the RTL with ARM v5 regarding loading dynamic libraries
Hi, I messed up with replying to Michael privately only first, then only noticing that I hit the wrong reply button. @Michael: Please try to avoid CC'ing additional people from the list in addition to the list for list-specific discussions. The additional cc'ing achieves nothing but people making errors. Thanks. On Wed, 2013-01-23 at 13:18 +0100, Michael Schnell wrote: On 01/23/2013 12:16 PM, Thomas Schatzl wrote: People are using the arm/linux compiler to compile and run a lot more complex software than your example program, e.g. lazarus. Or build and run fairly complex Android applications to just mention some I happen to have heard about from attending the mailing lists. Of course. But do they use pl and friends to load dynamic libraries ? (In fact I don't intend to do this but Synapse does it and I can't (easily) help it) These programs use the dl library for the convenience of not having to link to a particular version of a specific library at compile time. There are many examples for that, e.g. graphics, unicode support, networking, ... I mentioned that the fpc testsuite completes an almost exact copy of the program you described successfully daily. I successfully compiled and ran an example program I reconstructed from your vague description on an arm qnap (ts-119 turbo or so fyi). Including instructions how to reproduce. So no, it's very unlikely that there is a bug in the compiler or rtl. Please try the example given first. You did not state from where exactly you got that cprt0.as file from. I got it from the current svn trunk, But I in fact don't know if this is in fact what produces the cprt0.o in the TAR distribution. The program compiles and the program prints Hello. If it did not work, I'd have mentioned it and asked you to file a bug report. Note that the use of cmem in that program is not needed, it's just that I tried first with cmem, then added dynlibs. I tried with only dynlibs too now. It still works. I'll check this... Again, fixes (2.6.1) or trunk (2.7.0) or official distribution (2.6.0)? You seemed to have recommended to use the link you gave me the to the official 2.6.0. I provided links to all of them. So, given this last statement, it's likely 2.6.0. This also answers your question about whether the comparison of the cprt0 files makes sense. Using the same compiler also helps reproducing my step-by-step compilation example. Do you think it would make sense to pull the svn trunk sources and try to compile 2.7.0 using the compiler I have ? No. You should only make sure that we don't need to second guess the context of your problem by providing the necessary information in the very first mail. Hth, Thomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] assumed bug in the RTL with ARM v5 regarding loading dynamic libraries
Am 23.01.2013 12:55, schrieb Michael Schnell: On 01/23/2013 10:34 AM, Thomas Schatzl wrote: That may be different in your ipkg installation - your firmware is likely different/newer. Still, there should be no need to directly link to crti.o. That is what I hope, as in fact the project never access any CRT related stuff. The binding of CRT is a nasty side-effect of something not too well done in pl.pp or called by pl.pp You do know that CRT in this case is not related to the Pascal unit crt, but code needed for C libraries (calling their initializers and finalizers)? (CRT = C RunTime) Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
