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 - [email protected]
http://lists.freepascal.org/mailman/listinfo/fpc-devel
