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 "uses dl", I get the linker message about _fini and _init, that I feature with any use of Synapse.

This can be resolved by
{$I crti.o}
and copying crti.o from /lib in my system to the project directory. crti.o supposedly came with the libc-devel package that had been fetched when installing gcc.

But now the compiled program results in a segfault before the first line of user code (a writeln) is executed, and before a line of code in Synapse had been executed. .

In fact I have neither any clue why Synapse wants to access a dynamic library called "libiconv", (a converter between multiple ASCII and ANSI codes) nor why the code that loads dynamic libraries needs any "CRT" stuff. But Synapse is not easily modified avoiding the initialization of dynamic library access. (Maybe I should try to do dummy a dl.pp. )

In /rtl/unix/dl.pp there is:

{$if defined(linux) and defined(cpuarm)}
{ arm-linux seems to require this }
{$linklib c}
{$endif}

So in may testing program, instead of

uses dl and
"{$I crti.o}

I do
{$linklib c}

This results in the linker message about _fini and _init

This can be cured by adding
{$I crti.o}

And I have the segfault again

It looks like a bug in the RTL file /rtl/unix/dl.pp

It would be great if anybody could fix this issue.

If anybody confirms that this might be a bug and not a result of my silliness, I will do a Mantis entry.

-Michael

From: "Michael Schnell"

It seems you have libdl statically linked to your executable. That's why you have such linker errors. Probably the linker is unable to find libdl.so but finds only libdl.a

Anyway static linking should work too, but you need to link with libc. If you get segfaults when linking to libc, then cprt0.as for arm-linux is buggy.

Yury Sidorov.

Michael Schnell wrote

Hi fpc RTL experts.

Non-expert here.

In trunk it uses ctypes. I think in a lot of cases people using this will also be pulling in cmem, which could fix/hide some problems.

Hi,

[topic is about a compilation problem specific to qnap ARM/linux based NASes using the heavily modded stock OS]

when you install libc-dev using ipkg on qnap (or install anything using ipkg), *everything* is installed into the /opt subdirectory.

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.

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 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

Hth,
Thomas

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. Everything that you think might be needed to understand the context and reproduce the issue.
Especially if you start a new thread, so that other readers not following your qnap problems from the beginning in already X different threads have a chance to understand and comment without reading 50 or so emails.
Thanks.

Hi,

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.

Try searching for a different lib directory, preferably in the directory where ipkg/optware installs its stuff.

Otherwise I cannot help any further. It's definitely an issue with a wrong linker resources.

Thomas

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

Yury Sidorov wrote

It seems you have libdl statically linked to your executable.

Is this what
{$linklib c}
does ?

I just copied it from dl.pp in the svn.

That's why you have such linker errors. Probably the linker is unable to find libdl.so but finds only libdl.a

I can't believe that the linker should automatically search for potentially usable dynamic libraries: in fact it does not know on which machine the program is supposed to run.

Anyway static linking should work too, but you need to link with libc. If you get segfaults when linking to libc, then cprt0.as for arm-linux is buggy.

I installed the "TAR distribution" of fpc and the libraries, so I assume a compiled version of cprt0.as came from same.

the svc version of /linux/arm/cprt0.as contains this

....
.type _init,%function
.type _fini,%function
.weak _init
.weak _fini
....

So it does not seem to _require_ the symbols to be provided.

Anyway, there is nothing I can do about cprt0 :-( .

-Michael

In our previous episode, Mark Morgan Lloyd said:

Afaik the correct way is:

1. Avoid any explicit linking commands ($L/$linklib) to libc related files.
2. to force linking to libc, USES unit initc, it should contain a $linklib C, or whatever else. (linklib root on beos iirc). It also contains access to the threadsafe C errno.
3. Anything else is up to the compiler t_* code that creates the linker script. This code should recognize the need for the switch from prt0 to cprt0 (linkliblist contains "c"), and prepare everything that is needed.

There are two problems with this:

1)
the t_* code might assume that it only need to link a certain file, and that the linker will add other needed files.

(2) The trouble is that there are multiple such scenarios for Linux. In the past multiple glibc versions with different and differently named startups, more recently uclibc, our own si_ stuff etc. It might be that the hardcoded scenario for the platform deviates from what it really is. In the past this was even made worse by doing runtime checks. So the availability (or not) of a certain file might trigger a different linking scenario.

Be wary with the embedded Linuxes of filers. They often base on highly customers (and old) MontaVista linux.

That's normal on ELF based systems: all libraries need to be known at link time (at least as long as you don't load them dynamically at runtime).

Regards,
Sven

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
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 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.

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

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.

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 located.)

