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

[Michael Schnell]

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





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20130125/8e204e0f/attachment.html>