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]