2. to force linking to libc, USES unit initc, it should contain a $linklib C, or whatever else. (linklib root on beos iirc). It also contains access to the threadsafe C errno.

Will rtl/unix/dl.pp be fixed according to this guidelines ? (unfortunately I don't think that I would be knowledgeable enough to do this.)

BTW.: I understand that the way of the fpc RTL is reducing the use of libc as far as possible and provide the functionality locally whenever possible. (This of course introduces more problems with supporting different processor flavors.) So, is it really necessary to use libc for dynamic linking ?

3. Anything else is up to the compiler t_* code that creates the linker script. This code should recognize the need for the switch from prt0 to cprt0 (linkliblist contains "c"), and prepare everything that is needed.

Sorry. I can't follow here (I suppose this goes out to those that might be able to modify dl.pp or whatever appropriately).

Thanks,
-Michael

Sven Barth wrote

That's normal on ELF based systems: all libraries need to be known at link time (at least as long as you don't load them dynamically at runtime).

I see. But automatically using a library statically when the dynamic version is not found does not seem to be appropriate.

-Michael

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 is a nasty side-effect of something not too well done in pl.pp or called by pl.pp

Try searching for a different lib directory, preferably in the directory where ipkg/optware installs its stuff.

What file am I supposed to find ? The offending line in pl.pp is
{$linklib c}

I compile just doing
fpc test123.pas

I did do a symlink for /usr/lib/fpc to allow for the rtl and fcl files to be found as (supposedly) denoted in fpc.cfg (which I copied from the debian package to /etc, as there was none in the TAR distribution) So where does the linker search for what file when the compiler sees {$linklib c} ? libc.so ? libc.a ? what else ?

Otherwise I cannot help any further. It's definitely an issue with a wrong linker resources.

I'll keep trying....
Thanks,
-Michael

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 before trying to load a library. I understand that Synapse uses the rtl infrastructure to dynamically load and attach to the library at runtime, when necessary and not when starting.

My testing program does not even know about any other dynamic library then what is denoted by {$linklib c} I don't know if this tries to load an so right when starting.

-Michael

Hi,

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.

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 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.

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.

Again, fixes (2.6.1) or trunk (2.7.0) or official distribution (2.6.0)?

Thomas

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 making errors. Thanks.

These programs use the dl library for the convenience of not having to link to a particular version of a specific library at compile time. There are many examples for that, e.g. graphics, unicode support, networking, ...

I mentioned that the fpc testsuite completes an almost exact copy of the program you described successfully daily.

I successfully compiled and ran an example program I reconstructed from your vague description on an arm qnap (ts-119 turbo or so fyi). Including instructions how to reproduce.

So no, it's very unlikely that there is a bug in the compiler or rtl. Please try the example given first.

I provided links to all of them. So, given this last statement, it's likely 2.6.0. This also answers your question about whether the comparison of the cprt0 files makes sense.

Using the same compiler also helps reproducing my step-by-step compilation example.

Do you think it would make sense to pull the svn trunk sources and try to compile 2.7.0 using the compiler I have ?

No. You should only make sure that we don't need to second guess the context of your problem by providing the necessary information in the very first mail.

Hth,
Thomas

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)

Regards,
Sven

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 me :-[ .

-Michael

Hi Tomas.

I tested your code and compiler line on my device and it behaves as I expected:

============================================
[/share/Public/heizarm] # ppcarm -Fl/opt/arm-linux-gnueabi/lib test.pas Free Pascal Compiler version 2.6.0 [2011/12/27] for arm Copyright (c) 1993-2011 by Florian Klaempfl and others Target OS: Linux for ARMEL
Compiling test.pas
Assembling test
Linking test
/share/Public/root/lib/fpc/2.6.0/units/arm-linux/rtl/cprt0.o: In function `_haltproc_eabi':
(.text+0x88): undefined reference to `_fini'
/share/Public/root/lib/fpc/2.6.0/units/arm-linux/rtl/cprt0.o: In function `_haltproc_eabi':
(.text+0x90): undefined reference to `_init'
test.pas(4,18) Error: Error while linking
test.pas(4,18) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted
[/share/Public/heizarm] # cp /opt/arm-none-linux-gnueabi/lib/c ============================================

Obviously something in my installation is different.

/opt/arm-linux-gnueabi/lib is exactly the location where I copied crti.o from.

I still don't see the difference between copying the file to the current dir and using -Fl to add that dir to the library search path.

Up till now I used the gnu linker only with embedded projects in C language via cross-compiling and without dynamic link libraries.

So I of course am lacking a lot of knowledge, but you might be inclined to fill some gaps.

I understand that
a) the linker does not open all files in a search directory and try to find resolutions for open (non weak) externals
b) the linker only opens the .o and .a files it is told to use (e.g. in a linker script file - this is what I used in the said "C" projects) c) if one of the denoted files is not found in any of the search directories, the linker aborts with an error message.

