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 "u
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.
I
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:
>
> Sy
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}
> >
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"
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
thing
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:56 AM, Marco van de Voort wrote:
Afaik the correct way is:
1. Avoid any explicit linking commands ($L/$linklib) to libc related files.
I understand that this is exactly what /rtl/unix/dl.pp does. (I only did
it in a testing program to find out where the problem in the RTL is
l
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 bef
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
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 maki
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 acc
On 01/23/2013 03:58 PM, Sven Barth wrote:
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)
Ahh ! Thanks for the clarification. I indeed assumed "Cathode Ray
Display". Silly
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" dir
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 directo
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
Hi,
On Thu, 2013-01-24 at 11:07 +0100, Michael Schnell wrote:
> 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 te
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 packa
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
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
co
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
25 matches
Mail list logo
