Re: Calling libtool from configure.ac
On Tue, 2008-09-23 at 14:11 +0200, Ralf Wildenhues wrote: > * Scott James Remnant wrote on Tue, Sep 23, 2008 at 02:08:03PM CEST: > > While porting a bunch of GNOME applications from using libtool 1.5 to > > 2.2, we've encountered a couple that use libtool in their configure.ac > > to test compilation. > > Use LT_OUTPUT (if it is defined). > Aha! Thanks, had forgotten about that completely. Happily I think our info documentation has been fixed to be shipped in the package now :) Scott -- Scott James Remnant [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ http://lists.gnu.org/mailman/listinfo/libtool
Calling libtool from configure.ac
While porting a bunch of GNOME applications from using libtool 1.5 to
2.2, we've encountered a couple that use libtool in their configure.ac
to test compilation.
e.g.:
if /bin/sh ../libtool --mode=compile ${CC} $PYTHON_CFLAGS -c
testpython.c >/dev/null 2>&1 && \
/bin/sh ../libtool --mode=link ${CC} -o testpython.la -rpath `pwd`
-module -avoid-version $PYTHON_LIB_LOC testpython.lo $PYTHON_LIBS
$PYTHON_EXTRA_LIBS >/dev/null 2>&1 && \
grep 'dlname.*testpython' testpython.la >/dev/null 2>&1; then
result=yes
Any idea what the best approach to porting these would be?
Scott
--
Scott James Remnant
[EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
___
http://lists.gnu.org/mailman/listinfo/libtool
autoreconf vs. libtoolize when upgrading to libtool 2.2
Hey folks, We've switched the default version of Libtool in our development version to 2.2, and are doing such migrations as are necessary to permit this. In the progress, we've encountered an interesting difference between the behaviour of autoreconf and libtoolize that leaves you with a broken build system and no warning. It can be summarised thus: - autoreconf updates all files to their newer version - autoreconf does not install new files unless --install is given - libtoolize updates all files to their newer version *and* always installs ltmain.sh - since this always installs, autoreconf does not call libtoolize unless --install is given - aclocal always updates libtool's m4 files, and includes the new ones into aclocal.m4 This means if you upgrade libtool, and run "autoreconf", you end up with the old 1.5 ltmain.sh and the newer 2.2 autoconf macros. This obviously breaks. I humbly suggest the following fixes: - libtoolize should not install files unless --install is given - but should update any that are already installed - thus, if libtoolize supports --install, autoreconf may freely call libtoolize when not given, and add the argument when given. Assuming both maintainer groups are ok with this, I'm happy to cook up some patches. I'm also happy to hear alternate suggestions? Scott -- Scott James Remnant [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: another 1.5 release
On Thu, 2004-12-02 at 18:36 -0500, Daniel Reed wrote: > Is there any chance .multilib2 can be incorporated into 1.5.12? As written, > it simply causes libtool to ask gcc to find .la files if gcc is in use. It > should have no impact on non-gcc builds and should not cause any files to be > missed (the original behavior is used if gcc is unable to find a requested > file). > Do you have a copy of the patch to be considered? I suspect it's the one that isn't compatible with the multilib layout chosen by Debian. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: RFC: proposal for indirect deplibs
On Wed, 2004-11-24 at 10:19 +0100, Ralf Wildenhues wrote: > Libtool and inter-library dependencies > == > > needed-following linker: > A system with a needed-following linker has a means to record > dependencies on other libraries within a library (based on the soname of > the dependency library), and a linker that uses this information to load > dependent libraries. Solaris and Linux are examples of this, [ > prominent counter-example ]. > I always consider Solaris the prominent counter-example, though my information may be out of date. Can you demonstrate which versions of Solaris do and don't have link-loaders that follow NEEDED? It may be that they fixed it, but didn't add appropriate NEEDEDs to some of their shipped libraries. We'll need to take this into account if that's the case. > This has lead to subtle problems on such systems when dependent > libraries are recompiled against different versions of its dependencies. > Multiple versions of a library may be linked in the same output, > resulting in a broken link. > [ insert example from Scott ] > Generally it's not a "multiple versions may be linked" problem, because you have that exact same problem when you don't link them all. They still both get loaded into the address space. The problem is when you have a SONAME change in a low-level library (such as libpng) in a very large stack (such as GNOME or KDE). The low-level library is only being used by the libraries that link it, yet you have to recompile the entire desktop environment to move to the new library as everything directly linked it. By only linking the actually declared dependencies, you only need recompile the libraries that declare dependencies on libpng itself. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Tue, 2004-11-16 at 11:15 -0800, Jacob Meuser wrote: > On Tue, Nov 16, 2004 at 03:02:55PM +0000, Scott James Remnant wrote: > > Actually, I'd say the opposite is true ... the LONGER link line, > > produced by the current Libtool, is what allows people to get away with > > this because Libtool puts more stuff into the link line. > > > > A shorter, more concise, link line actually forces people to make sure > > they *do* link anything they require themselves, rather than relying on > > Libtool to do the right thing for them. > > but where does the problem show up? on !Linux, because Linux will > "do the right thing". > No, on Linux ... because Linux does the right thing and causes the applications to break; whereas Libtool does the wrong thing and links the application directly with half the libraries on the system. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Mon, 2004-11-15 at 10:51 -0800, Jacob Meuser wrote: > On Mon, Nov 15, 2004 at 03:45:10PM +0000, Scott James Remnant wrote: > > It does assume that all library dependencies are registered, yes. This > > has never been a problem, because we've never found any Libtool-produced > > library that doesn't have all dependencies registered. > > > > If this isn't the case, and at one time Libtool never registered all of > > the dependencies, we should check for that. Otherwise I don't see the > > need -- we can assume sanity from our own output. > > for a long time, libtool did not handle -pthread properly. > It still doesn't, the current situation is a botch that produces the right results but does it in the wrong way. Libraries should record what compiler/linker flags they need (-pthread is not a dependency library). > I can point to at least a few .la files on my system that do > not have -pthread or even other required libraries registered. > I'd be quite shocked if the current version of Libtool produces libraries with -pthread in dependency_libs; I specifically wrote the patch to prevent that, because it causes a lot of problems. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Mon, 2004-11-15 at 17:19 -0600, Bob Friesenhahn wrote: > On Mon, 15 Nov 2004, Gary V. Vaughan wrote: > >> Bob Friesenhahn wrote: > >>> > >>> Doesn't this patch cause Linux to be more equal than other operating > >>> systems, thereby causing free applications to be developed which won't > >>> work anywhere else? > > > > No, it just shortens the link line on platforms that support that. > > The point of my statement is that many applications are developed > solely under Linux, but the authors expect them to be portable because > they use autotools and standard APIs. It seems that the shortened > link line will allow developers to not list the dependencies which are > necessary on some other platforms. > Actually, I'd say the opposite is true ... the LONGER link line, produced by the current Libtool, is what allows people to get away with this because Libtool puts more stuff into the link line. A shorter, more concise, link line actually forces people to make sure they *do* link anything they require themselves, rather than relying on Libtool to do the right thing for them. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Mon, 2004-11-15 at 15:51 +, Joe Orton wrote: > On Mon, Nov 15, 2004 at 02:42:51PM +0000, Scott James Remnant wrote: > > On Mon, 2004-11-15 at 13:16 +, Gary V. Vaughan wrote: > > > > > Ralf Wildenhues wrote: > > > >>>>Scott James Remnant wrote: > > > >>>>> > > > >>>>>They're both trying to deal with platforms like Solaris that don't > > > >>>>>have > > > >>>>>a needed-following link loader. > > > > > > > The patch that is in Debian's libtool? > > > > > > It is? I'll defer to Scott... > > > > > Yes. When you're making a distribution, Libtool's behaviour of directly > > linking indirect-dependencies is insane. For a SONAME change to a > > library deep in the stack, that only affects the library immediately > > above it, you suddenly need to rebuild your entire desktop environment. > > How does libtool know that the SONAME change only affects the library > above it? What if there is a structure exposed through multiple levels > of libraries or something like that? I can think of several cases where > doing this by default in libtool would be unsafe. > Then those additional levels should directly link to the shared libraries they depend on. This is just correct practice. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Mon, 2004-11-15 at 15:34 +, Gary V. Vaughan wrote: > Scott James Remnant wrote: > > > I submitted keybuk-linux-deplibs.patch to libtool-patches back in March, > > and there was a slight objection from Bob and nobody else joined in to > > ok it. > > The list was very busy around then, and I was waiting to see the results > of you and Bob duking it out ;-) You didn't answer any of Bob's > questions... > I was pretty busy at the time as well, and have been manically busy since then with the new job -- only just getting my head above water again. > >Bob Friesenhahn wrote: > >> > >> Doesn't this patch cause Linux to be more equal than other operating > >> systems, thereby causing free applications to be developed which won't > >> work anywhere else? > > No, it just shortens the link line on platforms that support that. > And, indeed, only does that for shared libraries. It should actually promote better support, because you need to remember to directly link any library you depend on -- and don't rely on a dependency library linking it in for you. > >> This solution does not seem to support the case where an actual > >> dependency exists but is not registered in the library (because the > >> user didn't supply it) so that the dynamic link loader doesn't know > >> about it? > > Good point. We really ought to check the library registered > dependencies against the .la deplibs and only drop the deplibs > common to both, since we know the linker will pick those up. > I guess that means looking through the dependency tree of .la > files to find matches. > It does assume that all library dependencies are registered, yes. This has never been a problem, because we've never found any Libtool-produced library that doesn't have all dependencies registered. If this isn't the case, and at one time Libtool never registered all of the dependencies, we should check for that. Otherwise I don't see the need -- we can assume sanity from our own output. > Also, what do we do about -rpath? We still need to encode the > runtime path to even the dropped deplib directories so that the > same library we linked with is picked up at runtime. > Libraries have their own RPATH, don't they? > >> If libone or libfour contain weak symbols, what happens? > > I have no idea! Scott? > They're available to the library that links them. If the application was relying on something down the stack, it was broken anyway and should've directly linked libone or libfour itself. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Mon, 2004-11-15 at 13:16 +, Gary V. Vaughan wrote: > Ralf Wildenhues wrote: > >>>>Scott James Remnant wrote: > >>>>> > >>>>>They're both trying to deal with platforms like Solaris that don't have > >>>>>a needed-following link loader. > > > The patch that is in Debian's libtool? > > It is? I'll defer to Scott... > Yes. When you're making a distribution, Libtool's behaviour of directly linking indirect-dependencies is insane. For a SONAME change to a library deep in the stack, that only affects the library immediately above it, you suddenly need to rebuild your entire desktop environment. > > If yes, the why in the world are we not using it? > > Exactly! :-) > I submitted keybuk-linux-deplibs.patch to libtool-patches back in March, and there was a slight objection from Bob and nobody else joined in to ok it. Attached again. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? diff -ruNp libtool-CVS~/ChangeLog libtool-CVS/ChangeLog --- libtool-CVS~/ChangeLog 2004-03-24 14:23:18.0 + +++ libtool-CVS/ChangeLog 2004-03-28 22:12:29.0 +0100 @@ -0,0 +1,11 @@ +2004-03-28 Scott James Remnant <[EMAIL PROTECTED]> + + * ltmain.in: The dynamic link loader on some platforms is able to + correctly traverse dependency trees, therefore when $link_all_deplibs + is set to 'no' don't add the contents of dependency_libs to the + link line to link a program. + * m4/libtool.m4 (AC_LIBTOOL_PROG_LD_SHLIBS) [linux*]: Linux is one + of those platforms, set link_all_deplibs to 'no' for both C++ and + other compilers. + * NEWS: Updated. + diff -ruNp libtool-CVS~/ltmain.in libtool-CVS/ltmain.in --- libtool-CVS~/ltmain.in 2004-03-24 02:59:18.0 + +++ libtool-CVS/ltmain.in 2004-03-28 21:45:45.0 +0100 @@ -1904,7 +1904,10 @@ EOF case $pass in dlopen) libs="$dlfiles" ;; dlpreopen) libs="$dlprefiles" ;; - link) libs="$deplibs %DEPLIBS% $dependency_libs" ;; + link) + libs="$deplibs %DEPLIBS%" + test "X$link_all_deplibs" != Xno && libs="$libs $dependency_libs" + ;; esac fi if test "$pass" = dlopen; then diff -ruNp libtool-CVS~/m4/libtool.m4 libtool-CVS/m4/libtool.m4 --- libtool-CVS~/m4/libtool.m4 2004-03-24 14:08:28.0 + +++ libtool-CVS/m4/libtool.m4 2004-03-28 22:08:26.0 +0100 @@ -3381,6 +3381,9 @@ m4_if([$1], [CXX], [ cygwin* | mingw*) _LT_AC_TAGVAR(export_symbols_cmds, $1)='$NM $libobjs $convenience | $global_symbol_pipe | $SED -e '\''/^[[BCDGS]] /s/.* \([[^ ]]*\)/\1 DATA/;/^.* __nm__/s/^.* __nm__\([[^ ]]*\) [[^ ]]*/\1 DATA/;/^I /d;/^[[AITW]] /s/.* //'\'' | sort | uniq > $export_symbols' ;; + linux*) +_LT_AC_TAGVAR(link_all_deplibs, $1)=no + ;; *) _LT_AC_TAGVAR(export_symbols_cmds, $1)='$NM $libobjs $convenience | $global_symbol_pipe | $SED '\''s/.* //'\'' | sort | uniq > $export_symbols' ;; @@ -3566,6 +3569,7 @@ _LT_EOF else _LT_AC_TAGVAR(archive_expsym_cmds, $1)=$_LT_AC_TAGVAR(archive_cmds, $1) fi + _LT_AC_TAGVAR(link_all_deplibs, $1)=no else _LT_AC_TAGVAR(ld_shlibs, $1)=no fi diff -ruNp libtool-CVS~/NEWS libtool-CVS/NEWS --- libtool-CVS~/NEWS 2004-03-24 14:13:19.0 + +++ libtool-CVS/NEWS 2004-03-28 22:13:41.0 +0100 @@ -31,6 +31,9 @@ New in 1.5b: 2004-??-??; CVS version 1.5 * If you configure libtool with --disable-shared (or if libtool does not support shared libraries on your platform) trying to build a library using `-shared' is a fatal error. +* libtool no longer adds the contents of dependency_libs to the link line + to link a program on Linux as its dynamic link loader is able to + correctly traverse dependency trees. * libtoolize installs libtool.m4 (and ltdl.m4 if used) to AC_CONFIG_MACRO_DIR. * Mode inferrence removed, shorthand for choosing modes added. * Specifying -allow-undefined is now an error. signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Sun, 2004-11-14 at 14:45 -0600, Bob Friesenhahn wrote: > On Sun, 14 Nov 2004, Albert Chin wrote: > > > On Sun, Nov 14, 2004 at 08:57:27AM +, Scott James Remnant wrote: > >> They're both trying to deal with platforms like Solaris that don't have > >> a needed-following link loader. > > > > What does this mean? > > I assume that he is talking about ELF inherited dependencies. With > inherited dependencies, libraries which were not specified at link > time may appear in the output of `ldd' because one of the linked > libraries does require other non-listed libraries. > Indeed. The link-loader follows the NEEDED of shared libraries it loads and loads *their* dependencies as well. > Recent versions of Solaris do inherit shared library dependencies. > Are you sure about that?! Solaris 9 here doesn't. > Probably Scott should have mentioned Linux instead since I recall a time > (possibly as recent > as Red Hat 5.0) when it did not inherit shared library dependencies. > Nowhere near that recent. Linux's ELF link-loader has, from what I recall, *always* done it. You'd have to go back to before ELF, I suspect. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO ... solution to the pkg-config "conflict"?
On Sun, 2004-11-14 at 17:37 -0800, Jacob Meuser wrote: > On Sun, Nov 14, 2004 at 08:53:15AM +0000, Scott James Remnant wrote: > > I actually tend to think we should look at this the other way ... if we > > could expose the information Libtool has to other tools, pkg-config > > could defer to Libtool. > > > > So rather than libtool taking over pkg-config, we make them work > > together. > > so, what you want, is simply something like ... > > $ pkg-config --libs foo > -L/path/to -lfoo > $ pkg-config --libs-libtool foo > /path/to/libfoo.la > $ pkg-config --libs bar > -L/path/to -lbar -L/path/to -lfoo > $ pkg-config --libs-libtool bar > /path/to/libbar.la > > where libbar depends on libfoo? > Something along those lines, perhaps; yes. I haven't fully thought out my plans yet. > if so, then write the patch and give it to the pkg-config folks. > I took over pkg-config from Havoc some time ago; I haven't had the time to either patch or reimplement it yet :o) Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Sun, 2004-11-14 at 13:35 -0500, Daniel Reed wrote: > On 2004-11-14T08:50-0000, Scott James Remnant wrote: > ) On Fri, 2004-11-12 at 11:20 +, Gary V. Vaughan wrote: > ) > Haven't thought through the -I thing yet though... maybe that doesn't > ) > belong in libtool... maybe we could provide a macro that can intuit > ) > include directories from .la locations... I dunno... > ) The most common arrangement is libraries in /usr/lib and includes > ) in /usr/include/- ... so not easy to intuit like that. > > That appears to be common of GNOME components, but does not appear to be > common in the general case. > pkg-config is a GNOME component that became generically useful enough to become a Freedesktop.org component. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Fri, 2004-11-12 at 23:02 -0800, Jacob Meuser wrote: > > It doesn't care about package versions, but it has to care about library > > versions and paths to libraries. > > again, functionality provided by pkg-config. > > I am contesting the claim "Libtool already has all the information > it needs". > I actually tend to think we should look at this the other way ... if we could expose the information Libtool has to other tools, pkg-config could defer to Libtool. So rather than libtool taking over pkg-config, we make them work together. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Sat, 2004-11-13 at 15:27 -0800, Jacob Meuser wrote:
> On Sat, Nov 13, 2004 at 10:21:19AM +0100, Ralf Corsepius wrote:
> > It's just that their functionality
> > intersects and partially conflicts.
>
> how?
>
> pkg-config is used to give basic information about installed packages.
> libtool is used to build libraries.
>
> pkg-config is used in configure scripts.
> libtool is used in Makefiles.
>
> yes, it's possible to use constructs like
>
> foo.so: foo.o
> ${CC} ${LDFLAGS} -o foo.so foo.o `pkg-config bar --libs`
>
> in Makefiles, but this is not overlap in a conflicting way.
>
This is actually exactly what happens when you use pkg-config in a
configure script. It generates a (e.g.) GLIB_LIBS Makefile variable and
you arrange for the contents of that to be added to the link line --
just like you say here.
The conflict is that pkg-config not only provides the -L and -l needed
to the library, but also those for all of its dependency libraries.
So does Libtool.
They're both trying to deal with platforms like Solaris that don't have
a needed-following link loader.
It would be far neater if they could co-operate with this.
Scott
--
Have you ever, ever felt like this?
Had strange things happen? Are you going round the twist?
signature.asc
Description: This is a digitally signed message part
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Fri, 2004-11-12 at 11:20 +, Gary V. Vaughan wrote: > Albert Chin wrote: > > On Wed, Nov 10, 2004 at 03:43:48PM +0000, Scott James Remnant wrote: > > > > Ick. Libtool is about portably building/using libraries. Why can't we > > leave it at that? > > But linking against installed libraries using the correct -L and -l flags > *is* part of portably building/using libraries! ;-) > > Haven't thought through the -I thing yet though... maybe that doesn't > belong in libtool... maybe we could provide a macro that can intuit > include directories from .la locations... I dunno... > The most common arrangement is libraries in /usr/lib and includes in /usr/include/- ... so not easy to intuit like that. Scot -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: License of m4/ltoptions.m4
On Wed, 2004-11-10 at 14:57 -0800, Paul Eggert wrote: > As a special exception to the GNU General Public License, if you > distribute this file as part of a package that automatically derives > from this file a configuration script (and perhaps some associated > intermediate files), then you may distribute this file and the derived > files for that purpose, under the same terms that you use for the rest > of the package. > Has my vote. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Wed, 2004-11-10 at 12:17 -0600, Bob Friesenhahn wrote: > On Wed, 10 Nov 2004, Ralf Wildenhues wrote: > > >> However it *also* provides the right -I flags to point at the include > >> files. A GTK+ application will '#include ' for example > >> and require -I/usr/include/gtk-2.0 to actually be able to find that (or > >> -1.0, -3.0, etc.) > > > > That's a good feature. Dunno whether I want that (or it can even be) in > > a .la file or not. But letting libtool output both information might > > prove valuable. Absorbing pkgconfig in libtool in a way that each > > pkgconfig user must use libtool will pave way for quote some resistance, > > I'd expect. > > pkg-config does not issue the "right" -I flags. It merely proposes > some based on where the package is installed. This is fine if the > package is used in isolation. Sometimes these flags work ok in > conjuction with flags from other unrelated packages, but other times > it results in a bloody mess and wrong behavior. > It should never do ... the intent is that the directory specified by the -I flag *only* contains the include files of the given package; otherwise you'd be doing -I/usr/include or similar which pkg-config specifically removes from any output. Do you have an example of the wrong behaviour? Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Wed, 2004-11-10 at 13:25 +, Gary V. Vaughan wrote: > Peter O'Gorman wrote: > > Well, I haven't thought about it really, I was vaguely imagining running > > a perl script during bootstrap which would take the bits and pieces and > > put them all together. I am told that xslt could do this too. The point > > being that we'd end up with the same (more or less) libtool.m4 as we > > have now, it would just be a heck of a lot easier to find the bits and > > pieces related to specific platforms, and would leave the platform > > independent stuff in a single file. > > Gah, perl? Blech. XML? Bah! Choke... > This does seem rather over-the-top to me ... the only thing worse I can think of would be using lisp for anything other than scaring comp-sci students with. > I think that porting ltmain to C or a byte-compiled language of some sort > is definitely a win all round, so we can probably come up with an > implementation in whatever language ltmain gets rewritten in eventually. > The trouble is that you need to either compile ltmain on every platform, or have an interpreter handy. I guess there could be a magic Automake-shimmy to make every binary depend on "libtool", which can be compiled in-place in the source a bit like libintl. This scares me more than the shell script :p Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Tue, 2004-11-09 at 14:24 +, Gary V. Vaughan wrote: > 6. Absorb the functionality of the aberration called pkg-config. Libtool > already has all the information it needs, we just need to teach it (or > maybe a subsidiary script) to spit out link flags after poking around > in a dependency chain of .la files. > There's actually a couple of things pkg-config does that Libtool doesn't currently do. pkg-config's main job can be summed up simply as enabling parallel-installed -dev packages. Principally it provides the right -L and -l flags to link libraries, we can get this from Libtool. An an improvement would then be only providing the dependency -l flags on platforms that need it, and not on Linux for example. However it *also* provides the right -I flags to point at the include files. A GTK+ application will '#include ' for example and require -I/usr/include/gtk-2.0 to actually be able to find that (or -1.0, -3.0, etc.) Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Tue, 2004-11-09 at 16:29 +0100, Ralf Wildenhues wrote: > 6. Versioned libraries. Although this is not very portable yet, it is a > concept which IMHO needs support. Many people ask for it. > One of the principal problems is that you need to record when symbols were added to the library to get any use out of them, this means you actually need a version script that gets incrementally modified as new symbols are added. If you just globally attach the same symbol to all of the symbols, you're not really accomplishing much (other than enabling two different versions to be loaded into the same application, and -Bsymbolic solves that *DON'T SHOOT ME* :p). > 9. Support multilibbing. > Can you explain? > 10. More testcases. Faster test suite. Please submit test cases for > stuff that does not work. > I've been playing with some test frameworks recently, the Autotest one that comes with Autoconf is fairly primitive but surprisingly useful (as you can just define your own m4 to improve it) -- I've still not found anything that can truly unit test C though (if we plan down that road). Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Tue, 2004-11-09 at 14:24 +, Gary V. Vaughan wrote: > > 5. Think about speed, compile mode needs to be as fast as possible, can > > it be faster than it is? > > 6. Absorb the functionality of the aberration called pkg-config. Libtool > already has all the information it needs, we just need to teach it (or > maybe a subsidiary script) to spit out link flags after poking around > in a dependency chain of .la files. > I'm "maintaining" that now :) so we can definitely do that Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: error with inter-library-dependencies
On Wed, 2004-11-03 at 15:08 +0100, Christoph Wellner wrote: > I have a problem with libtool-1.5.6, when I want to start my compiled app, > I get an error-message, that some libraries are not found: > > /home/chwellner/nmm2_sarge/apps/clic/.libs/lt-clic: error while loading > shared libraries: libnmmutils.so.0: cannot open shared object file: No > such file or directory > How are you starting the application? Libtool provides a "lt-clic" wrapper shell-script which you should run, this correctly sets up the paths to find the libraries. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: Why doesn't ...
On Wed, 2004-06-16 at 21:23 +0200, Alexandre Duret-Lutz wrote: > >>> "Gary" == Gary V Vaughan <[EMAIL PROTECTED]> writes: > > [...] > > Gary> FYI: I've made CVS libtoolize take its files from $aclocaldir again. > > Great! Thanks for doing this. > > Does it also handle the case where AC_CONFIG_MACRO_DIR isn't > used? libtoolize used to install all the m4 files in the > top-level directory, although nothing will read them here. > I guess the correct thing to do in this case would be not install them at all, and let aclocal do that? Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: Linking against indirect dependencies
On Wed, 2004-05-26 at 08:07 +0200, Szombathelyi GyÃrgy wrote: > > Yes, I read the thread. I agree that libtool should perform the > > optimization you want but I don't see it as something that is a > > show-stopper. > > > I agree that it isn't a show-stopper, but it would be very nice if > libtool could handle this. Can someone add this 'feature' to the libtool > TODO list? > Patch was written and rejected; The Debian libtool packages include it. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Multiple -rpaths
On Sat, 2004-05-15 at 02:27 -0400, Braden McDaniel wrote: > I'm getting this warning (using libtool 1.5.6): > > libtool: link: warning: ignoring multiple `-rpath's for a libtool library > > I'm trying to build a module and I'm only explicitly adding one rpath in > LDFLAGS. The first one on the command line appears to be added by > libtool--it points to the module's installation directory. So the rpath > I'm adding is the one that gets ignored. Is there some way around this? > You're using the wrong option. -rpath is a Libtool command line option to tell it where you intend to install the Library (the RPATH other things might need to link to it). If you want to *encode* an RPATH into the library use -R/path/to/encode, you can use that as many times as you like. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: about libtool's trace interface for tags (gah, went to wrong list)
On Sat, 2004-04-17 at 22:48, Alexandre Duret-Lutz wrote: > >>> "Scott" == Scott James Remnant <[EMAIL PROTECTED]> writes: > > Scott> On Wed, 2004-04-14 at 18:45, Alexandre Duret-Lutz wrote: > >> Ah, thanks! Sorry for being dense, but since it takes > >> tag names as argument, why is it called _LT_LANG? > >> > Scott> Because it actually takes language configuration names, which just > Scott> happen to be the same as the tags that get generated. (There's a patch > Scott> floating around by me that breaks that assumption.) > > What is the difference between >a tag name >a language configuration name >a language name >an internal name > ? > Ok... here's how I see it: A tag name is the name of a configuration block placed inside the generated libtool script. They can be automatically inferred by the compiler name, or selected with the --tag=TAG option. A language name is the name of a language that Libtool supports, which are deliberately the same as Autoconf language names. They're human-parseable and the current list is "C", "C++", "Java", "Fortran 77" and "Windows Resource". A language configuration name is an internal name for the human language names ... they're basically the $1 in _LT_LANG_$1_CONFIG which are the macros that actually configure them. In current HEAD, they always match the tag name, A user can place LT_LANG(language name) in their configure.ac to enable a language, this calls _LT_LANG(language configuration name) to actually enable it. A user can place AC_PROG_CXX in their configure.ac and Libtool will automatically enable that language by calling LT_LANG (for some on-crack reason, it uses internal names but that's irrelevant :p). > So far I had been assuming that there was only to sort of names: > language names (passed as argument to LT_LANG), and tag names > (passed as arguments to --tag=). > > What exactly is the assumption that you'll break? The arguments > passed to _LT_LANG will not always be tag names? If so I'm > afraid Automake cannot use this macro. (See below.) > I'm not entirely sure it'll ever break, when I wrote the LT_LANG support it was actually quite a bit wilder than the patch I committed. There's an RFC patch (keybuk-lt-tag.patch) that adds the wildness. It basically allows users to define their own tags: # Default F77 support LT_LANG(Fortran 77) # Create a C++ language tag called BINCXX LT_LANG(C++, BINCXX) The idea would be you can go: CXX="/some/other/cxx" LT_LANG(C++, OTHERCXX) To enable support for multiple C++ compilers and the like. With this patch, _LT_LANG gets called with two arguments; the first is the language configuration name, the second the resulting tag name. But this isn't the current state of HEAD. > Scott> LT_LANG is the public-facing version of this macro, > Scott> which takes "friendly" names like 'C++' and 'Fortran > Scott> 77'. It then calls _LT_LANG with the internal name, > Scott> which is the most convenient trace point for you. > > I don't want Automake to rely on anything internal to Libtool. > This is not a safe road. If Libtool use some *internal* names, > Automake should not rely on them. > Fair enough... > I couldn't find the documentation for libtool's --tag=TAG > option, by I'm assuming it's a public option. It's list of > allowed argument is therefore something public too. I will call > these arguments "tags". > Yup, that's correct ... it's what ends up in available_tags in libtool and comes from the content of the _LT_TAGS macro. > In order to generate Makefiles, Automake needs to know what > language libtool has been configured for, and the corresponding > tags to pass to the --tag option. > > So far I have been assuming that there would be a macro to trace > that would return a list of enabled tags. > The trouble is that tracing doesn't work like that, when you trace you don't get a definition or a "return value", you see the arguments passed to the macro. AC_DEFUN([TRACE_ME_PLENTY], []) TRACE_ME_PLENTY(foo, bar) configure.ac:999:TRACE_ME_PLENTY:foo:bar This makes _LT_LANG a nice thing to trace, because it's part of the internal macro set to enable language support and happens to take arguments useful to you. _LT_CONFIG would be equally traceable for the same reason, it's just a bit further down the stack. (_LT_LANG calls _LT_LANG_*_CONFIG to configure a language will calls _LT_CONFIG to add a tag to the resulting file). This is why tracing _LT_TAG which is used during _LT_CONFIG to
Re: about libtool's trace interface for tags
On Wed, 2004-04-14 at 18:45, Alexandre Duret-Lutz wrote: > Ah, thanks! Sorry for being dense, but since it takes > tag names as argument, why is it called _LT_LANG? > Because it actually takes language configuration names, which just happen to be the same as the tags that get generated. (There's a patch floating around by me that breaks that assumption.) > How about calling it `LT_SUPPORTED_TAG' or something similar? I > can supply a patch to rename and document this macro in the > manual, if that sounds OK. I really think that this interface > should be public, like every other traced macros (at least all > those registered in autom4te.cfg). > Because it isn't public ... LT_LANG is the public-facing version of this macro, which takes "friendly" names like 'C++' and 'Fortran 77'. It then calls _LT_LANG with the internal name, which is the most convenient trace point for you. The trouble with making public macros is people will tend to put them in their configure.ac, no matter how large the instruction telling them not to. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: about libtool's trace interface for tags
On Wed, 2004-04-14 at 08:00, Alexandre Duret-Lutz wrote: > >>> "Scott" == Scott James Remnant <[EMAIL PROTECTED]> writes: > > Scott> On Tue, 2004-04-13 at 22:39, Alexandre Duret-Lutz wrote: > >> Is it done or is there any obstacle to it? I'm dreaming about > >> Automake 1.9, and if possible I would like to include support > >> for this. > >> > > Scott> The current interface should be pretty good, trace for > Scott> invocations of _LT_TAG and the first argument will be a > Scott> tag name that maps equally to a language name (CC, CXX, > Scott> F77, etc.) > > Huh? > Sorry, I'll put my brain on this time ... :o) * _LT_LANG * descent libtool-bootstrap% autoconf --trace=_LT_LANG configure.ac:178:_LT_LANG:CXX configure.ac:178:_LT_LANG:GCJ configure.ac:178:_LT_LANG:F77 configure.ac:178:_LT_LANG:RC Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: about libtool's trace interface for tags
On Tue, 2004-04-13 at 22:39, Alexandre Duret-Lutz wrote: > Is it done or is there any obstacle to it? I'm dreaming about > Automake 1.9, and if possible I would like to include support > for this. > The current interface should be pretty good, trace for invocations of _LT_TAG and the first argument will be a tag name that maps equally to a language name (CC, CXX, F77, etc.) I tried to make sure it was easy and everything that invented a tag went through the same mechanism. Even if things change, I'll make sure that _LT_TAG remains the trace point. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [PATCH] x86-64 and multilib
On Mon, 2004-04-05 at 14:12, Jens Petersen wrote: > Albert, Thank you for looking at the patch, and sorry for taking > too long to follow up to your comments. (please see below) > > AC> You reset sys_lib_dlsearch_path_spec. > > AC> So, do you want to add to sys_lib_dlsearch_path_spec? > > AC> Also, do you want to set sys_lib_search_path_spec, > AC> sys_lib_dlsearch_path_spec for non x86_64 systems? > AC> The patch does this which, as far as I can see, is > AC> not current behavior. > > Good points. (Fwiw I didn't make the patch...:) > > Is the revised patch below any better? > This patch is still RedHat/Fedora specific with no check to make sure it is only running on that system. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: no serial number?
On Wed, 2004-03-10 at 16:48, Gary V. Vaughan wrote: > Patrick Welche wrote: > | libtool.m4 contains: > | > | # serial 49 AC_PROG_LIBTOOL > | AC_DEFUN_ONCE([LT_INIT], > | AU_DEFUN([AC_PROG_LIBTOOL], [LT_INIT]) > | AU_DEFUN([AM_PROG_LIBTOOL], [LT_INIT]) > | > |>From the above, libtoolize won't include libtool.m4, because it is looking > | for AC_DEFUN([AC_PROG_LIBTOOL]) > | > | It seems one can either change libtool.m4's serial line to LT_INIT and > | change libtoolize to look for LT_INIT, or one can change libtoolize to > | look for A[CU]_DEFUN [macro_name]. > | > | Thoughts? > > Exactly right. I have a half cocked patch to fix this that needs testing > before I commit... > Did this patch get lost in the battle of BT vs. THE PLIERS? :-) Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool: link: warning: '[.la file]' seems to be moved
On Fri, 2004-02-13 at 20:07, Albert Chin wrote: > ltmain.in prints out a warning when it thinks the .la file isn't in > $libdir: > if test "$absdir" != "$libdir"; then > $echo "$modename: warning: \`$deplib' seems to be moved" 1>&2 > fi > > However, if $absdir has "..", and it resolves to $libdir taking ".." > into consideration, the warning is still printed. How do we solve > this? (cd $absdir; /bin/pwd) won't work because of automounter > madness. > > Or should we just remove the message? > It's just a warning that something might be amiss, it doesn't cause the world to end at that point and would likely alert someone that there really is a problem. We should keep it. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: more on serial
On Sun, 2004-03-07 at 22:23, Patrick Welche wrote: > LT_INIT is defined using AC_DEFUN_ONCE. There is no documentation for > this macro in autoconf.texi, and aclocal doesn't know about it, or at > least, it doesn't pick up the fact that as LT_INIT appears in configure.ac, > it should include m4/libtool.m4. (s/AC_DEFUN_ONCE/AC_DEFUN/ changes this) > Yeah, it's certainly not a documented Autoconf macro and aclocal doesn't pick it up. This is causing our test suite to fail at the moment, because the call to LT_INIT gets placed raw in the output configure script. Gary, why AC_DEFUN_ONCE ? > The other thing is libtool.m4 has: > > AC_REQUIRE([LTOPTIONS_VERSION])dnl > > but I don't see that defined anywhere... > It's in m4/ltoptions.m4: # This is to help aclocal find these macros, as it can't see m4_define. AC_DEFUN([LTOPTIONS_VERSION], [m4_if([1])]) Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Crosscompiling again...
On Thu, 2004-03-04 at 12:17, Tietz Fabian (AA/ESW1) wrote: > Im trying to crosscompile a c++ shared Library for a Mips target > System using libtool. > Unfortunately linking fails, because of libtool trying > to link against "/usr/lib/libstdc++.so", which is the X86 Version > of the Library, not the Mips one. > > Is there a way to tell libtool not to use the system's standard > library paths? Adding -L doesn't work. Setting the > environment variables "LIBRARY_PATH/LD_LIBRARY_PATH" also has no > effect. > Wow, now I've fixed this bug I keep finding references to it. Patch went into HEAD this evening. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool & crosscompile problem
On Thu, 2004-02-12 at 17:08, Pieter Grimmerink wrote: > I have a strange situation with libtool (version 1.4.3), I'm wondering what I > could do to make it work. > This is yet another result of the bug that Libtool would ignore the -L option for non-libtool libraries, and instead pick a library of the same name up from a system search directory. It will be fixed in 1.6 (and maybe a 1.5.4 release). Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Linking order
On Wed, 2004-01-28 at 18:05, Matthew Zeits wrote: > I am working on a project that should compile both globally--with prefix > unset so install goes to /usr/local/ and with prefix set to an arbitrary > directory. When the program links, even if I define an -L or an rpath, > it looks to /usr/local/lib for libraries even though I have prefix set > to something else and libraries that I am making going there. > Could you give us simple example commands that exhibit this bug, I have a feeling I've just fixed this one :-) Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Linking with relocated libraries
On Thu, 2004-02-05 at 19:18, [EMAIL PROTECTED] wrote: Sorry about the late reply, but here goes... > I have a situation where I'm constructing a filesystem image, and I need > to use the contents of that image to build new packages to be installed > in the image. For example, I have $ROOT, which might be something like > /usr/local/images or whatever. *snip* > When I'm building packages to be placed into that image, I need to link > with libraries in $ROOT/usr/lib (for example), but at runtime those > libraries will be at /usr/lib. *snip* > Note how the path to glib can been changed from -lglib, to > "/usr/lib/libglib.so", ignoring my -L setting. And of course, this is > the wrong one so it fails. > This is exactly the same problem reported by Markus Diesmann, fixed by the patch I've just mailed to -patches. In summary: it was ignoring the -L when finalising the library paths. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Another stable release?
On Sun, 2004-03-14 at 17:47, Albert Chin wrote: > On Sun, Mar 14, 2004 at 03:00:27PM +0000, Scott James Remnant wrote: > > On Sun, 2004-03-14 at 14:51, Peter O'Gorman wrote: > > > > > I'll probably have some free time toward the end of this month, and am > > > volunteering to roll a release of branch-1-5 if nobody has any objections. > > > > > > Would that be 1.5.4 or 1.5.3? > > > > > 1.5.4 :-) > > I'd like to see the following patches in the next 1.5 release: > http://mail.gnu.org/archive/html/libtool-patches/2004-02/msg00069.html > This one's tied up in a fix to the "preferring .la libraries over earlier non-.la libraries" patch. I'm back on top of things now, so expect the combined patch RSN (I'm trying to get LT_LANG/LT_TAG out of the door atm.) > http://mail.gnu.org/archive/html/libtool-patches/2004-02/msg00092.html > This needs a version written for HEAD as well, we shouldn't patch branch-1-5 until HEAD is patched. > http://mail.gnu.org/archive/html/libtool-patches/2004-02/msg00131.html > http://mail.gnu.org/archive/html/libtool-patches/2004-03/msg00018.html > These two need checking and applying to HEAD first (are the patches against HEAD?) Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Another stable release?
On Sun, 2004-03-14 at 14:51, Peter O'Gorman wrote: > I'll probably have some free time toward the end of this month, and am > volunteering to roll a release of branch-1-5 if nobody has any objections. > > Would that be 1.5.4 or 1.5.3? > 1.5.4 :-) Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: relink_command quoting bug
On Tue, 2004-02-17 at 13:27, Peter O'Gorman wrote: > Michael Pruett wrote: > | The change you suggested fixed the first problem but not the second. > > We probably need to go through ltmain.in and modify every line containing > pwd we find, then modify every line that uses the vars that were assigned to > the value of pwd. Even then it may not work, spaces in the path to your > source are likely to cause breakage, I assume you did this on purpose? > We already did that some time ago, if you search -patches passim. you'll find I did that and found an even bigger problem... When directory names contain spaces the following kinda breaks... deplibs="-L/path/to/directory with/spaces in/its filename -lfoo -lbar" for deplib in $deplibs... ie most of Libtool breaks. I figured at that point we aught to just flat out not support spaces in directory names and simply error if we see them. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Why doesn't ...
On Thu, 2004-02-05 at 03:40, name wrote: > Why doesn't installation copy libtool.m4 to aclocal? > Assuming you are talking about CVS HEAD (libtool 1.5a, future 1.6 release) this is because libtoolize now copies libtool.m4 from its own data directory into your macro directory. "Your macro directory" is a directory in your source to hold macro files that would've gone into aclocal.m4. Call it something like 'm4' and specify it with 'AC_CONFIG_MACRO_DIR([m4])' in your configure.ac and add 'ACLOCAL_AMFLAGS = -I m4' in your top-level Makefile.am. (If you don't do this, your top-level source directory will simply be used instead.) This is consistent with "The Future of `aclocal'" as outlined in the Automake manual chapter of the same title. The great advantage of this is that it ensures that libtool.m4 and ltmain.sh are matched versions, running libtoolize and forgetting to run aclocal, or the reverse, used to be the source of many developer's woes in the past. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 1.5.2 released
On Thu, 2004-01-29 at 12:00, Peter O'Gorman wrote: > Scott James Remnant wrote: > > | That's actually an Autoconf macro that's failing, unfortunately. It's > | an irritant, but I've not figured out a way of getting around it short > | of overriding AC_MSG_ERROR. > > Well, we already know the results of AC_PROG_CPP, so we could just set > CXXCPP to whatever CPP is after calling AC_PROG_CC in our configure.ac and > all should be well. We do not actually care about the results anyway, so it > shouldn't matter. > You're not supposed to be able to use the same cpp for both aiui. Might work though, ya never know *shrug*. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 1.5.2 released
On Thu, 2004-01-29 at 01:35, Daniel Reed wrote: > On 2004-01-28T15:59-0000, Scott James Remnant wrote: > ) On Wed, 2004-01-28 at 15:15, Daniel Reed wrote: > ) > Since there does not appear to be any C++ code (.cc, .cxx, .C) in libtool, > ) > would it be possible for the next release of libtool to not: > ) There isn't any C code either ... it checks for various compilers so it > ) can provide support for them (ie. you can go "libtool g++"). > > The problem I was reporting is not so much the testing for C++ as it was the > failing of ./configure if a C++ preprocessor was not available. There is C > code in the various examples directories, so failing for lack of a C > compiler might at least be reasonable. > That's actually an Autoconf macro that's failing, unfortunately. It's an irritant, but I've not figured out a way of getting around it short of overriding AC_MSG_ERROR. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool macros installed in pkgdatadir?
On Wed, 2004-01-28 at 22:26, Albert Chin wrote: > On Wed, Jan 28, 2004 at 10:13:21PM +0000, Scott James Remnant wrote: > > One day a version of Autoconf will use these, but for now when you run > > aclocal it'll add an "m4_include" line to aclocal.m4 for each of these > > files (rather than including them verbatim). > > Ugh. So *every* package providing useful 3rd-party autoconf macros > must be copied locally to the package using them? > This is exactly what happens now, aclocal does exactly this. Every third party macro set gets copied locally into the package using it, just into one great big unmanangeable file called aclocal.m4. By giving this kind of thing to individual packages to maintain and worry about, for example through autopoint and libtoolize (which both do this now) -- better tracking is provided, you know that the m4 macros you're relying on *haven't changed*. Which will of course mean that every time random package changes its macros, it *WON'T* break your configure script :-) Having a directory of individual files rather than lumping them together in aclocal.m4 is more manageable. It's not really that big a change result-wise, it's just a much cleaner way of doing things. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool macros installed in pkgdatadir?
On Wed, 2004-01-28 at 20:29, Braden McDaniel wrote: > Why are the libtool macros being installed to $(pkgdatadir) rather than > $(datadir)/aclocal? > Because aclocal is slowly being deprecated, and will eventually vanish entirely. Managing Autoconf macros really isn't a job for Automake. The new utopia is to create a directory within your source called "m4" (or some such) and in configure.ac declare AC_CONFIG_MACRO_DIR([m4]) Then when you run libtoolize, it will copy the appropriate m4 files into this directory for you. One day a version of Autoconf will use these, but for now when you run aclocal it'll add an "m4_include" line to aclocal.m4 for each of these files (rather than including them verbatim). Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 1.5.2 released
On Wed, 2004-01-28 at 15:15, Daniel Reed wrote: > On 2004-01-25T14:47-0000, Scott James Remnant wrote: > ) The Libtool Team is pleased to announce the release of GNU Libtool > ) 1.5.2. > > Since there does not appear to be any C++ code (.cc, .cxx, .C) in libtool, > would it be possible for the next release of libtool to not: > There isn't any C code either ... it checks for various compilers so it can provide support for them (ie. you can go "libtool g++"). The next "major" release (1.6) allows you to specify which tags you want to include, that's available from CVS HEAD right now if you want to play. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool 1.5.2 on SGI/IRIX
On Wed, 2004-01-28 at 14:18, Florian Bachmann wrote:
> I am trying to produce a 64bit shared library on a IRIX 6.5 (MIPS4)
> machine using the GNU toolchain (gcc, autoconf, automake, libtool).
> I am configuring gcc to produce 64bit binaries with CC="gcc -mabi=64".
> Libtool correctly picks up the SGI system linker ("/usr/bin/ld"), but
> for some reason it will always add the "-n32" option, which instructs
> ld to link 32bit binaries. What is the correct way of telling libtool
> to run ld with the "-64" option instead?
>
What happens if you specify "-mabi=64" in CFLAGS instead of changing
CC? Does that work?
Scott
--
Have you ever, ever felt like this?
Had strange things happen? Are you going round the twist?
signature.asc
Description: This is a digitally signed message part
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 1.5.2 released
On Mon, 2004-01-26 at 23:30, Kevin Ryde wrote: > Scott James Remnant <[EMAIL PROTECTED]> writes: > > > > ftp://ftp.gnu.org/gnu/libtool/libtool-1.5-1.5.2.diff.gz > > This doesn't seem to have the changes to the generated files, > therefore requiring a re-autoconf etc. I think a diff is normally > meant to be between the .tar files of the respective versions. > Well spotted, this will be addressed for the next release with a patch I'm preparing at the moment. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
GNU Libtool 1.5.2 released
The Libtool Team is pleased to announce the release of GNU Libtool 1.5.2. GNU Libtool hides the complexity of using shared libraries behind a consistent, portable interface. GNU Libtool ships with GNU libltdl, which hides the comlexity of loading dynamic runtime libraries (modules) behind a consistent, portable interface. This release fixes bugs and annoyances present in the 1.5 release. New in 1.5.2: 2004-01-25 * lt_dlrealloc is an official part of the libltdl API. * --tag, --silent and --debug options are preserved and reused when libtool calls itself for relinking etc. * `-pthread' and similar options are honoured when linking shared libraries. * -no-suppress in compile mode shows compiler output for both PIC and non-PIC object compilation. * New link mode option `-precious-files-regex' to prevent accidental removal of files you want to keep, such as test coverage data, from the temporary output directory. * Directories specified in /etc/ld.so.conf are no longer hardcoded on Linux. * Recognises the 'R' symbol type on Solaris so read-only symbols can be exported. * Bug fixes. libtool-1.5.2 is available now from ftp.gnu.org, along with diffs and xdeltas against libtool-1.5 that are also available from ftp.gnu.org. Please use a mirror to reduce stress on the main gnu machine: http://www.gnu.org/order/ftp.html Here are the compressed sources: ftp://ftp.gnu.org/gnu/libtool/libtool-1.5.2.tar.gz Here are the xdeltas and diffs against libtool-1.5: ftp://ftp.gnu.org/gnu/libtool/libtool-1.5-1.5.2.diff.gz ftp://ftp.gnu.org/gnu/libtool/libtool-1.5-1.5.2.xdelta Here are the gpg detached signatures: ftp://ftp.gnu.org/gnu/libtool/libtool-1.5.2.tar.gz.sig ftp://ftp.gnu.org/gnu/libtool/libtool-1.5-1.5.2.diff.gz.sig ftp://ftp.gnu.org/gnu/libtool/libtool-1.5-1.5.2.xdelta.sig Here are the MD5 and SHA1 checksums: db66ba05502f533ad0cfd84dc0e03bd5 libtool-1.5.2.tar.gz cb66ad829b082cc5fdd9a99b2315e390 libtool-1.5-1.5.2.diff.gz 1df023f4893bb8cc77acf843250b5d38 libtool-1.5-1.5.2.xdelta d6f1e8fb544d71b3c88fb959521b34b9b6290260 libtool-1.5.2.tar.gz c6624106bf83517c923500ca215744901fec2070 libtool-1.5-1.5.2.diff.gz 63918920176c20e999abc06860d82fee58cabda8 libtool-1.5-1.5.2.xdelta This release was bootstrapped with Autoconf 2.59 and Automake 1.8.2, but is useable with Autoconf 2.50 & later and Automake 1.4 & later in your own projects. Alternatively, you can fetch the unbootstrapped sourcecode from anonymous cvs by using the following commands (just hit return when you are prompted for the password): $ cvs -z3 -d :pserver:[EMAIL PROTECTED]:/cvsroot/libtool login Password: $ cvs -z3 -d :pserver:[EMAIL PROTECTED]:/cvsroot/libtool \ co -r release-1-5-2 libtool You will then need to have the latest release versions of Automake and Autoconf installed to bootstrap the checked out sources yourself. Please report bugs to <[EMAIL PROTECTED]>. signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool-commit ML
On Thu, 2004-01-22 at 13:55, Peter O'Gorman wrote: > Nick Hudson wrote: > > | Is the libtool-commit ML supposed to work anymore? I've not seen a message > | there for sometime now. > > It is broken. > But we do co-ordinate all patches, even trivial ones, on [EMAIL PROTECTED] -- so you can see what we're *going* to commit before we do it. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Bug in CVS bootstrap with Automake 1.7
On Fri, 2004-01-16 at 16:49, Bob Friesenhahn wrote: > On Fri, 16 Jan 2004, Scott James Remnant wrote: > > > > I'm going to see whether we can hack around this, but to be honest, I > > don't see any problem with requiring 1.8 for our bootstrap now -- it > > significantly reduces the size of our tar.gz > > I don't see any problem with this requirement either. Perhaps some > Linux distribution maintainers would disagree. Linux distributions > should be encouraged to use and provide the latest auto* tools. > Theoretically they shouldn't need to worry about our CVS bootstrap, as they'd be packaging our released tarballs anyway. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Bug in CVS bootstrap with Automake 1.7
It seems that Automake 1.7 isn't automatically including m4/* in the distribution tarball, I'm not even sure why -- there's code in /usr/bin/automake-1.7 to do just that. I'm going to see whether we can hack around this, but to be honest, I don't see any problem with requiring 1.8 for our bootstrap now -- it significantly reduces the size of our tar.gz Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Bootstrapping Redux.
On Wed, 2004-01-14 at 12:43, Gary V. Vaughan wrote: > What about adding m4/obsolete.m4 with: > > AU_DEFUN([AC_LIBTOOL_CONFIG], [AC_LIBTOOL_CONFIG])dnl > AU_DEFUN([AC_LIBTOOL_LINKER_OPTION], [AC_LIBTOOL_LINKER_OPTION])dnl > ... > AU_DEFUN([AC_PROG_EGREP], [AC_PROG_EGREP])dnl > Try it :-) You might want a -20 root shell to kill m4 with once you get a bit bored :p I've come up with a quite nice solution though, coming to a -patches list near you. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Bootstrapping Redux.
Bootstrapping the new stuff with Automake 1.8 and an older
/usr/share/aclocal/libtool.m4 still causes the contents of that to be
dumped into aclocal.m4 as well as the new m4_include line.
This is (still) because at least some of the following m4_defines used
to be AC_DEFUNs:
AC_LIBTOOL_CONFIG
AC_LIBTOOL_LINKER_OPTION
_LT_AC_LANG_C_CONFIG
_LT_AC_LANG_GCJ_CONFIG
_LT_AC_LANG_RC_CONFIG
_LT_AC_PROG_ECHO_BACKSLASH
_LT_AC_SHELL_INIT
_LT_AC_SYS_LIBPATH_AIX
_LT_AC_TAGVAR
As well as the whole AC_PROG_EGREP debacle.
However I've come up with a fairly evil, hacky but nonetheless amusing
solution ... *cackle* Add this to the bottom of bootstrap:
8<8<8<8<8<8<8<8<
for dir in $reconfdirs; do
if grep '^m4_include.*libtool\.m4' $dir/aclocal.m4 >/dev/null && \
grep '^# serial .* AC_PROG_LIBTOOL' $dir/aclocal.m4 >/dev/null
then
echo "Fixing aclocal.m4 in $dir"
sed -e '/^# libtool.m4/,/^AC_MSG_RESULT(\[$$SED])/{N;d}' \
< $dir/aclocal.m4 > $dir/aclocal.m4_
mv $dir/aclocal.m4_ $dir/aclocal.m4
(cd $dir && autoconf)
fi
done
>8>8>8>8>8>8>8>8
Scott
--
Have you ever, ever felt like this?
Had strange things happen? Are you going round the twist?
signature.asc
Description: This is a digitally signed message part
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: bootstrapping CVS libtool
On Wed, 2003-11-26 at 15:49, Gary V. Vaughan wrote: > Scott James Remnant wrote: > |On Wed, 2003-11-26 at 11:41, Gary V. Vaughan wrote: > |> 1: remove $prefix/share/aclocal/l(ibtoo|td)l.m4 of old releases at install > |> time > |> 2: keep copies of the latest versions only in $prefix/share/libtool/m4 > |> 3: maybe we need a new $prefix/share/aclocal/ltcompat.m4 with stubs for > |> the macros you list above to keep aclocal happy? > |> > | > | We wouldn't need the stubs if aclocal could only see one libtool.m4. > > Agreed. And 1+2 achieves this. I'll post a patch shortly. > Did you ever get very far with this patch? (aclocal dragging in /usr/share/aclocal/libtool.m4 when m4/libtool.m4 would do) Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool audit
On Thu, 2003-12-18 at 12:08, Peter O'Gorman wrote: > Gary V. Vaughan wrote: > | Scott James Remnant wrote: > | We're done! > > Jeez, I didn't even get the chance to start looking! > > Thank you both so much, I'll buy both multiple beers should we ever meet. > If the Libtool Team were to ever meet, we should ensure that the arrangements were made under the utmost secrecy. Everyone responsible in the same room might be too tempting a target for some ;-) Happy New Year to all, btw. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool/config.status issue on IRIX
On Fri, 2004-01-02 at 00:30, Bob Friesenhahn wrote: > On Fri, 2 Jan 2004, Joe Orton wrote: > > > > _ACEOF > > > cat foo.out > > > > > > Note that the update adds an extra backslash in front of all the inner > > > double-quotes. > > > > OK, I made those changes to libtool.m4 as below, and can confirm that > > the configure script produced works correctly on IRIX 6.2 (and a > > GNU/Linux system). Thanks a lot! > > If another libtool maintainer would care to apply this important > patch, I would certainly appreciate it. My CVS commit access is not > re-enabled yet. > Consider it done. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Missing, presumed Dead! Libtool CVS logging via e-mail
The script and everything under CVSROOT that logged our commits and sent them to [EMAIL PROTECTED] has been lost. Don't suppose anyone kept a copy of this around, and could re-add it to CVSROOT (possibly fixing the broken CVSweb URLs along the way). Otherwise I guess we'd have to use the commit_prep/log_accum which come with CVS? Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: tag inference broken?
On Sun, 2003-12-07 at 23:18, Peter O'Gorman wrote:
> Scott James Remnant wrote:
>
> | On Sat, 2003-12-06 at 15:14, Peter O'Gorman wrote:
> |>Looks like it is simply infering too early in link mode.
> |>
> |
> | Yeah, my last patch moved the code to before the rest of the argument
> | parsing to make -shared, -static and -all-static work with a tagged
> | configuration.
> |
>
> Actually, I "fixed" it much more simply by changing the
> case "$base_compile "
> to
> case "$base_compile $@" in both places in link mode.
>
That'd work too, as far as I can see the loop just sticks every $arg
into $base_compile anyway.
Hell, we could probably get away with the following patch and that'd
probably result in exactly the same thing, there's nothing that breaks
out of that loop.
Scott
--
Have you ever, ever felt like this?
Had strange things happen? Are you going round the twist?
--- ltmain.in.orig 2003-12-17 23:21:55.0 +
+++ ltmain.in 2003-12-17 23:22:30.0 +
@@ -856,7 +856,7 @@
;;
esac
libtool_args="$nonopt"
-base_compile="$nonopt"
+base_compile="$nonopt $@"
compile_command="$nonopt"
finalize_command="$nonopt"
@@ -906,7 +906,7 @@
# Only attempt this if the compiler in the base link
# command doesn't match the default compiler.
if test -n "$available_tags" && test -z "$tagname"; then
- case "$base_compile " in
+ case $base_compile in
# Blanks in the command may have been stripped by the calling shell,
# but not from the CC environment variable when configure was run.
"$CC "* | " $CC "* | "`$echo $CC` "* | " `$echo $CC` "*) ;;
@@ -917,7 +917,7 @@
if grep "^# ### BEGIN LIBTOOL TAG CONFIG: $z$" < "$0" > /dev/null; then
# Evaluate the configuration.
eval "`${SED} -n -e '/^# ### BEGIN LIBTOOL TAG CONFIG: '$z'$/,/^# ### END LIBTOOL TAG CONFIG: '$z'$/p' < $0`"
- case "$base_compile " in
+ case $base_compile in
"$CC "* | " $CC "* | "`$echo $CC` "* | " `$echo $CC` "*)
# The compiler in $compile_command matches
# the one in the tagged configuration.
@@ -985,7 +985,6 @@
# Go through the arguments, transforming them on the way.
while test "$#" -gt 0; do
arg="$1"
- base_compile="$base_compile $arg"
shift
case $arg in
*[\[\~\#\^\&\*\(\)\{\}\|\;\<\>\?\'\ \ ]*|*]*|"")
signature.asc
Description: This is a digitally signed message part
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool audit
On Wed, 2003-12-17 at 17:23, Gary V. Vaughan wrote: > Argh. I am beginning to resent the amount of admin I am doing in what would > otherwise be my hacking time :-( > > It's difficult, tedious and error prone. > By using my own subversion mirror which spanned the compromise, I've been able to make this slightly easier for myself when it came to the moved files. Still bloody tedious work, and I think I've gone cross-eyed now. Where I could, I collated diffs together using the -patches mailing list as a guide and checked each patch as a whole against what got mailed. Then when it matched (they all did) I read it as a whole to double-check. Seeing things as one unit helped quite a bit. > Ignoring files which are not code, or involved in the generation of code, and > removing those files I have examined already, this is what remains: > I've removed things I've checked from the lists, we're now just left with: ./tests/cdemo-conf.test,v-1 ./tests/assign.test,v-1 ./tests/demo-noinst-link.test,v-1 ./tests/cdemo-exec.test,v-1 ./tests/cdemo-make.test,v-1 ./tests/cdemo-shared.test,v-1 ./tests/cdemo-static.test,v-1 ./tests/defs,v-1 ./tests/demo-conf.test,v-1 ./tests/demo-deplibs.test,v-1 ./tests/demo-exec.test,v-1 ./tests/demo-hardcode.test,v-1 ./tests/demo-inst.test,v-1 ./tests/demo-make.test,v-1 ./tests/demo-nofast.test,v-1 ./tests/depdemo-nofast.test,v-1 ./tests/demo-nopic.test,v-1 ./tests/demo-pic.test,v-1 ./tests/demo-relink.test,v-1 ./tests/demo-shared.test,v-1 ./tests/demo-static.test,v-1 ./tests/demo-unst.test,v-1 ./tests/depdemo-conf.test,v-1 ./tests/depdemo-exec.test,v-1 ./tests/depdemo-inst.test,v-1 ./tests/depdemo-make.test,v-1 ./tests/depdemo-relink.test,v-1 ./tests/depdemo-shared.test,v-1 ./tests/depdemo-static.test,v-1 ./tests/depdemo-unst.test,v-1 ./tests/f77demo-conf.test,v-1 ./tests/f77demo-exec.test,v-1 ./tests/f77demo-make.test,v-1 ./tests/f77demo-shared.test,v-1 ./tests/f77demo-static.test,v-1 ./tests/link-2.test,v-1 ./tests/link.test,v-1 ./tests/mdemo-conf.test,v-1 ./tests/mdemo-dryrun.test,v-1 ./tests/mdemo-exec.test,v-1 ./tests/mdemo-inst.test,v-1 ./tests/mdemo-make.test,v-1 ./tests/mdemo-shared.test,v-1 ./tests/mdemo-static.test,v-1 ./tests/mdemo-unst.test,v-1 ./tests/mdemo2-conf.test,v-1 ./tests/mdemo2-exec.test,v-1 ./tests/mdemo2-make.test,v-1 ./tests/nomode.test,v-1 ./tests/pdemo-conf.test,v-1 ./tests/pdemo-exec.test,v-1 ./tests/pdemo-inst.test,v-1 ./tests/pdemo-make.test,v-1 ./tests/quote.test,v-1 ./tests/sh.test,v-1 ./tests/suffix.test,v-1 ./tests/tagdemo-conf.test,v-1 ./tests/tagdemo-exec.test,v-1 ./tests/tagdemo-make.test,v-1 ./tests/tagdemo-shared.test,v-1 ./tests/tagdemo-static.test,v-1 ./tests/Attic/build-relink.test,v-1 ./tests/Attic/build-relink2.test,v-1 ./tests/Attic/deplibs.test,v-1 ./tests/Attic/dryrun.test,v-1 ./tests/Attic/dryrun.test,v-1.9.2 ./tests/Attic/hardcode.test,v-1 ./tests/Attic/noinst-link.test,v-1 These got a fair rewrite a while back, which makes things slightly more complicated. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: tag inference broken?
On Sat, 2003-12-06 at 15:14, Peter O'Gorman wrote:
> Albert Chin wrote:
> | On Sat, Dec 06, 2003 at 10:57:52PM +0900, Peter O'Gorman wrote:
> |
> |>Okay, I must be stupid, the tag inference goes like this:
> |>case $base_compile in
> |>
> | Before the case, what is the output of:
> | echo .$CC.
>
> And things begin to make a little more sense, with echo .$CC. and echo
> .$base_compile. before the case statement in both compile and link
> modes, I get the following output # comments added:
>
> .gcc -arch ppc -arch i386. # This is .$CC.
> .gcc. # And .$base_compile.
> libtool: link: unable to infer tagged configuration
> libtool: link: specify a tag with `--tag'
> make[1]: *** [libltdl.la] Error 1
> make: *** [all] Error 2
>
> Looks like it is simply infering too early in link mode.
>
Yeah, my last patch moved the code to before the rest of the argument
parsing to make -shared, -static and -all-static work with a tagged
configuration.
Here's a patch you might want to try; it moves the tagged config
inference to beneath the argument parsing again. I also had to move the
handling of those three arguments to beneath it as well, even though for
some reason they were separate (I couldn't find a reason for this
anymore...)
Anyway, this probably breaks everything, but try it anyway :-)
Scott
--
Have you ever, ever felt like this?
Had strange things happen? Are you going round the twist?
diff -ruNp libtool-CVS~/ChangeLog libtool-CVS/ChangeLog
--- libtool-CVS~/ChangeLog 2003-11-30 17:13:29.00000 +0000
+++ libtool-CVS/ChangeLog 2003-12-07 18:59:19.0 +
@@ -0,0 +1,7 @@
+2003-12-07 Scott James Remnant <[EMAIL PROTECTED]>
+
+ * ltmain.in: Move the code to infer the tagged configuration in
+ link mode until after the argument parsing again, so $base_compile
+ contains the complete command line. Move the code to handle -shared,
+ -static and -all-static until after this.
+
diff -ruNp libtool-CVS~/ltmain.in libtool-CVS/ltmain.in
--- libtool-CVS~/ltmain.in 2003-11-26 15:20:42.0 +
+++ libtool-CVS/ltmain.in 2003-12-07 18:54:43.0 +
@@ -900,87 +900,7 @@ EOF
thread_safe=no
vinfo=
vinfo_number=no
-
-# Infer tagged configuration to use if any are available and
-# if one wasn't chosen via the "--tag" command line option.
-# Only attempt this if the compiler in the base link
-# command doesn't match the default compiler.
-if test -n "$available_tags" && test -z "$tagname"; then
- case "$base_compile " in
- # Blanks in the command may have been stripped by the calling shell,
- # but not from the CC environment variable when configure was run.
- "$CC "* | " $CC "* | "`$echo $CC` "* | " `$echo $CC` "*) ;;
- # Blanks at the start of $base_compile will cause this to fail
- # if we don't check for them as well.
- *)
- for z in $available_tags; do
- if grep "^# ### BEGIN LIBTOOL TAG CONFIG: $z$" < "$0" > /dev/null; then
- # Evaluate the configuration.
- eval "`${SED} -n -e '/^# ### BEGIN LIBTOOL TAG CONFIG: '$z'$/,/^# ### END LIBTOOL TAG CONFIG: '$z'$/p' < $0`"
- case "$base_compile " in
- "$CC "* | " $CC "* | "`$echo $CC` "* | " `$echo $CC` "*)
- # The compiler in $compile_command matches
- # the one in the tagged configuration.
- # Assume this is the tagged configuration we want.
- tagname=$z
- break
- ;;
- esac
- fi
- done
- # If $tagname still isn't set, then no tagged configuration
- # was found and let the user know that the "--tag" command
- # line option must be used.
- if test -z "$tagname"; then
- $echo "$modename: unable to infer tagged configuration"
- $echo "$modename: specify a tag with \`--tag'" 1>&2
- exit 1
-# else
-# $echo "$modename: using $tagname tagged configuration"
- fi
- ;;
- esac
-fi
-
-# We need to know -static, to get the right output filenames.
-for arg
-do
- case $arg in
- -shared)
- if test "$build_libtool_libs" != yes; then
- $echo "$modename: can not build a shared library" 1>&2
- $echo "Fatal configuration error." 1>&2
- exit 1
- fi
- build_old_libs=no
- break
- ;;
- -all-static | -static)
- if test "X$arg" = "X-all-static"; then
- if test "$build_libtool_libs" = yes && test -z "$link_static_flag"; then
- $echo "$modename: warning: complete static linking is impossible in this configuration" 1>&2
- fi
- if test -n "$link_static_flag"; then
Re: avoiding C++, Fortran tags
On Wed, 2003-11-26 at 14:51, Thien-Thi Nguyen wrote: > i recently swiched to libtool 1.5 and now AC_PROG_LIBTOOL pulls in a > horrendous amount of irrelevant checks for C++ and Fortran. *snip* are > there plans to extend AC_PROG_LIBTOOL to specify which, if any, tags > are to be included/omitted? should i elevate this in my mind from > kludge to "acceptable methodology"? > Yes, libtool 1.6 includes an AC_LIBTOOL_TAGS macro in which you can list the additional tags you want to use. AC_LIBTOOL_TAGS([CXX]) AC_PROG_LIBTOOL Would only include the C++ compiler tag in addition to the default C compiler one. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: bootstrapping CVS libtool
On Wed, 2003-11-26 at 11:41, Gary V. Vaughan wrote: > Scott James Remnant wrote: > | This means if you use AC_FOO in m4/libtool.m4 then the first file that > | happens to AC_DEFUN that will get included, even though it's defined > | with m4_define in that same file. > > Gah! That has got to be a bug!! Otherwise libtool.m4 will be slowly crushed > under the weight of its old releases. > It stops us changing our AC_DEFUNs to m4_defines, yes. It wouldn't stop us removing old macros, because we'd remove the calls to them too one hopes. > A better algorithm would be to use an existing AC_FOO macro (howsoever it is > defined) in preference to pulling in a new file of macros and all of its > dependencies? > The problem is that aclocal doesn't know about m4_define, yes. > | So in summary, to stop this madness, we need to either change the > | definition of the above macro list from m4_define to AC_DEFUN or rename > | the macros and then restore the definition of AC_PROG_EGREP even if it's > | just a hack like this: > > I have been wanting to split libtool.m4 up into several files for a while to > help maintenance, and maybe reduce the size of aclocal.m4 for some of our > users. Now that libtoolize installs libtool.m4 and ltdl.m4 if they are used, > the trick might be to only show aclocal the local (libtoolize installed) > libtool macros. I think we should: > > ~ 1: remove $prefix/share/aclocal/l(ibtoo|td)l.m4 of old releases at install > ~ time > ~ 2: keep copies of the latest versions only in $prefix/share/libtool/m4 > ~ 3: maybe we need a new $prefix/share/aclocal/ltcompat.m4 with stubs for > ~ the macros you list above to keep aclocal happy? > We wouldn't need the stubs if aclocal could only see one libtool.m4. Yet again I wish that Autoconf would learn how to keep its own macros in order, and didn't need a tool from Automake to do it for it! The true way to fix this is to add AC_MACRO_DIR to Autoconf, and allow it to source files in that directory the same way it does its own macro library. No more stuffing everything in aclocal.m4. But I digress. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: bootstrapping CVS libtool
On Tue, 2003-11-25 at 13:27, Gary V. Vaughan wrote:
> Scott James Remnant wrote:
> | The gotcha is that for some reason aclocal pulls in both m4/libtool.m4
> | AND /usr/share/aclocal/libtool.m4 into aclocal.m4 and puts the latter
> | last, so its macros get used.
>
> This means that aclocal has found a dependency on a macro that is defined in
> /usr/share/aclocal/libtool.m4, but not $top_srcdir/m4/libtool.m4 (m4_defined
> macros can't be seen by aclocal.m4). If you have time to investigate, it
> would be nice to prevent this happening before we release.
>
Ok, I've investigated this and I think the problem is that we're
assigning too much intelligence to aclocal :-(
As far as I can tell it has two basic phases:
1) Scan every m4 file and build up a list of AC_DEFUNs (or AU_DEFUN) it
can find, and remember which file it found them in[0].
2) Scan configure.{ac,in} looking for the name of any macro it saw a
definition for, pull in the appropriate file and then scan that file
in the same way (recurse until happy).
This means if you use AC_FOO in m4/libtool.m4 then the first file that
happens to AC_DEFUN that will get included, even though it's defined
with m4_define in that same file.
In other words, anything previously defined with AC_DEFUN in older
libtool.m4 files will need to be defined with AC_DEFUN in later versions
too, including 1.6.
Here's the list of m4_define macros that need to be changed back to
AC_DEFUN simply because they used to be defined with it[1]:
AC_LIBTOOL_CONFIG
AC_LIBTOOL_LINKER_OPTION
_LT_AC_LANG_C_CONFIG
_LT_AC_LANG_GCJ_CONFIG
_LT_AC_LANG_RC_CONFIG
_LT_AC_PROG_ECHO_BACKSLASH
_LT_AC_SHELL_INIT
_LT_AC_SYS_LIBPATH_AIX
_LT_AC_TAGVAR
But that's not enough, oh no, precious. You see, aclocal doesn't know
about macros supplied by Autoconf. So if we were to define a macro in
an older libtool.m4, say AC_PROG_EGREP, and removed it because it's now
included in the version of Autoconf we AC_PREREQ on, aclocal wouldn't
know about it so would pull in the older libtool.m4 simply because it
defined it.
So in summary, to stop this madness, we need to either change the
definition of the above macro list from m4_define to AC_DEFUN or rename
the macros and then restore the definition of AC_PROG_EGREP even if it's
just a hack like this:
# AC_PROG_EGREP
# -
# This is included in Autoconf, but aclocal will pull in an
# older libtool.m4 unless we AC_DEFUN it *sigh*
m4_ifndef([AC_PROG_EGREP], [AC_DEFUN([AC_PROG_EGREP], [])])
Scott
[0] Interestingly, it doesn't consider 'dnl' to be a comment and if you
do 'dnl AC_DEFUN([FOO])' it considers that a valid definition of
'FOO'. It does ignore '## AC_DEFUN([FOO])' though, is this
m4ly-correct?
[1] Or we could cheat and rename them, which is why _LT_AC_TAG_CONFIG
(was _LT_AC_TAGCONFIG) isn't in that list.
--
Have you ever, ever felt like this?
Had strange things happen? Are you going round the twist?
signature.asc
Description: This is a digitally signed message part
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: bootstrapping CVS libtool
On Tue, 2003-11-25 at 13:24, Gary V. Vaughan wrote: You've just woken up, haven't you? :-) > Scott James Remnant wrote: > | On Mon, 2003-11-24 at 17:36, Bob Friesenhahn wrote: > | > | > |>On Mon, 24 Nov 2003, Scott James Remnant wrote: > |> > |>>I use Autoconf 2.58 and Automake 1.7 (latest Debian packages, basically) > |>>to bootstrap and it works just fine. > |> > |>The top of libtool's bootstrap script says: > |> > |># Helps bootstrapping libtool, when checked out from CVS > |># requires at least GNU autoconf 2.58 and GNU automake 1.8. > |> > |>Perhaps this comment is in error? > |> > | > | Yes, Makefile.am says: > | > | AUTOMAKE_OPTIONS = 1.7 gnu > | > | > | Though, I believe, if you use 1.8 it will take advantage of the new > | include stuff? > > Yep. That's right. We could explain that in the comment in bootstrap instead > of lying... ;-) > I'll leave you to make that ObviousFix :-) I'm going to be too busy examining aclocal *glares at it ruefully* :p Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: bootstrapping CVS libtool
On Mon, 2003-11-24 at 17:36, Bob Friesenhahn wrote: > On Mon, 24 Nov 2003, Scott James Remnant wrote: > > > > > I use Autoconf 2.58 and Automake 1.7 (latest Debian packages, basically) > > to bootstrap and it works just fine. > > The top of libtool's bootstrap script says: > > # Helps bootstrapping libtool, when checked out from CVS > # requires at least GNU autoconf 2.58 and GNU automake 1.8. > > Perhaps this comment is in error? > Yes, Makefile.am says: AUTOMAKE_OPTIONS = 1.7 gnu Though, I believe, if you use 1.8 it will take advantage of the new include stuff? Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: bootstrapping CVS libtool
On Sat, 2003-11-22 at 16:41, Bob Friesenhahn wrote: > I am trying to get the current CVS libtool properly bootstrapped. The > libtool bootstrap script says that GNU autoconf 2.58 and GNU automake > 1.8 are required. There is no such thing as automake 1.8 yet. I > retrieved a package called automake-1.7d from alpha.gnu.org but it is > not clear what it really is (the NEWS file is extended over the one > from 1.7.9). > > Using Autoconf 2.58 with this automake did not succeed to bootstrap > libtool. > I use Autoconf 2.58 and Automake 1.7 (latest Debian packages, basically) to bootstrap and it works just fine. The gotcha is that for some reason aclocal pulls in both m4/libtool.m4 AND /usr/share/aclocal/libtool.m4 into aclocal.m4 and puts the latter last, so its macros get used. > Running configure still does not result in a libtool script so I get > this error: > > /home/bfriesen/src/gnu/libtool' > CONFIG_FILES= CONFIG_HEADERS= CONFIG_COMMANDS=libtool > /usr/local/bin/bash ./config.status > config.status: executing libtool commands > chmod +x libtool > chmod: libtool: No such file or directory > gmake[1]: *** [libtool] Error 1 > gmake[1]: Leaving directory `/home/bfriesen/src/gnu/libtool' > gmake: *** [all-recursive] Error 1 > I think this is because it's using the old libtool.m4, have you tried removing that from your aclocal directory and seeing if it works from clean then? Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool 1.5 tag woes
On Wed, 2003-11-12 at 20:49, Albert Chin wrote: > On Wed, Nov 12, 2003 at 06:59:44PM +0100, Paolo Bonzini wrote: > > I have just upgraded to libtool 1.5 (Debian's package which is taken > > out of CVS) and here are my first experiences. > > HEAD or branch-1-5? I think development is happening on HEAD towards a > 1.6 release. > The Debian libtool package is branch-1-5 with the patches I've recently submitted to HEAD. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool pre-1.5b tests fail on 9 debian arches
On Tue, 2003-10-07 at 16:36, Gary V. Vaughan wrote: > Robert Millan wrote: > > On Sat, Sep 27, 2003 at 08:04:55PM +0100, Scott James Remnant wrote: > >>Robert Millan wrote: > >>>We should start doing that, and I can help. Just requested copyright papers > >>>myself (I assume you've already done that). > >>> > >>>libtool maintainers: Would you consider giving either Scott or me (preferably > >>>both) with CVS access? That'd help a lot getting libtool in shape for all > >>>architectures without having to maintain such a "debian fork" of libtool. > > Absolutely. The FSF will inform me when the paperwork is done, and I have > recently updated http://www.gnu.org/software/libtool/contribute.html to make > it as easy as possible for us to accept new maintainers. > This should have happened now, I received my copies of el paperworko back the other day. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Fwd: Bug#207475: libtool: wrongly hides important compiler output]
On Tue, 2003-10-07 at 16:14, Gary V. Vaughan wrote: > Scott James Remnant wrote: > > I can see Sam's point, but I can also see the reason for suppressing one > > of two near-identical compilations. > > How about a -no-suppress option? (see attachment) > Certainly seems like a good compromise, I imagine using #ifdef __PIC__ is rare enough that they'll be aware to stick an extra option in their flags. Sam, would this solve your problem? Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool pre-1.5b tests fail on 9 debian arches
On Tue, 2003-10-07 at 18:48, Robert Millan wrote: > On Tue, Oct 07, 2003 at 04:36:47PM +0100, Gary V. Vaughan wrote: > > >>>libtool maintainers: Would you consider giving either Scott or me > > >>>(preferably > > >>>both) with CVS access? That'd help a lot getting libtool in shape for all > > >>>architectures without having to maintain such a "debian fork" of libtool. > > > > Absolutely. The FSF will inform me when the paperwork is done, > > Ok. I'll take care about the paperwork. Scott, will you go through this too? > Already done, signed and sent back to the FSF yesterday -- will take a few days to fly across the pond though I imagine. > > You must also agree not to commit anything for which you do not have > > knowledge of the author, and the author has exchanged paperwork with the > > FSF, except for very small patches. > > No problem. > Indeed, also no problem. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
[Fwd: Bug#207475: libtool: wrongly hides important compiler output]
Forwarded for discussion purposes ... I can see Sam's point, but I can also see the reason for suppressing one of two near-identical compilations. Scott -Forwarded Message- From: Sam Hocevar <[EMAIL PROTECTED]> To: Debian Bug Tracking System <[EMAIL PROTECTED]> Subject: Bug#207475: libtool: wrongly hides important compiler output Date: Wed, 27 Aug 2003 12:40:32 +0200 Package: libtool Version: 1.5-1 (not installed) Severity: normal My generated libtool scripts contain the following lines (coming from /usr/share/libtool/ltmain.sh, line 725): # Allow error messages only from the first compilation. suppress_output=' >/dev/null 2>&1' Which means that if the -fPIC compilation succeeded, it sends the output of the non-PIC compilation to /dev/null, wrongly assuming that if a file builds in PIC mode it will build in non-PIC mode (which is obviously wrong since one can put broken code between #ifndef PIC). It is then highly irritating to get a build error from the buildd that simply says "Error 1". I suggest that this suppress_output line either be simply removed, because it is simply wrong to hide meaningful output from the user, or at least be made configurable. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux c18 2.4.21-rc5 #2 Wed May 28 22:10:14 CEST 2003 i686 Locale: LANG=C, LC_CTYPE=fr_FR -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Version numbering
On Tue, 2003-09-30 at 17:58, Gary V. Vaughan wrote: > After the next cron web update, please read: > > http://www.gnu.org/software/libtool/contribute.html > > and give me your feedback... > Makes sense to me, seems to cover everything well enough to avoid any confusion about what kind of release things are or not. Also happens that dpkg agrees with your order (whereas it thinks 1.7 is older than 1.7a). I'm assuming that x. means it's an alpha and x. means a stable release? Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Version numbering
On Tue, 2003-09-30 at 10:15, Gary V. Vaughan wrote: > Alexandre Duret-Lutz wrote: > > I didn't understand your proposal, but I hope you are not > > planning to make 2.2 < 2.3a < 2.3. That would be counter > > intuitive. IMHO any numbering scheme ought to work with `ls -v'. > > Actually, that is what I'm proposing: I've had to explain it many, many times > over the years, and people just expect to see alpha/beta releases named after > the final release they are heading towards. > > Your point about `ls -v' is a good one though. I'll put an extra `-' before > the letter: > Not sure whether it's a concern, but generally most packaging systems (RPM springs to mind) do not allow a '-' in the package's upstream version. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Version numbering
On Tue, 2003-09-30 at 09:31, Bernd Jendrissek wrote: > On Tue, Sep 30, 2003 at 09:33:29AM +0200, Alexandre Duret-Lutz wrote: > > etc. Keeping odd version for development ensure people cannot > > mis-sort versions with letters with others. It could also gives > > some feeling of sense to accustomed to the odd/even version > > numbering scheme of Linux. > > Besides the Linux kernel, what *else* uses that odd/even numbering > scheme? I have seen a couple, but I can't remember any now. > GLib, GTK+, Gimp and GNOME (as well as many to most GNOME apps) spring immediately to mind. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool pre-1.5b tests fail on 9 debian arches
On Fri, 2003-09-26 at 20:46, Robert Millan wrote: > The libtool upstream maintainers are preparing a new 1.5b release. On their > behalf I've recently attempted to test a snapshot from CVS branch-1-5 on all > architectures Debian supports (or pretends to support) that I had access to. > Actually if it was branch-1-5 you were testing, that'd be the new 1.5.0a (1.5.1) release. 1.5b would be on HEAD (as far as I understand the esoteric version numbering upstream use) and a pre-release of libtool 1.6 (which we know Gary wants to get out of the door alongside Autoconf 2.58 and Automake 1.8). > For testing libtool branch-1-5, get a CVS snapshot while passing > "-r branch-1-5" to the checkout command, and run: > > export CVSROOT=:pserver:[EMAIL PROTECTED]:/cvsroot/libtool > cvs -z9 co -r branch-1-5 libtool ; cd libtool > ./bootstrap && ./configure && make && make check > From a Debian point of view, this is a totally wrong thing to do and will result in a *very* broken version of libtool being used! Use the Debian libtool package, not only do I currently track CVS rather than use the pure 1.5 release, there are additional Debian patches added to make it work on some of the architectures. Getting these patches accepted upstream is tricky though, I've sent some bug fixes through. A few days ago I decided to have a go getting some of the portability patches (some of which are large) accepted, I mailed the smallest (yet one of the more far-reaching ones) to -patches; haven't had any follow-up yet though. FWIW, I've run the same tests on Debian unstable with the Debian libtool 1.5-2 package. I've also tried to ascertain *why* tests are failing, it would've been nice if you could've done the same (or perhaps you're working on that?) There's a slight bug in the Debian package, as tests/mdemo2-*.test are added in the .diff.gz, they never get made executable... Before running the tests, chmod a+x tests/mdemo2-*.test This will be fixed in the next Debian libtool package. And now, as they say, the results... [i386] > gluck i386ok > All tests passed with Debian's libtool package. [powerpc] > voltaire powerpc ok > All tests passed with Debian's libtool package. [ia64] > meruloia6417 tests failed > 16 tests failed (out of 101) with Debian's libtool package. They all fail because of: PASS: demo-static.test PASS: demo-make.test FAIL: demo-exec.test [EMAIL PROTECTED]:~/libtool-1.5/tests$ ./demo-exec.test === Running demo-exec.test Executing uninstalled programs in ../demo Welcome to GNU Hell! Welcome to GNU Hell! ./demo-exec.test: cannot execute ../demo/helldl [EMAIL PROTECTED]:~/libtool-1.5/tests$ ../demo/helldl Welcome to *modular* GNU Hell! found file: libhello.a found symbol: hello found symbol: foo found symbol: nothing Illegal instruction It's the call to the function pointer obtained that generates the illegal instruction. An ia64 guru might want to look at this? (mdemo and pdemo likewise fail) [mips] > casalsmips?? [3] > All tests passed with Debian's libtool package. [arm] > debussy arm ok > All tests passed with Debian's libtool package. The upstream libtool (even CVS) can't compile (amongst other libraries) GTK+ because the file_magic deplibs method is broken ... Debian includes a necessary patch to change linux* to pass_all, which fixes this. [alpha] > escheralpha ok > All tests passed with Debian's libtool package. [s390] > raptors3903 tests failed > All tests passed with Debian's libtool package. [hppa] > paer hppa4 tests failed > 1 test failed (out of 101) with Debian's libtool package. PASS: demo-nopic.test PASS: demo-make.test FAIL: demo-exec.test Entirely unsurprising given that hppa is the most fascist platform with regards to PIC code... You can't have Non-PIC shared libraries on hppa. This should be in XFAIL_TESTS for hppa, or skipped (patched Debian libtool appropriately). [m68k] > crest m68k?? [3] > All tests passed with Debian's libtool package. [sparc] > vore sparc ?? [3] > All tests passed with Debian's libtool package. [amd64] > ravel [1] amd64 25 tests failed > (in i686 mode on pergolesi) All tests passed with Debian's libtool package. (in amd32 mode on ravel) All tests passed with Debian's libtool package. (in amd64 mode on ravel) 25 tests failed (out of 65) with Debian's libtool package. This is most likely either amd64 isn't supported by libtool properly yet (it's a very new architecture), given that the failures are all in the *-make tests: gcc-3.3: cannot specify -o with -c or -S and multiple compilations [mipsel] > williams mipsel ?? [2] > Both vaughan and williams are still down :( Though theoretically there'd be no difference from the mips result. [sh] > ??sh ?? [4] > sh isn't even vaguely approaching usefulness yet.
Re: libtool pre-1.5b tests fail on 9 debian arches
On Sat, 2003-09-27 at 21:46, Robert Millan wrote: > On Sat, Sep 27, 2003 at 07:26:20PM +0100, Scott James Remnant wrote: > > Updating to any later version of Libtool is the same amount of work, > > whether it be the Debian-patched version or not. Most of the time, when > > build failures occur, the package upstream is using either an insanely > > out of date version anyway and needs updating whatever the case. > > That implies asking upstream to update their libtool using upstream libtool > in first place, then replacing it with debian's libtool. > We've tended to leave that decision up to individual maintainers so far. > Asides from the > time-consuming effort this represents, the following are examples of problems > that may (and usualy do) occur: > > - libtool.m4 is in a non-standard location or even with a different name; >go search for it. > - aclocal.m4 won't regenerate with your version of aclocal, and the version >upstream used is not present in Debian (e.g: 1.7.6) > - configure won't regenerate with your version of autoconf, and the version >upstream used is not present in Debian (e.g: 2.53) > Or an even better one, just from build failures in the last few days ... upstream placing the contents of libtool.m4 in acinclude.m4, so even after aclocal runs the old version is still used. One thing about maintaining a GNU auto tools package, you certainly see some brain dead practises by other upstream developers. Do these guys not read the manuals? :) > > Getting appropriate patches submitted upstream is a difficult task, and > > I'm not the only person who believes so, it is something I want to do > > and have been trying to do, but it's proving hard work to get replies > > half the time! > > We should start doing that, and I can help. Just requested copyright papers > myself (I assume you've already done that). > > libtool maintainers: Would you consider giving either Scott or me (preferably > both) with CVS access? That'd help a lot getting libtool in shape for all > architectures without having to maintain such a "debian fork" of libtool. > I brought it up about six months ago (about the same time I sorted through all the patches), I'm quite willing to undergo the paper signing -- . > > If that makes sense? I wasn't intending to infer a new libtool project, > > I was trying to indicate we wouldn't be able to use the original > > upstream tar file in the package anymore. > > Yep, it makes sense now. (it's just the same I've been doing for Bochs) > > > I sent an e-mail over a month ago to open a discussion about this > > problem, and it went unanswered. > > Let's reopen it. > Gary, Peter, Bob? Probably the best compromise all round would be to add something like this to libtool.texi below the current permission statements: Provided this document contains no Invariant Sections, it may instead, at your option. be copied, distributed and/or modified under the same terms of the Software it accompanies. or if you'd prefer: Provided this document contains no Invariant Sections, it may instead, at your option. be copied, distributed and/or modified under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. That way you'd still be distributing the documentation under the GNU FDL according to the GNU standards, with the dual-licence of the GPL which would satisfy Debian's free-ness requirements. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool pre-1.5b tests fail on 9 debian arches
On Sat, 2003-09-27 at 19:46, Robert Millan wrote: > On Sat, Sep 27, 2003 at 04:30:15AM +0100, Scott James Remnant wrote: > > On Sat, 2003-09-27 at 06:06, Robert Millan wrote: > > > It's not the Debian libtool package which is (generaly) used by upstream > > > maintainers to update their libtools. My concern is with upstream packages > > > using upstream libtool, hence the Debian package is not relevant. > > > > > Which therefore makes me wonder why you Cc'd the various Debian ports > > lists. We've had an unofficial policy for some time now that porters > > will request/require package maintainers to use the Debian libtool > > package if things break. > > Which is an oddly insane policy. Updating libtool is a non-trivial task most > of the times and not a simple "libtoolize" run as you could pretend, I can > give you examples if you like. > Updating to any later version of Libtool is the same amount of work, whether it be the Debian-patched version or not. Most of the time, when build failures occur, the package upstream is using either an insanely out of date version anyway and needs updating whatever the case. The reason porters tell maintainers to use the Debian libtool package and not the upstream version is simple... They've generally grabbed me on IRC and we've gone through the build logs, and in some cases our libtool package has been patched and uploaded first. Getting appropriate patches submitted upstream is a difficult task, and I'm not the only person who believes so, it is something I want to do and have been trying to do, but it's proving hard work to get replies half the time! When the 1.5 package was prepared, and indeed why it took so long, I placed it in a Subversion repository and spent some time splitting out the individual changes and applying them to 1.5 as discreet commits. Since that time, I've been sending some of the "fringe" ones upstream to gauge how easy it's going to be to get the rest applied. It'd be the work of an afternoon to mail the rest to -patches, if upstream are happy to work though them. > > There's also the problem that Debian may not be able to continue > > distributing the upstream libtool tar file at all, because it contains > > non-free material (the GNU FDL licensed documentation) -- at which point > > I'll simply fork Debian libtool and maintain it by merging every so > > often with GNU libtool. > > So you want to fork a project because it contains non-free components? I've > been maintaining Bochs and Plex86 in Debian for quite some time now. They > have _always_ come with the non-free VGA BIOS, and I just removed it with > every update. Never considered forking for such a reason. > Uh, sorry, the exact meaning I was intending got lost in that paragraph... The current Debian package consists of 1) the upstream libtool tar file and 2) the patches. It's actually generated by exporting the "Debian libtool" Subversion tree and running debuild with the upstream tar file in the right place. That way we end up with a "pristine upstream source", with all the Debian modifications in the .diff.gz alongside it. Because the documentation is non-free, and this will be most-likely enforced the day after sarge is released, it *cannot* be distributed by Debian. This means we won't be able to distribute the upstream tar file because it contains non-free material. Therefore the Debian package would change to consisting of a single "Debian libtool" tar file, which would be the export from the Subversion tree. If that makes sense? I wasn't intending to infer a new libtool project, I was trying to indicate we wouldn't be able to use the original upstream tar file in the package anymore. I sent an e-mail over a month ago to open a discussion about this problem, and it went unanswered. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool pre-1.5b tests fail on 9 debian arches
(Removed debian lists from Cc, I don't see how this is relevant to the porters) On Sat, 2003-09-27 at 06:06, Robert Millan wrote: > On Sat, Sep 27, 2003 at 02:36:13AM +0100, Scott James Remnant wrote: > > Use the Debian libtool package, not only do I currently track CVS rather > > than use the pure 1.5 release, there are additional Debian patches added > > to make it work on some of the architectures. > > It's not the Debian libtool package which is (generaly) used by upstream > maintainers to update their libtools. My concern is with upstream packages > using upstream libtool, hence the Debian package is not relevant. > Which therefore makes me wonder why you Cc'd the various Debian ports lists. We've had an unofficial policy for some time now that porters will request/require package maintainers to use the Debian libtool package if things break. We're all VERY well aware that upstream libtool isn't portable across all Debian architectures, it doesn't work on arm at all -- and until recently didn't work on mips, mipsel or m68k either! This is precisely why Debian's libtool package contains so many additional patches, so when things do break we can just tell the maintainers to update the package with the libtool installed on their system. > > Getting these patches accepted upstream is tricky though, I've sent some > > bug fixes through. A few days ago I decided to have a go getting some > > of the portability patches (some of which are large) accepted, I mailed > > the smallest (yet one of the more far-reaching ones) to -patches; > > haven't had any follow-up yet though. > > My patch sending policy involves pinging them after a week of not responding, > then periodicaly pinging them at increased rate. It's quite effective. > It can be, but very often patches or mails I've sent are simply ignored. I'm almost positive the pass_all patch will be rejected, if it's ever even considered. And yet without that patch, Linux ARM and libtool won't be friends. > Could you try merging all the other patches, so that we can reliably test > libtool on all of Debian's arches? > Only once I've had some degree of success in getting some of the trivial patches applied will I actually worry about untangling the various changes and making them into patches. It's a non-trivial amount of work for each patch, and there are more than a dozen now -- a few of them quite large. Not to mention the various copyright problems that GNU will care about ... a fair chunk is my copyright, but some of the patches which have fixed Debian problems have come from others -- quite a few off the -patches list which upstream also ignored, and yet they fixed problems. There's also the problem that Debian may not be able to continue distributing the upstream libtool tar file at all, because it contains non-free material (the GNU FDL licensed documentation) -- at which point I'll simply fork Debian libtool and maintain it by merging every so often with GNU libtool. If you're interested whether upstream's libtool releases are portable between Linux architectures, you've already done that test and seen that they are not. I don't see the distinction between testing with Debian's libtool package, or the upstream libtool with Debian's patches applied? Debian's package "works" (except for the ia64 test problems, which I strongly suspect are problems in the test code not libtool) which is why when things break we tell maintainers to use our package instead whatever random version upstream found on their hard drive. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Building .so files only.
On Thu, 2003-08-28 at 00:49, Stephen Torri wrote:
> On Wed, 2003-08-27 at 01:50, Schleicher Ralph (LLI) wrote:
> >
> ! If the @samp{-static} option is given, then only a @samp{.o} file is
> ! built, even if libtool was configured with @samp{--disable-static}.
>
> This sounds logically confusing. What is the point of --disable-static
> if -static overrides it?
>
Because otherwise what would libtool's reaction to being passed
--disable-static at configure-time and -static at compile time be?
+ libtool -mode=compile -static...
libtool sits down and starts singing about gold...
?
Scott
--
Have you ever, ever felt like this?
Had strange things happen? Are you going round the twist?
signature.asc
Description: This is a digitally signed message part
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
libtool.info licence
The libtool documentation, as contained in libtool.info, is currently
licensed under the GNU Free Documentation License (GFDL).
As you are probably aware, there is significant opinion that this
licence does not meet the requirements of the Debian Free Software
Guidelines (DFSG).
This means that the libtool documentation will not be able to be
distributed in the Debian GNU/Linux distribution. Instead the
libtool-doc package will most likely be relegated to the non-free
section of the archive, and under Debian policy, the libtool package
will not be able to recommend or suggest it to users.
Some people will probably believe this is Debian's problem; however the
DFSG is considered as good as any benchmark requirements for a "free"
licence, and is the basis for the Open Source definition (which afaik,
the GFDL also fails).
Also Debian has a prior history of obeying paragraph 1 of the Debian
Social Contract ("Debian Will Remain 100% Free Software"), and as I'm
sure you're aware banished Qt and KDE from the archive until the licence
was changed.
So assuming no compromise between the Debian Project and the FSF can be
reached -- I for one am extremely doubtful that any "talks" will be
fruitful -- after the next stable release of Debian, libtool's
documentation will not be available to Debian users.
This is basically an appeal to change the licence for the documentation,
even if simply to a dual-licence of either the GFDL or the GPL at the
user's discretion.
Is there any hope for this?
Scott
--
Have you ever, ever felt like this?
Had strange things happen? Are you going round the twist?
signature.asc
Description: This is a digitally signed message part
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
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 being maintained at all?
On Mon, 2003-07-07 at 02:40, Charles Wilson wrote: > Scott James Remnant wrote: > > On Sun, 2003-07-06 at 11:18, Dalibor Topic wrote: > > >>http://ftp.debian.org/debian/pool/main/libt/libtool/libtool_1.4.3-10.diff.gz > >>etc. > >> > > > > As the Debian Libtool package maintainer, I'd like to know whether it > > would be possible to gain CVS commit access to the libtool repository. > > > > Not necessarily to merge in our (fairly hefty, now) patch, but to at > > least help with some of the work. > > NOTE: the following is not authoritative; it's just my (informed?) > opinion... > > I'd guess not. It appears that debian's changes are all on the 1.4.3 > branch, which is permanently and irrevocably dead. We really really > really don't want to provide anybody with more excuses to stay on 1.4.3. > Yeah, the current libtool package is 1.4 -- unfortunately there are still a huge number of software packages out there still using autoconf 2.13 for whom libtool 1.5 isn't useable until they get their collective arses in gear and update to 2.5x > If John Q. Developer wants new-and-improved libtool functionality, > then we want JQD to use 1.5.x. > Indeed, I've already packaged libtool 1.5 for Debian. The only reason it's not in the archive right now is cowardice. The Debian libtool package will be 1.5 within a month or so though. I'll still be maintaining the 1.4 branch (in a libtool1.4 package) out of need, there's too much that can't updated to 1.5 yet. Scott -- Who welcomes the death of 1.4.x :-) 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 being maintained at all?
On Sun, 2003-07-06 at 11:18, Dalibor Topic wrote: > Thanks, for an outsider like me, it's hard to understand a project's > internal social structure. I've got one more question, though: how do > you handle external patches from distributors? Do you hunt down their > patches trying to integrate their changes back into the CVS tree? Or do > you wait till they contact you? > > Here's a short list of patches I've found by browing the web: > http://www.openbsd.org/cgi-bin/cvsweb/ports/devel/libtool/patches/ > http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/devel/libtool/patches/ > http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/libtool15/files/ > http://rpmfind.net//linux/RPM/rawhide/1.0/i386/RedHat/RPMS/libtool-1.5-3.i386.html > http://ftp.debian.org/debian/pool/main/libt/libtool/libtool_1.4.3-10.diff.gz > etc. > As the Debian Libtool package maintainer, I'd like to know whether it would be possible to gain CVS commit access to the libtool repository. Not necessarily to merge in our (fairly hefty, now) patch, but to at least help with some of the work. Scott -- Who is responsible, well-presented AND washes behind his ears occasionally :-) signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Fwd: libtool munges '-(' linker options.]
On Sun, 2002-12-15 at 17:09, Albert Chin wrote:
> On Sun, Dec 15, 2002 at 04:42:42PM +0000, Scott James Remnant wrote:
> > Certain applications require the linker flags --start-group
> > and --end-group (abbreviated "-(" and "-)" ) in order to
> > resolve circular references between libraries. However,
> > libtool "sorts" these flags and places them at the beginning
> > of the command-line, destroying their utility. At the end
> > of this report is a uuencoded archive containing three
> > source files and a Makefile demonstrating the problem.
> > We end up with an archive A.a which uses symbols defined in B.a
> > and an archive B.a which uses symbols defined in A.a --- a
> > circular dependency. The command:
> > gcc -o foo c.o -Wl,"-(" A.a B.a -Wl,"-)"
> > correctly builds these archives into an executable by telling
> > ld that it should iterate over A.a and B.a to resolve all
> > circular references, instead of ld's usual search-once strategy.
> > However:
> > libtool gcc -o foo c.o -Wl,"-(" A.a B.a -Wl,"-)"
> > yields:
> > $ libtool gcc -o foo c.o -Wl,"-(" A.a B.a -Wl,"-)"
> > gcc -o foo c.o -Wl,"-(" -Wl,"-)" A.a B.a
> > B.a(b.o): In function `b':
> > b.o(.text+0x1b): undefined reference to `a'
> > collect2: ld returned 1 exit status
> >
> > As you can see, libtool re-orders the -( and -) flags, destroying
> > their function. This is a bug in libtool (and it's making my
> > life quite difficult at the moment).
>
> Why not invoke libtool as:
> $ libtool gcc -o foo c.o -Wl,"-(",A.a,B.a,"-)"
>
It actually turns out they weren't using ".a" files but ".la" files
instead.
I've received the following follow-up:
8<8<8<8<8<8<8<
Your proposed solution will not work. The complete command-line from my
application is:
$(LIBTOOL) --mode=link $(CC) $(STATIC_FLAG) $(AM_CFLAGS) $(CFLAGS) \
$(LDFLAGS) -o $@ -Wl,-Tinclude/asm/link-script "-Wl,-(" \
src/libflexc0.la $< src/libflexc1.la "-Wl,-)" @GC_LIB@ @LIBS@
Note that the ".la" files cannot be passed unmodified to the linker.
libtool *must* munge these appropriately *without* affecting the order
in which the -( flags are passed. The patch I provided does solve this
problem.
>8>8>8>8>8>8>8
Any further ideas?
Scott
--
Scott James Remnant Have you ever, ever felt like this? Had strange
http://netsplit.com/ things happen? Are you going round the twist?
signature.asc
Description: This is a digitally signed message part
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
[Fwd: Bug#179323: libtool - fails to relink cross compiled libs]
Have had a bug submitted by a Debian user, does anyone have any ideas? Scott -Forwarded Message- From: Bastian Blank <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Bug#179323: libtool - fails to relink cross compiled libs Date: 01 Feb 2003 13:46:06 +0100 Package: libtool Version: 1.4.3-5 Severity: important libtool fails to relink cross compiled libs: | /bin/sh ../libtool --mode=install /usr/bin/install -c libtuxbox-ucodes.la |/home/bastian/dbox2/cross/apps/misc/libs/debian/tmp/usr/lib/libtuxbox-ucodes.la | libtool: install: warning: relinking `libtuxbox-ucodes.la' | (cd /home/bastian/dbox2/cross/apps/misc/libs/build/libucodes; /bin/sh ../libtool |--mode=relink powerpc-linux-gcc -Wall -O2 -pipe -g3 -ggdb -o libtuxbox-ucodes.la |-rpath /usr/lib libucodes.lo ../libmd5sum/libtuxbox-md5sum.la -inst-prefix-dir |/home/bastian/dbox2/cross/apps/misc/libs/debian/tmp) | powerpc-linux-gcc -shared libucodes.lo -L/usr/lib |-L/home/bastian/dbox2/cross/apps/misc/libs/debian/tmp/usr/lib -ltuxbox-md5sum |-Wl,-soname -Wl,libtuxbox-ucodes.so.0 -o .libs/libtuxbox-ucodes.so.0.0.0 | /lib/libc.so.6: could not read symbols: Invalid operation | collect2: ld returned 1 exit status | libtool: install: error: relink `libtuxbox-ucodes.la' with the above command before |installing it | # libtuxbox-ucodes.la - a libtool library file | # Generated by ltmain.sh - GNU libtool 1.4.3 (1.922.2.111 2002/10/23 02:54:36) | # | # Please DO NOT delete this file! | # It is necessary for linking the library. | | # The name that we can dlopen(3). | dlname='libtuxbox-ucodes.so.0' | | # Names of this library. | library_names='libtuxbox-ucodes.so.0.0.0 libtuxbox-ucodes.so.0 libtuxbox-ucodes.so' | | # The name of the static archive. | old_library='libtuxbox-ucodes.a' | | # Libraries that this one depends upon. | dependency_libs=' |/home/bastian/dbox2/cross/apps/misc/libs/build/libmd5sum/libtuxbox-md5sum.la ' | | # Version information for libtuxbox-ucodes. | current=0 | age=0 | revision=0 | | # 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/lib' | relink_command="(cd /home/bastian/dbox2/cross/apps/misc/libs/build/libucodes; |/bin/sh ../libtool --mode=relink powerpc-linux-gcc -Wall -O2 -pipe -g3 -ggdb -o |libtuxbox-ucodes.la -rpath /usr/lib libucodes.lo ../libmd5sum/libtuxbox-md5sum.la |@inst_prefix_dir@)" bastian -- Another Armenia, Belgium ... the weak innocents who always seem to be located on a natural invasion route. -- Kirk, "Errand of Mercy", stardate 3198.4 -- Scott James Remnant Have you ever, ever felt like this? Had strange http://netsplit.com/ things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Fwd: libtool: SIGSEGV with ltdl.c (tryall_dlopen_module)]
On Sun, 2002-12-15 at 17:10, Albert Chin wrote: > On Sun, Dec 15, 2002 at 04:45:27PM +0000, Scott James Remnant wrote: > > This is actually two "problems" he's fixing, the first of which > > definitely looks like a good fix -- the second of which (the third hunk > > of the patch) I'm not sure about, and the third (the fourth hunk) he > > doesn't even know why he's including! > > I think some of this was fixed in 1.4.3. Have a peek. > I did notice that the last hunk of the patch was already in 1.4.3, sorry, I forgot to mention that! :) I didn't see a direct change that would specifically stop "objdir" or "dir" in the calls to tryall_dlopen_module() being NULL -- they'd still get caught at the assert(). Scott -- Scott James Remnant Have you ever, ever felt like this? Had strange http://netsplit.com/ things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
[Fwd: libtool: SIGSEGV with ltdl.c (tryall_dlopen_module)]
And here's another one,
This is actually two "problems" he's fixing, the first of which
definitely looks like a good fix -- the second of which (the third hunk
of the patch) I'm not sure about, and the third (the fourth hunk) he
doesn't even know why he's including!
Ossama, the old maintainer, was going to send this patch upstream in its
entirity -- I don't think he ever go the time though :(
8<8<8<8<8<8<8<
Date: Wed, 17 Jul 2002 01:24:05 +0200
From: Denis Barbier <[EMAIL PROTECTED]>
To: Debian Bug Tracking System <[EMAIL PROTECTED]>
Subject: libtool: SIGSEGV with ltdl.c (tryall_dlopen_module)
--lrZ03NoBR/3+SXJZ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Package: libtool
Version: 1.4.2-7
Severity: normal
Tags: patch
Hi,
when trying to add plug-ins machinery into one of my programs, I
encountered several problems with ltdl.c:
* A SIGSEGV occurs in tryall_dlopen_module when dirname is null.
(chunks 1 and 2 of attached patch)
* In try_dlopen, there is no reason to search for files in the
current directory, one may set any search path if needed.
Moreover it is not documented this way in info files.
(chunk 3)
* I cannot exactly remember why I needed chunk 4, but I did.
And fixed test is then in accord with preceding comment.
Let me know if you need further details here.
Denis
-- System Information:
Debian Release: 3.0
Architecture: i386
Kernel: Linux france0danemark2 2.4.18-386 #2 Sun Apr 14 10:38:08 EST 2002 i586
Locale: LANG=C, LC_CTYPE=C
Versions of packages libtool depends on:
ii altgcc [c-compiler]1:2.7.2.3-2 Alternate gcc package for the libc
ii autotools-dev 20020621.1Update infrastructure for config.{
ii cpp2:2.95.4-15 The GNU C preprocessor.
ii file 3.37-3.1 Determines file type using "magic"
ii gcc [c-compiler] 2:2.95.4-15 The GNU C compiler.
ii gcc-2.95 [c-compiler] 1:2.95.4-10 The GNU C compiler.
ii gcc-3.0 [c-compiler] 1:3.0.4-10The GNU C compiler.
ii gcc-3.1 [c-compiler] 1:3.1.1-0pre3 The GNU C compiler.
ii libc6-dev [libc-dev] 2.2.5-11 GNU C Library: Development Librari
-- no debconf information
--lrZ03NoBR/3+SXJZ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="ltdl.c.patch"
--- /usr/share/libtool/libltdl/ltdl.c.orig Tue Jul 2 19:12:16 2002
+++ /usr/share/libtool/libltdl/ltdl.c Fri Jul 5 22:29:28 2002
@@ -2034,7 +2034,7 @@
}
/* try to open the not-installed module */
- if (!installed)
+ if (!installed && objdir)
{
if (tryall_dlopen_module (handle, dir, objdir, dlname) == 0)
return 0;
@@ -2042,7 +2042,7 @@
/* maybe it was moved to another directory */
{
- if (tryall_dlopen_module (handle,
+ if (dir && tryall_dlopen_module (handle,
(const char *) 0, dir, dlname) == 0)
return 0;
}
@@ -2688,10 +2688,6 @@
}
#endif
}
- if (!file)
- {
- file = fopen (filename, LT_READTEXT_MODE);
- }
/* If we didn't find the file by now, it really isn't there. Set
the status flag, and bail out. */
@@ -2987,7 +2983,7 @@
failed, it is better to return an error message here than to
report FILE_NOT_FOUND when the alternatives (foo.so etc) are not
in the module search path. */
- if (handle || ((errors > 0) && file_not_found ()))
+ if (handle || ((errors > 0) && !file_not_found ()))
{
LT_DLFREE (tmp);
return handle;
--lrZ03NoBR/3+SXJZ--
>8>8>8>8>8>8>8
Scott
--
Scott James Remnant Have you ever, ever felt like this? Had strange
http://netsplit.com/ things happen? Are you going round the twist?
signature.asc
Description: This is a digitally signed message part
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
[Fwd: libtool munges '-(' linker options.]
compiler_flags $wl$qarg"
- prev=
compile_command="$compile_command $wl$qarg"
finalize_command="$finalize_command $wl$qarg"
continue
@@ -1177,6 +1185,14 @@ compiler."
save_ifs="$IFS"; IFS=','
for flag in $args; do
IFS="$save_ifs"
+ if test "$flag" = "-(" -o "$flag" = "--start-group" ; then
+ deplibs="$deplibs --start-group"
+ continue;
+ fi
+ if test "$flag" = "-)" -o "$flag" = "--end-group" ; then
+ deplibs="$deplibs --end-group"
+ continue
+ fi
case $flag in
*[\[\~\#\^\&\*\(\)\{\}\|\;\<\>\?\'\ \ ]*|*]*|"")
flag="\"$flag\""
@@ -1464,6 +1480,12 @@ compiler."
deplibs="$deplib $deplibs"
continue
;;
+ --start-group|--end-group)
+ deplibs="$deplib $deplibs"
+ compile_deplibs="$wl$deplib $compile_deplibs"
+ finalize_deplibs="$wl$deplib $finalize_deplibs"
+ continue
+ ;;
*.la) lib="$deplib" ;;
*.$libext)
if test $pass = conv; then
>8>8>8>8>8>8>8
Scott
--
Scott James Remnant Have you ever, ever felt like this? Had strange
http://netsplit.com/ things happen? Are you going round the twist?
signature.asc
Description: This is a digitally signed message part
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
