Dynamic Linking

Dynamic Linking

[Grant Carter]

Hi

I have been following the thread "Cross-compile Applications for 860 on
x86" and am running into similar problems. I have tried the solutions
that have been suggested but have had no success. Perhaps those
concerned have had private email conversations in which the solution has
been found, but since I cannot find one in the archives that helps me,
I'll post this question. Apologies for its length.

I am trying to get a hello world up and running using dynamically linked
libraries. The statically linked version works fine, so I presume that
the libraries are all fine. I am using linux-2.2.13 with no kernel
floating point support, but all the libraries and executables are
compiled with -msoft-float. I am using SASH-2.1 and it works fine. My
problem is that whenever I run something that I have compiled with the
dynamic linker, it exits on Signal 11.

I have made sure that LD_LIBRARY_PATH is set to /lib (it seems that I
had to do this even though all my libraries are in /lib as without it I
get a 

./hello: error in loading shared libraries: libc.so.6: cannot open
shared object file: No such file or directory

Doing a "strings" on the file shows that it is looking in /lib for
ld.so.1.)

---------------------------------
>powerpc-linux-strings hello
/lib/ld.so.1
__gmon_start__
libc.so.6
printf
_IO_stdin_used
__libc_start_main
GLIBC_2.0
}a[xN
Grant was here!
-----------------------------------

Anyhow, once the LD_LIBRARY_PATH has been set, the libraries are loaded
(or so it seems) Now everything that I run exits with Signal 11. I used
objdump -p on the main executable and saw that it required libc.so.6.
This exists in my /lib directory
-----------------------------------
>powerpc-linux-objdump -p hello

hello:     file format elf32-powerpc

<snip>

Dynamic Section:
  NEEDED      libc.so.6
  INIT        0x100003c8
  FINI        0x100003ec
  HASH        0x10000150
  STRTAB      0x100001c8
  SYMTAB      0x10000178
  STRSZ       0x42
  SYMENT      0x10
  DEBUG       0x0
  PLTGOT      0x100104f8
  PLTRELSZ    0x18
  PLTREL      0x7
  JMPREL      0x10000240
  RELA        0x10000240
  RELASZ      0x18
  RELAENT     0xc
  VERNEED     0x10000220
  VERNEEDNUM  0x1
  VERSYM      0x10000214

Version References:
  required from libc.so.6:
    0x0d696910 0x00 02 GLIBC_2.0
-----------------------------------

Doing the same thing on libc.so.6, I get the following:

-----------------------------------
>powerpc-linux-objdump -p libc.so.6 

libc.so.6:     file format elf32-powerpc

Program Header:
<snip> 

Dynamic Section:
  NEEDED      ld.so.1
  SONAME      libc.so.6
  INIT        0x21cb8
  FINI        0xe0fc8
  HASH        0xf4
  STRTAB      0x9d0c
  SYMTAB      0x2cdc
  STRSZ       0x7ca2
  SYMENT      0x10
  PLTGOT      0x103a9c
  PLTRELSZ    0x150c
  PLTREL      0x7
  JMPREL      0x204d8
  RELA        0x128c4
  RELASZ      0xf2dc
  RELAENT     0xc
  VERDEF      0x127e0
  VERDEFNUM   0x5
  VERNEED     0x12884
  VERNEEDNUM  0x1
  VERSYM      0x119da

Version definitions:
1 0x01 0x0865f4e6 libc.so.6
2 0x00 0x0d696910 GLIBC_2.0
3 0x00 0x0d696911 GLIBC_2.1
        GLIBC_2.0 
4 0x00 0x09691f71 GLIBC_2.1.1
        GLIBC_2.1 
5 0x00 0x09691f72 GLIBC_2.1.2
        GLIBC_2.1.1 

Version References:
  required from ld.so.1:
    0x09691f71 0x00 08 GLIBC_2.1.1
    0x0d696911 0x00 07 GLIBC_2.1
    0x0d696910 0x00 06 GLIBC_2.0
-----------------------------------

And now for ld.so.1

-----------------------------------
>powerpc-linux-objdump -p ld.so.1   

ld.so.1:     file format elf32-powerpc

Program Header:
<snip> 
Dynamic Section:
  SONAME      ld.so.1
  HASH        0x94
  STRTAB      0x838
  SYMTAB      0x2f8
  STRSZ       0xcfc
  SYMENT      0x10
  PLTGOT      0x25fd4
  PLTRELSZ    0x12c
  PLTREL      0x7
  JMPREL      0x2ab0
  RELA        0x167c
  RELASZ      0x1560
  RELAENT     0xc
  VERDEF      0x15fc
  VERDEFNUM   0x4
  VERSYM      0x1554

Version definitions:
1 0x01 0x0275a261 ld.so.1
2 0x00 0x0d696910 GLIBC_2.0
3 0x00 0x0d696911 GLIBC_2.1
        GLIBC_2.0 
4 0x00 0x09691f71 GLIBC_2.1.1
        GLIBC_2.1
-----------------------------------

So in summary, it seems that I have all of the required libraries
(ld.so.1 and libc.so.6) in the right place (/lib) as pointed to my
LD_LIBRARY_PATH and still I get a Signal 11 exit when trying to run it. 

Any ideas would be greatly appreciated.

Regards
Grant

-- 
Grant Carter                              gcarter@eng.uct.ac.za
Department of Electrical Engineering      University of Cape Town
Tel: +27 (0)21 650-3467                   Fax: +27 (0)21 650-3465
                     "Coffee not found - operator halted!"

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: Dynamic Linking

[Jeffrey R. Millar]

Here's a script to test the type of library used by a program.  It was
written by an engineer here at Transcept.  I'll let him take credit
personally
if he wants to.

jeff

		#!/bin/sh

		if test $# = 0; then
		  echo Usage: xfile FILE ...
		  exit
		fi

		for i in "$@"; do
		 echo -n "$i: "
		 
		 if test -f "$i"; then
		  :
		 else
		  echo "doesn't exist"
		  continue
		 fi

		 if file "$i" 2>&1 | grep -q "dynamically linked"; then
		  echo -n "Dynamically linked "
		 elif file "$i" 2>&1 | grep -q "statically linked"; then
		  echo -n "Statically linked "
		 else
		  echo "Not an executable"
		  continue
		 fi

		 if readelf -S "$i" 2>&1 | grep -q "\.note\.ABI-tag";
then
		  echo "with GNU Libc 2"
		 else
		  echo "with old Libc"
		 fi
			done

> ----- Original Message -----
> From: "Grant Carter" <gcarter@eng.uct.ac.za>
> To: "linuxppc-embedded" <linuxppc-embedded@lists.linuxppc.org>
> Sent: Monday, January 17, 2000 9:23 AM
> Subject: Dynamic Linking
> 
> >
> > Hi
> >
> > I have been following the thread "Cross-compile Applications for 860
> on
> > x86" and am running into similar problems. I have tried the
> solutions
> > that have been suggested but have had no success. Perhaps those
> > concerned have had private email conversations in which the solution
> has
> > been found, but since I cannot find one in the archives that helps
> me,
> > I'll post this question. Apologies for its length.
> >
> > I am trying to get a hello world up and running using dynamically
> linked
> > libraries. The statically linked version works fine, so I presume
> that
> > the libraries are all fine. I am using linux-2.2.13 with no kernel
> > floating point support, but all the libraries and executables are
> > compiled with -msoft-float. I am using SASH-2.1 and it works fine.
> My
> > problem is that whenever I run something that I have compiled with
> the
> > dynamic linker, it exits on Signal 11.
> >
> > I have made sure that LD_LIBRARY_PATH is set to /lib (it seems that
> I
> > had to do this even though all my libraries are in /lib as without
> it I
> > get a
> >
> > ./hello: error in loading shared libraries: libc.so.6: cannot open
> > shared object file: No such file or directory
> >
> > Doing a "strings" on the file shows that it is looking in /lib for
> > ld.so.1.)
> >
> > ---------------------------------
> > >powerpc-linux-strings hello
> > /lib/ld.so.1
> > __gmon_start__
> > libc.so.6
> > printf
> > _IO_stdin_used
> > __libc_start_main
> > GLIBC_2.0
> > }a[xN
> > Grant was here!
> > -----------------------------------
> >
> > Anyhow, once the LD_LIBRARY_PATH has been set, the libraries are
> loaded
> > (or so it seems) Now everything that I run exits with Signal 11. I
> used
> > objdump -p on the main executable and saw that it required
> libc.so.6.
> > This exists in my /lib directory
> > -----------------------------------
> > >powerpc-linux-objdump -p hello
> >
> > hello:     file format elf32-powerpc
> >
> > <snip>
> >
> > Dynamic Section:
> >   NEEDED      libc.so.6
> >   INIT        0x100003c8
> >   FINI        0x100003ec
> >   HASH        0x10000150
> >   STRTAB      0x100001c8
> >   SYMTAB      0x10000178
> >   STRSZ       0x42
> >   SYMENT      0x10
> >   DEBUG       0x0
> >   PLTGOT      0x100104f8
> >   PLTRELSZ    0x18
> >   PLTREL      0x7
> >   JMPREL      0x10000240
> >   RELA        0x10000240
> >   RELASZ      0x18
> >   RELAENT     0xc
> >   VERNEED     0x10000220
> >   VERNEEDNUM  0x1
> >   VERSYM      0x10000214
> >
> > Version References:
> >   required from libc.so.6:
> >     0x0d696910 0x00 02 GLIBC_2.0
> > -----------------------------------
> >
> > Doing the same thing on libc.so.6, I get the following:
> >
> > -----------------------------------
> > >powerpc-linux-objdump -p libc.so.6
> >
> > libc.so.6:     file format elf32-powerpc
> >
> > Program Header:
> > <snip>
> >
> > Dynamic Section:
> >   NEEDED      ld.so.1
> >   SONAME      libc.so.6
> >   INIT        0x21cb8
> >   FINI        0xe0fc8
> >   HASH        0xf4
> >   STRTAB      0x9d0c
> >   SYMTAB      0x2cdc
> >   STRSZ       0x7ca2
> >   SYMENT      0x10
> >   PLTGOT      0x103a9c
> >   PLTRELSZ    0x150c
> >   PLTREL      0x7
> >   JMPREL      0x204d8
> >   RELA        0x128c4
> >   RELASZ      0xf2dc
> >   RELAENT     0xc
> >   VERDEF      0x127e0
> >   VERDEFNUM   0x5
> >   VERNEED     0x12884
> >   VERNEEDNUM  0x1
> >   VERSYM      0x119da
> >
> > Version definitions:
> > 1 0x01 0x0865f4e6 libc.so.6
> > 2 0x00 0x0d696910 GLIBC_2.0
> > 3 0x00 0x0d696911 GLIBC_2.1
> >         GLIBC_2.0
> > 4 0x00 0x09691f71 GLIBC_2.1.1
> >         GLIBC_2.1
> > 5 0x00 0x09691f72 GLIBC_2.1.2
> >         GLIBC_2.1.1
> >
> > Version References:
> >   required from ld.so.1:
> >     0x09691f71 0x00 08 GLIBC_2.1.1
> >     0x0d696911 0x00 07 GLIBC_2.1
> >     0x0d696910 0x00 06 GLIBC_2.0
> > -----------------------------------
> >
> > And now for ld.so.1
> >
> > -----------------------------------
> > >powerpc-linux-objdump -p ld.so.1
> >
> > ld.so.1:     file format elf32-powerpc
> >
> > Program Header:
> > <snip>
> > Dynamic Section:
> >   SONAME      ld.so.1
> >   HASH        0x94
> >   STRTAB      0x838
> >   SYMTAB      0x2f8
> >   STRSZ       0xcfc
> >   SYMENT      0x10
> >   PLTGOT      0x25fd4
> >   PLTRELSZ    0x12c
> >   PLTREL      0x7
> >   JMPREL      0x2ab0
> >   RELA        0x167c
> >   RELASZ      0x1560
> >   RELAENT     0xc
> >   VERDEF      0x15fc
> >   VERDEFNUM   0x4
> >   VERSYM      0x1554
> >
> > Version definitions:
> > 1 0x01 0x0275a261 ld.so.1
> > 2 0x00 0x0d696910 GLIBC_2.0
> > 3 0x00 0x0d696911 GLIBC_2.1
> >         GLIBC_2.0
> > 4 0x00 0x09691f71 GLIBC_2.1.1
> >         GLIBC_2.1
> > -----------------------------------
> >
> > So in summary, it seems that I have all of the required libraries
> > (ld.so.1 and libc.so.6) in the right place (/lib) as pointed to my
> > LD_LIBRARY_PATH and still I get a Signal 11 exit when trying to run
> it.
> >
> > Any ideas would be greatly appreciated.
> >
> > Regards
> > Grant
> >
> > --
> > Grant Carter                              gcarter@eng.uct.ac.za
> > Department of Electrical Engineering      University of Cape Town
> > Tel: +27 (0)21 650-3467                   Fax: +27 (0)21 650-3465
> >                      "Coffee not found - operator halted!"
> >
> >

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

dynamic linking

[Martijn Sipkema]

I'm working on a library for accessing MIDI hardware, which uses plugins
to communicate with the hardware. Now I'm not sure how to compile
these shared libraries. Should I use -Bsymbolic? This makes the linker
give a warning when the library is not linked against all the shared
libraries
it needs itself. Still, I don't seem to be able to use the ALSA library (for
rawmidi) when the plugin is not loaded with RTLD_GLOBAL. This may
not be a problem, but I'd like to understand why RTLD_LOCAL won't
work?

