[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/opc_fitsio.so'
>>
>> 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
>loading.
That's what I had expected at first, even though I still saw them with just
-dlopen.
>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
resolved.
--
--John Gruenenfelder Research Assistant, Steward Observatory, U of Arizona
address@hidden
"This is the most fun I've had without being drenched in the blood
of my enemies!"
--Sam of Sam & Max