[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: building dynamically loaded modules

From: Ralf Wildenhues
Subject: Re: building dynamically loaded modules
Date: Thu, 5 Jul 2007 20:17:25 +0200
User-agent: Mutt/1.5.13 (2006-08-11)

Hello Thomas,

* Thomas Koeller wrote on Thu, Jul 05, 2007 at 06:47:47PM CEST:
> On Tuesday 03 July 2007 12:17, Ralf Wildenhues wrote:
> > Well, you can just not build the module in this case.  If you're using
> > Automake, you can use a conditional
> > <>
> > based on $enable_shared and just not build the module if it is not
> > "yes".
> But I do want to be able to load modules dynamically, even if the
> rest of the program is linked statically. What I want is something
> like glibc's nsswitch system, where the nss libraries are built as
> shared objects even if enable_shared=no.

This is problematic: if the code expanded from AC_PROG_LIBTOOL sees
enable_shared=no, it will not go through tests/settings that are needed
for dynamic linking.  (At least there exist some systems where this will
fail then.)

So one thing you could do is remember the value of $enable_shared and
set it to "yes", before AC_PROG_LIBTOOL.  Remember $enable_static as
well.  Afterward the macro, both may have changed: $enable_shared could
have been turned off iff libtool does not know how to build shared libs
on the system in question (in which case you should not try to build
modules).  On some systems (notably AIX (without runtimelinking)),
libtool will not build static libraries by default (because names for
both kind coincide).

You can use -static for compilation and linking for the stuff you want
statically iff the user disabled shared libs.  (You could transport this
information to the makefiles via a substituted variable or an Automake

Hope that helps.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]