dynamic linking

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

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

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 .