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

[Michael Schnell]

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