Any help would be appreciated.

--martijn




_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth@sourceforge.net

dynamic linking

[Wrazlov]

Hello,
I'd like to write a program that uses plugins, being linked into the program 
while it is running.
That problem is that I don't have any idea about it, and, additionally didn't 
find any manual about that.
 thank you

Re: dynamic linking

[Wrazlov]

*darn* i shouldn't send messages too fast...
I wanted to know if someone could help me... :o)
 thanks..

Re: dynamic linking

[Holger Freyther]

On Sunday 08 September 2002 22:03, Wrazlov wrote:
> *darn* i shouldn't send messages too fast...
> I wanted to know if someone could help me... :o)
>  thanks..
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-c-programming" in the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
Hi,
I'm new to this list and actually didn't read the faq but man dlopen is your 
friend.
After dlopening you need to dlsym the 'entry point' of your plugin


regards Holger
_____________________________________________
Holger 'zecke' Freyther
core member
Project OPIE- the Open Palmtop Integrated Environment
http://opie.handhelds.org | http://www.opie.info (german)
IRC: irc.freenode.net #opie #opie.de

Re: dynamic linking

[Wrazlov]

> Hi,
> I'm new to this list and actually didn't read the faq but man dlopen is
> your friend.
> After dlopening you need to dlsym the 'entry point' of your plugin