Regarding my inability to link your testing program, and my other tests:
1) rather obviously the file crti.o is not a viable file to be used, as (i) the linker will never see it unless explicitly denoted (e.g. by {$L crti.o ) and this is not done in your successful test on your machine and (ii) my testing programs immediately when I include it,
2) I suppose in your environment not crti.o, but some library (.a file or maybe some other file somehow specified) is used to resolve the _init and _finit externals.
3) I understand that for this, that library somehow needs to be specified, as I believe the linker will not on it's own go out and search and open files that might provide these globals.
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 with the 2.6.0 "TAR" distribution, so it is inherited from the Debian 2.2 stuff ).
5) In dl.pp (That I understand you test program implicitly pulls), there is the line {$linklib c}. I don't really understand what exactly this is suppose to mean. I would _assume_ that it might be an instruction to the linker to use the library file "c.a" but I believe there is no file with such name. So there might be some compiler magic that constructs a different instruction to the linker.

-Michael

FYI: This is the content of /opt/arm-linux-gnueabi/lib on this machine:

[/opt/lib] # ls -l
drwxr-xr-x 2 admin administ 4096 Jan 3 11:36 armv4t/ -rwxr-xr-x 1 admin administ 7132 Feb 14 2012 e2initrd_helper* drwxr-xr-x 3 admin administ 4096 Jan 3 11:36 gcc/ drwxr-xr-x 3 admin administ 4096 Jan 3 11:10 gio/ drwxr-xr-x 3 admin administ 4096 Jan 3 11:10 glib-2.0/ drwxr-xr-x 4 admin administ 4096 Jan 3 15:18 groff/ drwxr-xr-x 5 admin administ 4096 Jan 21 22:52 ipkg/ -rw-r--r-- 1 admin administ 4407522 Feb 14 2012 libbfd.a -rwxr-xr-x 1 admin administ 937 Feb 14 2012 libbfd.la* lrwxrwxrwx 1 admin administ 13 Jan 3 11:10 libblkid.so -> libblkid.so.1*
lrwxrwxrwx 1 admin administ 15 Jan 3 11:10 libblkid.so.1 -> libblkid.so.1.0*
-rwxr-xr-x 1 admin administ 41080 Feb 14 2012 libblkid.so.1.0* -rw-r--r-- 1 admin administ 209 Feb 14 2012 libc.so -rw-r--r-- 1 admin administ 20912 Feb 14 2012 libc_nonshared.a lrwxrwxrwx 1 admin administ 15 Jan 3 11:10 libcom_err.so -> libcom_err.so.2*
lrwxrwxrwx 1 admin administ 17 Jan 3 11:10 libcom_err.so.2 -> libcom_err.so.2.1*
-rwxr-xr-x 1 admin administ 8828 Feb 14 2012 libcom_err.so.2.1* -rwxr-xr-x 1 admin administ 721164 Feb 15 2012 libdb-4.2.so* lrwxrwxrwx 1 admin administ 12 Jan 3 11:24 libdb-4.so -> libdb-4.2.so*
lrwxrwxrwx 1 admin administ 12 Jan 3 11:24 libdb.so -> libdb-4.2.so*
lrwxrwxrwx 1 admin administ 11 Jan 3 11:10 libe2p.so -> libe2p.so.2*
lrwxrwxrwx 1 admin administ 13 Jan 3 11:10 libe2p.so.2 -> libe2p.so.2.3*
-rwxr-xr-x 1 admin administ 22796 Feb 14 2012 libe2p.so.2.3* lrwxrwxrwx 1 admin administ 14 Jan 3 11:10 libext2fs.so -> libext2fs.so.2*
lrwxrwxrwx 1 admin administ 16 Jan 3 11:10 libext2fs.so.2 -> libext2fs.so.2.4*
-rwxr-xr-x 1 admin administ 163556 Feb 14 2012 libext2fs.so.2.4* lrwxrwxrwx 1 admin administ 12 Jan 3 10:29 libform.so -> libform.so.5*
lrwxrwxrwx 1 admin administ 14 Jan 3 10:29 libform.so.5 -> libform.so.5.7*
-rwxr-xr-x 1 admin administ 44884 Dec 24 06:48 libform.so.5.7* lrwxrwxrwx 1 admin administ 13 Jan 3 15:19 libformw.so -> libformw.so.5*
lrwxrwxrwx 1 admin administ 15 Jan 3 15:19 libformw.so.5 -> libformw.so.5.7*
-rwxr-xr-x 1 admin administ 52232 Dec 22 00:32 libformw.so.5.7* lrwxrwxrwx 1 admin administ 13 Jan 3 11:36 libgcc_s.so -> libgcc_s.so.1
-rw-r--r-- 1 admin administ 238932 Feb 15 2012 libgcc_s.so.1 lrwxrwxrwx 1 admin administ 16 Jan 3 11:24 libgdbm.so -> libgdbm.so.3.0.0*
lrwxrwxrwx 1 admin administ 16 Jan 3 11:24 libgdbm.so.3 -> libgdbm.so.3.0.0*
-rwxr-xr-x 1 admin administ 18660 Feb 18 2012 libgdbm.so.3.0.0* lrwxrwxrwx 1 admin administ 23 Jan 3 11:24 libgdbm_compat.so -> libgdbm_compat.so.3.0.0*
lrwxrwxrwx 1 admin administ 23 Jan 3 11:24 libgdbm_compat.so.3 -> libgdbm_compat.so.3.0.0*
-rwxr-xr-x 1 admin administ 6188 Feb 18 2012 libgdbm_compat.so.3.0.0*
-rwxr-xr-x 1 admin administ 1063 Feb 14 2012 libgio-2.0.la* lrwxrwxrwx 1 admin administ 22 Jan 3 11:10 libgio-2.0.so -> libgio-2.0.so.0.2000.4*
lrwxrwxrwx 1 admin administ 22 Jan 3 11:10 libgio-2.0.so.0 -> libgio-2.0.so.0.2000.4*
-rwxr-xr-x 1 admin administ 415536 Feb 14 2012 libgio-2.0.so.0.2000.4*
-rwxr-xr-x 1 admin administ 986 Feb 14 2012 libglib-2.0.la* lrwxrwxrwx 1 admin administ 23 Jan 3 11:10 libglib-2.0.so -> libglib-2.0.so.0.2000.4*
lrwxrwxrwx 1 admin administ 23 Jan 3 11:10 libglib-2.0.so.0 -> libglib-2.0.so.0.2000.4*
-rwxr-xr-x 1 admin administ 842160 Feb 14 2012 libglib-2.0.so.0.2000.4*
-rwxr-xr-x 1 admin administ 1033 Feb 14 2012 libgmodule-2.0.la* lrwxrwxrwx 1 admin administ 26 Jan 3 11:10 libgmodule-2.0.so -> libgmodule-2.0.so.0.2000.4*
lrwxrwxrwx 1 admin administ 26 Jan 3 11:10 libgmodule-2.0.so.0 -> libgmodule-2.0.so.0.2000.4* -rwxr-xr-x 1 admin administ 9960 Feb 14 2012 libgmodule-2.0.so.0.2000.4*
-rwxr-xr-x 1 admin administ 1028 Feb 14 2012 libgobject-2.0.la* lrwxrwxrwx 1 admin administ 26 Jan 3 11:10 libgobject-2.0.so -> libgobject-2.0.so.0.2000.4*
lrwxrwxrwx 1 admin administ 26 Jan 3 11:10 libgobject-2.0.so.0 -> libgobject-2.0.so.0.2000.4* -rwxr-xr-x 1 admin administ 245804 Feb 14 2012 libgobject-2.0.so.0.2000.4*
-rwxr-xr-x 1 admin administ 1043 Feb 14 2012 libgthread-2.0.la* lrwxrwxrwx 1 admin administ 26 Jan 3 11:10 libgthread-2.0.so -> libgthread-2.0.so.0.2000.4*
lrwxrwxrwx 1 admin administ 26 Jan 3 11:10 libgthread-2.0.so.0 -> libgthread-2.0.so.0.2000.4* -rwxr-xr-x 1 admin administ 14228 Feb 14 2012 libgthread-2.0.so.0.2000.4*
lrwxrwxrwx 1 admin administ 15 Jan 3 10:29 libhistory.so -> libhistory.so.6*
lrwxrwxrwx 1 admin administ 17 Jan 3 10:29 libhistory.so.6 -> libhistory.so.6.1*
-r-xr-xr-x 1 admin administ 26328 Feb 14 2012 libhistory.so.6.1* -rw-r--r-- 1 admin administ 683294 Feb 14 2012 libiberty.a lrwxrwxrwx 1 admin administ 16 Jan 3 10:29 libipkg.so -> libipkg.so.0.0.0*
lrwxrwxrwx 1 admin administ 16 Jan 3 10:29 libipkg.so.0 -> libipkg.so.0.0.0*
-rwxr-xr-x 1 admin administ 150260 Feb 15 2012 libipkg.so.0.0.0* lrwxrwxrwx 1 admin administ 12 Jan 3 10:29 libmenu.so -> libmenu.so.5*
lrwxrwxrwx 1 admin administ 14 Jan 3 10:29 libmenu.so.5 -> libmenu.so.5.7*
-rwxr-xr-x 1 admin administ 23508 Dec 24 06:48 libmenu.so.5.7* lrwxrwxrwx 1 admin administ 13 Jan 3 15:19 libmenuw.so -> libmenuw.so.5*
lrwxrwxrwx 1 admin administ 15 Jan 3 15:19 libmenuw.so.5 -> libmenuw.so.5.7*
-rwxr-xr-x 1 admin administ 24020 Dec 22 00:32 libmenuw.so.5.7* lrwxrwxrwx 1 admin administ 15 Jan 3 10:29 libncurses.so -> libncurses.so.5*
lrwxrwxrwx 1 admin administ 17 Jan 3 10:29 libncurses.so.5 -> libncurses.so.5.7*
-rwxr-xr-x 1 admin administ 251724 Dec 24 06:48 libncurses.so.5.7* lrwxrwxrwx 1 admin administ 16 Jan 3 15:19 libncursesw.so -> libncursesw.so.5*
lrwxrwxrwx 1 admin administ 18 Jan 3 15:19 libncursesw.so.5 -> libncursesw.so.5.7*
-rwxr-xr-x 1 admin administ 292860 Dec 22 00:32 libncursesw.so.5.7* -rw-r--r-- 1 admin administ 98394 Feb 14 2012 libnsl-2.5.so lrwxrwxrwx 1 admin administ 13 Jan 3 11:36 libnsl.so -> libnsl-2.5.so
lrwxrwxrwx 1 admin administ 13 Jan 3 11:36 libnsl.so.1 -> libnsl-2.5.so
-rw-r--r-- 1 admin administ 449090 Feb 14 2012 libopcodes.a -rwxr-xr-x 1 admin administ 945 Feb 14 2012 libopcodes.la* lrwxrwxrwx 1 admin administ 13 Jan 3 10:29 libpanel.so -> libpanel.so.5*
lrwxrwxrwx 1 admin administ 15 Jan 3 10:29 libpanel.so.5 -> libpanel.so.5.7*
-rwxr-xr-x 1 admin administ 8224 Dec 24 06:48 libpanel.so.5.7* lrwxrwxrwx 1 admin administ 14 Jan 3 15:19 libpanelw.so -> libpanelw.so.5*
lrwxrwxrwx 1 admin administ 16 Jan 3 15:19 libpanelw.so.5 -> libpanelw.so.5.7*
-rwxr-xr-x 1 admin administ 8224 Dec 22 00:32 libpanelw.so.5.7* -rw-r--r-- 1 admin administ 1404 Feb 14 2012 libpthread_nonshared.a
lrwxrwxrwx 1 admin administ 16 Jan 3 10:29 libreadline.so -> libreadline.so.6*
lrwxrwxrwx 1 admin administ 18 Jan 3 10:29 libreadline.so.6 -> libreadline.so.6.1*
-r-xr-xr-x 1 admin administ 204696 Feb 14 2012 libreadline.so.6.1* lrwxrwxrwx 1 admin administ 17 Jan 3 11:10 libslang.so -> libslang.so.2.2.3
lrwxrwxrwx 1 admin administ 17 Jan 3 11:10 libslang.so.2 -> libslang.so.2.2.3
-rw-r--r-- 1 admin administ 811612 Feb 23 2012 libslang.so.2.2.3 lrwxrwxrwx 1 admin administ 10 Jan 3 11:10 libss.so -> libss.so.2*
lrwxrwxrwx 1 admin administ 12 Jan 3 11:10 libss.so.2 -> libss.so.2.0*
-rwxr-xr-x 1 admin administ 17036 Feb 14 2012 libss.so.2.0* -rwxr-xr-x 1 admin administ 1308 Feb 15 2012 libstdc++.la* lrwxrwxrwx 1 admin administ 18 Jan 3 15:19 libstdc++.so -> libstdc++.so.6.0.9
lrwxrwxrwx 1 admin administ 18 Jan 3 15:19 libstdc++.so.6 -> libstdc++.so.6.0.9
-rw-r--r-- 1 admin administ 816192 Feb 14 2012 libstdc++.so.6.0.9 -rw-r--r-- 1 admin administ 551800 Feb 15 2012 libsupc++.a -rwxr-xr-x 1 admin administ 1214 Feb 15 2012 libsupc++.la* lrwxrwxrwx 1 admin administ 12 Jan 3 11:10 libuuid.so -> libuuid.so.1*
lrwxrwxrwx 1 admin administ 14 Jan 3 11:10 libuuid.so.1 -> libuuid.so.1.2*
-rwxr-xr-x 1 admin administ 15668 Feb 14 2012 libuuid.so.1.2* drwxr-xr-x 4 admin administ 4096 Jan 3 11:24 perl5/ drwxr-xr-x 2 admin administ 4096 Jan 3 11:10 pkgconfig/ drwxr-xr-x 3 admin administ 4096 Jan 3 11:10 slang/ lrwxrwxrwx 1 admin administ 17 Jan 3 10:29 terminfo -> ../share/terminfo/
drwxr-xr-x 2 admin administ 4096 Jan 3 11:36 thumb2/ [/opt/lib] #

