HP-UX hppa64 and gcc
Libtool 1.5.22 There is a problem on HP-UX 64 bit when using gcc. Problem is at line 3167 in libtool.m4 : _LT_AC_TAGVAR(hardcode_libdir_flag_spec_ld, $1)='+b $libdir' gcc doesn't like that ! Roger While ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: HP-UX hppa64 and gcc
OK. So what should this area of code look like ?
(ie. What's with the export dynamic) :
Starting at line 3160
hpux10*|hpux11*)
if test $with_gnu_ld = no; then
_LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}+b ${wl}$libdir'
_LT_AC_TAGVAR(hardcode_libdir_separator, $1)=:
case $host_cpu in
hppa*64*|ia64*)
_LT_AC_TAGVAR(hardcode_libdir_flag_spec_ld, $1)='+b $libdir'
;;
*)
_LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
;;
esac
fi
case $host_cpu in
hppa*64*|ia64*)
_LT_AC_TAGVAR(hardcode_direct, $1)=no
_LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
;;
*)
_LT_AC_TAGVAR(hardcode_direct, $1)=yes
_LT_AC_TAGVAR(hardcode_minus_L, $1)=yes # Not in the search PATH,
# but as the default
# location of the library.
;;
esac
Roger While
> Albert Chin wrote:
On Wed, Jan 04, 2006 at 10:19:27AM +0100, Roger While wrote:
> Libtool 1.5.22
> There is a problem on HP-UX 64 bit when using gcc.
> Problem is at line 3167 in libtool.m4 :
> _LT_AC_TAGVAR(hardcode_libdir_flag_spec_ld, $1)='+b $libdir'
>
> gcc doesn't like that !
We can ditch hardcode_libdir_flag_spec_ld for HP-UX.
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
Spaces in path names
Per Subject. Libtool 1.5.22 I found some earlier mails about this from 2005. Is anything being/going to be done about this ? This is a real pain on most Cygwin machines where users are likely to have spaces in path names (eg. in HOME - "Roger While"). Roger While ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Spaces in path names
Hi Ralf,
Well, how ARE you supposed to get around this ?
Here's an excerpt :
HOME is /cygdrive/c/Dokumente und Einstellungen/Roger While
build directory is $HOME/open-cobol-0.33
Interesting is that previously the shared library has been succesfully created.
(in libcob) - So libtool is obviously doing something right.
ie. Compilations and creating the libcob dll were successful.
Here we are trying to link a binary -
- Snip
make all-recursive
make[1]: Entering directory `/cygdrive/c/Dokumente und Einstellungen/Roger
While/open-cobol-0.33'
Making all in lib
make[2]: Entering directory `/cygdrive/c/Dokumente und Einstellungen/Roger
While/open-cobol-0.33/lib'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/cygdrive/c/Dokumente und Einstellungen/Roger
While/open-cobol-0.33/lib'
Making all in libcob
make[2]: Entering directory `/cygdrive/c/Dokumente und Einstellungen/Roger
While/open-cobol-0.33/libcob'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/cygdrive/c/Dokumente und Einstellungen/Roger
While/open-cobol-0.33/libcob'
Making all in cobc
make[2]: Entering directory `/cygdrive/c/Dokumente und Einstellungen/Roger
While/open-cobol-0.33/cobc'
make all-am
make[3]: Entering directory `/cygdrive/c/Dokumente und Einstellungen/Roger
While/open-cobol-0.33/cobc'
make[3]: Nothing to be done for `all-am'.
make[3]: Leaving directory `/cygdrive/c/Dokumente und Einstellungen/Roger
While/open-cobol-0.33/cobc'
make[2]: Leaving directory `/cygdrive/c/Dokumente und Einstellungen/Roger
While/open-cobol-0.33/cobc'
Making all in bin
make[2]: Entering directory `/cygdrive/c/Dokumente und Einstellungen/Roger
While/open-cobol-0.33/bin'
echo "/bin/sh ../libtool --tag=CC --mode=link gcc -fsigned-char -Wall
-Wwrite-strings -Wmissing-prototypes -Wno-format-y2k -O2 -march=i686
-mtune=pentium2 -finline-functions -fomit-frame-pointer
-Wl,--export-all-symbols -Wl,--enable-auto-import -o
cobcrun.exe cobcrun-cobcrun.o -lm -ldb-4.3 -lgmp -lintl -lncurses
-L../libcob/.libs -lcob "
/bin/sh ../libtool --tag=CC --mode=link gcc -fsigned-char -Wall
-Wwrite-strings -Wmissing-prototypes -Wno-format-y2k -O2 -march=i686
-mtune=pentium2 -finline-functions -fomit-frame-pointer
-Wl,--export-all-symbols -Wl,--enable-auto-import -o
cobcrun.exe cobcrun-cobcrun.o -lm -ldb-4.3 -lgmp -lintl -lncurses
-L../libcob/.libs -lcob
libtool: link: cannot find the library `' or unhandled argument `und'
make[2]: *** [cobcrun.exe] Error 1
make[2]: Leaving directory `/cygdrive/c/Dokumente und Einstellungen/Roger
While/open-cobol-0.33/bin'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/cygdrive/c/Dokumente und Einstellungen/Roger
While/open-cobol-0.33'
make: *** [all] Error 2
End snip
("Dokumente und Einstellungen/" is default HOME for Cygwin on German
Win2K/XP)
Roger
Hi Roger,
* Roger While wrote on Thu, Jan 12, 2006 at 11:06:51AM CET:
>
> I found some earlier mails about this from 2005.
> Is anything being/going to be done about this ?
> This is a real pain on most Cygwin machines
> where users are likely to have spaces in
> path names (eg. in HOME - "Roger While").
No, unfortunately that has not been addressed yet.
Volunteers are few and bug count is not low, which
forces me to prioritize bugs that can not be worked
around.
Sorry,
Ralf
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Spaces in path names
Actually on Cygwin (and MingW) this whole thing is caused by the following lines in ltmain.sh : -L*) dir=`$echo "X$arg" | $Xsed -e 's/^-L//'` # We need an absolute path. case $dir in [\\/]* | [A-Za-z]:[\\/]*) ;; *) absdir=`cd "$dir" && pwd` And there is the probem. Replacing that last line with a simple absdir="$dir" and, what do you know, everything works as it should. Of course, leaving as original, it is a heck of a problem trying to trace further usage of absdir and dir. THe question is, of course, what is the downside of this change (locally for our product). Roger On Thu, 12 Jan 2006, Roger While wrote: Hi Ralf, Well, how ARE you supposed to get around this ? Here's an excerpt : HOME is /cygdrive/c/Dokumente und Einstellungen/Roger While build directory is $HOME/open-cobol-0.33 Due to the many layers of shell scripting in libtool, supporting spaces in filenames is complicated and must be proven for every case. It is a huge job. Since you are using Cygwin, you should be able to use Cygwin's 'mount' facility to map the problem path so that it appears as a path without spaces in the name. Of course, this approach is not as user friendly as it could be and requires extra effort on the part of the person who builds the package. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Spaces in path names
Hmm. Derek's patch is interesting. As an addendum to your mail commenting on Derek's mail (July 8 2005), note : (One of a few places) +_LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='\"-L$libdir\"' That, I think, is wrong. Should be ='-L\"$libdir\"' or ? Is/has anything going/gone on regarding this issue in CVS/2.x ? Roger > Ralf wrote: Hi Kurt, * Kurt Roeckx wrote on Thu, Jan 12, 2006 at 11:38:38PM CET: > On Thu, Jan 12, 2006 at 11:06:51AM +0100, Roger While wrote: > > > > I found some earlier mails about this from 2005. > > Is anything being/going to be done about this ? > > This is a real pain on most Cygwin machines > > where users are likely to have spaces in > > path names (eg. in HOME - "Roger While"). > > Debian has a open bug about this with has a patch at: > http://bugs.debian.org/193163 > And it seems this has been mailed to bug-libtool@gnu.org too. Oh well. > I do not believe the patch is complete, but might be something > you can start with if you really want to get this working. The attempt by Derek Price is *much* *much* more complete and useful. http://lists.gnu.org/archive/html/libtool-patches/2005-07/msg00047.html (This is mentioned on http://tkd.kicks-ass.net/GnuLibtoolProject/RoadMap by the way.) Please don't do the same work again, needlessly: the mentioned thread also explains why we could not apply the patch as-is; in addition to the fact that comprehensive testing is necessary (stresstest.at may be useful for that part). Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Spaces in path names
OK. I did not look at the actual usage of this example, but what is definitely true is that the resultant command passed to gcc/linker whatever, must have the quotes ala. -L"my space dir". I think we agree on that. On an aside note, it seems that autoconf is also busted here. Specifically autotest is blown eg. for as_dir in $PATH do IFS=$as_save_IFS test -z "$as_dir" && as_dir=. test -f $as_dir/$at_program && break done or : rm -rf $at_group_dir mkdir $at_group_dir || Hmm. Roger [ Cc:ing Derek, maybe he's still interested; this is http://thread.gmane.org/gmane.comp.gnu.libtool.general/7091 ] * Roger While wrote on Fri, Jan 13, 2006 at 11:27:23AM CET: > Hmm. Derek's patch is interesting. > As an addendum to your mail commenting > on Derek's mail (July 8 2005), note : > (One of a few places) > +_LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='\"-L$libdir\"' > > That, I think, is wrong. Should be > ='-L\"$libdir\"' > or ? No, that difference does not matter. You may want to get more familiar with how Bourne shells do word splitting. For example, test $foo = "no" (a common idiom seen in user's scripts) is wrong: the right hand side contains nothing (parameter expansions like $foo, or command substitutions like `ls`) that will introduce white space that will be word-split, unlike the left-hand side. Thus, the right way (with minimal quoting) would be test "$foo" = no If it's unclear whether $foo may start with a hyphen, the common idiom is test "X$foo" = Xno or, with minimal quoting, test X"$foo" = Xno Because the shell does not word-split on the right hand side of assignments, this: foo="$bar" can always safely be written as foo=$bar and this: foo="$bar $baz" as foo=$bar" "$baz or even foo=$bar\ $baz It's just that the former versions are often easier to read and help avoid bugs. > Is/has anything going/gone on regarding this issue in CVS/2.x ? No, not yet. I do have a couple of suggestions though for someone ambitious to work on this: I would be much more easy with integrating this if it were more backwards-compatible. One possibility could be to quote path names in .la files *only* if the have to be quoted. IOW, one common idiom in ltmain could be case $dir in *[$IFS]*) foo_dir="$foo_dir \"$dir\"" ;; *)foo_dir="$foo_dir $dir" ;; esac and it would be useful to factor this out in a small shell function; it would also be necessary to check whether above works with all kinds of shells. That way at least all other users would not see dramatical changes, libltdl would continue to work for them, and all in all we could incrementally(!) fix each occurrence of missing quotes, while as long as unfinished, only users of paths with spaces would be impacted. Pleas note also that my followup comment[1] contained a glitch itself, unfortunately: >> @@ -1043,7 +1043,7 @@ EOF >> compiler_flags= >> linker_flags= >> dllsearchpath= >> -lib_search_path=`pwd` >> +lib_search_path=\"`pwd`\" > >This change is not necessary. The general rule is, that command >substitutions and variable expansions do not get word-split in >assignments and in the word after `case'. This comment is wrong, the code was ok. I misread lib_search_path=\"`pwd`\" for lib_search_path="`pwd`" Cheers, Ralf [1] http://lists.gnu.org/archive/html/libtool-patches/2005-07/msg00051.html ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Spaces in path names
Hi Roger,
* Roger While wrote on Mon, Jan 16, 2006 at 12:29:39PM CET:
> OK. I did not look at the actual usage of this example,
> but what is definitely true is that the resultant command
> passed to gcc/linker whatever, must have the quotes
> ala. -L"my space dir". I think we agree on that.
No, we don't. I think you are misunderstanding something here.
If you do this:
gcc -o foo foo.o -L"my space dir" -lbar
But that is exactly what I said.
("Resultant command")
then your system generates a command line for gcc that contains in argv
these elements (elements separated by newlines):
gcc
-o
foo
foo.o
-Lmy space dir
-lbar
NULL
The quoting is merely to instruct the shell not to do word-splitting at
this point. Please read a good tutorial about Bourne-like shell command
language.
You could try this small shell script to see this for yourself:
--- cut here ---
#! /bin/sh
for arg
do
printf "Argument given: '%s'\n" "$arg"
done
--- cut here ---
Call it with -L"foo bar" or "-Lfoo bar" as argument.
Yes, this is clear. I was talking about the
resultant command as you would type it.
Roger
> On an aside note, it seems that autoconf is also
> busted here. Specifically autotest is blown
> eg.
Oh, there are many many instances all over all of the autotools where
you will encounter issues. One reason why we're trying to tell you that
it is far easier to work around it on your side.
Cheers,
Ralf
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: handling of missing AR
For IBM AIX 64-bit we need AR="ar -X64" and NM="nm -X64 -B" assuming /usr/ccs/bin is first in the path. (If you can detect you are building for AIX 64 then you can check /usr/ccs/bin and use absolute path in assignment) Roger Rolf wrote : I have seen very few uses where AR was actually set manually. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool and MingW, MSVC support
Look at what we have in OpenCOBOL for
dynamic loading of modules :
#ifdef USE_LIBDL
#include
#define lt_dlopen(x)dlopen(x, RTLD_LAZY | RTLD_GLOBAL)
#define lt_dlsym(x, y) dlsym(x, y)
#define lt_dlclose(x) dlclose(x)
#define lt_dlerror()dlerror()
#define lt_ptr_tvoid *
#define lt_dlhandle void *
#elif defined(_WIN32)
#include
/* Prototype */
static char * lt_dlerror (void);
static HMODULE
lt_dlopen (const char *x)
{
if (x == NULL) {
return GetModuleHandle(NULL);
}
return LoadLibrary(x);
}
#define lt_dlsym(x, y) GetProcAddress(x, y)
#define lt_dlclose(x) FreeLibrary(x)
static char errbuf[64];
static char *
lt_dlerror()
{
sprintf(errbuf, "LoadLibrary/GetProcAddress error %d",
(int)GetLastError());
return errbuf;
}
#define lt_ptr_tvoid *
#define lt_dlinit()
#define lt_dlhandle HMODULE
#else
#define LT_NON_POSIX_NAMESPACE 1
#include
#endif
The app is coded to use the lt_dl calls.
Configure sorts out when USE_LIBDL is set
(native loading, eg. Linux, Cygwin), else redefine when Windows, else
use ltdl.
Roger
___
http://lists.gnu.org/mailman/listinfo/libtool
HP-UX shared lib detection (1.5.24)
Go this on HP-UX 11 64-bit using stable 1.5.24 - *** Warning: linker path does not have real file for library -ldb. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libdb and none of the candidates passed a file format test *** using a file magic. Last file checked: /home/proghome/wgay/local/lib/libdb-4.5.sl *** The inter-library dependencies that have been dropped here will be *** automatically added whenever a program is linked with this library *** or is declared to -dlopen it. Problem is the file magic test. Here is what "file" produces - $ file /home/proghome/wgay/local/lib/libdb-4.5.sl /home/proghome/wgay/local/lib/libdb-4.5.sl: ELF 64-bit MSB shared object, PA-RISC 2.0 (LP64) version 1, not stripped which trips up when setting the deplibs_check_method. Got a quick fix? Roger While ___ http://lists.gnu.org/mailman/listinfo/libtool
HP-UX shared lib detection (1.5.24)
Some more info - Using different "file" versions $ file /home/proghome/wgay/local/lib/libdb-4.5.sl /home/proghome/wgay/local/lib/libdb-4.5.sl: ELF 64-bit MSB shared object, PA-RISC 2.0 (LP64) version 1, not stripped $ /usr/bin/file /home/proghome/wgay/local/lib/libdb-4.5.sl /home/proghome/wgay/local/lib/libdb-4.5.sl: ELF-64 shared object file - PA-RISC 2.0 (LP64) Note that in _both_ cases, there is a space after "PA-RISC". Trying a 32-bit shared library gives these results: $ file /usr/lib/liby.2 /usr/lib/liby.2: PA-RISC1.0 shared library - not stripped $ /usr/bin/file /usr/lib/pa2.0/libF90.1 /usr/lib/pa2.0/libF90.1:PA-RISC2.0 shared library -not stripped $ /home/proghome/wgay/local/bin/file /usr/lib/pa2.0/libF90.1 /usr/lib/pa2.0/libF90.1: PA-RISC2.0 shared library - not stripped In all the 32-bit versions of shared libraries, it seems that the blank is absent between PA-RISC and the x.x. Roger While ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: HP-UX shared lib detection (1.5.24)
Hi Ralf, host='hppa2.0w-hp-hpux11.11' host_alias='' host_cpu='hppa2.0w' host_os='hpux11.11' It's being passed +DA2.0W not +DD64 as documented by HP for PA. AFAIK, DD64 was meant for IA64. Roger Hello Roger, * Roger While wrote on Wed, Oct 31, 2007 at 04:55:09PM CET: > In all the 32-bit versions of shared libraries, it seems that > the blank is absent between PA-RISC and the x.x. What's the value of $host in the generated libtool file? The trick to get config.guess to compute for example hppa64-hp-hpux11.23 rather than hppa2.0w-hp-hpux11.23 is to pass for example this to configure: ./configure CC='cc +DD64' or to specify --host, but somewhere you have to specify 64bit mode anyway. Hope that helps. Please report back if it doesn't. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: HP-UX shared lib detection (1.5.24)
Hi Ralf, Ok, I tried out the 2 recommendations : >Still, please try either (both) of > ./configure CC="cc +DA2.0W" > ./configure --host=hppa64-hp-hpux11.11 ... Using --host produced messages to the effect --build should be used unless doing a cross compile. I tried both, and both were successful, but --build didn't produce the --host warning. The CC="cc +DA2.0W" did NOT work, producing the same libtool error I reported earlier. So now the HPUX 64 build configure amounts to this: ./configure \ --build=hppa64-hp-hpux11.11 \ --prefix=$HOME/local \ --disable-static \ CPPFLAGS=-I$HOME/local/include \ LDFLAGS=-L$HOME/local/lib \ CPP="cc -E" \ CFLAGS="+DA2.0W" \ CC=cc I have to keep the CFLAGS="+DA2.0W" there otherwise the configure script will choke with: configure:2435: checking for C compiler default output file name configure:2438: cc -I/home/proghome/wgay/local/include -L/home/proghome/wgay/local/lib conftest.c >&5 /usr/ccs/bin/ld: /usr/lib/pa20_64/libc.sl: Mismatched ABI. 64-bit PA shared library found in 32-bit link. * Roger While wrote on Wed, Oct 31, 2007 at 08:13:45PM CET: > host='hppa2.0w-hp-hpux11.11' > host_alias='' > host_cpu='hppa2.0w' > host_os='hpux11.11' > > It's being passed +DA2.0W not +DD64 as documented by HP > for PA. > > AFAIK, DD64 was meant for IA64. Ah, ok I was looking at older documentation that listed +DD64 as "currently equivalent to +DA2.0W." Still, please try either (both) of ./configure CC="cc +DA2.0W" ./configure --host=hppa64-hp-hpux11.11 ... and report which helps to build the application correctly (both should). If either one fails, please send for it the output of ./libtool --config Thanks, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
RE: Re: HP-UX shared lib detection (1.5.24)
Hi Warren, Which exactly solves the prob? I think the --build but ? However why should this not be ato-determined? 2.0W is always 64-bit. Roger Hi Roger: I forgot to mention that +DA2.0W and +DD64 are treated as equivalent on our platform. Warren. -Original Message- From: Roger While [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 31, 2007 4:54 PM To: Gay, Warren Cc: [EMAIL PROTECTED] Subject: Fwd: Re: HP-UX shared lib detection (1.5.24) Hi Warren, Some more from libtool list - Can you try as suggested at the bottom. Roger >Date: Wed, 31 Oct 2007 20:25:30 +0100 >From: Ralf Wildenhues <[EMAIL PROTECTED]> >To: Roger While <[EMAIL PROTECTED]> >Cc: libtool@gnu.org >Subject: Re: HP-UX shared lib detection (1.5.24) >Mail-Followup-To: Roger While <[EMAIL PROTECTED]>, libtool@gnu.org >Organization: Department of Numerical Simulation, University of Bonn >User-Agent: Mutt/1.5.13 (2006-08-11) >X-Spam: [F=0.3685210354; heur=0.500(-16300); stat=0.368; >spamtraq-heur=0.500(2007101727)] >X-MAIL-FROM: <[EMAIL PROTECTED]> >X-SOURCE-IP: [131.220.223.13] >X-SF-Loop: 1 >X-SIMBasis-MailScanner-Information: Please contact the ISP for more >information >X-SIMBasis-MailScanner: Found to be clean >X-SIMBasis-MailScanner-SpamCheck: not spam, SpamAssassin (score=-2.599, > required 5, autolearn=not spam, BAYES_00 -2.60) >X-SIMBasis-MailScanner-From: [EMAIL PROTECTED] > >* Roger While wrote on Wed, Oct 31, 2007 at 08:13:45PM CET: > > host='hppa2.0w-hp-hpux11.11' > > host_alias='' > > host_cpu='hppa2.0w' > > host_os='hpux11.11' > > > > It's being passed +DA2.0W not +DD64 as documented by HP > > for PA. > > > > AFAIK, DD64 was meant for IA64. > >Ah, ok I was looking at older documentation that listed +DD64 as >"currently equivalent to +DA2.0W." > >Still, please try either (both) of > ./configure CC="cc +DA2.0W" > ./configure --host=hppa64-hp-hpux11.11 ... > >and report which helps to build the application correctly (both should). >If either one fails, please send for it the output of > ./libtool --config > >Thanks, >Ralf This e-mail and any attachments may contain confidential information. Any distributing, copying or reliance upon the contents of this e-mail by anyone other than the intended recipient is strictly prohibited. If you have received this e-mail accidentally, please delete it and notify the sender. Although this message has been screened for viruses, we cannot guarantee that our virus scanner will detect all viruses and take no responsibility for any damage or loss that may be caused by its contents. Ce courriel et toutes les pièces jointes peuvent contenir des renseignements confidentiels dont la diffusion, reproduction ou utilisation par quiconque autre que le destinataire est interdite. S'il vous a été transmis par erreur, veuillez en informer l'expéditeur et le supprimer. Ce courriel a été vérifié avec un logiciel de détection de virus mais nous ne pouvons pas garantir qu'il détecte tous les virus et déclinons toute responsabilité quant aux dommages ou pertes découlant de son contenu. ___ http://lists.gnu.org/mailman/listinfo/libtool
HP-UX shared lib detection (1.5.24)
The command: ./configure --build=hppa64-hp-hpux11.11 ... CFLAGS="+DA2.0W" worked, with the proviso that I had to add the CFLAGS= for the configure script (its tests would bomb). As far as --host vs --build, they both work. --host just whines about whether it is a cross compile or not. Question is why is --build necessary? Roger ___ http://lists.gnu.org/mailman/listinfo/libtool
