Re: building modules/plugins (GModule) in a portable way

["David Necas (Yeti)" <yeti physics muni cz>]

On Thu, Dec 29, 2005 at 01:15:02PM +0100, Olivier Sessink wrote:
> we have excellent portable GModule functions for module loadingin glib,
> but how do we compile them in a portable way? I thought libtool was the
> solution, but I have little success there.
>
> My plugin uses symbols that are exported by the application, and the
> plugin exports a single symbol to the application.
>
> I therefore, compile my application with
>
> libtool -mode=compile $CC blabla compile flags
>
> and then I link it with
>
> libtool -mode=link $CC -export-dynamic blabla link flags
>
> I compile the plugin with
>
> libtool -mode=compile $CC blabla compile flags
>
> and I link the plugin with
>
> libtool -mode=link $CC -module -export-dynamic blabla link flags
>
> but linking fails.... If I add '-shared' to this command, it succeeds on
> Linux, but it fails on OSX...
>
> So what is the portable way to compile plugins?

What works is to compile most of your app as a shared object
(== library) and make your app executable a more or less
trivial program that links to it.  At least it works on
Linux, *BSD, OS X, and Solaris where I tried that.

On these systems (where libtool's $allow_undefined_flag is
supported) it also isn't necessary to link modules with
anything the program links to, greatly improving linking and
dlopen()ing speed.  Of course, it changes symbol resolution
(to better in my opinion).

Well, this may not be what you want and it may not work
out-of-the-box on Win32 (AFAIK neither does the method you
described).

Yeti


--
That's enough.