[fpc-devel] assumed bug in the RTL with ARM v5 regarding loading dynamic libraries

[Thomas Schatzl]

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