On Wed, Jan 18, 2006 at 09:26:26AM +0100, Ralf Wildenhues wrote:
> Thanks for the concise bug report. Two comments: your libtest.la
> libraries are convenience archives, so this usage should probably
> be accepted.
ok, we both agree on this :) I believe in this case it should be
fixed. A simple hack that worked for me was to modify
func_extract_archives() in ltmain.sh (around line 330 on 1.5.22),
changing:
my_xdir="$my_gentop/$my_xlib"
to:
my_xdir="$my_gentop/$my_xlib.${RANDOM-0}"
Assuming that $RANDOM comes from a prng with a long period, and that
the clashing libraries will hardly exceed the number of 1-2 on
most environments, it is reasonably safe to assume that no clashing will
ever take place.
The error seems to be reported only while working on .a files, no
warning/error while working on .so files.
> With general libraries, however, using the same name
> for two different libraries is simply not portable -- some systems
> don't have the means to even specify them correctly on the command
> line, some systems simply have a shared library system that does not
> allow two libs with the same soname to be loaded in core simultaneously.
> It should be a rather easy workaround to simply to rename one of the
> libraries; is there a reason this is may be unduly difficult in your
> situation?
actually, my environment is much more complex than the example I provided.
litest.la are both supposed to be _modules_ (to be dlopened), not simple
libraries.
The directory hierarchy is some kind of "namespace", handled
directly by the application itself that takes care of handling path
problems with dlopen & family.
The problem is that some of the modules, choosen at configure time,
are to be compiled into the application itself, to allow the application
to "bootstrap". Those modules are thus compiled twice, in two different
build trees: once, as dynamic modules, and one more time as convenience
libraries.
The binaries that need those modules to "bootstrap" are then linked against
them with simple libtool options. Renaming the module would both imply
a flat namespace, which is something I'd rather try to avoid, and a
complete rework of modules naming conventions (lot of changes in .m4
macros for configure, and a lot of coding).
The curios thing is that from the build tree I generate both a couple
binaries using those convenience libraries with the same name, and
another module to be loaded into an external application that needs
those libraries too to bootstrap.
Well, with the binaries, I don't get any warning nor error, and
they seem to work correctly both on linux and freebsd (uhm.. now
that I look at them, ldd does not list those two libraries in
them... let's look at the options I've used...).
However, it is only the module that triggers the error I just
reported.
If there's something not allowed/portable/..., I'd expect something
like: "moron don't do that!" from libtool...
If you need to, I can do some tests / checks or provide you with
the full command lines used to compile the various components,
or as much help as I can. I'm also open to suggestions...
I know it's something you'd rather try to avoid, but the code I'm
working on is released under GPL. If you need to, you can test it
by yourself by checking it out from the public TLA archives or I
can send you a complete tarball with a brief description of the
installation process.
Forgive my english, hope I've been clear enough and that this
mail is understandable.
Just let me know,
TIA,
Carlo
--
GPG Fingerprint: 2383 7B14 4D08 53A4 2C1A CA29 9E98 5431 1A68 6975
-------------
Yesterday I was a dog. Today I'm a dog. Tomorrow I'll probably still
be a dog. Sigh! There's so little hope for advancement.
-- Snoopy
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
