Is libtool 1.4 dead and buried forever?
Subject line says is all really, I ask because I've cleaned up the Debian libtool 1.4 package and got a small handful of patches which could be useful if anyone forsees a libtool 1.4.4 coming up at any point in the future. If not no worries, a couple of these patches need to be applied to 1.5 too anyway, and once I've tested them I'll send a few mails to libtool-patches with them. Scott signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Is libtool 1.4 dead and buried forever?
The 1.4 release cycle is officially finished. We encourage everyone to use 1.5 (or development 1.5.0a), and to submit patches to fix any flaws. Bob On 30 Jul 2003, Scott James Remnant wrote: Subject line says is all really, I ask because I've cleaned up the Debian libtool 1.4 package and got a small handful of patches which could be useful if anyone forsees a libtool 1.4.4 coming up at any point in the future. If not no worries, a couple of these patches need to be applied to 1.5 too anyway, and once I've tested them I'll send a few mails to libtool-patches with them. Scott == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
libtool 1.4 branch and IRIX 6.x
When using CC=cc on IRIX 6.x, ld is used to create shared libraries.
However:
hardcode_libdir_flag_spec='${wl}-rpath ${wl}$libdir'
This causes -Wl,-rpath to be passed to ld. Unfortunately, ld
recognizes -rpath but not -Wl so we get errors like:
(null): WARNING 1 : Unknown option: Wl,-rpath (ignored).
So, the solution would seem to be the patch below. However, after
applying this patch and running 'make check', build-relink2 dies at
the end:
if test $shlibpath_overrides_runpath != yes; then
rm -f $objdir/lt-depdemo || exit 1
cp $objdir/depdemo $objdir/lt-depdemo || exit 1
echo running ../depdemo/depdemo with installed libl3.la
if ./depdemo; then
echo Worked, as expected
else
echo shlibpath_overrides_runpath should be set to yes
status=1
fi
rm -f $objdir/lt-depdemo
fi
For IRIX 6.x:
shlibpath_overrides_runpath = no
because, according to rld(5):
The search path for shared objects is as follows:
1. The path of the shared object, if specified in the liblist. That
is, if the soname of the shared object has a path. For more
information, see the ld(1) man page.
2. DT_RPATH, if it is defined in the executable or any DSO that rld
has opened.
3. Use LD_LIBRARY_PATH, if it is defined in the environment at the
time of execution.
4. The default library search path.
However:
$ elfdump -L depdemo/.libs/depdemo | grep RPATH
/opt/build/libtool-1.4.2/depdemo/l1/.libs:/opt/build/libtool-1.4.2/tests/_inst/lib:/opt/build/libtool-1.4.2/depdemo/l2/.libs:/opt/build/libtool-1.4.2/depdemo/l3/.libs:/opt/build/libtool-1.4.2/tests/_inst/lib/extra
Both /opt/build/libtool-1.4.2/depdemo/l3/.libs and
/opt/build/libtool-1.4.2/tests/_inst/lib/extra contain libl3.so.1.0 so
the version in /opt/build/libtool-1.4.2/depdemo/l3/.libs is selected
as it is first in the search path. However, before the
shlibpath_overrides_runpath test, we broke libl3.so.1.0 earlier in
build-relink2 so libl3.so.1.0 does not contain var_l3. This results
in:
$ .libs/depdemo
174396:./depdemo: rld: Error: unresolvable symbol in
/opt/build/libtool-1.4.2/tests/_inst/lib/libl4.so.1: var_l3
174396:./depdemo: rld: Fatal Error: this executable has unresolvable
symbols
causing the test to fail. So, is build-relink2.test broken?
--
albert chin ([EMAIL PROTECTED])
-- snip snip
Index: libtool.m4
===
RCS file: /cvsroot/libtool/libtool/libtool.m4,v
retrieving revision 1.166.2.32
diff -u -3 -p -r1.166.2.32 libtool.m4
--- libtool.m4 15 Nov 2001 01:22:58 - 1.166.2.32
+++ libtool.m4 28 Jan 2002 17:37:35 -
@@ -1636,10 +1636,11 @@ else
irix5* | irix6* | nonstopux*)
if test $GCC = yes; then
archive_cmds='$CC -shared $libobjs $deplibs $compiler_flags ${wl}-soname
${wl}$soname `test -n $verstring echo ${wl}-set_version ${wl}$verstring`
${wl}-update_registry ${wl}${output_objdir}/so_locations -o $lib'
+ hardcode_libdir_flag_spec='${wl}-rpath ${wl}$libdir'
else
archive_cmds='$LD -shared $libobjs $deplibs $linker_flags -soname $soname `test
-n $verstring echo -set_version $verstring` -update_registry
${output_objdir}/so_locations -o $lib'
+ hardcode_libdir_flag_spec='-rpath $libdir'
fi
-hardcode_libdir_flag_spec='${wl}-rpath ${wl}$libdir'
hardcode_libdir_separator=:
link_all_deplibs=yes
;;
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool 1.4 not passing linker directives
Well, I do realize that it's non-portable, but the number of platforms I'm building on is very restricted (the application is only of any real use on Linux systems running RPM, dpkg, and a few other special cases). I'm not really intentionally trying to use libtool; I'm just using automake, which told me to pass linker directives in the prog_LDADD variable, which I did, until it broke, and it seems that libtool 1.4 is what changes this behaviour. I'm not sure why it's using libtool to link my program -- is this necessary, avoidable? Ian On Sat, 2001-10-06 at 17:15, Peter Eisentraut wrote: Ian Peters writes: Yes, the end goal is to have all of the libraries between the -Bstatic and -Bdynamic linked statically, while keeping a dynamic binary against libc and ld-linux. You do realize that this goal cannot be portably accomplished, so you perhaps shouldn't use libtool? -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool 1.4 not passing linker directives
Ian: Automake uses Libtool to create libraries because it is portable, it's practially the only thing that is. One thing you should check, do you really have to specify what is static? I belive that under Linux, the linker will choose shared libs over archives, if that helps at all. Perhaps you could train your app to find only the archive libs at link time rather than add -Wl,Bstatic in your link line. Another alternative is to stop using Automake, just use the Makefile.in that you already generated, and tailor it to link with exactly the options you're hoping for. Did I miss anything? HTH, Rob Ian Peters wrote: Well, I do realize that it's non-portable, but the number of platforms I'm building on is very restricted (the application is only of any real use on Linux systems running RPM, dpkg, and a few other special cases). I'm not really intentionally trying to use libtool; I'm just using automake, which told me to pass linker directives in the prog_LDADD variable, which I did, until it broke, and it seems that libtool 1.4 is what changes this behaviour. I'm not sure why it's using libtool to link my program -- is this necessary, avoidable? Ian On Sat, 2001-10-06 at 17:15, Peter Eisentraut wrote: Ian Peters writes: Yes, the end goal is to have all of the libraries between the -Bstatic and -Bdynamic linked statically, while keeping a dynamic binary against libc and ld-linux. You do realize that this goal cannot be portably accomplished, so you perhaps shouldn't use libtool? -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool -- Robert Boehne Software Engineer Ricardo Software Chicago Technical Center TEL: (630)789-0003 x. 238 FAX: (630)789-0127 email: [EMAIL PROTECTED] ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
libtool 1.4, rpm, and dynamic libraries depending on each other
I don't know where to ask this, but this is as good a place as any I guess (rpm-list and libtool-list). My problem is this: I have two dynamic libraries in the project. One of them depends on the other, so I have pkglib_LTLIBRARIES = libmsgevents.la libdvdcontrol.la libmsgevents_la_LDFLAGS = -version-info 3:0:0 libdvdcontrol_la_LIBADD = libmsgevents.la libdvdcontrol_la_LDFLAGS = -version-info 3:0:0 among other things in my Makefile.am. As you can see, libdvdcontrol depends on libmsgevents. This works well when installing normally. However, when building an RPM package RPM installs the package in a directory different from the directory in which the package should be installed. This is so that non-root users can build the rpm packages. This makes libtool not find libmsgevents in the intended installation location, because it's not there. Is there a way around this? Any fix or workaround is fine. The very clumsy workaround I use right now is, build the rpm package. Install with --nodeps, build the package _again_ (this time libtool finds libmsgevents since it's installed), remove the old package, install the new package. Oh, and if you want the full source code and the source rpms, please find them at http://www.dtek.chalmers.se/~dvd/ Regards, Martin -- [ http://www.dtek.chalmers.se/~d95mback/ ] [ PGP: 0x453504F1 ] [ UIN: 4439498 ] Opinions expressed above are mine, and not those of my future employees. SIGBORE: Signature boring error, core dumped ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool 1.4 not passing linker directives
Ian Peters writes: Yes, the end goal is to have all of the libraries between the -Bstatic and -Bdynamic linked statically, while keeping a dynamic binary against libc and ld-linux. You do realize that this goal cannot be portably accomplished, so you perhaps shouldn't use libtool? -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool 1.4 not passing linker directives
On Fri, 2001-10-05 at 02:19, [EMAIL PROTECTED] wrote: On Fri, Oct 05, 2001 at 01:14:52AM -0400, Ian Peters wrote: Conspicuously missing are the linker directives to be passed to gcc, namely -Wl,-Bstatic and -Wl,-Bdynamic. I do this to produce a binary that is linked statically except for libc and the dynamic linker. Did you send the write output? I see -Wl,-Bstatic and -Wl,-Bdynamic in the output above. What's bad is their position has been reordered. What version of libtool are you using? I take it you want all libraries between -Bstatic and -Bdynamic statically linked? Whoops, you're right -- I only looked at the end of the output, I didn't look closely enough to notice they'd just been reordered, not stripped. Yes, the end goal is to have all of the libraries between the -Bstatic and -Bdynamic linked statically, while keeping a dynamic binary against libc and ld-linux. -- Ian Peters [EMAIL PROTECTED] ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool 1.4 not passing linker directives
On Fri, 2001-10-05 at 02:19, [EMAIL PROTECTED] wrote: What's bad is their position has been reordered. What version of libtool are you using? I take it you want all libraries between -Bstatic and -Bdynamic statically linked? Forgot to say, this has been tested with libtool 1.4 and 1.4.2. -- Ian Peters [EMAIL PROTECTED] ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool 1.4 not passing linker directives
On Fri, 2001-10-05 at 02:21, Tim Van Holder wrote: On Fri, 2001-10-05 at 07:14, Ian Peters wrote: Unfortunately, with libtool 1.4.x, I get this instead (after a much, much longer time): gcc -g -O2 -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -o [snip] installer-ui.o -Wl,-Bstatic -rdynamic -rdynamic -rdynamic -rdynamic -Wl,-Bdynamic ../libredcarpet/src/libredcarpet.a [snip] Conspicuously missing are the linker directives to be passed to gcc, namely -Wl,-Bstatic and -Wl,-Bdynamic. I do this to produce a binary that is linked statically except for libc and the dynamic linker. Clearly, they're not missing, but they do seem to have been overzealously grouped together at the start, with the change in results. Whoops, you're right. I didn't look at all of the command line close enough, I just assumed they'd been stripped. Is this a bug in libtool 1.4.x, or an undocumented change in behaviour? If so, is there some other way to accomplish the same goal? I'd say a bug, since options libtool doesn't handle itself are moved around when they shouldn't be. Suck, that was what I was afraid of. Any workarounds? -- Ian Peters [EMAIL PROTECTED] ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool 1.4 not passing linker directives
On Fri, Oct 05, 2001 at 01:14:52AM -0400, Ian Peters wrote: An application I work on has been calling libtool (through automake) with linker directives on the libtool line, around many of the libraries specified, like so (apologies if this wraps strangely, it's all one line): /bin/sh ../libtool --mode=link gcc -g -O2 -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -o installer installer-distro.o installer-page.o installer-page-install.o installer-page-deps.o installer-page-finish.o installer-page-gdm.o installer-page-method.o installer-page-mirror.o installer-page-more-deps.o installer-page-proxy.o installer-page-select.o installer-page-start.o installer-state-machine.o installer-ui.o ../libredcarpet/src/libredcarpet.a ../libgnometransfer/src/libgnometransfer.a -Wl,-Bstatic -rdynamic -L/usr/lib -L/usr/X11R6/lib -L/usr/lib/lib -lgtkhtml -lgal -lgnomeprint -lglade-gnome -lglade -lxml -lz -lgnomeui -lart_lgpl -lSM -lICE -lgtk -lgdk -lgmodule -lXi -lXext -lX11 -lgnome -lgnomesupport -lesd -laudiofile -lm -ldb1 -lglib -ldl -lgnet -rdynamic -lgmodule -lglib -ldl /home/itp/gdk-pixbuf-0.11.0//gdk-pixbuf/.libs/libgdk_pixbuf.a -lgtk -lgdk -rdynamic -lgmodule -lglib -ldl -lXi -lXext -lX11 -lm /home/itp/gdk-pixbuf-0.11.0//gdk-pixbuf/.libs/libgnomecanvaspixbuf.a /home/itp/imlib-1.9.10//gdk_imlib/.libs/libgdk_imlib.a -ljpeg -ltiff -lungif -lpng -lz -lm -lgtk -lgdk -rdynamic -lgmodule -lglib -ldl -lXi -lXext -lX11 -lm -luuid -lcrypt -lz -lutil -Wl,-Bdynamic I see -Wl,-Bstatic -rdynamic -Wl,-Bdynamic With libtool 1.3.x, this resulted in the following call to gcc: gcc -g -O2 -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -o installer installer-distro.o installer-page.o installer-page-install.o installer-page-deps.o installer-page-finish.o installer-page-gdm.o installer-page-method.o installer-page-mirror.o installer-page-more-deps.o installer-page-proxy.o installer-page-select.o installer-page-start.o installer-state-machine.o installer-ui.o ../libredcarpet/src/libredcarpet.a ../libgnometransfer/src/libgnometransfer.a -Wl,-Bstatic -rdynamic -L/usr/lib -L/usr/X11R6/lib -L/usr/lib/lib -lgtkhtml -lgal -lgnomeprint -lglade-gnome -lglade -lxml -lz -lgnomeui -lart_lgpl -lSM -lICE -lgtk -lgdk -lgmodule -lXi -lXext -lX11 -lgnome -lgnomesupport -lesd -laudiofile -lm -ldb1 -lglib -ldl -lgnet -rdynamic -lgmodule -lglib -ldl /home/itp/gdk-pixbuf-0.11.0/gdk-pixbuf/.libs/libgdk_pixbuf.a -lgtk -lgdk -rdynamic -lgmodule -lglib -ldl -lXi -lXext -lX11 -lm /home/itp/gdk-pixbuf-0.11.0/gdk-pixbuf/.libs/libgnomecanvaspixbuf.a /home/itp/imlib-1.9.10/gdk_imlib/.libs/libgdk_imlib.a -ljpeg -ltiff -lungif -lpng -lz -lm -lgtk -lgdk -rdynamic -lgmodule -lglib -ldl -lXi -lXext -lX11 -lm -luuid -lcrypt -lz -lutil -Wl,-Bdynamic Ditto. Unfortunately, with libtool 1.4.x, I get this instead (after a much, much longer time): gcc -g -O2 -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -o installer installer-distro.o installer-page.o installer-page-install.o installer-page-deps.o installer-page-finish.o installer-page-gdm.o installer-page-method.o installer-page-mirror.o installer-page-more-deps.o installer-page-proxy.o installer-page-select.o installer-page-start.o installer-state-machine.o installer-ui.o -Wl,-Bstatic -rdynamic -rdynamic -rdynamic -rdynamic -Wl,-Bdynamic ../libredcarpet/src/libredcarpet.a ^ ../libgnometransfer/src/libgnometransfer.a -L/usr/lib -L/usr/X11R6/lib -L/usr/lib/lib /usr/lib/libgtkhtml.so /usr/lib/libgnomecanvaspixbuf.so /usr/lib/libbonobo.so /usr/lib/liboaf.so /usr/lib/libORBitCosNaming.so /usr/lib/libORBit.so /usr/lib/libIIOP.so /usr/lib/libORBitutil.so /usr/lib/libbonobox.so -lz -lXi -lXext -lX11 -lm -ldl /usr/lib/libgal.so /usr/lib/libgnomeprint.so /usr/lib/libgdk_pixbuf.so -ldl -lXi -lXext -lX11 -lm -lz /usr/lib/libglade-gnome.so -lXi -lXext -lX11 -lm -ldl -lz /usr/lib/libglade.so -ldl -lXi -lXext -lX11 -lm -lz /usr/lib/libxml.so -lz -lz -lz /usr/lib/libgnomeui.so -lm -lm -ldl /usr/lib/libgdk_imlib.so -ldl -lXi -lXext -lX11 -lm -ldl -lXi -lXext -lX11 -lm -lz -lm /usr/lib/libart_lgpl.so -lSM -lICE -ldl -lXi -lXext -lX11 -lm -ldl -lXi -lXext -lX11 -lm -ldl -lXi -lXext -lX11 /usr/lib/libgnome.so -lm -ldl -lz -lm /usr/lib/libgnomesupport.so -lz -lm /usr/lib/libesd.so -lm -lm /usr/lib/libaudiofile.so -lm -lm -lm -ldb1 -ldl /usr/lib/libgnet.so -lresolv -lnsl -ldl -ldl /home/itp/gdk-pixbuf-0.11.0//gdk-pixbuf/.libs/libgdk_pixbuf.a -ldl -lXi -lXext -lX11 -lm -ldl -lXi -lXext -lX11 -lm -ldl -ldl -lXi -lXext -lX11 -lm /home/itp/gdk-pixbuf-0.11.0//gdk-pixbuf/.libs/libgnomecanvaspixbuf.a /home/itp/imlib-1.9.10//gdk_imlib/.libs/libgdk_imlib.a /usr/lib/libjpeg.so -ltiff /usr/lib/libungif.so -lX11 -lpng -lz -lm /usr/lib/libgtk.so -ldl -lXi -lXext -lX11 -lm /usr/lib/libgdk.so -ldl -lXi -lXext -lX11 -lm /usr/lib/libgmodule.so -ldl /usr/lib/libglib.so -ldl -lXi -lXext -lX11 -lm
Re: Patch for libtool 1.4 on QNX.
On Wednesday 11 July 2001 3:35 am, Don Anderson wrote: Hello libtoolers, Here is a patch to run libtool 1.4 on QNX. I set lt_cv_deplibs_check_method to 'unknown' because I was unable to successfully run the test suite: since I don't have direct access to the QNX box, I'm working through it with someone else. However, these changes do allow us to build shared libraries on QNX. Cool! Thanks for the patch. Applied to HEAD. Please supply a ChangeLog entry next time though... Cheers, Gary. -- ())_. Gary V. Vaughan gary@(oranda.demon.co.uk|gnu.org ( '/ Research Scientist http://www.oranda.demon.co.uk ,_()) / )= GNU Hacker http://www.gnu.org/software/libtool \' ` `(_~)_ Tech' Authorhttp://sources.redhat.com/autobook =`---d__/ ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Patch for libtool 1.4 on QNX.
Hello libtoolers,
Here is a patch to run libtool 1.4 on QNX. I set
lt_cv_deplibs_check_method to 'unknown' because I was unable to
successfully run the test suite: since I don't have direct access to
the QNX box, I'm working through it with someone else. However, these
changes do allow us to build shared libraries on QNX.
Thanks.
- Don
*** libtool.m4.ORIG Tue Apr 24 19:34:11 2001
--- libtool.m4 Sat Jun 16 16:45:25 2001
***
*** 2183,2188
--- 2183,2198
fi
;;
+ nto-qnx)
+ version_type=linux
+ need_lib_prefix=no
+ need_version=no
+ library_names_spec='${libname}${release}.so$versuffix
+${libname}${release}.so$major $libname.so'
+ soname_spec='${libname}${release}.so$major'
+ shlibpath_var=LD_LIBRARY_PATH
+ shlibpath_overrides_runpath=yes
+ ;;
+
*)
dynamic_linker=no
;;
***
*** 3228,3233
--- 3238,3247
[lt_cv_deplibs_check_method='file_magic ELF [0-9][0-9]*-bit [ML]SB
(executable|dynamic lib)']
lt_cv_file_magic_cmd=/usr/bin/file
lt_cv_file_magic_test_file=/usr/lib/libnls.so
+ ;;
+
+ nto-qnx)
+ lt_cv_deplibs_check_method=unknown
;;
osf3* | osf4* | osf5*)
- Don Anderson
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Remember to send requests for assistance on
new problems to [EMAIL PROTECTED]
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Don Anderson[EMAIL PROTECTED]
Sleepycat Software Inc. +1-978-287-4781
118 Tower Rd. http://www.sleepycat.com
Lincoln, MA 01773
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
?? libtool 1.4 bug
I sent the message below to bug-libtool about a week ago, no reply.
Does anyone have solutions, answers, ... ?
Danny
-- Forwarded by Danny Backx/U27113/KB/KredAlm on
06/08/2001 11:55 AM ---
[EMAIL PROTECTED] on 06/02/2001 07:30:00 PM
To: [EMAIL PROTECTED]@Internet
cc: [EMAIL PROTECTED]@Internet (bcc: Danny
Backx/U27113/KB/KredAlm)
Subject:libtool 1.4 bug
Hi,
The attached file contains excerpts of the LessTif build process.
We think a libtool bug may be the cause of our build problems.
You'll see in the make install command that libtool wants to relink
libMrm.la. In the next command I've added a -n flag to that libtool
invocation so we can see which gcc command is given.
The gcc command itself fails because it doesn't get the right
library (../Xm-2.1/libXm.la which is not installed yet so this
should become
/usr/src/packages/BUILD/lesstif-0.92.32/lib/Xm-2.1/.libs/libXm.so.2.0.1)
passed to it.
I've attached libXm.la as well.
Please help, this currently prevents us from doing our release process
in a decent way. (I've looked inside the libtool sources but it appears
to take a LOT of learning time before I can start to debug this.)
Danny
--
Danny Backx ([EMAIL PROTECTED] [EMAIL PROTECTED])
Home page : http://users.skynet.be/danny.backx
Projects: LessTif (http://www.lesstif.org)
Oleo(http://www.gnu.org/software/oleo/oleo.html)
dell: {193} pwd
/usr/src/packages/BUILD/lesstif-0.92.32/lib/Mrm-2.1
dell: {194} make install DESTDIR=/tmp/lesstif_0.92.32-root
gmake[1]: Entering directory `/usr/src/packages/BUILD/lesstif-0.92.32/lib/Mrm-2.1'
/bin/sh ../../mkinstalldirs /tmp/lesstif_0.92.32-root/usr/X11R6/LessTif/Motif2.1/lib
/bin/sh ../../libtool --mode=install /usr/bin/ginstall -c libMrm.la
/tmp/lesstif_0.92.32-root/usr/X11R6/LessTif/Motif2.1/lib/libMrm.la
libtool: install: warning: relinking `libMrm.la'
cd /usr/src/packages/BUILD/lesstif-0.92.32/lib/Mrm-2.1; /bin/sh ../../libtool
--mode=relink gcc -O2 -m486 -fno-strength-reduce -L/usr/local/lib/mysql -o libMrm.la
-rpath /usr/X11R6/LessTif/Motif2.1/lib -version-info 2:1 Mrm.lo lookup.lo misc.lo
../Xm-2.1/libXm.la
mv: cannot stat `libMrm.so.2.0.1': No such file or directory
libtool: install: error: relink `libMrm.la' with the above command before installing it
libtool: install: warning: remember to run `libtool --finish
/usr/X11R6/LessTif/Motif2.1/lib'
gmake install-data-hook
gmake[2]: Entering directory `/usr/src/packages/BUILD/lesstif-0.92.32/lib/Mrm-2.1'
rm -f /tmp/lesstif_0.92.32-root/usr/X11R6/lib/libMrm.so.2*
(cd /tmp/lesstif_0.92.32-root/usr/X11R6/lib ln -s
../LessTif/Motif2.1/lib/libMrm.so.2* .)
rm -f /tmp/lesstif_0.92.32-root/usr/X11R6/lib/libMrm.la
(cd /tmp/lesstif_0.92.32-root/usr/X11R6/lib ln -s ../LessTif/Motif2.1/lib/libMrm.la
.)
rm -f /tmp/lesstif_0.92.32-root/usr/X11R6/lib/libMrm.so
(cd /tmp/lesstif_0.92.32-root/usr/X11R6/lib ln -s ../LessTif/Motif2.1/lib/libMrm.so
.)
gmake[2]: Leaving directory `/usr/src/packages/BUILD/lesstif-0.92.32/lib/Mrm-2.1'
gmake[1]: Leaving directory `/usr/src/packages/BUILD/lesstif-0.92.32/lib/Mrm-2.1'
dell: {195} /bin/sh ../../libtool --mode=relink -n gcc -O2 -m486 -fno-strength-reduce
-L/usr/local/lib/mysql -o libMrm.la -rpath /usr/X11R6/LessTif/Motif2.1/lib
-version-info 2:1 Mrm.lo lookup.lo misc.lo ../Xm-2.1/libXm.la
gcc -shared Mrm.lo lookup.lo misc.lo -Wl,--rpath -Wl,/usr/X11R6/LessTif/Motif2.1/lib
-L/usr/X11R6/lib -L/usr/local/lib/mysql -L/usr/X11R6/LessTif/Motif2.1/lib -lXm
-Wl,-soname -Wl,libMrm.so.2 -o .libs/libMrm.so.2.0.1
dell: {196} gcc -shared Mrm.lo lookup.lo misc.lo -Wl,--rpath
-Wl,/usr/X11R6/LessTif/Motif2.1/lib -L/usr/X11R6/lib -L/usr/local/lib/mysql
-L/usr/X11R6/LessTif/Motif2.1/lib -lXm -Wl,-soname -Wl,libMrm.so.2 -o
.libs/libMrm.so.2.0.1
/usr/i486-suse-linux/bin/ld: cannot find -lXm
collect2: ld returned 1 exit status
# libXm.la - a libtool library file
# Generated by ltmain.sh - GNU libtool 1.4 (1.920 2001/04/24 23:26:18)
#
# Please DO NOT delete this file!
# It is necessary for linking the library.
# The name that we can dlopen(3).
dlname='libXm.so.2'
# Names of this library.
library_names='libXm.so.2.0.1 libXm.so.2 libXm.so'
# The name of the static archive.
old_library=''
# Libraries that this one depends upon.
dependency_libs=' -L/usr/local/lib/mysql -L/usr/X11R6/lib -lXt -lSM -lICE -lXp -lXext
-lX11'
# Version information for libXm.
current=2
age=0
revision=1
# Is this an already installed library?
installed=no
# Files to dlopen/dlpreopen
dlopen=''
dlpreopen=''
# Directory that this library needs to be installed in:
libdir='/usr/X11R6/LessTif/Motif2.1/lib'
Re: libtool 1.4 failure on Solaris 8
This patch got me through the ugly ethereal build. I applied them to libtool, so obviously they need to be applied to the ltmain.in file. I do not know if every one of these is strictly required, I started getting impatient. :-) Regards, Bruce $ gdiff -u libtool /tmp/LIBTOOL --- libtool Thu Jun 7 10:59:32 2001 +++ /tmp/LIBTOOLThu Jun 7 10:57:07 2001 @@ -720,7 +720,7 @@ pic_mode=default ;; esac -if test $pic_mode = no test $deplibs_check_method != pass_all; then +if test X$pic_mode = Xno test $deplibs_check_method != pass_all; then # non-PIC code in shared libraries is not supported pic_mode=default fi @@ -739,7 +739,7 @@ # Lock this critical section if it is needed # We use this script file to make the link, it avoids creating a new file -if test $need_locks = yes; then +if test X$need_locks = Xyes; then until $run ln $0 $lockfile 2/dev/null; do $show Waiting for $lockfile to be removed sleep 2 @@ -2631,7 +2631,7 @@ *) finalize_rpath=$finalize_rpath $libdir ;; esac done - if test $hardcode_into_libs != yes || test $build_old_libs = yes; then + if test X$hardcode_into_libs != Xyes || test $build_old_libs = yes; then dependency_libs=$temp_xrpath $dependency_libs fi fi @@ -2656,7 +2656,7 @@ esac done - if test $build_libtool_libs = yes; then + if test X$build_libtool_libs = Xyes; then if test -n $rpath; then case $host in *-*-cygwin* | *-*-mingw* | *-*-pw32* | *-*-os2* | *-*-beos*) @@ -2671,7 +2671,7 @@ ;; *) # Add libc to deplibs on all other systems if necessary. - if test $build_libtool_need_lc = yes; then + if test X$build_libtool_need_lc = Xyes; then deplibs=$deplibs -lc fi ;; @@ -2943,8 +2943,8 @@ dlname= # Test again, we may have decided not to build it any more - if test $build_libtool_libs = yes; then - if test $hardcode_into_libs = yes; then + if test X$build_libtool_libs = Xyes; then + if test X$hardcode_into_libs = Xyes; then # Hardcode the library paths hardcode_libdirs= dep_rpath= ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool 1.4 failure on Solaris 8
On Thu, Jun 07, 2001 at 10:48:04AM -0700, Bruce Korb wrote: Building ethereal: Making all in gryphon /bin/sh ../../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../.. -I/u/local/include -I../.. -I../../wiretap -I../../epan -I/usr/local/include -I/u/local/include -Wall -g -O2 -I../.. -I../../wiretap -I../../epan -I/usr/local/include -I/usr/openwin/include -I/usr/local/lib/glib/include -I/usr/local/include -I/u/local/include -c packet-gryphon.c ../../libtool: test: argument expected How did you configure Ethereal 0.8.18? We built with --enable-shared --enable-static and it worked fine (we have a customized version of libtool 1.4 but out changes don't affect Solaris). -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool 1.4 failure on Solaris 8
[EMAIL PROTECTED] wrote: On Thu, Jun 07, 2001 at 10:48:04AM -0700, Bruce Korb wrote: Building ethereal: Making all in gryphon /bin/sh ../../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../.. -I/u/local/include -I../.. -I../../wiretap -I../../epan -I/usr/local/include -I/u/local/include -Wall -g -O2 -I../.. -I../../wiretap -I../../epan -I/usr/local/include -I/usr/openwin/include -I/usr/local/lib/glib/include -I/usr/local/include -I/u/local/include -c packet-gryphon.c ../../libtool: test: argument expected How did you configure Ethereal 0.8.18? We built with --enable-shared --enable-static and it worked fine (we have a customized version of libtool 1.4 but out changes don't affect Solaris). as in: ./configure I couldn't use downloadable packages (like yours) because /usr/local is for global admins, so I have to configure for /u/local. [Cannot copy the files, either, because they contain compiled in path names.] I presume you saw my later patch? That failed, too, because some library was not findable. I gave up and am at home now. Thanks for your suggestion, tho. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
libtool 1.4 bug
Hi,
The attached file contains excerpts of the LessTif build process.
We think a libtool bug may be the cause of our build problems.
You'll see in the make install command that libtool wants to relink
libMrm.la. In the next command I've added a -n flag to that libtool
invocation so we can see which gcc command is given.
The gcc command itself fails because it doesn't get the right
library (../Xm-2.1/libXm.la which is not installed yet so this
should become
/usr/src/packages/BUILD/lesstif-0.92.32/lib/Xm-2.1/.libs/libXm.so.2.0.1)
passed to it.
I've attached libXm.la as well.
Please help, this currently prevents us from doing our release process
in a decent way. (I've looked inside the libtool sources but it appears
to take a LOT of learning time before I can start to debug this.)
Danny
--
Danny Backx ([EMAIL PROTECTED] [EMAIL PROTECTED])
Home page : http://users.skynet.be/danny.backx
Projects: LessTif (http://www.lesstif.org)
Oleo(http://www.gnu.org/software/oleo/oleo.html)
dell: {193} pwd
/usr/src/packages/BUILD/lesstif-0.92.32/lib/Mrm-2.1
dell: {194} make install DESTDIR=/tmp/lesstif_0.92.32-root
gmake[1]: Entering directory `/usr/src/packages/BUILD/lesstif-0.92.32/lib/Mrm-2.1'
/bin/sh ../../mkinstalldirs /tmp/lesstif_0.92.32-root/usr/X11R6/LessTif/Motif2.1/lib
/bin/sh ../../libtool --mode=install /usr/bin/ginstall -c libMrm.la
/tmp/lesstif_0.92.32-root/usr/X11R6/LessTif/Motif2.1/lib/libMrm.la
libtool: install: warning: relinking `libMrm.la'
cd /usr/src/packages/BUILD/lesstif-0.92.32/lib/Mrm-2.1; /bin/sh ../../libtool
--mode=relink gcc -O2 -m486 -fno-strength-reduce -L/usr/local/lib/mysql -o libMrm.la
-rpath /usr/X11R6/LessTif/Motif2.1/lib -version-info 2:1 Mrm.lo lookup.lo misc.lo
../Xm-2.1/libXm.la
mv: cannot stat `libMrm.so.2.0.1': No such file or directory
libtool: install: error: relink `libMrm.la' with the above command before installing it
libtool: install: warning: remember to run `libtool --finish
/usr/X11R6/LessTif/Motif2.1/lib'
gmake install-data-hook
gmake[2]: Entering directory `/usr/src/packages/BUILD/lesstif-0.92.32/lib/Mrm-2.1'
rm -f /tmp/lesstif_0.92.32-root/usr/X11R6/lib/libMrm.so.2*
(cd /tmp/lesstif_0.92.32-root/usr/X11R6/lib ln -s
../LessTif/Motif2.1/lib/libMrm.so.2* .)
rm -f /tmp/lesstif_0.92.32-root/usr/X11R6/lib/libMrm.la
(cd /tmp/lesstif_0.92.32-root/usr/X11R6/lib ln -s ../LessTif/Motif2.1/lib/libMrm.la
.)
rm -f /tmp/lesstif_0.92.32-root/usr/X11R6/lib/libMrm.so
(cd /tmp/lesstif_0.92.32-root/usr/X11R6/lib ln -s ../LessTif/Motif2.1/lib/libMrm.so
.)
gmake[2]: Leaving directory `/usr/src/packages/BUILD/lesstif-0.92.32/lib/Mrm-2.1'
gmake[1]: Leaving directory `/usr/src/packages/BUILD/lesstif-0.92.32/lib/Mrm-2.1'
dell: {195} /bin/sh ../../libtool --mode=relink -n gcc -O2 -m486 -fno-strength-reduce
-L/usr/local/lib/mysql -o libMrm.la -rpath /usr/X11R6/LessTif/Motif2.1/lib
-version-info 2:1 Mrm.lo lookup.lo misc.lo ../Xm-2.1/libXm.la
gcc -shared Mrm.lo lookup.lo misc.lo -Wl,--rpath -Wl,/usr/X11R6/LessTif/Motif2.1/lib
-L/usr/X11R6/lib -L/usr/local/lib/mysql -L/usr/X11R6/LessTif/Motif2.1/lib -lXm
-Wl,-soname -Wl,libMrm.so.2 -o .libs/libMrm.so.2.0.1
dell: {196} gcc -shared Mrm.lo lookup.lo misc.lo -Wl,--rpath
-Wl,/usr/X11R6/LessTif/Motif2.1/lib -L/usr/X11R6/lib -L/usr/local/lib/mysql
-L/usr/X11R6/LessTif/Motif2.1/lib -lXm -Wl,-soname -Wl,libMrm.so.2 -o
.libs/libMrm.so.2.0.1
/usr/i486-suse-linux/bin/ld: cannot find -lXm
collect2: ld returned 1 exit status
# libXm.la - a libtool library file
# Generated by ltmain.sh - GNU libtool 1.4 (1.920 2001/04/24 23:26:18)
#
# Please DO NOT delete this file!
# It is necessary for linking the library.
# The name that we can dlopen(3).
dlname='libXm.so.2'
# Names of this library.
library_names='libXm.so.2.0.1 libXm.so.2 libXm.so'
# The name of the static archive.
old_library=''
# Libraries that this one depends upon.
dependency_libs=' -L/usr/local/lib/mysql -L/usr/X11R6/lib -lXt -lSM -lICE -lXp -lXext
-lX11'
# Version information for libXm.
current=2
age=0
revision=1
# Is this an already installed library?
installed=no
# Files to dlopen/dlpreopen
dlopen=''
dlpreopen=''
# Directory that this library needs to be installed in:
libdir='/usr/X11R6/LessTif/Motif2.1/lib'
libtool 1.4: make uninstall broken?
I installed libtool 1.4 in the wrong place and then tried make uninstall before doing a reconfigure. It complained about not finding install-info or something - I didn't care to investigate further. Lars J ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
libtool-1.4 -- libltdl_cv_sys_dlopen_deplibs=yes on Uw7
Hi folks, I had this discussion with Gary on this list a week or so ago. Does UnixWare 7.x.x load deplibs, or does libltdl have to do so... Trying to build libtool-1.4. I got an answer back from comp.unix.sco.programmer. In summary, I think Dave Prosser, from SCO, trys to explain that the anwer is yes, even though what he said was a bit convoluted. Here's the ng thread, where: == Matt Schalit == Gary Vaughn == Dave Prosser - On Saturday 21 April 2001 10:02 pm, Matthew Schalit wrote: The only other thing I noticed was this section in libltdl/configure: # PORTME does your system automatically load deplibs for dlopen()? libltdl_cv_sys_dlopen_deplibs=unknown case $host_os in linux*) libltdl_cv_sys_dlopen_deplibs=yes ;; netbsd*) libltdl_cv_sys_dlopen_deplibs=yes ;; solaris*) libltdl_cv_sys_dlopen_deplibs=yes ;; esac As a general rule, UnixWare and Solaris have common roots here and thus should act the same. I noticed that I got an unknown from this. I don't understand what it's checking for, so I don't know how to ask about it or fix it. Presumably the owner of the configure script should be told to include UnixWare in the list of yess. Setting this variable to yes tells libltdl that if a dlopened library depends an another unloaded library that the OS takes care of loading the deplib too. For instance, if I use libltdl to load libgtk.so into my app, will the OS also load libgdk, libglib, libX11 etc for me? If the variable is not set to yes, libltdl will dlopen() those libraries for me (and recursively any of their deplibs) before trying to perform the dlopen actually asked for. Needless to say this slows down dlopening a lot, especially when it is not needed. If a dynamic library has DT_NEEDED entries for other dynamic libraries (see dump -Lv output), then they are *required* to be present before the original dynamic library can be completely loaded. That's what the dependency means. If the depended-on libraries have initialization routine(s) -- also listed in the dump -Lv output -- they need to be run before any initialization of the original library. If the dependent libraries have already been included in the process, the dynamic linker just points to these, so there isn't any real overhead after the system calls necessary to verify that we've got a duplicate. If this is too much overhead, don't list other dynamic libraries when building (cc/CC -G) dynamic libraries. However, I don't recall anyone ever complaining about the speed of dlopen() -- not that that means there isn't a problem for some applications. So I'm wondering how UnixWare 7.x.x deals with this aspect? I guess it'd be helpful to know how it relates it OSR 5.0.x, too. This will help SCO's OS's get well supported by libtool and hopefully, some better software for us all. OpenServer and UnixWare share the same behavior here. The basics of dynamic library dependencies and the like are common across many UNIX systems and are found in the Generic Application Binary Interface specification. There is an up-to-date version of the key portions of this available on SCO's web site: http://www.sco.com/developer/gabi -- Dave Prosserdfp at sco dot com SCO, Murray Hill, NJ That's all. Matthew ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
[ANNOUNCE] GNU Libtool 1.4
Hello Libtoolers, On this, the 2nd anniversary of the release of libtool-1.3, the Libtool Team is delighted to announce Libtool version 1.4: Available now from ftp://ftp.gnu.org/gnu/libtool/libtool-1.4.tar.gz and shortly from all GNU mirror sites. You will find diffs and xdeltas from libtool-1.3.5 in ftp://ftp.gnu.org/gnu/libtool/, and diffs and xdeltas from libtool-1.3d in ftp://alpha.gnu.org/gnu/libtool/. The md5sums for the new files are: 68e1cbaef7ffedfd8dd8841ead13e589 libtool-1.3.5-1.4.diff.gz b8698da0155839e23b3f22e4429e2e4f libtool-1.3.5-1.4.tar.xdp.gz 523b7c4eafa989c21b35c95dbc4d7e16 libtool-1.3d-1.4.diff.gz efa33bfbdeba289ee0db514506ef6c4b libtool-1.3d-1.4.tar.xdp.gz ad40e22c9037dc0e569668c30734bc49 libtool-1.4.tar.gz If you prefer, you can fetch the unbootstrapped sourcecode using anonymous CVS by following the instructions ath ttp://www.gnu.org/software/libtool/libtool.html#AnonymousCVS but using the tag release-1-4. The main user visible differences from the last stable release, version 1.3.5 follow; more details are given in the NEWS file in the release tarballs. * ltconfig is no more. Generation of libtool happens directly from the configure file. * Complete inter-library dependencies support. It's now possible to link libtool libraries against other libtool libraries. * Libtool now allows you to link shared libraries against static code. * Libtool is able to find already-installed libtool libraries, even if they were moved out of their installation directory. * New -no-install flag to avoid the use of executable wrapper scripts. * New --with-pic, -prefer-pic and -prefer-non-pic flags to control the generation of PIC/non-PIC code. * Support for hardcoding run-time paths (-R) into libraries. * Support -dlopen and -dlpreopen for libraries. * -Xcompiler and -Wc, does now work in compile mode, too. * New -Wc,flag and -Xcompiler flag flags to pass flags directly to the compiler * New -Wl,flag and -Xlinker flag flags to pass flags directly to the linker * New -no-fast-install flag to selectively disable fast-install mode. * Support for installing stripped libraries using GNU strip (install -s). Automake = 1.5 will install stripped libraries with make install-strip. * Multithread safe with lt_dlmutex_register callback registration. * New functions in libltdl: lt_dlgetinfo, lt_dlhandle_next and lt_dlforeach provide access to module specific data in handles. lt_dlcaller_register, lt_dlcaller_set_data and lt_dlcaller_get_data provide management for user storage of per module data. lt_dlloader_next, lt_dlloader_name, lt_dlloader_find, lt_dlloader_add and lt_dlloader_remove can be used for adding new types of module loaders. lt_dladderror, lt_dlseterror integrate user module loaders with lt_dlerror. * Support recent dlltool formats. * Start of support code for cross-compiling to win32. * libltdl can now be built as a dll with win32. * m4 macros needed to configure libltdl split out into ltdl.m4. * Allow linking shared libraries against static ones on FreeBSD, GNU/Linux, GNU Hurd and Solaris * Support for linking DLLs on Win32 * New `clean' mode to delete uninstalled files. * New demos and tests * Improved support for darwin (rhapsody), mingw32, NetBSD, Compaq Tru64 V5.0 and Digital Unix V4.*. * Initial support for ia64 linux. * Initial support for a.out freebsd shared libs. * Initial support for Paul Sokolovsky's pw32 POSIX over win32 layer. * Support for aix5*. * New port to NEWS-OS Release 6. * Many bugfixes (especially in libltdl) Enjoy! -- ___ _ ___ __ _ mailto: [EMAIL PROTECTED] / __|__ _ _ ___ _| | / / | / /_ _ _ _ __ _| |_ __ _ ___ [EMAIL PROTECTED] | (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \ \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/ home page: /___/ /___/ gpg public key: http://www.oranda.demon.co.uk http://www.oranda.demon.co.uk/key.asc ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
libtool 1.4 README patch
With these two items from the announcement: * Improved support for darwin (rhapsody), mingw32, NetBSD, Compaq Tru64 V5.0 and Digital Unix V4.*. ... * Support for aix5*. and my understanding of the very recent changes related to AIX (including AIX 5), coupled with the version numbering that is apparently going to be used on the next autoconf release, I think the libtool README might benefit from the following patch. Are the suggested changes all correct? diff -ur libtool-1.4.orig/README libtool-1.4/README --- libtool-1.4.orig/README Wed Dec 13 20:53:45 2000 +++ libtool-1.4/README Thu Apr 26 16:55:48 2001 @@ -17,10 +17,10 @@ Libtool supports building static libraries on all platforms. Shared library support has been implemented for these platforms: - AIX 3.x, 4.x (*-*-aix3*, *-*-aix4*) + AIX 3.x, 4.x, 5.x (*-*-aix3*, *-*-aix4*, *-*-aix5*) BeOS (*-*-beos*) BSD/OS 2.1, 3.x, 4.x (*-*-bsdi2.1, *-*-bsdi3*, *-*-bsdi4*) - Digital/UNIX 3.x, 4.x, a.k.a. OSF/1 (*-*-osf3*, *-*-osf4*) + Digital/Tru64 UNIX, a.k.a. OSF/1 3.x, 4.x, 5.x (*-*-osf[345]*) DG/UX R4.11, R4.12, R4.20 (*-*-dguxR411*, *-*-dguxR412*, *-*-dguxR420*) FreeBSD 2.x, 3.x, 4.x (*-*-freebsd2*, *-*-freebsd3*, *-*-freebsd4*) GNU Hurd (*-*-gnu*) @@ -52,7 +52,7 @@ workaround is to specify CC when run configure with CC='cc -Hnocopyr'. NOTE: Due to a bug in autoconf cc isn't supported on Motorola System V 4. -You can only use gcc. This bug will hopefully be fixed in autoconf 2.14. +You can only use gcc. This bug will hopefully be fixed in autoconf 2.50. NOTE: Any earlier DG/UX system with ELF executables, such as R3.10 or R4.10, is also likely to work, but hasn't been explicitly tested. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool-1.4
On Apr 24, 2001, Gary V.Vaughan [EMAIL PROTECTED] wrote:
Since I don't want to hold up the release any longer, I am going to
break the commit rules and remove all use of the inline keyword (and
the AC_C_INLINE) from libltdl before I roll up the release -- unless
someone asks me not to in the next few hours.
I've finally understood the problem, and it seems that removing all
uses of inline is probably excessive. We just can't declare functions
with static variables as inline. `static inline' (but not `inline
static') is ok for functions without static variables, as long as
`inline' is defined away for compilers that don't support it (which
AC_C_INLINE should take care of).
Of course, re-enabling inline is not a requirement for the release,
since we can always re-enable it later.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool-1.4
On Wednesday 25 April 2001 8:33 pm, Alexandre Oliva wrote: On Apr 24, 2001, Gary V.Vaughan [EMAIL PROTECTED] wrote: Since I don't want to hold up the release any longer, I am going to break the commit rules and remove all use of the inline keyword (and the AC_C_INLINE) from libltdl before I roll up the release -- unless someone asks me not to in the next few hours. I've finally understood the problem, and it seems that removing all uses of inline is probably excessive. We just can't declare functions with static variables as inline. `static inline' (but not `inline static') is ok for functions without static variables, as long as `inline' is defined away for compilers that don't support it (which AC_C_INLINE should take care of). Of course, re-enabling inline is not a requirement for the release, since we can always re-enable it later. I have applied and ported so many patches in the last week that I couldn't face looking through each of the inline functions to determine which ones accessed static variables (it is the access rather than the declaration that causes problems if I understood correctly) when a quick keyboard macro would do the job. Please add sorting this out properly to the TODO list so that we don't forget to do that after MLB has gone. My plan is now to wait for the release to arrive on ftp.gnu.org; make the release announcements; take a couple of days off (hopefully the first phase of MLB merge will have happened by then); sort out the ltconfig- libtool.m4 problem for the final phase of the merge; and then to apply any outstanding patches and/or TODO items that have built up in the interim and release 1.4.1. I guess we will be close to a scheduled monthly alpha release from HEAD at that point, so we can put 1.4b out there near the end of May. Cheers, Gary. -- ___ _ ___ __ _ mailto: [EMAIL PROTECTED] / __|__ _ _ ___ _| | / / | / /_ _ _ _ __ _| |_ __ _ ___ [EMAIL PROTECTED] | (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \ \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/ home page: /___/ /___/ gpg public key: http://www.oranda.demon.co.uk http://www.oranda.demon.co.uk/key.asc ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool-1.4
On Monday 23 April 2001 3:30 pm, Michael Matz wrote: Hi, On Mon, 23 Apr 2001, Gary V. Vaughan wrote: I must say that my spidey-sense tells me that `static inline' is a GNU extension... Yep, but the autoconf macro AC_C_INLINE is used, which #define's inline away in config.h, if inline isn't supported by the compiler (although it tests only for acceptance of 'inline', not 'static inline'). if I am right we should reduce all static inline's to static anyhow. The function in question are not performance critical anyway, so removing inline probably is the safest. I agree. Since I don't want to hold up the release any longer, I am going to break the commit rules and remove all use of the inline keyword (and the AC_C_INLINE) from libltdl before I roll up the release -- unless someone asks me not to in the next few hours. I hope that is okay? When I get an explicit yes/no (or the 72 hour commit limit is up) I will either apply the same patch to MLB, or else revert it in branch-1-4 as necessary. Cheers, Gary. -- ___ _ ___ __ _ mailto: [EMAIL PROTECTED] / __|__ _ _ ___ _| | / / | / /_ _ _ _ __ _| |_ __ _ ___ [EMAIL PROTECTED] | (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \ \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/ home page: /___/ /___/ gpg public key: http://www.oranda.demon.co.uk http://www.oranda.demon.co.uk/key.asc ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool 1.4
On Sunday 22 April 2001 7:09 am, you wrote: Hello. A friend told me the about your libtool 1.4 test mail, so I tried it on a few platforms.. Great! Thankyou for posting your results. I am unable to reproduce your quote.test failure on my Solaris 8 box with the current HEAD revision. If you still have this failure and you have time to do so, please send me the results of running: $ cd tests $ VERBOSE=1 sh -x ./quote.test $ echo $? Cheers, Gary. AIX 4.3.3 box, automake 1.4, autoconf 2.13, gcc 2.95.3, IBM CSet++ 3.6.6 (xlc), native ld checking for gcc... gcc checking host system type... powerpc-ibm-aix4.3.3.0 [..] PASS: cdemo-static.test PASS: cdemo-make.test PASS: cdemo-exec.test PASS: demo-static.test PASS: demo-make.test PASS: demo-exec.test PASS: demo-inst.test PASS: demo-unst.test PASS: depdemo-static.test PASS: depdemo-make.test PASS: depdemo-exec.test PASS: depdemo-inst.test PASS: depdemo-unst.test PASS: mdemo-static.test PASS: mdemo-make.test PASS: mdemo-exec.test PASS: mdemo-inst.test PASS: mdemo-unst.test PASS: cdemo-conf.test PASS: cdemo-make.test PASS: cdemo-exec.test PASS: demo-conf.test PASS: demo-make.test FAIL: demo-exec.test PASS: demo-inst.test PASS: demo-unst.test FAIL: deplibs.test PASS: depdemo-conf.test PASS: depdemo-make.test FAIL: depdemo-exec.test FAIL: depdemo-inst.test PASS: depdemo-unst.test PASS: mdemo-conf.test FAIL: mdemo-make.test PASS: mdemo-unst.test FAIL: dryrun.test PASS: demo-pic.test PASS: demo-make.test FAIL: demo-exec.test PASS: demo-nopic.test PASS: demo-make.test FAIL: demo-exec.test PASS: cdemo-shared.test PASS: cdemo-make.test PASS: cdemo-exec.test PASS: demo-shared.test PASS: demo-make.test FAIL: demo-exec.test PASS: demo-inst.test FAIL: hardcode.test FAIL: build-relink.test PASS: noinst-link.test PASS: demo-unst.test PASS: depdemo-shared.test PASS: depdemo-make.test FAIL: depdemo-exec.test FAIL: depdemo-inst.test FAIL: build-relink2.test PASS: depdemo-unst.test PASS: mdemo-shared.test FAIL: mdemo-make.test PASS: mdemo-unst.test PASS: assign.test PASS: link.test PASS: link-2.test PASS: nomode.test PASS: quote.test PASS: sh.test PASS: suffix.test = 15 of 69 tests failed = checking for gcc... xlc [..] checking if we can lock with hard links... yes checking whether the linker (/usr/bin/ld) supports shared libraries... ./configure[3567]: shared: not found yes [..] PASS: cdemo-static.test PASS: cdemo-make.test PASS: cdemo-exec.test PASS: demo-static.test PASS: demo-make.test PASS: demo-exec.test PASS: demo-inst.test PASS: demo-unst.test PASS: depdemo-static.test PASS: depdemo-make.test PASS: depdemo-exec.test PASS: depdemo-inst.test PASS: depdemo-unst.test PASS: mdemo-static.test PASS: mdemo-make.test PASS: mdemo-exec.test PASS: mdemo-inst.test PASS: mdemo-unst.test PASS: cdemo-conf.test PASS: cdemo-make.test PASS: cdemo-exec.test PASS: demo-conf.test PASS: demo-make.test FAIL: demo-exec.test PASS: demo-inst.test PASS: demo-unst.test PASS: deplibs.test PASS: depdemo-conf.test PASS: depdemo-make.test FAIL: depdemo-exec.test FAIL: depdemo-inst.test PASS: depdemo-unst.test PASS: mdemo-conf.test FAIL: mdemo-make.test PASS: mdemo-unst.test [.. hangs with foo1.o.lock and sub.o.lock in the dir ..] FAIL: dryrun.test [.. hangs with foo.o.lock, hell[12o].o.lock ...] PASS: demo-nofast.test PASS: demo-make.test FAIL: demo-exec.test PASS: demo-inst.test PASS: demo-unst.test PASS: demo-pic.test [.. hangs with foo.o.lock and hello.o.lock ..] PASS: demo-make.test FAIL: demo-exec.test [.. hangs with foo.o.lock and hello.o.lock ..] PASS: demo-nopic.test PASS: demo-make.test FAIL: demo-exec.test PASS: depdemo-nofast.test [.. hangs with l?/l?.o.lock ...] PASS: depdemo-make.test FAIL: depdemo-exec.test FAIL: depdemo-inst.test PASS: depdemo-unst.test [.. hangs with foo.o.lock ...] PASS: cdemo-shared.test PASS: cdemo-make.test PASS: cdemo-exec.test PASS: demo-shared.test [.. hangs with foo.o.lock ...] PASS: demo-make.test PASS: demo-exec.test PASS: demo-inst.test PASS: hardcode.test PASS: build-relink.test PASS: noinst-link.test PASS: demo-unst.test PASS: depdemo-shared.test [.. hangs with l?.o.lock ...] PASS: depdemo-make.test PASS: depdemo-exec.test PASS: depdemo-inst.test PASS: build-relink2.test PASS: depdemo-unst.test PASS: mdemo-shared.test [.. hangs with sub.o.lock and foo?.o.lock ...] FAIL: mdemo-make.test PASS: mdemo-unst.test PASS: assign.test PASS: link.test PASS: link-2.test PASS: nomode.test FAIL: quote.test PASS: sh.test PASS: suffix.test = 12 of 79 tests failed = Solaris 8, gcc 2.95.2, automake 1.4, autoconf 2.13, native ld checking for gcc... gcc checking host system type... sparc-sun-solaris2.8 [..] FAIL: quote.test ... 1 of 83 tests failed
Re: libtool 1.4
On 23 April, 2001 - Gary V. Vaughan sent me these 6.3K bytes: On Sunday 22 April 2001 7:09 am, you wrote: Hello. A friend told me the about your libtool 1.4 test mail, so I tried it on a few platforms.. Great! Thankyou for posting your results. I am unable to reproduce your quote.test failure on my Solaris 8 box with the current HEAD revision. If you still have this failure and you have time to do so, please send me the results of running: $ cd tests $ VERBOSE=1 sh -x ./quote.test $ echo $? need_prefix=no + test -z + sed s%/[^/]*$%% + echo ./quote.test srcdir=. + test . = ./quote.test + test set != set + . ./defs + cd . + pwd srcdir=/tmp/ap/libtool/tests + sed s%^.*/%% + echo ./quote.test progname=quote.test libtool=../libtool make=make prefix=./_inst + test no = yes + test -d ./_inst prefix=NONE + echo === Running quote.test === Running quote.test status=0 echo=echo + test X = X\t IFS= save_ifs= IFS= : + test -f /home/adm/stric/gnome/bin/echo + test -f /home/adm/stric/bin/echo + test -f /home/adm/stric/bin/sun4u/echo + test -f /usr/gnu/bin/echo + test X\t = X\t echo=/usr/gnu/bin/echo + break IFS= + test X/usr/gnu/bin/echo = Xecho + /usr/gnu/bin/echo == compile mode == compile mode preargs=gcc -c preflag= flag=-DVAR= postargs=foo.c + /usr/gnu/bin/echo = trying: no quoting = trying: no quoting + ../libtool -n --mode=compile gcc -c -DVAR=test foo.c result=mkdir .libs gcc -c -DVAR=test foo.c-fPIC -DPIC -o .libs/foo.lo gcc -c -DVAR=test foo.c -o foo.o /dev/null 21 mv -f .libs/foo.lo foo.lo match=gcc -c -DVAR=test + /usr/gnu/bin/echo = passed: mkdir .libs gcc -c -DVAR=test foo.c-fPIC -DPIC -o .libs/foo.lo gcc -c -DVAR=test foo.c -o foo.o /dev/null 21 mv -f .libs/foo.lo foo.lo = passed: mkdir .libs gcc -c -DVAR=test foo.c-fPIC -DPIC -o .libs/foo.lo gcc -c -DVAR=test foo.c -o foo.o /dev/null 21 mv -f .libs/foo.lo foo.lo + /usr/gnu/bin/echo = trying: \\ quoting = trying: \\ quoting + ../libtool -n --mode=compile gcc -c -DVAR=\test\ foo.c result=mkdir .libs gcc -c -DVAR=\\test\\ foo.c-fPIC -DPIC -o .libs/foo.lo gcc -c -DVAR=\\test\\ foo.c -o foo.o /dev/null 21 mv -f .libs/foo.lo foo.lo match=gcc -c -DVAR=\\test\\ + /usr/gnu/bin/echo = failed: mkdir .libs gcc -c -DVAR=\\test\\ foo.c-fPIC -DPIC -o .libs/foo.lo gcc -c -DVAR=\\test\\ foo.c -o foo.o /dev/null 21 mv -f .libs/foo.lo foo.lo = failed: mkdir .libs gcc -c -DVAR=\\test\\ foo.c-fPIC -DPIC -o .libs/foo.lo gcc -c -DVAR=\\test\\ foo.c -o foo.o /dev/null 21 mv -f .libs/foo.lo foo.lo status=1 + /usr/gnu/bin/echo = trying: \ quoting = trying: \ quoting + ../libtool -n --mode=compile gcc -c -DVAR=test foo.c result=mkdir .libs gcc -c -DVAR=\test\ foo.c-fPIC -DPIC -o .libs/foo.lo gcc -c -DVAR=\test\ foo.c -o foo.o /dev/null 21 mv -f .libs/foo.lo foo.lo match=gcc -c -DVAR=\test\ + /usr/gnu/bin/echo = failed: mkdir .libs gcc -c -DVAR=\test\ foo.c-fPIC -DPIC -o .libs/foo.lo gcc -c -DVAR=\test\ foo.c -o foo.o /dev/null 21 mv -f .libs/foo.lo foo.lo = failed: mkdir .libs gcc -c -DVAR=\test\ foo.c-fPIC -DPIC -o .libs/foo.lo gcc -c -DVAR=\test\ foo.c -o foo.o /dev/null 21 mv -f .libs/foo.lo foo.lo status=1 + /usr/gnu/bin/echo = trying: \` quoting = trying: \` quoting + ../libtool -n --mode=compile gcc -c -DVAR=`test` foo.c result=mkdir .libs gcc -c -DVAR=\`test\` foo.c-fPIC -DPIC -o .libs/foo.lo gcc -c -DVAR=\`test\` foo.c -o foo.o /dev/null 21 mv -f .libs/foo.lo foo.lo match=gcc -c -DVAR=\`test\` + /usr/gnu/bin/echo = failed: mkdir .libs gcc -c -DVAR=\`test\` foo.c-fPIC -DPIC -o .libs/foo.lo gcc -c -DVAR=\`test\` foo.c -o foo.o /dev/null 21 mv -f .libs/foo.lo foo.lo = failed: mkdir .libs gcc -c -DVAR=\`test\` foo.c-fPIC -DPIC -o .libs/foo.lo gcc -c -DVAR=\`test\` foo.c -o foo.o /dev/null 21 mv -f .libs/foo.lo foo.lo status=1 + /usr/gnu/bin/echo = trying: \$ quoting = trying: \$ quoting + ../libtool -n --mode=compile gcc -c -DVAR=$test$ foo.c result=mkdir .libs gcc -c -DVAR=\$test\$ foo.c-fPIC -DPIC -o .libs/foo.lo gcc -c -DVAR=\$test\$ foo.c -o foo.o /dev/null 21 mv -f .libs/foo.lo foo.lo match=gcc -c -DVAR=\$test\$ + /usr/gnu/bin/echo = failed: mkdir .libs gcc -c -DVAR=\$test\$ foo.c-fPIC -DPIC -o .libs/foo.lo gcc -c -DVAR=\$test\$ foo.c -o foo.o /dev/null 21 mv -f .libs/foo.lo foo.lo = failed: mkdir .libs gcc -c -DVAR=\$test\$ foo.c-fPIC -DPIC -o .libs/foo.lo gcc -c -DVAR=\$test\$ foo.c -o foo.o /dev/null 21 mv -f .libs/foo.lo foo.lo status=1 + /usr/gnu/bin/echo = trying: [ quoting = trying: [ quoting + ../libtool -n --mode=compile gcc -c -DVAR=[test[ foo.c result=mkdir .libs gcc -c -DVAR=[test[ foo.c-fPIC -DPIC -o .libs/foo.lo gcc -c -DVAR=[test[ foo.c -o foo.o /dev/null 21 mv -f .libs/foo.lo foo.lo match=gcc -c -DVAR=[test[ + /usr/gnu/bin/echo = passed: mkdir .libs gcc -c -DVAR=[test[ foo.c-fPIC -DPIC -o .libs/foo.lo gcc -c -DVAR=[test[ foo.c -o foo.o /dev/null 21 mv -f .libs/foo.lo foo.lo
Re: libtool 1.4
On 23 April, 2001 - Gary V. Vaughan sent me these 6.3K bytes:
On Sunday 22 April 2001 7:09 am, you wrote:
Hello.
A friend told me the about your libtool 1.4 test mail, so I tried it on
a few platforms..
Great! Thankyou for posting your results. I am unable to reproduce your
quote.test failure on my Solaris 8 box with the current HEAD revision. If
you still have this failure and you have time to do so, please send me the
results of running:
$ cd tests
$ VERBOSE=1 sh -x ./quote.test
$ echo $?
Sorry.. $? = 1
/Tomas
--
Tomas Ögren, [EMAIL PROTECTED], http://www.ing.umu.se/~stric/
|- Student at Computing Science, University of Umeå
`- Sysadmin at {cs,ing,acc}.umu.se
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool-1.4 release
On Monday 23 April 2001 2:00 am, I wrote: I'm holding off the release for a day or two... Revised release date tomorrow April 24, around 10pm GMT unless someone points out a serious enough problem to me before then. Cheers, Gary. -- ___ _ ___ __ _ mailto: [EMAIL PROTECTED] / __|__ _ _ ___ _| | / / | / /_ _ _ _ __ _| |_ __ _ ___ [EMAIL PROTECTED] | (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \ \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/ home page: /___/ /___/ gpg public key: http://www.oranda.demon.co.uk http://www.oranda.demon.co.uk/key.asc ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool-1.4
On Saturday 21 April 2001 11:20 pm, Peter Eisentraut wrote: Gary V. Vaughan writes: Failing major disasters, or the discovery of a showstopper, there are less than 18 hours to go before the release of libtool-1.4 from CVS HEAD. I think that's going to be a problem for you: libtool$ make dist make: *** No rule to make target `ltconfig', needed by `distdir'. Stop. The ltconfig reference comes from automake's list of files to be distributed if the package uses libtool. There is a small patch to automake-1.4 at the end of the libtool README file to fix this problem at the source. Cheers, Gary. -- ___ _ ___ __ _ mailto: [EMAIL PROTECTED] / __|__ _ _ ___ _| | / / | / /_ _ _ _ __ _| |_ __ _ ___ [EMAIL PROTECTED] | (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \ \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/ home page: /___/ /___/ gpg public key: http://www.oranda.demon.co.uk http://www.oranda.demon.co.uk/key.asc ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool-1.4
Gary V. Vaughan wrote: Hi everyone, $ ./configure ... Configuring libtool 1.3e (1.900 2001/04/20 20:55:18) ... checking host system type... i686-pc-linux-gnu This is an a.out system checking host system type... i386-unknown-netbsd1.4.3A All versions of 1.4.x with x3A will fail a couple of tests due to a bug in ld.aout_so. Its not a problem with libtool. ... $ make ... $ make check ... === All 83 tests passed === === All 83 tests passed === gmake[2]: Leaving directory `/dsk/home/nick/libtool-test/libtool/tests' Nick -- aka [EMAIL PROTECTED], [EMAIL PROTECTED] ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
libtool-1.4
Hi everyone, Failing major disasters, or the discovery of a showstopper, there are less than 18 hours to go before the release of libtool-1.4 from CVS HEAD. I would be grateful for any host triplets (as reported by the libtool configure script) on which you are able to run the test suite, so that I can update the PLATFORMS file. This is what you need to do to contribute: $ cvs -z3 -d :pserver:[EMAIL PROTECTED]:/cvsroot/libtool login Password: [Hit RETURN] $ cvs -z3 -d :pserver:[EMAIL PROTECTED]:/cvsroot/libtool co libtool ... $ cd libtool $ ./bootstrap $ ./configure ... Configuring libtool 1.3e (1.900 2001/04/20 20:55:18) ... checking host system type... i686-pc-linux-gnu ... $ make ... $ make check ... === All 83 tests passed === Please let me know if you are using an unusual mixture of automake, autoconf, compiler, linker etc in order to get it to pass, otherwise I will assume automake-1.4, autoconf-2.13, gcc-2.95.x with matching GNU ld. Cheers, Gary. -- ___ _ ___ __ _ mailto: [EMAIL PROTECTED] / __|__ _ _ ___ _| | / / | / /_ _ _ _ __ _| |_ __ _ ___ [EMAIL PROTECTED] | (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \ \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/ home page: /___/ /___/ gpg public key: http://www.oranda.demon.co.uk http://www.oranda.demon.co.uk/key.asc ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Downtime... musings... libtool-1.4
Alexandre Oliva writes: On Apr 18, 2001, "Gary V. Vaughan" [EMAIL PROTECTED] wrote: However, I just deleted my savannah#2 certificate, and I can can now get in. Me too. Sorry about the noise. I am truly sorry this was necessary. I don't know yet why the new certificate required this. I think but did not check that it is because the openssl library was upgraded between the two certificates. I'm no security expert and that sucks :-( Thanks for your patience, -- Loic Dachary http://www.dachary.org/ [EMAIL PROTECTED] 24 av Secretan http://www.senga.org/ [EMAIL PROTECTED] 75019Paris Tel: 33 1 42 45 09 16[EMAIL PROTECTED] GPG Public Key: http://www.dachary.org/loic/gpg.txt ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Downtime... musings... libtool-1.4
On Apr 18, 2001, "Gary V. Vaughan" [EMAIL PROTECTED] wrote:
However, I just deleted my savannah#2 certificate, and I can can now
get in.
Me too. Sorry about the noise.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: Downtime... musings... libtool-1.4
On Wednesday 18 April 2001 4:35 am, Alexandre Oliva wrote: On Apr 17, 2001, Thomas Tanner [EMAIL PROTECTED] wrote: Hi Gary, Alexandre and the rest of the team! Gee! So you're still alive, after all! You had got me worried :-) Wow. Hi Thomas. I'm afraid I didn't even list you as a maintainer when I redid the libtool webpages... PS: can anybody please add me to the libtool group on savannah? my login name is tanner Nup. Sorry. There is no way to log in to savannah at the moment, as there is still no SSL certificate =(O| I'm Ccing Loic, who might be able to shed some light, since I can't find any reference to the certification issue since the last one was regenerated in February. In the mean while, I'd be happy to commit patches on your behalf if you mail them to the patches list. I wish I could. But I can't even log in now :-( This is when I connect using a localhost proxy. If I connect directly, Mozilla 0.8.1 says the site's certificate has expired and doesn't let me through :-( Cheers, Gary. -- ___ _ ___ __ _ mailto: [EMAIL PROTECTED] / __|__ _ _ ___ _| | / / | / /_ _ _ _ __ _| |_ __ _ ___ [EMAIL PROTECTED] | (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \ \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/ home page: /___/ /___/ gpg public key: http://www.oranda.demon.co.uk http://www.oranda.demon.co.uk/key.asc ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Downtime... musings... libtool-1.4
Gary V. Vaughan writes: Nup. Sorry. There is no way to log in to savannah at the moment, as there is still no SSL certificate =(O| I'm Ccing Loic, who might be able to shed some light, since I can't find any reference to the certification issue since the last one was regenerated in February. Why do you think it's no possible to login savannah ? The certificate is self-signed but usable. 5 to 10 accounts are created every day therefore I guess it's not only working for myself ;-) Cheers, -- Loic Dachary http://www.dachary.org/ [EMAIL PROTECTED] 24 av Secretan http://www.senga.org/ [EMAIL PROTECTED] 75019Paris Tel: 33 1 42 45 09 16[EMAIL PROTECTED] GPG Public Key: http://www.dachary.org/loic/gpg.txt ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Downtime... musings... libtool-1.4
Hi Gary, On 18-Apr-2001 Gary V. Vaughan wrote: I'd rather not, since there is a difficult merge on the other side of the release and I won't have the time to help Alexandre with that in 2 weeks if we wait that long =(O| I really need to finalise 1.4 so that I can concentrate on my book for the Summer. How about this: I'll release 1.4 this weekend and make a maintenance branch so that Alexandre can make the first MLB merge. If you find any bugs after that, we can fix them in the maintenance branch and release 1.4.1. I'm sure we'll get a much bigger response to my call for testing on a 1.4 release than we did with 1.3d, so I expect that a 1.4.1 release will be needed inside a month anyhow. Well, OK. Do what you think is right. I really don't know how stable libtool-HEAD is right now. Maybe I can find and fix some bugs till this weekend. In the mean while, I'd be happy to commit patches on your behalf if you mail them to the patches list. Thanks. Thomas Tanner - email: tanner@(ffii.org|gnu.org|gmx.de) web: http://home.pages.de/~tanner UMI: http://umi.ffii.org ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Downtime... musings... libtool-1.4
On Wednesday 18 April 2001 1:33 pm, [EMAIL PROTECTED] wrote: Gary V. Vaughan writes: Nup. Sorry. There is no way to log in to savannah at the moment, as there is still no SSL certificate =(O| I'm Ccing Loic, who might be able to shed some light, since I can't find any reference to the certification issue since the last one was regenerated in February. Why do you think it's no possible to login savannah ? The certificate is self-signed but usable. 5 to 10 accounts are created every day therefore I guess it's not only working for myself ;-) I was getting `either the date on your computer is wrong or this certificate has expired from March 26 2001' when pressing the `Login via SSL' link, which prevented me from reaching the password entry dialogue whether I answered `Cancel' or `Continue'. However, I just deleted my savannah#2 certificate, and I can can now get in. Doh! Not sure why I didn't try that earlier, sorry. Alexandre, I expect this is the problem you are having too. Thomas, I have added you to the developers for the libtool project. Cheers, Gary. -- ___ _ ___ __ _ mailto: [EMAIL PROTECTED] / __|__ _ _ ___ _| | / / | / /_ _ _ _ __ _| |_ __ _ ___ [EMAIL PROTECTED] | (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \ \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/ home page: /___/ /___/ gpg public key: http://www.oranda.demon.co.uk http://www.oranda.demon.co.uk/key.asc ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
RE: Downtime... musings... libtool-1.4
Hi Gary, Alexandre and the rest of the team! On 11-Apr-2001 Gary V. Vaughan wrote: I plan to clear any patches left in the queue, test on the hosts I have access to and release libtool-1.4 from HEAD upon my return. I would be extremely appreciative of feedback from libtool users about their experiences with the daily snapshots between now and then... After almost one year of inactivity I can finally spend some time working on libtool. I certainly won't be able to catch up with the mailinglist but AFAICS you all have done a great job maintaining libtool! Gary, would you please delay the release of libtool 1.4 and give me two weeks to fix all the old bugs in the ILD code and libltdl (or at least to verify that they've already been fixed)? PS: can anybody please add me to the libtool group on savannah? my login name is tanner Thomas Tanner - email: tanner@(ffii.org|gnu.org|gmx.de) web: http://home.pages.de/~tanner UMI: http://umi.ffii.org ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
