[Top][All Lists]

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

Re: More libltdl problems

From: John Gruenenfelder
Subject: Re: More libltdl problems
Date: Thu, 16 Aug 2001 17:46:24 -0700
User-agent: Mutt/1.3.20i

On Thu, Aug 16, 2001 at 11:48:57PM +0100, Gary V. Vaughan wrote:
>On Wednesday 15 August 2001 2:58 am, John Gruenenfelder wrote:
>> After my program loads a modules, it tries to get the symbol
>> "module_definition" out of the module.  This is now failing with an
>> "unknown error" message.  By poking around in ltdl.c, I can see that the
>> symbol name it is searching for is correctly
>> "opc_fitsio_LTX_module_definition", yet it cannot find it.
>Perhaps you could download some of the model examples from the Goat Book web 
>pages (link in my .sig) and play with them to get a better feel for how this 
>stuff all fits together?

Oh yes, I'm quite familiar with it.  It was *VERY* helpful it making all this
work together.  I've done a lot of C work, and Makefiles are no problem, but
starting from scratch with autoconf, automake, and libtool all at once was
quite daunting.  The book helped a lot.  And I've been through most of the
examples, as they were how I figured out how a lot of this works.

>> Also of note:  I remember that at the end of the compilation phase, libtool
>> would extract symbols for every file I had named with '-dlopen' in the
>> Makefile, giving lines like:
>>   extracting global C symbols from `../modules/.libs/'
>> It does not do this anymore.  If I change the Makefile to use -dlpreopen, I
>> once again see these lines, but the symbols still cannot be loaded.
>> Am I doing something wrong, or is libltdl?
>Neither.  If you use -dlpreopen, the static version of the named module will 
>be linked into the executable (pre-loaded) so that the calls to lt_dlopen 
>will work even on static only platforms.  The extraction phase you are seeing 
>is some of the plumbing to make this work.
>With -dlopen, libtool will fallback on preopening if there are no shared 
>components to the modules you name, otherwise it has no effect on module 

That's what I had expected at first, even though I still saw them with just

>Curiously, in either case (even when the module is preloaded) an appropriate 
>.la file needs to be present in the module load path for loading to work.

They are definitely present in the target installation directory, along with
the actual .so libraries.  When I load a module, I am requesting it without a
suffix (using dl_openext).

I went back to using the July release of libtool 1.4 and it seems happy once
again.  I'll try the CVS code sometime to see if the problems have been

--John Gruenenfelder    Research Assistant, Steward Observatory, U of Arizona
"This is the most fun I've had without being drenched in the blood
of my enemies!"
        --Sam of Sam & Max

reply via email to

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