[SCM] GNU Libtool branch, master, updated. v2.2.6-133-ga228f07
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project GNU Libtool. The branch, master has been updated via a228f07a8ffb9610c070203de04ea2242755a71e (commit) from 7244857f7bc0e90f52ca5b6be37652911653e654 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit a228f07a8ffb9610c070203de04ea2242755a71e Author: Charles Wilson libt...@cwilson.fastmail.fm Date: Sun Jun 28 18:50:30 2009 -0400 Finish adding alias for obsoleted AC_LIBTOOL_RC macro. * libltdl/m4/libtool.m4: Add reminder comment concerning aclocal-1.4 backwards compatibility. * libltdl/m4/lt~obsolete.m4: Remove unnecessary AC_DEFUN. --- Summary of changes: ChangeLog |8 libltdl/m4/libtool.m4 |1 + libltdl/m4/lt~obsolete.m4 |1 - 3 files changed, 9 insertions(+), 1 deletions(-) diff --git a/ChangeLog b/ChangeLog index e5b40ca..2b7ba3e 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,11 @@ +2009-06-28 Charles Wilson libt...@cwilson.fastmail.fm + + Finish adding alias for obsoleted AC_LIBTOOL_RC macro. + + * libltdl/m4/libtool.m4: Add reminder comment concerning + aclocal-1.4 backwards compatibility. + * libltdl/m4/lt~obsolete.m4: Remove unnecessary AC_DEFUN. + 2009-06-27 Charles Wilson libt...@cwilson.fastmail.fm Add alias for obsoleted AC_LIBTOOL_RC macro. diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4 index 0777d4d..1fe09d2 100644 --- a/libltdl/m4/libtool.m4 +++ b/libltdl/m4/libtool.m4 @@ -866,6 +866,7 @@ dnl AC_DEFUN([AC_LIBTOOL_CXX], []) dnl AC_DEFUN([AC_LIBTOOL_F77], []) dnl AC_DEFUN([AC_LIBTOOL_FC], []) dnl AC_DEFUN([AC_LIBTOOL_GCJ], []) +dnl AC_DEFUN([AC_LIBTOOL_RC], []) # _LT_TAG_COMPILER diff --git a/libltdl/m4/lt~obsolete.m4 b/libltdl/m4/lt~obsolete.m4 index 544ae45..bf92b5e 100644 --- a/libltdl/m4/lt~obsolete.m4 +++ b/libltdl/m4/lt~obsolete.m4 @@ -77,7 +77,6 @@ m4_ifndef([AC_DISABLE_FAST_INSTALL], [AC_DEFUN([AC_DISABLE_FAST_INSTALL])]) m4_ifndef([_LT_AC_LANG_CXX], [AC_DEFUN([_LT_AC_LANG_CXX])]) m4_ifndef([_LT_AC_LANG_F77], [AC_DEFUN([_LT_AC_LANG_F77])]) m4_ifndef([_LT_AC_LANG_GCJ], [AC_DEFUN([_LT_AC_LANG_GCJ])]) -m4_ifndef([AC_LIBTOOL_RC], [AC_DEFUN([AC_LIBTOOL_RC])]) m4_ifndef([AC_LIBTOOL_LANG_C_CONFIG], [AC_DEFUN([AC_LIBTOOL_LANG_C_CONFIG])]) m4_ifndef([_LT_AC_LANG_C_CONFIG], [AC_DEFUN([_LT_AC_LANG_C_CONFIG])]) m4_ifndef([AC_LIBTOOL_LANG_CXX_CONFIG], [AC_DEFUN([AC_LIBTOOL_LANG_CXX_CONFIG])]) hooks/post-receive -- GNU Libtool
Re: [PATCH] Add alias for obsoleted AC_LIBTOOL_RC macro.
* Charles Wilson wrote on Sat, Jun 27, 2009 at 05:40:40PM CEST:
lt~obsolete.m4 supplies only empty, non-functional aliases for old,
public libtool macros that have been removed. It currently has this:
m4_ifndef([AC_LIBTOOL_RC], [AC_DEFUN([AC_LIBTOOL_RC])])
Can that line stay, or should it be removed, now that
libltdl/m4/libtool.m4 will provide a non-empty, functional alias for
AC_LIBTOOL_RC?
It can be removed, but only if you add another line for it a few lines
below your other change in libtool.m4, at:
dnl aclocal-1.4 backwards compatibility:
dnl AC_DEFUN([AC_LIBTOOL_CXX], [])
dnl AC_DEFUN([AC_LIBTOOL_F77], [])
dnl AC_DEFUN([AC_LIBTOOL_FC], [])
dnl AC_DEFUN([AC_LIBTOOL_GCJ], [])
I dug thru the git log, but I really could not figure
out why this was put in lt~obsolete in the first place, instead of
treated like the other AC_LIBTOOL_{lang} macros...
I don't know.
Cheers,
Ralf
[PATCH] Finish adding alias for obsoleted AC_LIBTOOL_RC macro.
* libltdl/m4/libtool.m4: Add reminder comment concerning aclocal-1.4 backwards compatibility. * libltdl/m4/lt~obsolete.m4: Remove unnecessary AC_DEFUN. --- Pushed as pre-approved. -- Chuck ChangeLog |8 libltdl/m4/libtool.m4 |1 + libltdl/m4/lt~obsolete.m4 |1 - 3 files changed, 9 insertions(+), 1 deletions(-) diff --git a/ChangeLog b/ChangeLog index e5b40ca..2b7ba3e 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,11 @@ +2009-06-28 Charles Wilson libt...@cwilson.fastmail.fm + + Finish adding alias for obsoleted AC_LIBTOOL_RC macro. + + * libltdl/m4/libtool.m4: Add reminder comment concerning + aclocal-1.4 backwards compatibility. + * libltdl/m4/lt~obsolete.m4: Remove unnecessary AC_DEFUN. + 2009-06-27 Charles Wilson libt...@cwilson.fastmail.fm Add alias for obsoleted AC_LIBTOOL_RC macro. diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4 index 0777d4d..1fe09d2 100644 --- a/libltdl/m4/libtool.m4 +++ b/libltdl/m4/libtool.m4 @@ -866,6 +866,7 @@ dnl AC_DEFUN([AC_LIBTOOL_CXX], []) dnl AC_DEFUN([AC_LIBTOOL_F77], []) dnl AC_DEFUN([AC_LIBTOOL_FC], []) dnl AC_DEFUN([AC_LIBTOOL_GCJ], []) +dnl AC_DEFUN([AC_LIBTOOL_RC], []) # _LT_TAG_COMPILER diff --git a/libltdl/m4/lt~obsolete.m4 b/libltdl/m4/lt~obsolete.m4 index 544ae45..bf92b5e 100644 --- a/libltdl/m4/lt~obsolete.m4 +++ b/libltdl/m4/lt~obsolete.m4 @@ -77,7 +77,6 @@ m4_ifndef([AC_DISABLE_FAST_INSTALL], [AC_DEFUN([AC_DISABLE_FAST_INSTALL])]) m4_ifndef([_LT_AC_LANG_CXX], [AC_DEFUN([_LT_AC_LANG_CXX])]) m4_ifndef([_LT_AC_LANG_F77], [AC_DEFUN([_LT_AC_LANG_F77])]) m4_ifndef([_LT_AC_LANG_GCJ], [AC_DEFUN([_LT_AC_LANG_GCJ])]) -m4_ifndef([AC_LIBTOOL_RC], [AC_DEFUN([AC_LIBTOOL_RC])]) m4_ifndef([AC_LIBTOOL_LANG_C_CONFIG], [AC_DEFUN([AC_LIBTOOL_LANG_C_CONFIG])]) m4_ifndef([_LT_AC_LANG_C_CONFIG], [AC_DEFUN([_LT_AC_LANG_C_CONFIG])]) m4_ifndef([AC_LIBTOOL_LANG_CXX_CONFIG], [AC_DEFUN([AC_LIBTOOL_LANG_CXX_CONFIG])]) -- 1.6.1.2
[PATCH] [mingw] Improve sys_lib_search_path_spec detection.
* libltdl/m4/libtool.m4 (_LT_SYS_DYNAMIC_LINKER): Fix handling
of dos-style paths when parsing $CC -print-search-dirs output.
---
It appears that this particular behavior has been broken for quite some time.
Currently, libtool mangles $CC -print-search-dirs badly on mingw:
sys_lib_search_path_spec= =c /mingw/bin/../lib/gcc/mingw32/4.4.0-dw2/;c
/mingw/bin/../lib/gcc/;/usr/lib/gcc/mingw32/4.4.0-dw2/;c
/mingw/bin/../lib/gcc/mingw32/4.4.0-dw2/../../../../mingw32/lib/mingw32/4.4.0-dw2/;c
/mingw/bin/../lib/gcc/mingw32/4.4.0-dw2/../../../../mingw32/lib/;c
/mingw/bin/../lib/gcc/mingw32/4.4.0-dw2/../../../mingw32/4.4.0-dw2/;c
/mingw/bin/../lib/gcc/mingw32/4.4.0-dw2/../../../;/mingw/lib/mingw32/4.4.0-dw2/;/mingw/lib/
with the attached patch:
sys_lib_search_path_spec=c:/mingw/lib/gcc/mingw32/4.4.0-dw2 c:/mingw/lib/gcc
c:/mingw/mingw32/lib c:/mingw/lib /mingw/lib
Furthermore, as the old code destroyed the earlier (multilib-capable) version of
sys_lib_search_path_spec and replaced it with the broken version (line 2181
below),
by moving the special handling for dos-style paths up the the multilib-handling
area, we may -- MAY -- see some benefits with regards to mingw64/mingw32
multilib
behavior. That's just a guess, tho.
Currently running regression tests on MSYS-1.0.12 + mingw-4.4.0-dw2 (TDM
version).
OK to push, if no regressions from earlier behavior on mingw?
--
Chuck
libltdl/m4/libtool.m4 | 27 +++
1 files changed, 11 insertions(+), 16 deletions(-)
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 1fe09d2..b6862a0 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -1986,7 +1986,11 @@ if test $GCC = yes; then
darwin*) lt_awk_arg=/^libraries:/,/LR/ ;;
*) lt_awk_arg=/^libraries:/ ;;
esac
- lt_search_path_spec=`$CC -print-search-dirs | awk $lt_awk_arg | $SED -e
s/^libraries:// -e s,=/,/,g`
+ case $host_os in
+mingw* | cegcc*) lt_sed_strip_eq=s,=\([[A-Za-z]]:\),\1,g ;;
+*) lt_sed_strip_eq=s,=/,/,g ;;
+ esac
+ lt_search_path_spec=`$CC -print-search-dirs | awk $lt_awk_arg | $SED -e
s/^libraries:// -e $lt_sed_strip_eq`
case $lt_search_path_spec in
*\;*)
# if the path contains ; then we assume it to be the separator
@@ -2031,6 +2035,12 @@ BEGIN {RS= ; FS=/|\n;} {
if (lt_foo != ) { lt_freq[[lt_foo]]++; }
if (lt_freq[[lt_foo]] == 1) { print lt_foo; }
}'`
+ # AWK program above erroneously prepends '/' to C:/dos/paths
+ # for these hosts.
+ case $host_os in
+mingw* | cegcc*) lt_search_path_spec=`$ECHO $lt_search_path_spec |\
+ $SED 's,/\([[A-Za-z]]:\),\1,g'` ;;
+ esac
sys_lib_search_path_spec=`$ECHO $lt_search_path_spec | $lt_NL2SP`
else
sys_lib_search_path_spec=/lib /usr/lib /usr/local/lib
@@ -2178,21 +2188,6 @@ m4_if([$1], [],[
mingw* | cegcc*)
# MinGW DLLs use traditional 'lib' prefix
soname_spec='${libname}`echo ${release} | $SED -e
's/[[.]]/-/g'`${versuffix}${shared_ext}'
- sys_lib_search_path_spec=`$CC -print-search-dirs | $SED
'/^libraries:/!d; s///; s,=/,/,g'`
- case $sys_lib_search_path_spec in
- *\;[c-zC-Z]:*)
-# It is most probably a Windows format PATH printed by
-# mingw gcc, but we are running on Cygwin. Gcc prints its search
-# path with ; separators, and with drive letters. We can handle the
-# drive letters (cygwin fileutils understands them), so leave them,
-# especially as we might pass files found there to a mingw objdump,
-# which wouldn't understand a cygwinified path. Ahh.
-sys_lib_search_path_spec=`$ECHO $sys_lib_search_path_spec | $SED -e
's/;/ /g'`
-;;
- *)
-sys_lib_search_path_spec=`$ECHO $sys_lib_search_path_spec | $SED -e
s/$PATH_SEPARATOR/ /g`
- ;;
- esac
;;
pw32*)
# pw32 DLLs use 'pw' prefix rather than 'lib'
--
1.6.1.2
Re: [PATCH] [mingw] Improve sys_lib_search_path_spec detection.
Charles Wilson wrote: * libltdl/m4/libtool.m4 (_LT_SYS_DYNAMIC_LINKER): Fix handling of dos-style paths when parsing $CC -print-search-dirs output. --- Currently running regression tests on MSYS-1.0.12 + mingw-4.4.0-dw2 (TDM version). OK to push, if no regressions from earlier behavior on mingw? On MSYS-1.0.12 with gcc-4.4.0dw2 (TDM): = OLD: 2 of 114 tests failed (10 tests were not run) FAIL: tests/f77demo-exec.test (after f77demo-static.test) FAIL: tests/fcdemo-exec.test (after fcdemo-static.test) NOTE: in this configuration, all of the other f77 and fc tests were skipped. The real bug here is why these weren't skipped also; but I don't think it has anything to do with this patch. NEW: 82 tests behaved as expected. 6 tests were skipped. However, a lot of these were reported as expected failure because my MSYS-1.0.12 installation does not have any of the other autotools installed. So, I also ran the test suite under the older setup: On MSYS-1.0.11 with gcc-3.4.5 (mingw.org): = OLD: 4 of 106 tests failed (18 tests were not run) FAIL: tests/demo-exec.test [*] FAIL: tests/f77demo-static.test [**] FAIL: tests/f77demo-conf.test [**] FAIL: tests/f77demo-shared.test [**] [*] after demo-shared. This is fixed by one of my other recent patches. [**] these failures have been around a while on mingw. Note the missing g77.exe below: checking for Fortran 77 libraries of g77... -L/usr/lib -L/bin/../lib/gcc-lib/i686-pc-msys/2.95.3-1 -L/bin/../lib/gcc-lib -L/usr /lib/gcc-lib/i686-pc-msys/2.95.3-1 -L/bin/../lib/gcc-lib/i686-pc-msys/2.95.3-1/../../../../i686-pc-msys/lib -L/usr/lib/gcc-lib/i 686-pc-msys/2.95.3-1/../../../../i686-pc-msys/lib -lg2c -lmsys-1.0 -luser32 -lkernel32 -ladvapi32 -lshell32 checking for dummy main to link with Fortran 77 libraries... unknown So, that's something else to fix, but it's not related to this patch AFAICT. NEW: 8 failed (3 expected failures). 4 tests were skipped. 34: search-path.at:25 sys_lib_search_path libtool 71: recursive.at:60compiling softlinked libltdl libtoolize autoconf automake 72: recursive.at:80compiling copied libltdl libtoolize autoconf automake 73: recursive.at:100 installable libltdl libtoolize autoconf automake 86: cmdline_wrap.at:28 Run tests with low max_cmd_len recursive Now, 34 is ironic. However, it is because I don't have an accessible zlib installed, so naturally the link never succeeds. But, it's at least testing all the right directories: 34. search-path.at:25: testing ... libtool: link: /mingw/src/libtool/libtool-2.2.7a/libltdl/config/compile gcc -g -O2 -o .libs/main.exe main.o -Lc:/MinGW/lib/gcc/ mingw32/3.4.5 -lz c:\MinGW\bin\..\lib\gcc\mingw32\3.4.5\..\..\..\..\mingw32\bin\ld.exe: cannot find -lz collect2: ld returned 1 exit status Repeated with different -L options: -Lc:/MinGW/lib/gcc/ -LC:/MinGW/lib/gcc/ -Lc:/MinGW/mingw32/ -LC:/MinGW/mingw32/ -L/mingw/lib -Lc:/MinGW/lib - -LC:/MinGW/lib -L/lib (actually, that directory list is *wrong* -- because mingw gcc 3.4.5's specs file is wrong. It should never search /lib, that's msys stuff. But...it does: libraries: =c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/;c:/MinGW/bin/../lib/gcc/;C:/MinGW/lib/gcc/mingw32/3.4.5/;/usr/lib/gcc/mingw32 /3.4.5/;c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../mingw32/lib/mingw32/3.4.5/;c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../.. /../../mingw32/lib/;C:/MinGW/lib/gcc/mingw32/3.4.5/../../../../mingw32/lib/mingw32/3.4.5/;C:/MinGW/lib/gcc/mingw32/3.4.5/../../. ./../mingw32/lib/;/mingw/lib/mingw32/3.4.5/;/mingw/lib/;c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../mingw32/3.4.5/;c:/MinGW/b in/../lib/gcc/mingw32/3.4.5/../../../;C:/MinGW/lib/gcc/mingw32/3.4.5/../../../mingw32/3.4.5/;C:/MinGW/lib/gcc/mingw32/3.4.5/../. ./../;/lib/mingw32/3.4.5/;/lib/;/usr/lib/mingw32/3.4.5/;/usr/lib/ So, the bug there is actually in gcc-3.4.5... 71: C:\msys\1.0\local\bin\autoheader: line 159: exec: C:\msys\1.0\local\bin\autoheader-2.61: not found This is because 'the autoconf wrapper couldn't find the actual autoconf with the specified version'. It's actually a wrapper script bug. 72: same wrapper script bug. 73: ditto. 86: just a repeat of #34 above. = OK to push? -- Chuck
Re: [PATCH] [mingw] Improve sys_lib_search_path_spec detection.
Vincent Torri wrote: On MSYS-1.0.12 with gcc-4.4.0dw2 (TDM): 1.0.12 ?? There is only 1.0.11 RC (on the mingw.org wiki) afaik. Where did you get that version ? You're right. It's 1.0.11 and 1.0.10, not 1.0.12 and 1.0.11. Sorry, it's late. -- Chuck
Re: Different object lists for static and shared libraries
Hello Charles, * Charles Wilson wrote on Sun, Jun 28, 2009 at 12:54:59AM CEST: The best I could come up with is this: IN the source code for the object, do - top of file - #if defined(BUILDING_MY_LIBRARY) defined(DLL_EXPORT) stuff #endif - end of file - This way, the object is included in both the static and shared libraries, but in the former case it doesn't have any contents. Is there a better way? Not that I know of. The current code might cause the object list for the static library to be a larger set than that for the shared library (because it won't add objects compiled with -static/--tag=disable-shared to $non_pic_objects), but not vice versa; but my guess is that was only done to avoid relocation errors. With a suitably smart linker, your approach shouldn't cause a larger final shared library product, however. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Different object lists for static and shared libraries
Ralf Wildenhues wrote: * Charles Wilson wrote on Sun, Jun 28, 2009 at 12:54:59AM CEST: Is there a better way? Not that I know of. The current code might cause the object list for the static library to be a larger set than that for the shared library (because it won't add objects compiled with -static/--tag=disable-shared to $non_pic_objects), but not vice versa; but my guess is that was only done to avoid relocation errors. With a suitably smart linker, your approach shouldn't cause a larger final shared library product, however. Well, as it happens windres does not like empty files. So, I hacked up this approach: %.lo : %.rc $(LTRCCOMPILE) -i $ -o $@ $(COMPILE) -x c -c $ -o $(*D)/$(*F).o where the second line forces to recreate the static .o by using gcc to compile it as a C file (without -DRC_INVOKED), where the .rc source looks like: #if defined(RC_INVOKED) stuff #endif Since automake doesn't yet put rules for .rc files into Makefile.in, I had to do it manually anyway -- so the hack above is not TOO bad. Anyway, it seems to do the right thing. However...now I have noticed a different problem related to creating both static and shared libraries from (the same) convenience archives. I'll start a new thread. -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
Creating shared and static libraries with convenience libraries
I ran in to a problem using libtool to generate both shared and static libraries with convenience archives (on cygwin, but I believe this is cross-platform). Working with git-master xz utils, with some local patches, I saw the following: /bin/sh ../../libtool --tag=CC --mode=link gcc -std=gnu99 -Wall -Wextra -Wformat=2 -Winit-self -Wstrict-aliasing -Wfloat-equal -Wundef -Wshadow -Wpointer-arith -Wbad-function-cast -Wwrite-strings -Waggregate-return -Wstrict-prototypes -Wold-style-definition -Wmissing-prototypes -Wmissing-declarations -Wmissing-noreturn -Wredundant-decls -Werror -g -O2 -version-info 0:0:0 -no-undefined -Xlinker --output-def -Xlinker liblzma.def.in -o liblzma.la -rpath /usr/local/lib common/libcommon.la check/libcheck.la lz/liblz.la lzma/liblzma2.la rangecoder/librangecoder.la delta/libdelta.la simple/libsimple.la liblzma_w32res.lo ... link DLL Creating library file: .libs/liblzma.dll.a link static archive: libtool: link: (cd .libs/liblzma.lax/libcommon.a ar x /usr/src/packages/xz/git/_build/src/liblzma/common/.libs/libcommon.a) libtool: link: (cd .libs/liblzma.lax/libcheck.a ar x /usr/src/packages/xz/git/_build/src/liblzma/check/.libs/libcheck.a) ... Note the various convenience libraries, such as common/libcommon.la. In $build/common/ there exist a lot of .o and .lo files, while $build/common/.libs contains a lot of (other) .o files. As expected, the first set of .o's were all compiled with normal flags, while the second set were compiled with the pic flags (which for cygwin are -DDLL_EXPORT -DPIC). However, for each of those convenience archives, only a single .a is created -- e.g. $build/common/.libs/libcommon.a, and it contains only the pic .o's from $build/common/.libs/. The associated .la file looks like this: ... # The name that we can dlopen(3). dlname='' # Names of this library. library_names='' # The name of the static archive. old_library='libcommon.a' ... So, when we get around to linking the actually installable library, both the DLL and the static' archive contain the same .o's -- the ones compiled with the pic flags -DDLL_EXPORT and -DPIC. This is a problem, because now the static archive contains declspec(dllexport)-decorated symbols. (a) Is this a known issue, a new bug, or a design decision? (b) I can work around it by avoiding convenience archives entirely, and using subdir objects instead. However, I'm unsure which released automake version first *successfully* supported those...I know they were introduced in 1.9, but IIRC proper operation required a patch that wasn't merged until 1.10. Is my recollection correct? (c) longer term, if this IS a bug, then should it be fixed? How? The relevant code is a maze of twisty passages, all alike... -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Creating shared and static libraries with convenience libraries
On Sun, 28 Jun 2009, Charles Wilson wrote: So, when we get around to linking the actually installable library, both the DLL and the static' archive contain the same .o's -- the ones compiled with the pic flags -DDLL_EXPORT and -DPIC. This is a problem, because now the static archive contains declspec(dllexport)-decorated symbols. Interesting. I think that it is assumed that PIC code will work in a static archive. Apparently this is a wrong assumption for decorated DLL code. Most open source projects ported to Windows rely on GCC's automatic DLL import feature. (b) I can work around it by avoiding convenience archives entirely, and using subdir objects instead. However, I'm unsure which released automake version first *successfully* supported those...I know they were introduced in 1.9, but IIRC proper operation required a patch that wasn't merged until 1.10. Is my recollection correct? I know that I used it successfully for a large non-recursive build with subdir objects prior to 1.10 being released. That would have been when the Automake feature was still bleeding edge. Problems I noticed in those days were libtool's fault and not Automake's fault. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