A file libc.so.6 is in /lib. But adding -Fl/lib to the compile line does not change the behavior.

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" directory here, so why did you add that path if it doesn't even exist?

Find crti.o on the device and add that path to -Fl.

Henry

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 directory Thomas instructed me to include in the compiler command line does exit.

Thanks for the hint,
-Michael

While unrelated to your problem: the syntax of the fpc.cfg file is simple. It's main content is just the same options that can be given on the command line of the compiler. Instead of seperating them by spaces they are seperated by newlines though.

Additionally the config file allows conditional configuration by using "define", "ifdef" and co (similar to Pascal code). For this certain defines of the compiler are available as well (like the selected target and whether this is a cross compilation).
Also you can use variables through $name with which you can insert the contents of internal compiler variables (like $fpcversion => 2.7.1) or of environment variables. On Windows systems you can also have access to the CSIDL_... paths (though just now I don't remember how exactly you can access them...).

Regards,
Sven

Thanks for the clarification.

-Michael

Hi,

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 packages I installed. And I don't know how to find out which package might provide it."

Then you go on to look for crti* assembler files in the fpc svn, until I tell you that these are provided by libc-dev package. Which was inexact, and I got confused by your search for crti.o files (well, the answer was exact in that I told you where you can find crti files, i.e. what you asked for, but that was not what you wanted :]).

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 curious.

Libc-dev *also* provides a set of libc-related shared libraries that are seemingly already in /lib. The ones provided by libc-dev export necessary symbols for the linker during linking, the ones in /lib not. That's why you need the -dev packages for all shared libraries you want to link to.

Try objdump -t /lib/libdl-X.X.so and /opt/<wherever>/lib/libdl-X.X.so and see the difference.

If you happen to finally find and specify the correct path to the correct libdl.so it will definitely work. There is no bug in fpc.

Actually the first few answers in this thread already provide hints to find the problem.

Because it's the wrong _init and _fini.

It tries the ones you add with {$linklib}

b) the linker only opens the .o and .a files it is told to use (e.g. in a linker script file - this is what I used in the said "C" projects)

Yes, but it's not useful here.

see above.

2) I suppose in your environment not crti.o, but some library (.a file or maybe some other file somehow specified) is used to resolve the _init and _finit externals.

libdl-<version>.so

3) I understand that for this, that library somehow needs to be specified, as I believe the linker will not on it's own go out and search and open files that might provide these globals.

Already done via {$linklib dl}. This searches for libdl.so in the a) default paths hardcoded into fpc and b) everything specified by -Fl.

You can create one using the install.sh script?

No, per shared library naming convention a "lib" prefix is added.

.a files are used to link a library statically. Not needed here, and you don't use $linklib with them.

hth+sorry,
Thomas

In the Internet, I found the hint to use crti.o. But now I don't believe that this is a valid advice.

The "_init" and "_fini" you need are the ones from libdl.so.

I am very inclined to believe that you are right, but seemingly in my project libdl.so is not linked in (I hope to find out, how an .so is "linked" at compile time, how it is made known to the linker in your environment and why it does not work in my environment, so I'm eagerly reading on....)

Can you explain how you got to the impression that you need a crti.o that provides _init and _fini? Just curious.

Just using Google I found this advice in some forums.

If you happen to finally find and specify the correct path to the correct libdl.so it will definitely work.

I'll try this. But I still fail to understand how the linker is supposed to know that it should look into this file.

There is no bug in fpc.

I hoped this and that is why I did not file a Mantis entry right away.

Yep. In other words: crti.o is the wrong file. (even though (IIRC) it is in the dir you told me to provide in "-Fl"

It tries the ones you add with {$linklib}

That is what I understand, but the line I saw in the unit in question (dl.pp) confusingly is {$linklib c} and there is no c.whatever file that is supposed to be linked in..

> 2) I suppose in your environment not crti.o, but some library (.a file > or maybe some other file somehow specified) is used to resolve the _init > and _finit externals. libdl-<version>.so

I see. The name in fact is "speaking" regarding it is pulled by dl.pp. But the compiler magic creating "linker please look at libdl-<version>.so, and do what is necessary for dynamic library support" from "{$linklib c}" is far beyond my understanding.

> 3) I understand that for this, that library somehow needs to be > specified, as I believe the linker will not on it's own go out and > search and open files that might provide these globals. Already done via {$linklib dl}.

Ahhh. But yet I did not yet see this line. (I just found {$linklib c}). Ill take another look....

This searches for libdl.so in the a) default paths hardcoded into fpc and b) everything specified by -Fl.

I suppose the current directory and instructions from fpc.cfg are additional options.

Which install.sh ? I used the one in the TAR fpc distribution and it did not say it created one and I did not find it one the newly created "installation dir" that I provided as the script asked me. Maybe it overwrote the one in /etc without notice. I'll take another look.

No, per shared library naming convention a "lib" prefix is added.

I see: {$linklib dl} is translated to libdl-<version>.so This does make sense. But in the svn Trunk version of dl.pp there in fact is {$linklib c} this should be translated to libc-<version>.so. I don't know how this is related and maybe {$linklib dl} just is found somewhere else.

Anyway if {$linklib dl} is in the source, a "file not found" error message be issued if libdl-<version>.so is not found, but instead we just see the the unresolved external messages.

.a files are used to link a library statically. Not needed here, and you don't use $linklib with them.

I understand (just curious: is there another {$??? } instruction for static libraries ?

hth+sorry,

I am very happy with all the valuable information I got.

-Michael

Hi,

Actually {$linklib x} searches for libx.so . But libx.so (without version) is typically symlinked to the actual one.

>> 3) I understand that for thut notice. I'll take another look.

If you untar the fpc-<whatever> file there should be an install.sh *if* you downloaded what I think is the tar fpc distribution.

The {$linklib c} is in addition to the external reference to libdl in the function interfaces.

E.g.

function dlclose(Lib : Pointer) : Longint; cdecl; external libdl; <----

and libdl is a constant containing the 'dl' string. Again the usual rules for name expansion apply here.

You may want to look at fpc manuals how to use external libraries and what options there are.

If you untar the fpc-<whatever> file there should be an install.sh *if* you downloaded what I think is the tar fpc distribution.

It would be nice, that if you have more questions about this, and you think it's interesting, define "tar fpc distribution" after all. I.e. give an exact location where you got it from. I seems to me I already asked multiple times for you to tell us, and we still don't know exactly.

dl and its functions are special. They are typically actually implemented in the loader (ld-linux.so) according to some websites. ld-linux.so is more or less a fake shared library, so you cannot link to it in the normal way.

Libdl (and always?) libc both export these symbols. But they are only forwards to ld.so in the end I read somewhere.

E.g. do objdump -t libdl, and at least here, for e.g. dlopen it indicates that it's a forward to the libc function.

For several reasons, compatibility is one, libdl still exists. You can also simply use the c library in some cases it seems. Apparently the original author of the arm/linux port found eons ago that on his arm/linux there was no particular libdl or it did not work without the {$linklib c}, so he added the define. Maybe it just hid a bug that was fixed later and the linklib c forgotten. Don't read too much into some code from r6355, especially it has a comment "arm-linux seems to require this" going with it.

You can also see in dl.pp, that the functions dl provides is in different libraries on different platforms.

Anyway if {$linklib dl} is in the source, a "file not found" error message be issued if libdl-<version>.so is not found, but instead we just see the the unresolved external messages.

FPC is not responsible for gnu ld error messages. Ask them what they thought when implementing this. You could probably also get more detailed information about the linking process in linux with ELF files there too.

Thomas

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 correctly and compile your and my projects.

libdl.so in fact is where you suggested:

