Hi Thomas.
Got it working now.
Thanks a lot for all your help !
(I usually need to understand what is happening before accepting a
solution.)
In the end I suppose something went wrong some days ago and after I know
that I need to provide the path to libdl.so, I could do the command line
In our previous episode, Thomas Schatzl said:
The _init and _fini you need are the ones from libdl.so. The linker
message doesn't help here. Crt*.o etc. are startup files for gcc
programs. Can you explain how you got to the impression that you need a
crti.o that provides _init and _fini? Just
On 01/23/2013 10:20 AM, Thomas Schatzl wrote:
program test;
uses cmem, dynlibs;
begin
writeln('Hello');
end.
Compile with:
ppcarm -Fl/opt/arm-none-linux-gnueabi/lib test.pas
Hi Tomas.
I tested your code and compiler line on my device and it behaves as I
expected:
On Thu, Jan 24, 2013 at 11:07:25AM +0100, Michael Schnell wrote:
FYI: This is the content of /opt/arm-linux-gnueabi/lib on this machine:
[/opt/lib] # ls -l
is not the same as the path you added with -Fl. And there
is no crti.o here. There isn't even an arm-linux-gnueabi
On 01/24/2013 11:17 AM, Henry Vermaak wrote:
And there is no crti.o here. There isn't even an arm-linux-gnueabi
directory here, so why did you add that path if it doesn't even exist?
I'll recheck as soon as I have access to the box.
From the top of my head I remember that in fact the
Am 24.01.2013 11:07, schrieb Michael Schnell:
4) Thus in your environment somehow such a library file is specified.
Maybe it's done in fpc.cfg, which in my environment has not been
obtained in a really decent way ant the syntax of which I fail to
understand well enough. (The file did not come
Thanks for the clarification.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 01/24/2013 02:08 PM, Thomas Schatzl wrote:
Looking back, so it want's some _init and _fini...
In your mail titled [fpc-devel] Install fpc and Friends on a non-Debian
ARM-Linux Device you state:
I found, that _fini and _init *should* be provided by crti.o which is
not included in the
Hi,
On Thu, 2013-01-24 at 16:13 +0100, Michael Schnell wrote:
On 01/24/2013 02:08 PM, Thomas Schatzl wrote:
Looking back, so it want's some _init and _fini...
2) I suppose in your environment not crti.o, but some library (.a file
or maybe some other file somehow specified) is used to
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
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
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
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
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
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
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
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
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
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
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
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
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
22 matches
Mail list logo