Thanks for that, but that's only one part, for I don't know how to compile 
such a lib.so?
Is it possible to import let's say a class using dlopen?

Re: dynamic linking

[Glynn Clements]

Wrazlov wrote:

> > I'm new to this list and actually didn't read the faq but man dlopen is
> > your friend.
> > After dlopening you need to dlsym the 'entry point' of your plugin
> 
> Thanks for that, but that's only one part, for I don't know how to compile 
> such a lib.so?

1. Ensure that the source files are compiled with the "-fPIC" switch,
e.g.
	gcc -c -fPIC -o foo.o foo.c
	gcc -c -fPIC -o bar.o bar.c

2. Link using "gcc -shared ...", e.g.

	gcc -shared -fPIC -o libfoo.so foo.o bar.o

Note: this is sufficient for "private" shared libraries, e.g. plugins. 
If you wish to build "public" shared libraries (to be installed in
e.g. /usr/local/lib), you should add a version, e.g.

	gcc -shared -fPIC -Wl,-soname,libfoo.so.1 -o libfoo.so.1.0 foo.o bar.o
	ln -s libfoo.so.1.0 libfoo.so.1
	ln -s libfoo.so.1.0 libfoo.so

> Is it possible to import let's say a class using dlopen?

No; classes don't exist. At least, they don't exist as data within a
binary (object file, library, executable). Classes only exist within
the C++ compiler. The object files only contain individual functions
and (global) variables.