===================================================== [/opt/arm-none-linux-gnueabi/lib] # ls -l
-rw-r--r-- 1 admin administ 654 Feb 14 2012 Mcrt1.o -rw-r--r-- 1 admin administ 1508 Feb 14 2012 Scrt1.o -rw-r--r-- 1 admin administ 1508 Feb 14 2012 crt1.o -rw-r--r-- 1 admin administ 1168 Feb 14 2012 crti.o -rw-r--r-- 1 admin administ 827 Feb 14 2012 crtn.o -rw-r--r-- 1 admin administ 2012 Feb 14 2012 gcrt1.o drwxr-xr-x 2 admin administ 4096 Jan 3 11:35 ldscripts/ -rwxr-xr-x 1 admin administ 27344 Feb 14 2012 libcrypt-2.5.so* lrwxrwxrwx 1 admin administ 13 Jan 3 11:36 libcrypt.so -> libcrypt.so.1*
lrwxrwxrwx 1 admin administ 15 Jan 3 11:36 libcrypt.so.1 -> libcrypt-2.5.so*
*-rwxr-xr-x 1 admin administ 15192 Feb 14 2012 libdl-2.5.so*** ****lrwxrwxrwx 1 admin administ 10 Jan 3 11:36 libdl.so -> libdl.so.2***
**lrwxrwxrwx 1 admin administ 12 Jan 3 11:36 libdl.so.2 -> libdl-2.5.so***
***-rwxr-xr-x 1 admin administ 731885 Feb 14 2012 libm-2.5.so* lrwxrwxrwx 1 admin administ 9 Jan 3 11:36 libm.so -> libm.so.6*
lrwxrwxrwx 1 admin administ 11 Jan 3 11:36 libm.so.6 -> libm-2.5.so*
-rwxr-xr-x 1 admin administ 135935 Feb 14 2012 libpthread-2.5.so* lrwxrwxrwx 1 admin administ 15 Jan 3 11:36 libpthread.so -> libpthread.so.0*
lrwxrwxrwx 1 admin administ 17 Jan 3 11:36 libpthread.so.0 -> libpthread-2.5.so*
-rwxr-xr-x 1 admin administ 75709 Feb 14 2012 libresolv-2.5.so* lrwxrwxrwx 1 admin administ 14 Jan 3 11:36 libresolv.so -> libresolv.so.2*
lrwxrwxrwx 1 admin administ 16 Jan 3 11:36 libresolv.so.2 -> libresolv-2.5.so*
-rwxr-xr-x 1 admin administ 40684 Feb 14 2012 librt-2.5.so* lrwxrwxrwx 1 admin administ 10 Jan 3 11:36 librt.so -> librt.so.1*
lrwxrwxrwx 1 admin administ 12 Jan 3 11:36 librt.so.1 -> librt-2.5.so*
-rwxr-xr-x 1 admin administ 13662 Feb 14 2012 libutil-2.5.so* lrwxrwxrwx 1 admin administ 12 Jan 3 11:36 libutil.so -> libutil.so.1*
lrwxrwxrwx 1 admin administ 14 Jan 3 11:36 libutil.so.1 -> libutil-2.5.so*
=====================================================

I understand that you suggested that the advice to pull libdl.so is in dl.pp:

const    LibDL = 'dl';
function dlopen(Name : PChar; Flags : longint) : Pointer; cdecl;
external libdl;

But here (again) I fail to understand how the linker knows that the file libdl.so is the target and not dl.o

For me the show-stopper had been that the linker did not complain that it did not find a file (i.e. libdl.so) that obviously is requested by an appropriate instruction in a pascal unit, but instead complains about unresolved externals.

I have no idea what can be done about this behavior, but I think it's rather nasty.

Thanks again,
-Michael

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 curious.

compiler/systems/t_linux:

 if linklibc and (libctypeuclibc) then
       begin
         { crti.o must come first }
         if librarysearchpath.FindFile('crti.o',false,s) then
           AddFileName(s);
         { then the crtbegin* }

So when the compiler _knows_ it is linking to libc, it will generate a different link.res than without.

The compiler knows simply if the "c" name appears in the libs to link.

So there are actually four cases:

1. static FPC only application.
2. App that links to a library, but not to "c", and the library has no reference to libc.
3. App that links to a library, but not to "c", and the library has a reference to libc.
4. App links to library and C.

Case 1 is all FPC.

Case 2 strictly speaking too, just passes the linked library to the linker in link.res but both compiler and linker don't know libc is linked. So FPC generates a link.res for non libc linking, and ld probably doesn't link libc.

In case 3, while FPC doesn't know about the libc linkage, it generates the link.res like (1). ld knows that something is wrong, and _might_ add c linking though.

Case 4 is the normal situation for libc linking.

So just to make sure that case 4 is always picked, every lib should have a reference to "c". When I reformed the unix lib, the idea was that simply using "initc" should force that. (thus not having the ifdef block with linklibs in _every_ header).