Re: patch-6: several changes to libtoolize.m4sh
Ralf Wildenhues wrote: Hello Gary, Hallo Ralf! This has been so long ago it's a shame: http://lists.gnu.org/archive/html/libtool-patches/2005-12/msg00075.html So long that I'd completely forgotten about it!! * Gary V. Vaughan wrote on Wed, Dec 14, 2005 at 01:39:55PM CET: Ralf Wildenhues wrote: This patch is the last of the queue, and the most intertwined. Maybe I should make the effort to rip it apart -- please say so. Yes please. Unless it is a disproportionate amount of effort, in which case I'd rather spend that effort on rolling 1.9h. The fact that I haven't found the time to rip it apart in 6 months is enough reason for me to just apply it in one go. Agreed. Note that in the symlink-case, this file *must* retain its old time stamp, hence `cp -p'. Maybe we'd need `tar' instead here? I'm not sure `cp -p' is portable enough. We've used `tar' previously because of this (among other things). I've changed the patch to use tar. Although I really really doubt there to be any real advantage here of tar over cp -p. If there were such an issue, it should definitly be mentioned in the Autoconf portability section. I don't remember what the issues were that we encountered :-( But, we did have good reason for moving from cp -p to tar back in the day. I don't mind trying to revert to cp -p after the release if the archives don't hold a good reason not to. (Luckily the subsecond problem is not *so* much of an issue here: `cd libltdl aclocal' still takes a second on a fast machine -- maybe we should put a `sleep 1' into the manual rule even?) Yes, I think the sleep is a good idea for future proof against ultra fast machines that decide not to upgrade to libtool-3.0 in 2025 ;-) Let's not do that yet. Maybe after the stuff has stabilized. Good. I was just kidding!! :-D As a final bit, we default $tst_dist to `dist' now -- should work. :) I'd rather not have casual installers be even more likely to get bored and abort the testsuite run. What do you think of my LT_TEST_EXHAUSTIVE idea? The dist part isn't so much more expensive at all; you may have been thinking of distcheck, which would really be expensive. But dist uncovers the bugs fixed in this patch, and I definitely want to see those. ACK. As a general rule, the ChangeLog entry itself should be sufficient documentation for why the changeset is necessary. If you find yourself wanting to add more description to the libtool-patches post, rather add it to the ChangeLog entry instead for future readers. I've added some of the description to the ChangeLog entry now. Excellent. Thanks. I've applied the patch as shown below. Thanks for remembering! Once I've got my dev environment set up again, I have a couple of patches in quilt that need resynching with HEAD, and that need consideration before 2.0. Fix several libtoolize-related bugs: - Do not symlink aclocal.m4, to work around a bug in aclocal overwriting the linked-to file instead of removing the symlink. - Have `libtoolize --copy' cause current time stamps, so that dependents will be rebuilt; for this, install files in order. - Fix list of distribution files for (non)recursive libltdl. - Fix some failure cases. * libtoolize.m4sh (func_copy_cb): If `$opt_link', still copy `aclocal.m4', so a subsequent `aclocal' will not overwrite the symlink target. In `--copy' mode, do `cp -p' and `touch' for each file, so timestamps are updated but permissions preserved. (main): Reorder installing of files to match logical order and timestamp requirements. (func_fixup_Makefile_inc): Renamed to (func_fixup_Makefile): this. Add sed scriptlet to remove non-existent files from EXTRA_DIST, for either nonrecursive or recursive mode. (main): call it to mangle also in recursive mode. * tests/libtoolize.at (expout): Adjusted. * tests/testsuite.at (tst_dist): Default to `dist'. All good! Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://blog.azazil.net GNU Hacker / )= http://trac.azazil.net/projects/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature
Re: patch-6: several changes to libtoolize.m4sh
Hi Gary, * Gary V. Vaughan wrote on Tue, Jun 13, 2006 at 12:08:35PM CEST: Ralf Wildenhues wrote: This has been so long ago it's a shame: http://lists.gnu.org/archive/html/libtool-patches/2005-12/msg00075.html So long that I'd completely forgotten about it!! I have a mail folder with issues going back a few years (basically since I subscribed to libtool lists). * Gary V. Vaughan wrote on Wed, Dec 14, 2005 at 01:39:55PM CET: I'm not sure `cp -p' is portable enough. We've used `tar' previously because of this (among other things). I've changed the patch to use tar. Although I really really doubt there to be any real advantage here of tar over cp -p. If there were such an issue, it should definitly be mentioned in the Autoconf portability section. I don't remember what the issues were that we encountered :-( But, we did have good reason for moving from cp -p to tar back in the day. I don't mind trying to revert to cp -p after the release if the archives don't hold a good reason not to. I might check eventually... I've applied the patch as shown below. Thanks for remembering! Once I've got my dev environment set up again, I have a couple of patches in quilt that need resynching with HEAD, and that need consideration before 2.0. I may have obsoleted some of your patches, maybe even by redoing them in a less elegant way. Oh well. Expect more patches soon. Cheers, Ralf
Re: patch-6: several changes to libtoolize.m4sh
Ralf Wildenhues wrote: Hi Gary, Hallo Ralf, * Gary V. Vaughan wrote on Tue, Jun 13, 2006 at 12:08:35PM CEST: Ralf Wildenhues wrote: This has been so long ago it's a shame: http://lists.gnu.org/archive/html/libtool-patches/2005-12/msg00075.html So long that I'd completely forgotten about it!! I have a mail folder with issues going back a few years (basically since I subscribed to libtool lists). My (rather stupid with the benefit of hindsight) system has been to mark emails unread if I still have an action to take on it. I made an attempt at centralizing our todo list with: http://wiki.azazil.net/GnuLibtoolProject/RoadMap But it is still rather primitive. I'm still trying to migrate all my little scripts and tools from arch to svn, and after 2.0 I'll start bugging everyone to use: http://trac.azazil.net/projects/libtool But enough of that for now :-) I've applied the patch as shown below. Thanks for remembering! Once I've got my dev environment set up again, I have a couple of patches in quilt that need resynching with HEAD, and that need consideration before 2.0. I may have obsoleted some of your patches, maybe even by redoing them in a less elegant way. Oh well. No matter, we'll find those as I merge. IIRC, I only have a handful of pending patches addressing issues from the RoadMap above. Expect more patches soon. Likewise :-) Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://blog.azazil.net GNU Hacker / )= http://trac.azazil.net/projects/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature
Re: HEAD: Fix dependencies for libltdl generated files
Tag Ralf, Ralf Wildenhues wrote: [[snip]] Index: Makefile.am === [[snip snip]] +## Unfortunately, all this bogeyness [[...]] /me falls off his chair: ROFL. What on earth is 'bogeyness'? Is it related to bogosity? Titter, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://blog.azazil.net GNU Hacker / )= http://trac.azazil.net/projects/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature
Re: changing compiler flags at configure time
Hello Eric,
Thanks for helping!
* Eric Blake wrote on Tue, Jun 13, 2006 at 01:52:55PM CEST:
[dropping bug-m4, adding libtool-patches]
Let's drop libtool, too.
How about this?
Hmm.
2006-06-12 Eric Blake [EMAIL PROTECTED]
* libltdl/m4/ltoptions.m4 (_LT_SET_OPTION): Require literal
options.
(LT_ENABLE_SHARED, LT_DISABLE_SHARED): New macros.
(LT_ENABLE_STATIC, LT_DISABLE_STATIC): New macros.
(_LT_OBSOLETE): New helper macro.
I did not see _LT_OBSOLETE anywhere.
* libltdl/m4/libtool.m4 (LT_INIT): Fail on multiple invocations.
* doc/libtool.texi (LT_INIT, LT_DISABLE_SHARED, LT_ENABLE_SHARED),
(LT_DISABLE_STATIC, LT_ENABLE_STATIC): Document these changes.
* NEWS: Document new macros.
--- NEWS 15 May 2006 16:40:42 - 1.194
+++ NEWS 13 Jun 2006 11:48:07 -
@@ -1,6 +1,9 @@
NEWS - list of user-visible changes between releases of GNU Libtool
New in 1.9h: 2005-??-??; CVS version 2.1a, Libtool team:
+* New macros LT_ENABLE_SHARED, LT_DISABLE_SHARED, LT_ENABLE_STATIC,
+ and LT_DISABLE_STATIC work alongside LT_INIT to replace obsoleted
+ AC_ENABLE_SHARED and friends.
Please spell out all four. Future greppability is a major bonus.
--- doc/libtool.texi 18 May 2006 00:10:37 - 1.215
+++ doc/libtool.texi 13 Jun 2006 11:48:09 -
@@ -1902,6 +1901,11 @@ friend.}
LT_INIT([disable-shared])
@end example
[EMAIL PROTECTED] may only be invoked once. If you need to change the
+default selections after the fact, such as based on whether a particular
[EMAIL PROTECTED] option was passed to @code{./configure}, you can use
+macros such as @code{LT_DISABLE_SHARED} or @code{LT_DISABLE_STATIC}.
prior to using LT_INIT.
@@ -1996,6 +2000,16 @@ Change the default behaviour of @command
[EMAIL PROTECTED] objects. The user may still override this default by
specifying @option{--with-pic} to @command{configure}.
[EMAIL PROTECTED] shared
+Change the default behaviour for @code{LT_INIT} to enable
+shared libraries. The user may still override this default by
+specifying @option{--disable-shared} to @command{configure}.
Maybe add This is the default. after the first sentence?
[EMAIL PROTECTED] static
+Change the default behaviour for @code{LT_INIT} to enable
+static libraries. The user may still override this default by
+specifying @option{--disable-static} to @command{configure}.
Likewise.
@@ -2140,6 +2154,40 @@ Automake regeneration rules, @file{confi
the file itself.
@end defmac
[EMAIL PROTECTED] LT_DISABLE_SHARED
[EMAIL PROTECTED] AC_DISABLE_SHARED
+This macro changes the created @file{libtool} to avoid creating shared
+libraries by default. It is equivalent to
[EMAIL PROTECTED]([disable-shared])}, except that it may be called after
[EMAIL PROTECTED] Older versions of libtool used the obsolete name
[EMAIL PROTECTED]
[EMAIL PROTECTED] defmac
It is wrong to call these macros after LT_INIT. I don't know if we flag
this, but the old ways was that AC_DISABLE_SHARED must be called before
AC_PROG_LIBTOOL. We cannot change this. If the code doesn't allow this
now (untested), this is a bug. Likewise for the other three macros.
--- libltdl/m4/libtool.m4 1 Jun 2006 18:39:24 - 1.74
+++ libltdl/m4/libtool.m4 13 Jun 2006 11:48:11 -
@@ -37,7 +37,7 @@ m4_define([_LT_COPYING], [dnl
# the same distribution terms that you use for the rest of that program.
])
-# serial 52 LT_INIT
+# serial 53 LT_INIT
# LT_PREREQ(VERSION)
@@ -78,8 +78,8 @@ AC_SUBST(LIBTOOL)dnl
_LT_SETUP
-# Only expand once:
-m4_define([LT_INIT])
+# Diagnose multiple calls:
+m4_define([LT_INIT], [AC_MSG_ERROR([[$0 can only be invoked once]])])
m4_define([LT_INIT], [m4_fatal([$0 can only be invoked once])])
please; no need to bug the end-user with this.
--- libltdl/m4/ltoptions.m4 12 Nov 2005 12:08:14 - 1.7
+++ libltdl/m4/ltoptions.m4 13 Jun 2006 11:48:11 -
@@ -1,13 +1,13 @@
# Helper functions for option handling.-*- Autoconf -*-
-# Copyright (C) 2004, 2005 Free Software Foundation, Inc.
+# Copyright (C) 2004, 2005, 2006 Free Software Foundation, Inc.
# Written by Gary V. Vaughan [EMAIL PROTECTED]
#
# This file is free software; the Free Software Foundation gives
# unlimited permission to copy and/or distribute it, with or without
# modifications, as long as this notice is preserved.
-# serial 3 ltoptions.m4
+# serial 4 ltoptions.m4
# This is to help aclocal find these macros, as it can't see m4_define.
AC_DEFUN([LTOPTIONS_VERSION], [m4_if([1])])
@@ -23,12 +23,15 @@ m4_define([_LT_MANGLE_OPTION],
#
# Set option NAME, and if there is a matching handler defined,
# dispatch to it. Other NAMEs are saved as a flag.
+# Die if NAME is not a literal.
m4_define([_LT_SET_OPTION],
-[m4_define(_LT_MANGLE_OPTION([$1]))dnl
-m4_ifdef(_LT_MANGLE_DEFUN([$1]),
-
Re: HEAD: Fix dependencies for libltdl generated files
Ralf Wildenhues wrote: Hello Gary, Hallo Ralf! * Gary V. Vaughan wrote on Tue, Jun 13, 2006 at 01:52:20PM CEST: Ralf Wildenhues wrote: [[snip]] Index: Makefile.am === [[snip snip]] +## Unfortunately, all this bogeyness [[...]] /me falls off his chair: ROFL. What on earth is 'bogeyness'? Is it related to bogosity? Yes, I guess I meant bogosity; I probably intended to write bogusness, not knowing any better. Does bogeyness have any meaning? If not, you can regard it as intentional misspelling. Quoting from: http://www.reference.com/browse/wiki/Bogey * British slang for a piece of dried mucus; see the American equivalent, booger. The term was made famous in the United States by Harry Potter purists who objected to its replacement with booger in the American version. I was wondering if you were likening to our Makefile rules to dried nasal mucus :-D Now that you mention it, I don't think it is that unfair to confer all Makefile rules with bogeyness... no need to change the patch IMHO. Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://blog.azazil.net GNU Hacker / )= http://trac.azazil.net/projects/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature
Re: changing compiler flags at configure time
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Greetings, Ralf,
According to Ralf Wildenhues on 6/13/2006 6:49 AM:
Thanks for helping!
Thanks for the feedback. It will be a while before I can incorporate it
all (and most importantly, add a testsuite case to exercise it all), but I
appreciate your first read of my hastily written first cut.
2006-06-12 Eric Blake [EMAIL PROTECTED]
* libltdl/m4/ltoptions.m4 (_LT_SET_OPTION): Require literal
options.
(LT_ENABLE_SHARED, LT_DISABLE_SHARED): New macros.
(LT_ENABLE_STATIC, LT_DISABLE_STATIC): New macros.
(_LT_OBSOLETE): New helper macro.
I did not see _LT_OBSOLETE anywhere.
Oops. I originally tried:
m4_define([_LT_OBSOLETE], [AU_DEFUN([$1], [$2])
AC_DIAGNOSE([obsolete])])
But that killed aclocal. I guess I didn't re-update changelog.
* libltdl/m4/libtool.m4 (LT_INIT): Fail on multiple invocations.
* doc/libtool.texi (LT_INIT, LT_DISABLE_SHARED, LT_ENABLE_SHARED),
(LT_DISABLE_STATIC, LT_ENABLE_STATIC): Document these changes.
* NEWS: Document new macros.
--- NEWS 15 May 2006 16:40:42 - 1.194
+++ NEWS 13 Jun 2006 11:48:07 -
@@ -1,6 +1,9 @@
NEWS - list of user-visible changes between releases of GNU Libtool
New in 1.9h: 2005-??-??; CVS version 2.1a, Libtool team:
+* New macros LT_ENABLE_SHARED, LT_DISABLE_SHARED, LT_ENABLE_STATIC,
+ and LT_DISABLE_STATIC work alongside LT_INIT to replace obsoleted
+ AC_ENABLE_SHARED and friends.
Please spell out all four. Future greppability is a major bonus.
Gotcha.
--- doc/libtool.texi 18 May 2006 00:10:37 - 1.215
+++ doc/libtool.texi 13 Jun 2006 11:48:09 -
@@ -1902,6 +1901,11 @@ friend.}
LT_INIT([disable-shared])
@end example
[EMAIL PROTECTED] may only be invoked once. If you need to change the
+default selections after the fact, such as based on whether a particular
[EMAIL PROTECTED] option was passed to @code{./configure}, you can use
+macros such as @code{LT_DISABLE_SHARED} or @code{LT_DISABLE_STATIC}.
prior to using LT_INIT.
OK, and I'll see about making those macros do m4_fatal once LT_INIT has
happened.
@@ -1996,6 +2000,16 @@ Change the default behaviour of @command
[EMAIL PROTECTED] objects. The user may still override this default by
specifying @option{--with-pic} to @command{configure}.
[EMAIL PROTECTED] shared
+Change the default behaviour for @code{LT_INIT} to enable
+shared libraries. The user may still override this default by
+specifying @option{--disable-shared} to @command{configure}.
Maybe add This is the default. after the first sentence?
Good idea.
[EMAIL PROTECTED] static
+Change the default behaviour for @code{LT_INIT} to enable
+static libraries. The user may still override this default by
+specifying @option{--disable-static} to @command{configure}.
Likewise.
@@ -2140,6 +2154,40 @@ Automake regeneration rules, @file{confi
the file itself.
@end defmac
[EMAIL PROTECTED] LT_DISABLE_SHARED
[EMAIL PROTECTED] AC_DISABLE_SHARED
+This macro changes the created @file{libtool} to avoid creating shared
+libraries by default. It is equivalent to
[EMAIL PROTECTED]([disable-shared])}, except that it may be called after
[EMAIL PROTECTED] Older versions of libtool used the obsolete name
[EMAIL PROTECTED]
[EMAIL PROTECTED] defmac
It is wrong to call these macros after LT_INIT. I don't know if we flag
this, but the old ways was that AC_DISABLE_SHARED must be called before
AC_PROG_LIBTOOL. We cannot change this. If the code doesn't allow this
now (untested), this is a bug. Likewise for the other three macros.
--- libltdl/m4/libtool.m41 Jun 2006 18:39:24 - 1.74
+++ libltdl/m4/libtool.m413 Jun 2006 11:48:11 -
@@ -37,7 +37,7 @@ m4_define([_LT_COPYING], [dnl
# the same distribution terms that you use for the rest of that program.
])
-# serial 52 LT_INIT
+# serial 53 LT_INIT
# LT_PREREQ(VERSION)
@@ -78,8 +78,8 @@ AC_SUBST(LIBTOOL)dnl
_LT_SETUP
-# Only expand once:
-m4_define([LT_INIT])
+# Diagnose multiple calls:
+m4_define([LT_INIT], [AC_MSG_ERROR([[$0 can only be invoked once]])])
m4_define([LT_INIT], [m4_fatal([$0 can only be invoked once])])
please; no need to bug the end-user with this.
I always have to think about which macro I should be using there. It
makes sense when I take my time, but when I write in a hurry I seem to
always get it wrong :)
--- libltdl/m4/ltoptions.m4 12 Nov 2005 12:08:14 - 1.7
+++ libltdl/m4/ltoptions.m4 13 Jun 2006 11:48:11 -
@@ -1,13 +1,13 @@
# Helper functions for option handling.-*- Autoconf -*-
-# Copyright (C) 2004, 2005 Free Software Foundation, Inc.
+# Copyright (C) 2004, 2005, 2006 Free Software Foundation, Inc.
# Written by Gary V. Vaughan [EMAIL PROTECTED]
#
# This file is free software; the Free Software Foundation gives
# unlimited permission to copy
Re: libtool --ltdl vs. autoreconf
[ eliding bug-m4 and autoconf lists ]
Hello Eric,
* Ralf Wildenhues wrote on Thu, May 25, 2006 at 06:39:38PM CEST:
* Eric Blake wrote on Tue, May 09, 2006 at 02:04:23PM CEST:
As promised here,
http://lists.gnu.org/archive/html/m4-patches/2006-05/msg5.html, I
noticed that m4 bootstrap invokes libtoolize --ltdl prior to autoreconf,
which reinvokes libtoolize without --ltdl. This seems like a bit of a
waste of time, but when I tried removing the explicit libtoolize line, I
got a bootstrap failure that a required file, ltmain.sh, was not found. I
thought that using LT_CONFIG_LTDL_DIR in configure.ac would take care of
everything that --ltdl used to do on the command line, but I was obviously
mistaken.
Now that the issue above has been fixed, let's tackle some of the other
issues encountered here...
[...] with a pristine CVS checkout of M4, and deleting the
libtoolize invocation from `bootstrap', the aclocal call in the toplevel
will happen before libtoolize is called; since aclocal isn't called with
`--install' (well, that would work with CVS Automake aclocal only).
So, the Libtool macro files aren't in place yet, so the whole of them
ends up copied into aclocal.m4. This is then fixed after a second
bootstrap.
This is fixed already, too.
Which opens up an interesting side question: should autoreconf-2.60 be
prepared for `aclocal-1.10 --install'?
I have not looked at this yet...
Back to Libtool, the next issue is that, currently, the patch below will
cause libltdl to be copied twice: once from the toplevel dir, and once
from within the libltdl dir. This is ugly and error-prone. On the one
hand, we want `libtoolize --ltdl=.' to copy libltdl, on the other, we
don't want `libtoolize --ltdl' to copy libltdl if
`LT_CONFIG_LTDL_DIR([.])' is found; so I guess we should make libtoolize
change behavior between detected libltdl-directory `.' and passed
directory `.'. (All of this is in recursive-ltdl-mode.) I definitely
do not want to have to put more of this logic into autoreconf.
One easy way to fix this is to `autoreconf --no-recursive --ltdl' so
that autoreconf simply won't enter the directory in which the recursive
libltdl resides (see the patch I posted on m4-patches). (We may still
want to fix the issue as described above, but it's not so pressing.)
Then, currently inside a libltdl subdir, libtoolize wrongly suggests:
| libtoolize: Consider using `AC_CONFIG_AUX_DIR([./config])' in configure.ac.
| libtoolize: Consider using `AC_CONFIG_MACRO_DIR([./m4])' in configure.ac.
This is a libtoolize bug.
(First, these macros are already used, second, the arguments should not
start with `./', to cater for non-GNU make.)
To finish the sentence in parentheses: And third, libtoolize should
realize that AC_CONFIG_AUX_DIR([config]) is what is needed, and is
already present there.
These 3 issues are fixed by the patch below, which I have applied now.
You will notice that libtoolize output may seem a bit inconsistent now:
$ libtoolize --ltdl=.
| libtoolize: linking file `m4/argz.m4'
[...]
| libtoolize: linking file `./COPYING.LIB'
[...]
| libtoolize: linking file `./config/compile'
and I may eventually fix that (post 2.0). But that is not a serious
bug, if it could even be qualified as such, and the other functions in
libtoolize are sufficiently messed up that I don't care much to rewrite
them now.
Cheers,
Ralf
Fix the bugs where libtoolize needs to use `dir/file' instead of
`./dir/file', where ltdldir is `.', so that libtoolize correctly
checks for (and suggests) `config' and `m4' instead of
`./config' and `./m4' as auxiliary resp. macro directories.
The change is necessary for unambiguous naming, the chosen way
plays better with non-GNU make in VPATH builds.
* libtoolize.m4sh (ltdlprefix): New variable, to use as prefix
instead of `$ltdldir/'.
(func_check_macros): Use it. Bug report by Eric Blake.
Index: libtoolize.m4sh
===
RCS file: /cvsroot/libtool/libtool/libtoolize.m4sh,v
retrieving revision 1.55
diff -u -r1.55 libtoolize.m4sh
--- libtoolize.m4sh 12 Jun 2006 17:54:15 - 1.55
+++ libtoolize.m4sh 13 Jun 2006 18:55:32 -
@@ -904,8 +904,8 @@
func_echo and rerunning libtoolize.
fi
elif test -z $m4dir; then
- if $opt_ltdl test $ltdldir/m4 != $m4dir; then
- acmacrodir=$ltdldir/m4
+ if $opt_ltdl test ${ltdlprefix}m4 != $m4dir; then
+ acmacrodir=${ltdlprefix}m4
else
acmacrodir=$aclocaldir
fi
@@ -940,10 +940,10 @@
# Offer some suggestions for avoiding duplicate files in a project
# that uses libltdl:
- test $ltdldir/config = $auxdir ||
-func_echo Consider using \`AC_CONFIG_AUX_DIR([[$ltdldir/config]])' in
$configure_ac.
- $ac_config_macro_dir_advised || test $ltdldir/m4 = $m4dir ||
-
with_gcc using PGI compilers windows
It's been a long time since I've tried the PGI compilers with the autotools. I usually get frustrated and go a way for a while. Anyways, I ran into a problem I don't remember having before [updating the CVS source]. When with_gcc is not set to yes, libtool is replacing library files, -la with a.lib (assuming msvc). The problem is the PGI compilers won't look for a.lib in any of the -L arguments. Manually setting with_gcc=yes allows linking in the -L -l manner. So, I was wondering if a libtool autoconf test for linking style on windows would be better, or just manually adding pgcc, pgCC, and pgf* to the ones that set with_gcc=yes. As an aside does this really work with msvc? I thought msvc used -LIBPATH. Also, I had sent a patch in a while ago about making DLL's with the PGI compilers (-Mmakedll flag) that I guess never made it in. I remember having problems running the tests. I guess at some point I'll try to rerun that to get that fixed. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: with_gcc using PGI compilers windows
On 6/13/06, Christopher Hulbert [EMAIL PROTECTED] wrote: [snip] Also, I had sent a patch in a while ago about making DLL's with the PGI compilers (-Mmakedll flag) that I guess never made it in. I remember having problems running the tests. I guess at some point I'll try to rerun that to get that fixed. Ignore that. I was picking up the older libtool m4 macros. The newer ones do indeed use -Mmakedll. PGI compilers with autotools are looking promising despite the lib renaming. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: include the right ltdl.h
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Ralf, and adding libtool, According to Ralf Wildenhues on 6/13/2006 3:08 AM: This patch makes sure you use the in-tree ltdl.h if necessary, thus fixing a build failure (e.g., if the ltdl.h that is found in the default paths is an old one, or none is found there). And it is a fairly old patch; you submitted the same idea several months ago, and it is still sitting in my local tree, unchecked in. And as a wish, it would be nice if libtoolize would be more verbose about mentioning that this must be added to Makefile.am if it detects that automake was in use. Cheers, Ralf * Makefile.am (AM_CPPFLAGS): Add $(LTDLINCL), so the right ltdl.h is used. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEjr3p84KuGfSFAYARAmZOAKC0aLzzT8Gbsbw+TCS6b2mg6v19ZACfV4rS 5qiSWBg/SBeC+roToc0rBGc= =kV8u -END PGP SIGNATURE- ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: include the right ltdl.h
Hello Eric, * Eric Blake wrote on Tue, Jun 13, 2006 at 03:30:17PM CEST: According to Ralf Wildenhues on 6/13/2006 3:08 AM: This patch makes sure you use the in-tree ltdl.h if necessary, thus fixing a build failure (e.g., if the ltdl.h that is found in the default paths is an old one, or none is found there). And it is a fairly old patch; you submitted the same idea several months ago, and it is still sitting in my local tree, unchecked in. And it's documented in libtool.info that this is necessary. And on my system it fixes a hard build failure, because the installed ltdl.h is from 1.5.x (and I don't intend to change that, for obvious bug exposure reasons): | libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../m4 -I. -I. -I../m4 -Ignu -I../m4/gnu -Im4 -I../m4/m4 -O2 -pipe -MT m4/module.lo -MD -MP -MF m4/.deps/module.Tpo -c ../m4/m4/module.c -fPIC -DPIC -o m4/.libs/module.o | ../m4/m4/module.c:94: error: syntax error before iface_id | ../m4/m4/module.c:94: warning: data definition has no type or storage class | ../m4/m4/module.c: In function `m4__module_next': | ../m4/m4/module.c:297: warning: return makes pointer from integer without a cast | ../m4/m4/module.c: In function `m4__module_find': | ../m4/m4/module.c:307: warning: return makes pointer from integer without a cast And as a wish, it would be nice if libtoolize would be more verbose about mentioning that this must be added to Makefile.am if it detects that automake was in use. Hmm. For now I am working on making libtoolize less verbose, i.e., killing all those possibly-wrong notices it still spits out. I'm not very keen on adding warnings; the more babble you output, the less users are inclined to read. Reading the manual instead is unobtrusive, and you have to read that section anyway if you intend to use libltdl successfully -- there are far more intricate gotchas there than the need for LTDLINCL. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool --ltdl vs. autoreconf
[ eliding bug-m4 and autoconf lists ]
Hello Eric,
* Ralf Wildenhues wrote on Thu, May 25, 2006 at 06:39:38PM CEST:
* Eric Blake wrote on Tue, May 09, 2006 at 02:04:23PM CEST:
As promised here,
http://lists.gnu.org/archive/html/m4-patches/2006-05/msg5.html, I
noticed that m4 bootstrap invokes libtoolize --ltdl prior to autoreconf,
which reinvokes libtoolize without --ltdl. This seems like a bit of a
waste of time, but when I tried removing the explicit libtoolize line, I
got a bootstrap failure that a required file, ltmain.sh, was not found. I
thought that using LT_CONFIG_LTDL_DIR in configure.ac would take care of
everything that --ltdl used to do on the command line, but I was obviously
mistaken.
Now that the issue above has been fixed, let's tackle some of the other
issues encountered here...
[...] with a pristine CVS checkout of M4, and deleting the
libtoolize invocation from `bootstrap', the aclocal call in the toplevel
will happen before libtoolize is called; since aclocal isn't called with
`--install' (well, that would work with CVS Automake aclocal only).
So, the Libtool macro files aren't in place yet, so the whole of them
ends up copied into aclocal.m4. This is then fixed after a second
bootstrap.
This is fixed already, too.
Which opens up an interesting side question: should autoreconf-2.60 be
prepared for `aclocal-1.10 --install'?
I have not looked at this yet...
Back to Libtool, the next issue is that, currently, the patch below will
cause libltdl to be copied twice: once from the toplevel dir, and once
from within the libltdl dir. This is ugly and error-prone. On the one
hand, we want `libtoolize --ltdl=.' to copy libltdl, on the other, we
don't want `libtoolize --ltdl' to copy libltdl if
`LT_CONFIG_LTDL_DIR([.])' is found; so I guess we should make libtoolize
change behavior between detected libltdl-directory `.' and passed
directory `.'. (All of this is in recursive-ltdl-mode.) I definitely
do not want to have to put more of this logic into autoreconf.
One easy way to fix this is to `autoreconf --no-recursive --ltdl' so
that autoreconf simply won't enter the directory in which the recursive
libltdl resides (see the patch I posted on m4-patches). (We may still
want to fix the issue as described above, but it's not so pressing.)
Then, currently inside a libltdl subdir, libtoolize wrongly suggests:
| libtoolize: Consider using `AC_CONFIG_AUX_DIR([./config])' in configure.ac.
| libtoolize: Consider using `AC_CONFIG_MACRO_DIR([./m4])' in configure.ac.
This is a libtoolize bug.
(First, these macros are already used, second, the arguments should not
start with `./', to cater for non-GNU make.)
To finish the sentence in parentheses: And third, libtoolize should
realize that AC_CONFIG_AUX_DIR([config]) is what is needed, and is
already present there.
These 3 issues are fixed by the patch below, which I have applied now.
You will notice that libtoolize output may seem a bit inconsistent now:
$ libtoolize --ltdl=.
| libtoolize: linking file `m4/argz.m4'
[...]
| libtoolize: linking file `./COPYING.LIB'
[...]
| libtoolize: linking file `./config/compile'
and I may eventually fix that (post 2.0). But that is not a serious
bug, if it could even be qualified as such, and the other functions in
libtoolize are sufficiently messed up that I don't care much to rewrite
them now.
Cheers,
Ralf
Fix the bugs where libtoolize needs to use `dir/file' instead of
`./dir/file', where ltdldir is `.', so that libtoolize correctly
checks for (and suggests) `config' and `m4' instead of
`./config' and `./m4' as auxiliary resp. macro directories.
The change is necessary for unambiguous naming, the chosen way
plays better with non-GNU make in VPATH builds.
* libtoolize.m4sh (ltdlprefix): New variable, to use as prefix
instead of `$ltdldir/'.
(func_check_macros): Use it. Bug report by Eric Blake.
Index: libtoolize.m4sh
===
RCS file: /cvsroot/libtool/libtool/libtoolize.m4sh,v
retrieving revision 1.55
diff -u -r1.55 libtoolize.m4sh
--- libtoolize.m4sh 12 Jun 2006 17:54:15 - 1.55
+++ libtoolize.m4sh 13 Jun 2006 18:55:32 -
@@ -904,8 +904,8 @@
func_echo and rerunning libtoolize.
fi
elif test -z $m4dir; then
- if $opt_ltdl test $ltdldir/m4 != $m4dir; then
- acmacrodir=$ltdldir/m4
+ if $opt_ltdl test ${ltdlprefix}m4 != $m4dir; then
+ acmacrodir=${ltdlprefix}m4
else
acmacrodir=$aclocaldir
fi
@@ -940,10 +940,10 @@
# Offer some suggestions for avoiding duplicate files in a project
# that uses libltdl:
- test $ltdldir/config = $auxdir ||
-func_echo Consider using \`AC_CONFIG_AUX_DIR([[$ltdldir/config]])' in
$configure_ac.
- $ac_config_macro_dir_advised || test $ltdldir/m4 = $m4dir ||
-