While it is possible to dynamically load libraries which are written
in C++, it's a lot easier if you write C wrappers for the entry
points.

-- 
Glynn Clements <glynn.clements@virgin.net>

Re: dynamic linking

[Progga]

[-- Attachment #1: Type: text/plain, Size: 638 bytes --]

On Monday 09 Sep 2002 11:06 am, Wrazlov wrote:
> > Hi,
> > I'm new to this list and actually didn't read the faq but man dlopen is
> > your friend.
> > After dlopening you need to dlsym the 'entry point' of your plugin
>
> Thanks for that, but that's only one part, for I don't know how to compile
> such a lib.so?
> Is it possible to import let's say a class using dlopen?
>

    Please see whether libtool and libltdl can help you. I just had a glimpse 
of "$info libtool". 

Khoda Hafez
Progga

** I once learned to use "libtool"  and wrote a nano manual for future  
   reference. I have attached it with the mail.

[-- Attachment #2: LIBTOOL.TXT --]
[-- Type: text/plain, Size: 1960 bytes --]




                                 Manual de libtool
                            ***************************
                                     ( 1.0 )


                "libtool" is the programme for creating static and shared libraries .

   It's part of the GNU binutils ( Binary Utilities ) . The tool for creating Dynamic

   linker libraries is "dlltool" which isn't present in the Redhat Linux 7.0

   distribution .



         To create a static library , do the following :


         $ c++ -c del.c++  ( this will create del.o - the object code )


         $ ar cru libdel.a del.o   ( this will create libdel.a - the static library )

         $ ranlib libdel.a   ( this will test libdel.a )




         To create a shared library , do the following :



         $ libtool c++ -c del.c++  ( this will create del.lo )

         $ libtool c++ -o libdel.la del.lo -rpath /usr/lib

        ( this will create libdel.la and libdel.so , libdel.so.0 etc in the .libs

          directory which is hidden . )



          Now copy the libdel.so , libdel.so.0 and libdel.so.0.0.0 to the /usr/lib

  directory . The  "-rpath" option is needed to create the *.so files , though it

  won't place them in the /usr/lib directory . It's a good practice to test the del.c++

  file before making it a shared or static library by combining it with any C++ file

  having the main function . The strace utility can be a handy tool to watch the linking

  process if anything goes wrong . Various libraries are located in the /usr/lib/*

  directories and are loaded successfully while execution takes place , but I have

  so far failed to use this feature . So the new libraries must be placed in the /usr/lib

  or the /lib directory instead of /usr/lib/* or /lib/* directories .




  ** To use strace write "$ strace executive_file_name " and press enter .


  *** The argument for "-rpath" option can be any valid pathname instead of /usr/lib .

Re: dynamic linking

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1096 bytes --]

On Mon, 2002-09-09 15:24:57 +0100, Glynn Clements <glynn.clements@virgin.net>
wrote in message <15740.44857.172146.892963@cerise.nosuchdomain.co.uk>:

> > Is it possible to import let's say a class using dlopen?
> 
> No; classes don't exist. At least, they don't exist as data within a
> binary (object file, library, executable). Classes only exist within
> the C++ compiler. The object files only contain individual functions
> and (global) variables.
> 
> While it is possible to dynamically load libraries which are written
> in C++, it's a lot easier if you write C wrappers for the entry
> points.

For each classes constructor, also create a C'ish function exporting a
instantiated class as a void pointer. Then, you'll get access to classes
within the object file (*).

MfG, JBG
(*) It's more or less the only way, but personally I don't like OO
programming, so I don't use it, but co-workers of me do.

-- 
Jan-Benedict Glaw   .   jbglaw@lug-owl.de   .   +49-172-7608481
	 -- New APT-Proxy written in shell script --
	   http://lug-owl.de/~jbglaw/software/ap2/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]