Hello Joost,
* Joost Kraaijeveld wrote on Wed, Sep 29, 2010 at 10:46:09PM CEST:
> I have asked this question before, but I got no answer. If I asked it
> the wrong or impolite way: sorry and please forgive me.
No, it's simply that we don't have the manpower to address all bug
reports in a timely manner, or even all bug reports at all; sorry.
> For instance, when ld is called with the argument `-lxxx' it will
> attempt to find, in the first directory of its search path,
>
> libxxx.dll.a
> xxx.dll.a
> libxxx.a
> xxx.lib
> cygxxx.dll (*)
> libxxx.dll
> xxx.dll
>
> But it appears that libtool insists that is *must* be called libxxx.dll
> or otherwise the library is not found. Which is rather annoying because
> several other packages do not use the lib prefix.
Right. libtool should be detecting those without a prefix, and probably
also those with a different one. One place in the current code that is
wrong is this in ltmain:
for searchdir in $searchdirs; do
for search_ext in .la $std_shrext .so .a; do
# Search the libtool library
lib="$searchdir/lib${name}${search_ext}"
Just removing .so on systems where it's irrelevant (or = $std_shrext)
should help efficiency (as this is a fairly tight inner loop). We'd
need to look up whether there are systems accepting .so but have
something different set in $shrext_cmds.
But of course more importantly, other names should be detected as well.
I think one possible approach would be to allow here more general
libname_formats (set in libtool.m4) that for w32 could list the above
possibilities (taking into account std_shrext of course). This could
help a couple of other systems as well (yes, darwin, I'm looking at
you).
A good way to test this would be to create installed libraries with each
of the above naming convention (on suitable systems only, of course),
then remove .la files and the like, and link against them as you would.
Any takers?
Thanks,
Ralf
_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool
