Re: [SOLVED] RE: [ANNOUNCEMENT] NEW: libtool-2.2.2-2 / Updated: libltdl7-2.2.2-2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dave Korn wrote: Uh, no, not sure what you're referring to; got a reference? http://cygwin.com/ml/cygwin/2008-04/msg00378.html Another thought occurs: does that work for cross-compilation? You can't use /usr/bin/libtool for cross-compilation (it is coded for the i686-pc-cygwin toolchain), but the above OBJDUMP patch uses AC_CHECK_TOOL, so it should be fine for configure-generated libtools. This would only apply to w32api files, yes? Yes, because lib/w32api is the only directory in the standard linker path that isn't standard to other systems. Well that certainly is a problem with lib-link.m4. Perhaps libtool should mark sys_lib_search_path_spec read-only? Or would that just cause a failure later down the line? I would think the latter. I'm testing the attached patch against 0.17. Ok, now I've got one for you :-) Got any idea why libtool isn't including the typeinfo from my shared libstdc++ when it generates the import library? (If you do have any insight into this area, we should probably start a separate thread.) Not without a .cygport and patches, together with some more details. :-) Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEUEAREIAAYFAkj3CkcACgkQpiWmPGlmQSOXuwCcD0vQxqpPviG9hec9kIDqJA2f IUQAl02HUn7oJj5LziVueql0kysd73w= =lpJm -END PGP SIGNATURE- --- origsrc/gettext-0.17/gettext-tools/misc/autopoint.in 2007-11-06 20:53:58.0 -0600 +++ src/gettext-0.17/gettext-tools/misc/autopoint.in 2008-10-12 23:14:20.306696700 -0500 @@ -294,6 +294,7 @@ 0.15 | \ 0.16 | 0.16.1 | \ 0.17 ) +ver=$version ;; *) func_fatal_error The AM_GNU_GETTEXT_VERSION declaration in your $configure_in\ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: [SOLVED] RE: [ANNOUNCEMENT] NEW: libtool-2.2.2-2 / Updated: libltdl7-2.2.2-2
Yaakov (Cygwin Ports) wrote on 13 October 2008 04:52: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dave Korn wrote: Yep, you've got it. The problem is that OBJDUMP is not set to anything, and so the regexes all fail pretty hard. And the reason that OBJDUMP is not set to anything is due to this very common idiom in GNU projects that exercise recursive makes: Actually, I hate to burst your bubble, but I think that this is not the reason. Remember that I fixed the missing OBJDUMP defines, and Chuck included those patches in 2.2.2-2 and pushed them upstream. Uh, no, not sure what you're referring to; got a reference? Hmm, I see an OBJDUMP=objdump definition near the top of usr/bin/libtool. I /thought/ I'd been using uptodate libtool to build gcc packages (I do that on my home PC and I'm at work now so can't check), but I guess I can infer that I must not have been after all; I'm absolutely certain the only problem I had was no definition of objdump (the symptoms are immediately distinguishable when you see the output running under bash -x.) Another thought occurs: does that work for cross-compilation? /usr/lib /lib/w32api /lib /usr/local/lib. However, since AM_GNU_GETTEXT (or AM_ICONV) is invariably called *after* AC_PROG_LIBTOOL/LT_INIT, the correct value is clobbered, and suddenly libtool can't find a library that the linker can. This would only apply to w32api files, yes? Thoughts? Well that certainly is a problem with lib-link.m4. Perhaps libtool should mark sys_lib_search_path_spec read-only? Or would that just cause a failure later down the line? Ok, now I've got one for you :-) Got any idea why libtool isn't including the typeinfo from my shared libstdc++ when it generates the import library? (If you do have any insight into this area, we should probably start a separate thread.) cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [SOLVED] RE: [ANNOUNCEMENT] NEW: libtool-2.2.2-2 / Updated: libltdl7-2.2.2-2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dave Korn wrote: Yep, you've got it. The problem is that OBJDUMP is not set to anything, and so the regexes all fail pretty hard. And the reason that OBJDUMP is not set to anything is due to this very common idiom in GNU projects that exercise recursive makes: Actually, I hate to burst your bubble, but I think that this is not the reason. Remember that I fixed the missing OBJDUMP defines, and Chuck included those patches in 2.2.2-2 and pushed them upstream. AFAICS, the problem is, once again, gettext. Old versions of lib-link.m4 (pre-0.12) define sys_lib_search_path_spec from config.rpath output, and for Cygwin sets it to /lib /usr/lib /usr/local/lib. (Which also happens to be the default value in libtool, and was a red herring causing me to look into libtool itself as the problem instead of something else.) But libtool-2.2 uses that variable to know where to look for libraries by default, and sets it on Cygwin to /usr/lib /lib/w32api /lib /usr/local/lib. However, since AM_GNU_GETTEXT (or AM_ICONV) is invariably called *after* AC_PROG_LIBTOOL/LT_INIT, the correct value is clobbered, and suddenly libtool can't find a library that the linker can. This explains why: 1) this happened only sporadically (not every package uses AM_GNU_GETTEXT or AM_ICONV); 2) there was a difference in behaviour between libtool generated by config.lt (with LT_OUTPUT) and the libtool generated by config.status at the end of configure (only the latter was poisoned). Now, I mentioned before that there were other such conflicts with this macro; they were fixed in gettext, but only before 0.17. Since autopoint will pull in the exact version of the macros specified in AM_GNU_GETTEXT_VERSION, not only must the gettext package be updated to 0.17, but packages need to be forced to use the newest version as well. AFAICS the possible solutions are: 1) fix each package's call to AM_GNU_GETTEXT_VERSION to 0.17; 2) change autopoint to treat the value as a minimum instead of an absolute. If the latter is possible, it would make things a lot easier than patching configure.ac every single time (although perhaps I could automate that with cygport). Thoughts? Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkjyxfoACgkQpiWmPGlmQSNeVQCfWth0mN1F5PUrer0I3K8kEKgq qzAAoLjLAXhjfrxSqGDA4UDgyRkYGtQ6 =HKnN -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[SOLVED] RE: [ANNOUNCEMENT] NEW: libtool-2.2.2-2 / Updated: libltdl7-2.2.2-2
Charles Wilson wrote on 15 April 2008 00:07:
Yaakov (Cygwin Ports) wrote:
Charles Wilson wrote:
Changes sine libtool2.2-2.2.2-1
=
o changed base package name from 'libtool2.2' to 'libtool'
o Added patches from Yaakov Selkowitz
http://cygwin.com/ml/cygwin/2008-04/msg00378.html
Do you know why I'm getting this:
*** Warning: linker path does not have real file for library -lwinmm.
g I do!
I think that libtool hasn't been told that LDFLAGS should include
-L/usr/lib/w32api.
Nope, because as we know that's always in the default search path. It's
nowt t'do wi' t'PATH setting.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libwinmm but no candidates were found. (...for file magic test)
Is it the /usr/lib/w32api location that libtool is having a hard time
with, the .a extension, or something else?
No, it's not a file type or identification problem; libtool can't find
libwinmm.a at all.
Yep, that's correct. You ever-so-nearly had it here:
FWIW:
$ ./func_win32_libid.sh /usr/lib/w32api/libwinmm.a
x86 archive import
So that's ok. (func_win32_libid.sh is just func_win32_libid() from
libtool-2.2.2-2, with the OBJDUMP/NM/etc variables set.
Spot the missing gap in the logic?
1. This works.
2. This is just func_win32_libid with some variables set.
3. Therefore func_win32_libid works.
Given that we know the conclusion is wrong, there must be a problem with the
antecedents. #1 can't be wrong, we saw it with our own eyes. So it must be
#2.
Yep, you've got it. The problem is that OBJDUMP is not set to anything, and
so the regexes all fail pretty hard. And the reason that OBJDUMP is not set
to anything is due to this very common idiom in GNU projects that exercise
recursive makes:
# Work around what appears to be a GNU make bug handling MAKEFLAGS
# values defined in terms of make variables, as is the case for CC and
# friends when we are called from the top level Makefile.
AM_MAKEFLAGS = \
AR_FLAGS=$(AR_FLAGS) \
CC_FOR_BUILD=$(CC_FOR_BUILD) \
CFLAGS=$(CFLAGS) \
CXXFLAGS=$(CXXFLAGS) \
CFLAGS_FOR_BUILD=$(CFLAGS_FOR_BUILD) \
CFLAGS_FOR_TARGET=$(CFLAGS_FOR_TARGET) \
INSTALL=$(INSTALL) \
... snip ... actual list may vary per instance ...
prefix=$(prefix) \
includedir=$(includedir) \
AR=$(AR) \
AS=$(AS) \
CC=$(CC) \
CXX=$(CXX) \
LD=$(LD) \
LIBCFLAGS=$(LIBCFLAGS) \
NM=$(NM) \
PICFLAG=$(PICFLAG) \
RANLIB=$(RANLIB) \
DESTDIR=$(DESTDIR)
Notice anything missing? :-) The answer is simple enough: add a couple of
lines that read:
OBJDUMP=$(OBJDUMP) \
OBJDUMP_FOR_TARGET=$(OBJDUMP_FOR_TARGET) \
somewhere in there (I put them after NM myself but it's of no functional
relevance) in the Makefile.am, regenerate the Makefile.in, and you're away.
Chuck, it's not a libtool bug, but there might be something worth doing
upstream: since this happens a lot in GNU software, it might be a courtesy to
replace the reference to $OBJDUMP in func_win32_libid with something else
roughly along the lines of ${OBJDUMP:-echo 'Objdump not defined'; false}
(which won't work as-is owing to the output redirections in place, but YKWIM:
something that emits an error and fails/bails).
cheers,
DaveK
--
Can't think of a witty .sigline today
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] NEW: libtool-2.2.2-2 / Updated: libltdl7-2.2.2-2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Yaakov (Cygwin Ports) wrote: | This package had AM_GNU_GETTEXT in configure.ac without any arguments | nor AM_GNU_GETTEXT_VERSION. autoreconf decided not using Gettext[1] | and didn't install config.rpath[2]. But AC_LIB_RPATH (from the included | gettext-0.11.2 lib-link.m4) was called; while nothing happened due to | the missing config.rpath, it then defined libext=$acl_cv_libext, which | had never been defined. This empty $libext clobbered that of libtool. This is worse than I originally thought. AM_ICONV also calls AC_LIB_RPATH. I got yet another broken libtool, this time with a unsupported hardcode properties error. Here's why: a different package shipped with a 0-byte config.rpath, which obviously didn't do much. But the real problem is with AC_LIB_RPATH itself. In 0.15, it defines the following: wl=$acl_cv_wl libext=$acl_cv_libext shlibext=$acl_cv_shlibext hardcode_libdir_flag_spec=$acl_cv_hardcode_libdir_flag_spec hardcode_libdir_separator=$acl_cv_hardcode_libdir_separator hardcode_direct=$acl_cv_hardcode_direct hardcode_minus_L=$acl_cv_hardcode_minus_L Except for shlibext, all of the above variables can conflict with variables by the same name in libtool. If the config.rpath call doesn't succeed (usually because it's nonexistant), all of these variables are blank, which then clobbers the variables previously set by libtool. While each of these cases should be fixed within the package, I think the only *safe* answer is that: 1) libtool MUST protect its variables; 2) AC_LIB_RPATH should check that there was actually a result from config.rpath before proceeding. (And I would still patch shrext=dll.a as you suggested.) One thing I don't understand: if you call LT_OUTPUT (which generates an unclobbered libtool), isn't 'config.status libtool' supposed to use config.lt to generate libtool, which should avoid these problems? | [2] lib-link.m4 0.15 adds a line telling automake = 1.10 that | config.rpath is required, but this package was using 1.9. In any case, | this macro was from 0.11.2, which preceded automake-1.10. Lots of good that did me here, as the file was present but blank. :-( Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkgf6JcACgkQpiWmPGlmQSMolwCgiEIu5ZMjD1dulA+6uix60pTm 2j0An3ogNN7lFh0Sw8rvtmwJFrOtWO+I =DHry -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] NEW: libtool-2.2.2-2 / Updated: libltdl7-2.2.2-2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Chuck, Here's yet another interesting case with libtool-2.2: /bin/sh ../../libtool --tag=CXX --mode=link g++ -O2 -pipe-o libfoo-1.2.la -rpath /usr/lib -no-undefined sources.lo libtool: link: rm -fr .libs/libfoo-1.2.dll.a .libs/libfoo-1.2.la .libs/libfoo-1.2.lai libtool: link: g++ -shared -nostdlib .libs/sources.o - -L/usr/lib/gcc/i686-pc-cygwin/3.4.4 - -L/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../.. -lstdc++ -lgcc -lcygwin - -luser32 -lkernel32 -ladvapi32 -lshell32 -lgcc -o .libs/cygfoo-1.2-0.dll -Wl,--enable-auto-image-base -Xlinker - --out-implib -Xlinker .libs/libfoo-1.2.dll.a Creating library file: .libs/libfoo-1.2.dll.a libtool: link: ar cru .libs/libfoo-1.2. sources.o libtool: link: ranlib .libs/libfoo-1.2. libtool: link: ( cd .libs rm -f libfoo-1.2.la ln -s ../libfoo-1.2.la libfoo-1.2.la ) In this specific case, the static library is missing the .a extension (Windows ignores the final dot, as usual). Here's why: This package had AM_GNU_GETTEXT in configure.ac without any arguments nor AM_GNU_GETTEXT_VERSION. autoreconf decided not using Gettext[1] and didn't install config.rpath[2]. But AC_LIB_RPATH (from the included gettext-0.11.2 lib-link.m4) was called; while nothing happened due to the missing config.rpath, it then defined libext=$acl_cv_libext, which had never been defined. This empty $libext clobbered that of libtool. In this case, the solution was simply to call AM_GNU_GETTEXT_VERSION. But this is the second case where libtool's had its variables clobbered by other parts of configure. Could something be done to make sure that that can't happen? Yaakov [1] autoreconf decided not using Gettext because it looks solely for AM_GNU_GETTEXT_VERSION to make that determination. (It only looks for AM_GNU_GETTEXT to see if one of these two is used without the other, and emits a warning if so.) [2] lib-link.m4 0.15 adds a line telling automake = 1.10 that config.rpath is required, but this package was using 1.9. In any case, this macro was from 0.11.2, which preceded automake-1.10. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkgRC2sACgkQpiWmPGlmQSPDkwCfdkU3rN1Ul1YYm6yhebClVyDg Eu0AoO+O803peOIDxLD4RFEKNIWRHvyi =mGuQ -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] NEW: libtool-2.2.2-2 / Updated: libltdl7-2.2.2-2
Charles Wilson wrote: Yaakov (Cygwin Ports) wrote: ./.libs/lt-foo.c:263: warning: string length `4368' is greater than the length `4095' ISO C99 compilers are required to support This one can be fixed by splitting the string into two pieces. I'm working on a patch for that. ./.libs/lt-foo.c: In function `main': ./.libs/lt-foo.c:288: warning: implicit declaration of function `_setmode' This one is already fixed in current git. ./.libs/lt-foo.c: In function `chase_symlinks': ./.libs/lt-foo.c:577: warning: implicit declaration of function `realpath' ./.libs/lt-foo.c:577: warning: assignment makes pointer from integer without a cast These two are the same issue... (1) realpath() is invoked in a section of code that is #ifdef __CYGWIN__ (2) the wrapper source code unconditionally #includes stdlib.h (3) cygwin's stdlib.h declares realpath. ...but it does so inside a #ifndef __STRICT_ANSI__ block. And -std=c99 turns on __STRICT_ANSI__, while -std=gnu99 does not. Posix says that realpath() will be declared if #include stdlib.h Ansi says nothing about realpath(), so STRICT_ANSI requires that realpath is NOT declared when #include stdlib.h I guess the cwrapper should add a section like this, for __CYGWIN__ #if defined __CYGWIN__ # if defined __STRICT_ANSI__ char *realpath (const char *, char *); # endif #endif NOTE: usually you *want* the cwrapper to be compiled with the same CFLAGS that your target application needs. OTOH, if you explicitly set your compatibility flags (-c99, _POSIX_C_SOURCE=200112L, -ansi, etc) too low it is possible something's going to break. Or some pathological project could put '-Dprintf=exit' into CFLAGS. You can't guard against everything. But we ought to be compatible with c99. -- Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] NEW: libtool-2.2.2-2 / Updated: libltdl7-2.2.2-2
Yaakov (Cygwin Ports) wrote: * libtool should catch if the lt-foo.c compile fails; Yes. I haven't tracked this one down yet. I think I have also found a separate case of breakage when the CXX tag is enabled, in which case LTCC is mysteriously undefined. The results: ./libtool: line 7737: -O2: command not found strip: './foo.exe': No such file ./libtool: line 7748: $func_ltwrapper_scriptname_result: ambiguous redirect Well, that's not enough information at all. The c++ tests all pass, so I'm going to need a testcase or at least the actual project you're building that gives this error. -- Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] NEW: libtool-2.2.2-2 / Updated: libltdl7-2.2.2-2
Yaakov (Cygwin Ports) wrote: Here's yet another interesting case with libtool-2.2: interesting, as in may you live in interesting times? /bin/sh ../../libtool --tag=CXX --mode=link g++ -O2 -pipe-o libfoo-1.2.la -rpath /usr/lib -no-undefined sources.lo libtool: link: rm -fr .libs/libfoo-1.2.dll.a .libs/libfoo-1.2.la .libs/libfoo-1.2.lai libtool: link: g++ -shared -nostdlib .libs/sources.o -L/usr/lib/gcc/i686-pc-cygwin/3.4.4 -L/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../.. -lstdc++ -lgcc -lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32 -lgcc -o .libs/cygfoo-1.2-0.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker .libs/libfoo-1.2.dll.a Creating library file: .libs/libfoo-1.2.dll.a libtool: link: ar cru .libs/libfoo-1.2. sources.o libtool: link: ranlib .libs/libfoo-1.2. libtool: link: ( cd .libs rm -f libfoo-1.2.la ln -s ../libfoo-1.2.la libfoo-1.2.la ) In this specific case, the static library is missing the .a extension (Windows ignores the final dot, as usual). Here's why: This package had AM_GNU_GETTEXT in configure.ac without any arguments nor AM_GNU_GETTEXT_VERSION. autoreconf decided not using Gettext[1] [1] autoreconf decided not using Gettext because it looks solely for AM_GNU_GETTEXT_VERSION to make that determination. (It only looks for AM_GNU_GETTEXT to see if one of these two is used without the other, and emits a warning if so.) Looks like a gettext bug to me. Might be fixed in 0.16+, but please report upstream. and didn't install config.rpath[2]. [2] lib-link.m4 0.15 adds a line telling automake = 1.10 that config.rpath is required, but this package was using 1.9. In any case, this macro was from 0.11.2, which preceded automake-1.10. That's bizarre. Also, I believe that config.rpath may have a bug: --- config.rpath2008-04-16 03:59:54.87500 -0400 +++ config.rpath2008-04-16 04:00:04.546875000 -0400 @@ -501,7 +501,7 @@ bsdi[45]*) ;; cygwin* | mingw* | pw32*) -shrext=.dll +shrext=.dll.a ;; darwin* | rhapsody*) shrext=.dylib because the result of config.rpath is used to probe /usr/lib, not /usr/bin...BUT shrext is a widely used variable, and is not namespaced. No telling WHAT that change might break, which is why I haven't reported this as a bug. But I did have to impose that patch in the alternatives cygport, because otherwise I was forced to link statically to libintl and libiconv. Also, 'alternatives' is a wierd case -- I had to hack it to death since it's not actually a package of its own; it's really 'chkconfig'. So I decided not to draw any wide-ranging conclusions about config.rpath from any issues involving the alternative package. But AC_LIB_RPATH (from the included gettext-0.11.2 lib-link.m4) was called; while nothing happened due to the missing config.rpath, it then defined libext=$acl_cv_libext, which had never been defined. This empty $libext clobbered that of libtool. In this case, the solution was simply to call AM_GNU_GETTEXT_VERSION. But this is the second case where libtool's had its variables clobbered by other parts of configure. Could something be done to make sure that that can't happen? You don't want much, do you? This is a apparently not a libtool-2.2 issue; if gettext is broken or invoked incorrectly, AND shares some variables in the same namespace as libtool, AND clobbers them...the only thing that can be done there is to ensure that libtool never ever uses any variables outside the lt_ namespace. There's been a lot of work done to try to make libtool namespace clean and insensitive to variables outside lt_ -- but there's still quite a bit to be done. One of the problems is the .la file format is fixed, and the variables there are *not* in the lt_ namespace; there's no help for that, except a format change. -- Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] NEW: libtool-2.2.2-2 / Updated: libltdl7-2.2.2-2
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Charles Wilson wrote:
| Well, that's not enough information at all. The c++ tests all pass, so
| I'm going to need a testcase or at least the actual project you're
| building that gives this error.
.cygport attached, as well as the diff between the libtools generated by
config.lt and config.status. Let me know if you need more info.
Yaakov
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEAREIAAYFAkgRVN8ACgkQpiWmPGlmQSMq/QCfRLGUBl4McJLhETHVo1tjIAxp
weMAoJ36OFitVIgZP2Bd2Qc8I3qAKNWS
=64qn
-END PGP SIGNATURE-
--- libtool-1 2008-04-24 22:42:28.046875000 -0500
+++ libtool-2 2008-04-24 22:41:52.609375000 -0500
@@ -1,7 +1,7 @@
#! /bin/sh
# libtool - Provide generalized library-building support services.
-# Generated automatically by config.lt (xapian-core) 1.0.6
+# Generated automatically by config.status (xapian-core) 1.0.6
# Libtool was configured on host YAAKOV03:
# NOTE: Changes made to this file will be lost: look at ltmain.sh.
#
@@ -34,7 +34,7 @@
# The names of the tagged configurations supported by this script.
-available_tags=
+available_tags=CXX
# ### BEGIN LIBTOOL CONFIG
@@ -129,7 +129,7 @@
old_postuninstall_cmds=
# A C compiler.
-LTCC=gcc
+LTCC=
# LTCC compiler flags.
LTCFLAGS=-O2 -pipe
@@ -391,6 +391,20 @@
# How to hardcode a shared library path into an executable.
hardcode_action=immediate
+# The directories searched by this compiler when creating a shared library.
+compiler_lib_search_dirs=
+
+# Dependencies to place before and after the objects being linked to
+# create a shared library.
+predep_objects=
+postdep_objects=
+predeps=
+postdeps=
+
+# The library search path used internally by the compiler when linking
+# a shared library.
+compiler_lib_search_path=
+
# ### END LIBTOOL CONFIG
# Generated from ltmain.m4sh.
@@ -8276,3 +8290,158 @@
# End:
# vi:sw=2
+
+# ### BEGIN LIBTOOL TAG CONFIG: CXX
+
+# The linker used to build libraries.
+LD=/usr/i686-pc-cygwin/bin/ld.exe
+
+# Commands used to build an old-style archive.
+old_archive_cmds=\$AR \$AR_FLAGS \$oldlib\$oldobjs~\$RANLIB \$oldlib
+
+# A language specific compiler.
+CC=g++
+
+# Is the compiler the GNU compiler?
+with_gcc=yes
+
+# Compiler flag to turn off builtin functions.
+no_builtin_flag= -fno-builtin
+
+# How to pass a linker flag through the compiler.
+wl=-Wl,
+
+# Additional compiler flags for building library objects.
+pic_flag= -DDLL_EXPORT -DPIC
+
+# Compiler flag to prevent dynamic linking.
+link_static_flag=-static
+
+# Does compiler simultaneously support -c and -o options?
+compiler_c_o=yes
+
+# Whether or not to add -lc for building shared libraries.
+build_libtool_need_lc=no
+
+# Whether or not to disallow shared libs when runtime libs are static.
+allow_libtool_libs_with_static_runtimes=yes
+
+# Compiler flag to allow reflexive dlopens.
+export_dynamic_flag_spec=\${wl}--export-dynamic
+
+# Compiler flag to generate shared objects directly from archives.
+whole_archive_flag_spec=\${wl}--whole-archive\$convenience
\${wl}--no-whole-archive
+
+# Whether the compiler copes with passing no objects directly.
+compiler_needs_object=no
+
+# Create an old-style archive from a shared archive.
+old_archive_from_new_cmds=
+
+# Create a temporary old-style archive to link instead of a shared archive.
+old_archive_from_expsyms_cmds=
+
+# Commands used to build a shared archive.
+archive_cmds=\$CC -shared -nostdlib \$predep_objects \$libobjs \$deplibs
\$postdep_objects \$compiler_flags -o \$output_objdir/\$soname
\${wl}--enable-auto-image-base -Xlinker --out-implib -Xlinker \$lib
+archive_expsym_cmds=if test \\\x\\\`\$SED 1q \$export_symbols\\\`\\\ =
xEXPORTS; then
+ cp \$export_symbols \$output_objdir/\$soname.def;
+ else
+ echo EXPORTS \$output_objdir/\$soname.def;
+ cat \$export_symbols \$output_objdir/\$soname.def;
+ fi~
+ \$CC -shared -nostdlib \$output_objdir/\$soname.def \$predep_objects
\$libobjs \$deplibs \$postdep_objects \$compiler_flags -o
\$output_objdir/\$soname \${wl}--enable-auto-image-base -Xlinker --out-implib
-Xlinker \$lib
+
+# Commands used to build a loadable module if different from building
+# a shared archive.
+module_cmds=
+module_expsym_cmds=
+
+# Whether we are building with GNU ld or not.
+with_gnu_ld=yes
+
+# Flag that allows shared libraries with undefined symbols to be built.
+allow_undefined_flag=unsupported
+
+# Flag that enforces no undefined symbols.
+no_undefined_flag=
+
+# Flag to hardcode $libdir into a binary during linking.
+# This must work even if $libdir does not exist
+hardcode_libdir_flag_spec=-L\$libdir
+
+# If ld is used when linking, flag to hardcode $libdir into a binary
+# during linking. This must work even if $libdir does not exist.
+hardcode_libdir_flag_spec_ld=
+
+# Whether we need a single -rpath flag with a separated argument.
Re: [ANNOUNCEMENT] NEW: libtool-2.2.2-2 / Updated: libltdl7-2.2.2-2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Charles Wilson wrote: | Looks like a gettext bug to me. Might be fixed in 0.16+, but please | report upstream. I'll admit I'm not that fluent in gettext internals. Obviously both macros are supposed to be present; is having only one just old behaviour, or simply broken? | That's bizarre. Also, I believe that config.rpath may have a bug: | | -shrext=.dll | +shrext=.dll.a | | because the result of config.rpath is used to probe /usr/lib, not | /usr/bin...BUT shrext is a widely used variable, and is not namespaced. | No telling WHAT that change might break, which is why I haven't | reported this as a bug. But I did have to impose that patch in the | alternatives cygport, because otherwise I was forced to link statically | to libintl and libiconv. Trust me, I've always found this extremely annoying. The alternative (no pun intended) is to use $(LTLIBINTL) instead of $(LIBINTL), but that can require a lot of Makefile patching. Fixing this would be a blessing. AFAICS there shouldn't be any namespacing problems with shrext, because config.rpath is run as a script, not sourced as a macro; the value is exported as acl_cv_shlibext. So I'd say, go for it. | You don't want much, do you? Of course I do. :-) | This is a apparently not a libtool-2.2 issue; if gettext is broken or | invoked incorrectly, AND shares some variables in the same namespace as | libtool, AND clobbers them...the only thing that can be done there is to | ensure that libtool never ever uses any variables outside the lt_ | namespace. | | There's been a lot of work done to try to make libtool namespace clean | and insensitive to variables outside lt_ -- but there's still quite a | bit to be done. One of the problems is the .la file format is fixed, | and the variables there are *not* in the lt_ namespace; there's no help | for that, except a format change. OK, but libext is not exported to the .la file. Being that libext keeps getting clobbered in different ways, I would look into namespacing it if at all possible. Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkgRXFwACgkQpiWmPGlmQSPCWwCfXDH5Fj5vN1h4dQU9X37O+Emr YREAn3Zk+B7z+m9odHCxf7LWeT08UyyJ =i2LD -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] NEW: libtool-2.2.2-2 / Updated: libltdl7-2.2.2-2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Charles Wilson wrote: | That was fixed in libtool CVS after 2.2.2 was released: | http://lists.gnu.org/archive/html/libtool-patches/2008-04/msg00019.html | but this release is 'stock' libtool-2.2.2 with only your patches. I'm not sure what's triggering this, but *sometimes* I'm getting more than that: ./.libs/lt-foo.c:263: warning: string length `4368' is greater than the length `4095' ISO C99 compilers are required to support ./.libs/lt-foo.c: In function `main': ./.libs/lt-foo.c:288: warning: implicit declaration of function `_setmode' ./.libs/lt-foo.c: In function `chase_symlinks': ./.libs/lt-foo.c:577: warning: implicit declaration of function `realpath' ./.libs/lt-foo.c:577: warning: assignment makes pointer from integer without a cast strip: './foo.exe': No such file When this does happen, the libtool launchers 'foo' and 'foo.exe' are NOT created in the build directory, but the real executable .libs/foo.exe is built. Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkgPsroACgkQpiWmPGlmQSOrRACdGr3iBUSF+KVg813/0M78viI2 2GYAoKVkVJnkhy641kx6uVQxYGvaO7VM =OnNU -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] NEW: libtool-2.2.2-2 / Updated: libltdl7-2.2.2-2
Yaakov (Cygwin Ports) wrote: I'm not sure what's triggering this, but *sometimes* I'm getting more than that: ./.libs/lt-foo.c:263: warning: string length `4368' is greater than the length `4095' ISO C99 compilers are required to support ./.libs/lt-foo.c: In function `main': ./.libs/lt-foo.c:288: warning: implicit declaration of function `_setmode' ./.libs/lt-foo.c: In function `chase_symlinks': ./.libs/lt-foo.c:577: warning: implicit declaration of function `realpath' ./.libs/lt-foo.c:577: warning: assignment makes pointer from integer without a cast What's puzzling is there is no *error* message from the compiler -- just warnings. strip: './foo.exe': No such file But obviously something went wrong. I wonder of the string length warning is from the pre-processor, and then the compiler itself dies (dumps core?) without issuing an error message. Does the problem -- missing wrappers -- *always* occur paired with the string length warning? I can easily see the following; (1) the size of the wrapper script is very close to 4K (2) there are several embedded paths (3) sometimes, those paths are long enough to push the total script length over 4K -- and gcc-3.4.x is rude enough to fail silently. If so, I could easily split the the script generation into two separate strings... -- Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] NEW: libtool-2.2.2-2 / Updated: libltdl7-2.2.2-2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Charles Wilson wrote: | What's puzzling is there is no *error* message from the compiler -- just | warnings. | | strip: './foo.exe': No such file | | But obviously something went wrong. | | I wonder of the string length warning is from the pre-processor, and | then the compiler itself dies (dumps core?) without issuing an error | message. | | Does the problem -- missing wrappers -- *always* occur paired with the | string length warning? I can easily see the following; | (1) the size of the wrapper script is very close to 4K | (2) there are several embedded paths | (3) sometimes, those paths are long enough to push the total script | length over 4K -- and gcc-3.4.x is rude enough to fail silently. | If so, I could easily split the the script generation into two separate | strings... OK, I figured it out: libtool-2.2 adds CFLAGS to LTCFLAGS, which it uses to compile the lt-foo.c files. Many configure scripts add to CFLAGS, but usually after all the standard initializations. With 1.5, or with 2.2 and LT_OUTPUT, libtool would be generated before CFLAGS is altered beyond the default (-O2 -pipe with cygport). But with 2.2 without LT_OUTPUT, the package CFLAGS are added to LTCFLAGS, sometimes with disastrous consequences. The broken case was being compiled with the following CFLAGS: CFLAGS = ... -Wall -Werror -pedantic -std=c99 -D_POSIX_C_SOURCE=200112L * -Wall produces the _setmode warning; * -std=c99 produces the realpath and ptr2int warnings; * -pedantic produces the string length warning; * -Werror makes sure that the build fails, but libtool doesn't catch it. This is definitely a regression from 1.5, the problems being: * libtool should generate lt-foo.c files without warnings, or at least compile it with sane CFLAGS that work no matter what. * libtool should catch if the lt-foo.c compile fails; I think I have also found a separate case of breakage when the CXX tag is enabled, in which case LTCC is mysteriously undefined. The results: ./libtool: line 7737: -O2: command not found strip: './foo.exe': No such file ./libtool: line 7748: $func_ltwrapper_scriptname_result: ambiguous redirect Hopefully this gives you enough to figure out where these bugs really are. Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkgQEz4ACgkQpiWmPGlmQSMlCACcCUE3QzUDDTl1cgpeRQOIPhMf N4gAoNCWgSfvzFeCu7YqtqqYJROcy46L =cdxV -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] NEW: libtool-2.2.2-2 / Updated: libltdl7-2.2.2-2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Charles Wilson wrote: | Changes sine libtool2.2-2.2.2-1 | = I'm also seeing these warnings (where 'foo' is the executable being linked against a yet-uninstalled libtool library): ./.libs/lt-foo.c: In function `main': ./.libs/lt-foo.c:288: warning: implicit declaration of function `_setmode' ./.libs/lt-foo.c:288: warning: nested extern declaration of `_setmode' Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIBEWspiWmPGlmQSMRCICoAKDfm4XnxQYfrtX5K33uGXe7/wRZWgCcCQeJ uDgAASd1HHxPHP10WVa5K3c= =OTul -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] NEW: libtool-2.2.2-2 / Updated: libltdl7-2.2.2-2
Yaakov (Cygwin Ports) wrote: Charles Wilson wrote: | I think that libtool hasn't been told that LDFLAGS should include | -L/usr/lib/w32api. I think this is something that should be passed on | the invocation line in your makefile -- maybe AM_LDFLAGS needs to be set? As I'm sure you're aware, /usr/lib/w32api is in ld's default library path, so -L/usr/lib/w32api should never be necessary. unless -nostdlib, right? Which libtool uses. Besides, I don't know of a way to get ld to print its search path (which is why Brian grep'ed the binary) like gcc's -print-search-dirs. So libtool has no mechanism to obtain this info -- other than hardcoded variables like sys_lib_search_path_spec. And libtool needs this info, obviously, because it does this 'pre-screening' stuff on dependencies -- is it a static archive, is it this, is it that, etc -- so it has to know where to look. But you're right: it IS hardcoded, so what ld or gcc thinks is immaterial. Nor was it required with libtool-1.5; this is a regression, but I'm not sure what the cause is. In /usr/bin/libtool, I see the following: sys_lib_search_path_spec=/usr/lib /lib/w32api /lib /usr/local/lib which is hard-coded for cygwin in _LT_SYS_DYNAMIC_LINKER (prev. AC_LIBTOOL_SYS_DYNAMIC_LINKER). But with the libtool script in the package I'm trying to build, I find: sys_lib_search_path_spec=/lib /usr/lib /usr/local/lib this is the default setting of sys_lib_search_path_spec, established at the beginning of _LT_SYS_DYNAMIC_LINKER. However, as you point out, sys_lib_search_path_spec is a tagged variable... I wonder if there is some interaction here between tag support/order of invocation of the tag declarators -- LT_LANG(lang) or AC_PROG_lang, compared to when LT_OUTPUT is called. Both of the following examples are therefore valid ways of adding C++ language support to Libtool. LT_INIT LT_LANG([C++]) LT_INIT AC_PROG_CXX This didn't happen in another package, so I dug a bit further. If I run ./config.lt in this particular package, then the correct $sys_lib_search_path_spec appears, but when I run './config.status libtool', then I get the latter. Well, ordinarily you don't GET a config.lt file -- that is produced only when you use LT_OUTPUT. The bug is: Also, when `LT_OUTPUT' is used, for backwards compatibility with Automake regeneration rules, `config.status' will call `config.lt' to regenerate `libtool', rather than generating the file itself. So, 'config.status libtool' ought to delegate to config.lt in your case, which should, in a sane world, generate the same libtool script as calling config.lt directly. Either your config.status is NOT delegating to config.lt, or...the world's gone MAD. (Or maybe config.status is mucking up the environment before calling config.lt...) Both packages use CC and CXX tags, and but the one that works correctly had warnings during autoreconf: configure.ac:169: warning: LT_OUTPUT was called before LT_LANG /usr/share/aclocal/libtool.m4:775: LT_LANG is expanded from... configure.ac:169: the top level /usr/share/aclocal/libtool.m4:5282: _LT_PROG_CXX is expanded from... /usr/share/aclocal/libtool.m4:5305: _LT_LANG_CXX_CONFIG is expanded from... /usr/share/aclocal/libtool.m4:792: _LT_LANG is expanded from... autoreconf-2.61: configure.ac: tracing configure.ac:169: warning: LT_OUTPUT was called before LT_LANG aclocal.m4:790: LT_LANG is expanded from... configure.ac:169: the top level where the package with the buggy libtool had no such warnings. 1) do both packages use LT_OUTPUT 2) does either package explicitly call AC_PROG_CXX/LT_LANG([C++]) 3) if so, when? before LT_INIT, before LT_OUTPUT, or after? Somehow, the buggy version is NOT initializing sys_lib_search_path_spec to the proper value for this arch+tag; instead, it's using the default value for all arch and all tags. Any ideas? -- Macro: LT_OUTPUT ... You can add `LT_OUTPUT' to your `configure.ac' any time after `LT_INIT' and any `LT_LANG' calls; that done, `libtool' will be created by a specially generated `config.lt' file, and available for use in later tests. Make sure LT_LANG calls (*and* AC_PROG_lang ?) appear after LT_INIT but before LT_OUTPUT ? -- Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] NEW: libtool-2.2.2-2 / Updated: libltdl7-2.2.2-2
Yaakov (Cygwin Ports) wrote: Charles Wilson wrote: | Changes sine libtool2.2-2.2.2-1 | = I'm also seeing these warnings (where 'foo' is the executable being linked against a yet-uninstalled libtool library): ./.libs/lt-foo.c: In function `main': ./.libs/lt-foo.c:288: warning: implicit declaration of function `_setmode' ./.libs/lt-foo.c:288: warning: nested extern declaration of `_setmode' That was fixed in libtool CVS after 2.2.2 was released: http://lists.gnu.org/archive/html/libtool-patches/2008-04/msg00019.html but this release is 'stock' libtool-2.2.2 with only your patches. -- Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] NEW: libtool-2.2.2-2 / Updated: libltdl7-2.2.2-2
Charles Wilson wrote: way to get ld to print its search path (which is why Brian grep'ed the binary) like gcc's -print-search-dirs. So libtool has no mechanism to I grepped the default linker script which is a plain text file. This can be done programmatically by adding -Wl,-verbose to a test link which prints the output of the linker script used. Note that the linker script used depends on the linker options, but I don't think libtool supports relocatable links (-r) or anything exotic like that so it shouldn't matter; and in any case all the stock PE linker scripts have the same SEARCH_DIRs at the top. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[ANNOUNCEMENT] NEW: libtool-2.2.2-2 / Updated: libltdl7-2.2.2-2
GNU libtool is a generic library support script. Libtool hides the complexity of using shared libraries behind a consistent, portable interface. This update represents a name change from the previous 'libtool2.2' package, to the new 'libtool' package (the embedded version number '2.2' has been dropped). This is a TEST release, and is only available by choosing the 'test' version from setup's chooser menu. Normally, 'test' releases are not announced in this manner. However, this one replaces and obsoletes an existing, non-test package (libtool2.2), so the announcement is appropriate. Both the (now obsolete) libtool2.2 package and the new libtool package (at least, the ones derived from libtool-2.2 source) provide a libltdl7 subpackage, which is why that package is 'updated' and not 'new'. Note that both libltdl3 (from the libtool-1.5.x series) and libltdl7 (from this libtool-2.2.x series) can be installed at the same time, without conflict. Changes sine libtool2.2-2.2.2-1 = o changed base package name from 'libtool2.2' to 'libtool' o Added patches from Yaakov Selkowitz http://cygwin.com/ml/cygwin/2008-04/msg00378.html -- Chuck To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: [EMAIL PROTECTED] If you need more information on unsubscribing, start reading here: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] NEW: libtool-2.2.2-2 / Updated: libltdl7-2.2.2-2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Charles Wilson wrote: | Changes sine libtool2.2-2.2.2-1 | = | o changed base package name from 'libtool2.2' to 'libtool' | o Added patches from Yaakov Selkowitz | http://cygwin.com/ml/cygwin/2008-04/msg00378.html Do you know why I'm getting this: *** Warning: linker path does not have real file for library -lwinmm. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libwinmm but no candidates were found. (...for file magic test) Is it the /usr/lib/w32api location that libtool is having a hard time with, the .a extension, or something else? Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIA6pHpiWmPGlmQSMRCNhlAJ974LK/Ca4TnIYWNgq2bX2a9JVSZACcCMMf 5GycY0mZt9zNB/o3Us0DngU= =Irvq -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] NEW: libtool-2.2.2-2 / Updated: libltdl7-2.2.2-2
Yaakov (Cygwin Ports) wrote:
Charles Wilson wrote:
| Changes sine libtool2.2-2.2.2-1
| =
| o changed base package name from 'libtool2.2' to 'libtool'
| o Added patches from Yaakov Selkowitz
| http://cygwin.com/ml/cygwin/2008-04/msg00378.html
Do you know why I'm getting this:
*** Warning: linker path does not have real file for library -lwinmm.
I think that libtool hasn't been told that LDFLAGS should include
-L/usr/lib/w32api. I think this is something that should be passed on
the invocation line in your makefile -- maybe AM_LDFLAGS needs to be set?
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libwinmm but no candidates were found. (...for file magic test)
Is it the /usr/lib/w32api location that libtool is having a hard time
with, the .a extension, or something else?
No, it's not a file type or identification problem; libtool can't find
libwinmm.a at all.
FWIW:
$ ./func_win32_libid.sh /usr/lib/w32api/libwinmm.a
x86 archive import
So that's ok. (func_win32_libid.sh is just func_win32_libid() from
libtool-2.2.2-2, with the OBJDUMP/NM/etc variables set.
--
Chuck
#!/bin/bash
ECHO=echo
OBJDUMP=objdump
EGREP=grep -E
SED=sed
NM=nm
func_win32_libid ()
{
$opt_debug
win32_libid_type=unknown
win32_fileres=`file -L $1 2/dev/null`
case $win32_fileres in
*ar\ archive\ import\ library*) # definitely import
win32_libid_type=x86 archive import
;;
*ar\ archive*) # could be an import, or static
if eval $OBJDUMP -f $1 | $SED -e '10q' 2/dev/null |
$EGREP 'file format pe-i386(.*architecture: i386)?' /dev/null ; then
win32_nmres=`eval $NM -f posix -A $1 |
$SED -n -e '
1,100{
/ I /{
s,.*,import,
p
q
}
}'`
case $win32_nmres in
import*) win32_libid_type=x86 archive import;;
*)win32_libid_type=x86 archive static;;
esac
fi
;;
*DLL*)
win32_libid_type=x86 DLL
;;
*executable*) # but shell scripts are executable too...
case $win32_fileres in
*MS\ Windows\ PE\ Intel*)
win32_libid_type=x86 DLL
;;
esac
;;
esac
$ECHO $win32_libid_type
}
for fn in $@ ; do
func_win32_libid $fn
done
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] NEW: libtool-2.2.2-2 / Updated: libltdl7-2.2.2-2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Charles Wilson wrote: | I think that libtool hasn't been told that LDFLAGS should include | -L/usr/lib/w32api. I think this is something that should be passed on | the invocation line in your makefile -- maybe AM_LDFLAGS needs to be set? As I'm sure you're aware, /usr/lib/w32api is in ld's default library path, so -L/usr/lib/w32api should never be necessary. Nor was it required with libtool-1.5; this is a regression, but I'm not sure what the cause is. In /usr/bin/libtool, I see the following: sys_lib_search_path_spec=/usr/lib /lib/w32api /lib /usr/local/lib which is hard-coded for cygwin in _LT_SYS_DYNAMIC_LINKER (prev. AC_LIBTOOL_SYS_DYNAMIC_LINKER). But with the libtool script in the package I'm trying to build, I find: sys_lib_search_path_spec=/lib /usr/lib /usr/local/lib This didn't happen in another package, so I dug a bit further. If I run ./config.lt in this particular package, then the correct $sys_lib_search_path_spec appears, but when I run './config.status libtool', then I get the latter. Both packages use CC and CXX tags, and but the one that works correctly had warnings during autoreconf: configure.ac:169: warning: LT_OUTPUT was called before LT_LANG /usr/share/aclocal/libtool.m4:775: LT_LANG is expanded from... configure.ac:169: the top level /usr/share/aclocal/libtool.m4:5282: _LT_PROG_CXX is expanded from... /usr/share/aclocal/libtool.m4:5305: _LT_LANG_CXX_CONFIG is expanded from... /usr/share/aclocal/libtool.m4:792: _LT_LANG is expanded from... autoreconf-2.61: configure.ac: tracing configure.ac:169: warning: LT_OUTPUT was called before LT_LANG aclocal.m4:790: LT_LANG is expanded from... configure.ac:169: the top level where the package with the buggy libtool had no such warnings. Any ideas? | $ ./func_win32_libid.sh /usr/lib/w32api/libwinmm.a | x86 archive import That's good to know. Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIBBTapiWmPGlmQSMRCKi1AKD3rbfJKHjtOEKwIaXCu4pajiMDKQCg7pG2 64NcQWMFaGoEb9t3V8dmFX4= =79fv -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] NEW: libtool-2.2.2-2 / Updated: libltdl7-2.2.2-2
Charles Wilson wrote: I think that libtool hasn't been told that LDFLAGS should include -L/usr/lib/w32api. I think this is something that should be passed on the invocation line in your makefile -- maybe AM_LDFLAGS needs to be set? But the linker searches this location by default: $ grep SEARCH_DIR /usr/lib/ldscripts/i386pe.x SEARCH_DIR(/usr/i686-pc-cygwin/lib); SEARCH_DIR(/usr/local/lib); SEARCH_DIR(/usr/lib); SEARCH_DIR(/usr/lib/w32api); Shouldn't libtool be able to divine this information automatically? Likewise, having to specify -L/usr/lib/w32api anywhere in any *FLAGS seems wrong since it's a system location, just like you'd never expect to have to add -L/usr/lib to *FLAGS. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
NEW: libtool-2.2.2-2 / Updated: libltdl7-2.2.2-2
GNU libtool is a generic library support script. Libtool hides the complexity of using shared libraries behind a consistent, portable interface. This update represents a name change from the previous 'libtool2.2' package, to the new 'libtool' package (the embedded version number '2.2' has been dropped). This is a TEST release, and is only available by choosing the 'test' version from setup's chooser menu. Normally, 'test' releases are not announced in this manner. However, this one replaces and obsoletes an existing, non-test package (libtool2.2), so the announcement is appropriate. Both the (now obsolete) libtool2.2 package and the new libtool package (at least, the ones derived from libtool-2.2 source) provide a libltdl7 subpackage, which is why that package is 'updated' and not 'new'. Note that both libltdl3 (from the libtool-1.5.x series) and libltdl7 (from this libtool-2.2.x series) can be installed at the same time, without conflict. Changes sine libtool2.2-2.2.2-1 = o changed base package name from 'libtool2.2' to 'libtool' o Added patches from Yaakov Selkowitz http://cygwin.com/ml/cygwin/2008-04/msg00378.html -- Chuck To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: [EMAIL PROTECTED] If you need more information on unsubscribing, start reading here: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL.
Re: Attn: cygport maintainer [was: Re: Libtool 2.2.2]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Charles Wilson wrote: | Yaakov (Cygwin Ports) wrote: | AU_DEFUN([AC_PROG_LIBTOOL], | [LT_INIT | LT_OUTPUT | AC_DIAGNOSE([obsolete], | [$0: Remove this warning and the call to LT_OUTPUT if you do not need | libtool to exist before AC_OUTPUT.]) | ]) | | AU_ALIAS([AM_PROG_LIBTOOL], [AC_PROG_LIBTOOL]) | | That looks OK to me. I'll include something like this in the next | version of libtool2.2 (or libtool test: 2.2). One more patch will be required, namely, to define OBJDUMP where necessary. I've rolled these two patches together, as attached. Explanation: The AC_LIBTOOL_WIN32_DLL macro was supposed to be used in packages which built on Win32 platforms, in order to create DLLs. This macro tested for as, dlltool, and objdump. The latter is used in the file_magic test to determine if a .a is a static or import library. In 1.5 libtool worked anyway without it, because among other variables, OBJDUMP was given a sane default near the beginning of libtool.m4 and was always exported, and AS and DLLTOOL weren't needed. But in 2.2, the sane defaults have been minimized, and OBJDUMP is no longer defined by default, so without the win32-dll arg to LT_INIT (or the AC_LIBTOOL_WIN32_DLL compat macro), libtool refuses to link shared libs against non-libtoolized shared libs, because the file_magic test on the implib fails due to an undefined OBJDUMP variable. Assuring that OBJDUMP is defined is therefore necessary for compatibility with previous behaviour. Not only that, but this may fix another possible bug on Linux ELF systems, as there is a test on that platform (line 2461 after the patch) which uses OBJDUMP, which I don't see where it would have been defined. Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIAeHppiWmPGlmQSMRCLo1AKDx1ENwmwMhmKvL12avJ1RuVJfBHACg2g69 NKjvebLP38bbNdqP/cis8GI= =Z4Tf -END PGP SIGNATURE- --- libltdl/m4/libtool.m4 2008-04-01 13:20:04.0 -0500 +++ /usr/share/aclocal/libtool.m4 2008-04-13 05:21:22.296875000 -0500 @@ -99,8 +99,15 @@ ])# LT_INIT # Old names: -AU_ALIAS([AC_PROG_LIBTOOL], [LT_INIT]) -AU_ALIAS([AM_PROG_LIBTOOL], [LT_INIT]) +AU_DEFUN([AC_PROG_LIBTOOL], +[LT_INIT +LT_OUTPUT +AC_DIAGNOSE([obsolete], +[$0: Remove this warning and the call to LT_OUTPUT if you do not need +libtool to exist before AC_OUTPUT.]) +]) + +AU_ALIAS([AM_PROG_LIBTOOL], [AC_PROG_LIBTOOL]) dnl aclocal-1.4 backwards compatibility: dnl AC_DEFUN([AC_PROG_LIBTOOL], []) dnl AC_DEFUN([AM_PROG_LIBTOOL], []) @@ -2026,6 +2033,7 @@ [AC_REQUIRE([AC_CANONICAL_HOST])dnl m4_require([_LT_DECL_EGREP])dnl m4_require([_LT_FILEUTILS_DEFAULTS])dnl +m4_require([_LT_DECL_OBJDUMP])dnl m4_require([_LT_DECL_SED])dnl AC_MSG_CHECKING([dynamic linker characteristics]) m4_if([$1], @@ -2947,6 +2955,7 @@ # -- PORTME fill in with the dynamic library characteristics m4_defun([_LT_CHECK_MAGIC_METHOD], [m4_require([_LT_DECL_EGREP]) +m4_require([_LT_DECL_OBJDUMP]) AC_CACHE_CHECK([how to recognize dependent libraries], lt_cv_deplibs_check_method, [lt_cv_file_magic_cmd='$MAGIC_CMD' @@ -6961,6 +6970,18 @@ ]) +# _LT_DECL_OBJDUMP +# -- +# If we don't have a new enough Autoconf to choose the best objdump +# available, choose the one first in the user's PATH. +m4_defun([_LT_DECL_OBJDUMP], +[AC_CHECK_TOOL(OBJDUMP, objdump, false) +test -z $OBJDUMP OBJDUMP=objdump +_LT_DECL([], [OBJDUMP], [1], [An object symbol dumper]) +AC_SUBST([OBJDUMP]) +]) + + # _LT_DECL_SED # # Check for a fully-functional sed program, that truncates -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Attn: cygport maintainer [was: Re: Libtool 2.2.2]
Yaakov (Cygwin Ports) wrote: One more patch will be required, namely, to define OBJDUMP where necessary. I've rolled these two patches together, as attached. Explanation: The AC_LIBTOOL_WIN32_DLL macro was supposed to be used in packages which built on Win32 platforms, in order to create DLLs. This macro tested for as, dlltool, and objdump. The latter is used in the file_magic test to determine if a .a is a static or import library. In 1.5 libtool worked anyway without it, because among other variables, OBJDUMP was given a sane default near the beginning of libtool.m4 and was always exported, and AS and DLLTOOL weren't needed. But in 2.2, the sane defaults have been minimized, and OBJDUMP is no longer defined by default, I believe this was an attempt at optimization: avoid testing for specific tools need only on one platform, unless libtool has been told that it is ON that platform. Oddly, you'd think that libtool would figure that out from $build/$host/$target, and not [win32-dll]. so without the win32-dll arg to LT_INIT (or the AC_LIBTOOL_WIN32_DLL compat macro), libtool refuses to link shared libs against non-libtoolized shared libs, because the file_magic test on the implib fails due to an undefined OBJDUMP variable. Assuring that OBJDUMP is defined is therefore necessary for compatibility with previous behaviour. Not only that, but this may fix another possible bug on Linux ELF systems, as there is a test on that platform (line 2461 after the patch) which uses OBJDUMP, which I don't see where it would have been defined. Which is also odd. I wonder why linux uses objdump...maybe this is a dead code path? Oh, well: if it's necessary, it's necessary, and I'll push it upstream as well as including it in my next release of libtool2.2 (or libtool [*]). Thanks for doing this, Yaakov. -- Chuck [*] Having heard no objections, and a few votes in favor, I'm leaning towards replacing both libtool1.5 and libtool2.2 with a single libtool package, with 1.5-derived versions remaining curr: for the near-term. In the medium term, I expect that prev: will be the latest-1.5 derivative, and curr:/test: will both be 2.2-derived. Long term, libtool-1.5 will disappear from the standard prev:/curr:/test: trio, but setup's chooser should still allow the determined user to find a 1.5 variant if they click enough. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Attn: cygport maintainer [was: Re: Libtool 2.2.2]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Charles Wilson wrote: | I believe this was an attempt at optimization: avoid testing for | specific tools need only on one platform, unless libtool has been told | that it is ON that platform. Oddly, you'd think that libtool would | figure that out from $build/$host/$target, and not [win32-dll]. More than that, is AC_LIBTOOL_WIN32_DLL (now [win32-dll]) actually necessary anymore? Cygwin doesn't need it, but I don't know about MinGW. | Which is also odd. I wonder why linux uses objdump...maybe this is a | dead code path? I'm not sure; AFAICS such a test didn't exist for linux in libtool 1.5. | [*] Having heard no objections, and a few votes in favor, I'm leaning | towards replacing both libtool1.5 and libtool2.2 with a single | libtool package, with 1.5-derived versions remaining curr: for the | near-term. With my patch to libtool and some tweaking of cygport, libtool 2.2 seems to be working pretty well. I will need to know your final decision before committing the cygport patches, and I'll try to push an update as soon as possible thereafter. Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIAtMzpiWmPGlmQSMRCE3eAJ9mQXitBbfqWUnLRFL7HmalQaG2fgCeLd/A yA/G/Orc2yZcwB7GVikWUI4= =N1Er -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Attn: cygport maintainer [was: Re: Libtool 2.2.2]
Yaakov (Cygwin Ports) wrote: Charles Wilson wrote: | That should be taken up with the libtool maintainers. However, it has [snip] If I need to add LT_OUTPUT already, then I might as well switch entirely to the LT_* macros. True. But that is NOT required. libtool-emit-time is simply a new (possible backwards-incompatible) behavior change of the new libtool -- but one that hopefully impacts few clients. The compatibility AC_PROG_LIBTOOL macro should be just that: compatible with previous behaviour; otherwise, old packages WILL break. A very very small number. The attitude of the libtool maintainers is, this extremely small minority is supported via the LT_OUTPUT macro. For everybody else, the vast majority, AC_PROG_LIBTOOL will Just Work(tm), and we (they) are not going to pessimize everybody else just to support that small minority -- who can use the LT_OUTPUT if they really need to. This should not affect LT_INIT and the intended behaviour for the future. The change with regards to when, during the configure process, the libtool script itself is generated, is a separate and orthogonal issue from did you use the old A[CM]_PROG_LIBTOOL macro or the LT_INIT macro. Rather, the libtool-emit-time change is (one of the few) backwards-incompatiblities. Using the new libtool? Then the /default/ libtool-emit behavior has changed; simple as that. ~From the way you put it, it sounds like I shouldn't even waste my time asking upstream. If they won't accept this, can our libtool package be patched accordingly, so that packages work after libtoolize as they did with 1.5? Anything CAN be done, with enough developer 'tuits. The question is, is that wise? I don't know where to *automatically* insert a call to LT_OUTPUT in Q_RANDOM_PACKAGE's configure.ac; and I can't simply revert to the old way-- because the libtool-emission mechanisms are vastly different from 1.5.x. You don't know what you're asking... | You can continue to use | AC_PROG_LIBTOOL exactly as you did with libtool1.5. OK, that makes sense. I'm not sure exactly how widely tested 2.2 is, so I understand the logic. But there are a few packages with some 2.x libtool included (ImageMagick comes to mind), for which 1.5 is useless, and I don't want to wait too long to switch. Ack. And Bob F. jumped to 2.2 prematurely, IMO... I was looking more at the autoconf/automake side of libtool, but you raise a good point. Where are the ltdl changes outlined, and how many packages break due to those changes? Most of the removed interfaces were removed *because* they were not widely used (and were ugly; couldn't support the new features, etc). The changes are detailed in the new libtool's .info files. You can view them offline by unpacking libtool2.2 somewhere safe and using 'info -f /explicit/path/to/libtool2.2.info'. If AC_PROG_LIBTOOL can be compatible, and the ltdl API changes are indeed minor, than libtool should be a single package, especially if they can't be installed in parallel (unlike ac/am). It may be helpful for 2.2 to be in testing for a little while. Well, that's one of the possibilities I raised in my other email...however, it really doesn't solve the problem. It just makes switching between 1.5 and 2.2 a little easier given our setup.exe. Instead of explicitly uninstalling 2.2 and installing 1.5 (or vice versa), you just change the version of the single 'libtool' package from 1.5 to 2.2 (or vice versa) -- which effectively does the same thing: uninstall one then install the other. That's really too much trouble for those of us with hundreds (or thousands) of packages. Well, according to Ralf (hope he doesn't mind my paraphrase of his private email...) start Ralf LT_OUTPUT: I do not know how many packages are impacted by the LT_OUTPUT incompatibility issue, but was so far of the impression that it would be rather few. If that impression is wrong, then it's certainly a good idea to let libtool at gnu dot org know about this. LTDL API CHANGES: clients just need to cope. If there are clients out there for which it would be an unduly amount of work or hassle, we'd like to know about it. Actually, even more than with LT_OUTPUT, I believe that problems should be far and few between here. end Ralf The remainder of Ralf's email would tend to support this portion of your position: consolidate to a single 'libtool' package, make 2.2 the 'test' version, and leave it there until most of the maintainers have had a chance to see what issues arise with their packages. Then, and only then, bump the 2.2 version to current. His suggestion was: hey, just install libtool2.2 and rip through all your packages (...er, all 1300 of them? ...) and most of them ought to be fine. If more than a handful are not, then we (the libtool devs) need to know. | But this sort of thing is only necessary for those (hopefully rare) | packages where it actually MATTERS which
Re: Attn: cygport maintainer [was: Re: Libtool 2.2.2]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Charles Wilson wrote: | True. But that is NOT required. libtool-emit-time is simply a new | (possible backwards-incompatible) behavior change of the new libtool -- | but one that hopefully impacts few clients. I guess I'll be finding out exactly how many the hard way. | Anything CAN be done, with enough developer 'tuits. The question is, is | that wise? I don't know where to *automatically* insert a call to | LT_OUTPUT in Q_RANDOM_PACKAGE's configure.ac; and I can't simply revert | to the old way-- because the libtool-emission mechanisms are vastly | different from 1.5.x. You don't know what you're asking... I'm now looking at 2.2, what I mean is instead of (in libtool.m4): AU_ALIAS([AC_PROG_LIBTOOL], [LT_INIT]) AU_ALIAS([AM_PROG_LIBTOOL], [LT_INIT]) Do something like the following: AU_DEFUN([AC_PROG_LIBTOOL], [ LT_INIT LT_OUTPUT ]) AU_DEFUN([AM_PROG_LIBTOOL], [ LT_INIT LT_OUTPUT ]) AFAICS that would allow full compatibility with 1.5 behaviour after an autoreconf. But I see now that this would cause LT_OUTPUT to be added by autoupdate, which would generally be unnecessary. Is there another way to do this? | Well, that's one of the possibilities I raised in my other | email...however, it really doesn't solve the problem. It just makes | switching between 1.5 and 2.2 a little easier given our setup.exe. | Instead of explicitly uninstalling 2.2 and installing 1.5 (or vice | versa), you just change the version of the single 'libtool' package from | 1.5 to 2.2 (or vice versa) -- which effectively does the same thing: | uninstall one then install the other. True, but I don't think that's the primary reason to have only one libtool, and isn't the idea that it shouldn't be necessary to switch back and forth? | The remainder of Ralf's email would tend to support this portion of your | position: consolidate to a single 'libtool' package, make 2.2 the 'test' | version, and leave it there until most of the maintainers have had a | chance to see what issues arise with their packages. Then, and only | then, bump the 2.2 version to current. | | His suggestion was: hey, just install libtool2.2 and rip through all | your packages (...er, all 1300 of them? ...) and most of them ought to | be fine. If more than a handful are not, then we (the libtool devs) | need to know. Time consuming, but fair enough. (I just ran a count, it's 1500 source packages total, but it's hard to say how many of those use libtool.) | Yes it is. The problems would occur if the client needed a lot of work | to come into compliance with the new LTDL API. The LT_OUTPUT thing is | really very easy to fix for a given package. (And, according to Ralf, | the LT_OUTPUT thing, while rarely needed, is much more probable to arise | than LTDL API issues. That's good. I like my more common problems to | be easy to fix. And I like ALL my problems to be rare. Like my steak.) If the only real breakage is from LTDL API changes, then I agree it should be quite rare. | But it is not that simple. The old way of generating/emitting libtool | was not simply call some LT_OUTPUT-like macro at the end of | AC_PROG_LIBTOOL; that's far too early. And in almost all cases, | waiting until AC_OUTPUT() is fine. | | Besides, libtool-2.2 compatibility patches are the sort of thing | upstream maintainers like to see... There is another case which might be tricky. Some packages (namely Berkeley DB and KDE3) ship with libtool.m4 and then cat(1) it into aclocal.m4 (BDB) or acinclude.m4 (KDE3). With 1.5, cygport simply copies the libtool.m4 (and ltmain.sh) over the shipped copy in these cases. With 2.2, besides the change in location (the /usr/share/libtool/config subdir didn't exist in 1.5), there are now several libtool m4 macros. Besides ltdl.m4 and argz.m4 (AFAICS required only by ltdl.m4), are they all necessary for a working libtool.m4? | Well, Ralf seems to agree. I'd like to hear from a few other | maintainers before taking that plunge though. (For now, just don't | install the new libtool2.2 package, and you'll be fine). Please do that ASAP so that I can make the necessary changes in cygport. | So, please remove the libtool1.5 dep from cygport. Full stop. I don't see another choice for now, but if there becomes only one libtool package, I would add it back. Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH+yXTpiWmPGlmQSMRCDTdAKCs78ea+ZzeUPcU3WCRDfe+RtA01QCg4oeG gV+hAZBVVa0dv6tuOtyIeV4= =FjH/ -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Attn: cygport maintainer [was: Re: Libtool 2.2.2]
Yaakov (Cygwin Ports) wrote: Charles Wilson wrote: I'm now looking at 2.2, what I mean is instead of (in libtool.m4): AU_ALIAS([AC_PROG_LIBTOOL], [LT_INIT]) AU_ALIAS([AM_PROG_LIBTOOL], [LT_INIT]) Do something like the following: AU_DEFUN([AC_PROG_LIBTOOL], [ LT_INIT LT_OUTPUT ]) AU_DEFUN([AM_PROG_LIBTOOL], [ LT_INIT LT_OUTPUT ]) AFAICS that would allow full compatibility with 1.5 behaviour after an autoreconf. I'm not so sure. I still think that calling LT_OUTPUT immediately after LT_INIT is not exactly equivalent to 1.5 behavior. I think that is too early...but I don't know how to force a non-local insertion of LT_OUTPUT, and even if I did, I don't know how far down in configure.ac that non-local insertion should go. Of course, if you KNOW of a package that needs libtool before configure is finished (I don't), you could easily test my assertion by manually inserting LT_OUTPUT immediately after A[CM]_PROG_LIBTOOL/LT_INIT, manually running autoreconf with libtool2.2, and see if it works... But even so, this means that as part of cygport [*] you'd need to run autoupdate, which is not the current behavior. [*] But again, my recommedation is that cygport should NOT run autoupdate in an automated way. Instead, the package maintainer should run it, inspect the results, and fold those changes into .src.patch. In which case, manually adding LT_OUTPUT before generating .src.patch only when necessary rather than relying on autoupdate to do it automatically always even when unecessary, seems to be the better way to go. But I see now that this would cause LT_OUTPUT to be added by autoupdate, which would generally be unnecessary. That's a drawback, all right. Is there another way to do this? I don't know. True, but I don't think that's the primary reason to have only one libtool, and isn't the idea that it shouldn't be necessary to switch back and forth? Well, yeah -- in a perfect world. | Besides, libtool-2.2 compatibility patches are the sort of thing | upstream maintainers like to see... There is another case which might be tricky. Some packages (namely Berkeley DB and KDE3) ship with libtool.m4 and then cat(1) it into aclocal.m4 (BDB) or acinclude.m4 (KDE3). With 1.5, cygport simply copies the libtool.m4 (and ltmain.sh) over the shipped copy in these cases. With 2.2, besides the change in location (the /usr/share/libtool/config subdir didn't exist in 1.5), there are now several libtool m4 macros. Besides ltdl.m4 and argz.m4 (AFAICS required only by ltdl.m4), are they all necessary for a working libtool.m4? Correct. The gcc folks ran into this. FWICT, you need each of: libtool.m4, ltoptions.m4, ltsugar.m4, ltversion.m4, lt-obsolete.m4, It is recommeded, instead of copying those contents into aclocal.m4, that instead you do: m4_include([libtool.m4]) m4_include([ltoptions.m4]) m4_include([ltversion.m4]) m4_include([ltsugar.m4]) m4_include([lt~obsolete.m4]) | Well, Ralf seems to agree. I'd like to hear from a few other | maintainers before taking that plunge though. (For now, just don't | install the new libtool2.2 package, and you'll be fine). Please do that ASAP so that I can make the necessary changes in cygport. Sure...just waiting for more input. | So, please remove the libtool1.5 dep from cygport. Full stop. I don't see another choice for now, but if there becomes only one libtool package, I would add it back. I have modified cygport's setup.hint on sources. -- Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Attn: cygport maintainer [was: Re: Libtool 2.2.2]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Charles Wilson wrote: | I'm not so sure. I still think that calling LT_OUTPUT immediately after | LT_INIT is not exactly equivalent to 1.5 behavior. I think that is too | early...but I don't know how to force a non-local insertion of | LT_OUTPUT, and even if I did, I don't know how far down in | configure.ac that non-local insertion should go. I think it is equivalent, seeing from a typical configure run with libtool 1.5: ... checking dynamic linker characteristics... Win32 ld.exe checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag CXX to libtool ... appending configuration tag F77 to libtool ... | Of course, if you KNOW of a package that needs libtool before configure | is finished (I don't), you could easily test my assertion by manually | inserting LT_OUTPUT immediately after A[CM]_PROG_LIBTOOL/LT_INIT, | manually running autoreconf with libtool2.2, and see if it works... Some GNOME autoconf-based packages with python support run a python-module compile and link test with the previously created libtool. | That's a drawback, all right. Looking at some of the other compatibility macros, how about the following instead: AU_DEFUN([AC_PROG_LIBTOOL], [LT_INIT LT_OUTPUT AC_DIAGNOSE([obsolete], [$0: Remove this warning and the call to LT_OUTPUT if you do not need libtool to exist before AC_OUTPUT.]) ]) AU_ALIAS([AM_PROG_LIBTOOL], [AC_PROG_LIBTOOL]) | But even so, this means that as part of cygport [*] you'd need to run | autoupdate, which is not the current behavior. | | [*] But again, my recommedation is that cygport should NOT run | autoupdate in an automated way. Instead, the package maintainer should | run it, inspect the results, and fold those changes into .src.patch. In | which case, manually adding LT_OUTPUT before generating .src.patch only | when necessary rather than relying on autoupdate to do it automatically | always even when unecessary, seems to be the better way to go. Agreed. | Correct. The gcc folks ran into this. FWICT, you need each of: | libtool.m4, ltoptions.m4, ltsugar.m4, ltversion.m4, lt-obsolete.m4, | | It is recommeded, instead of copying those contents into aclocal.m4, | that instead you do: | | m4_include([libtool.m4]) | m4_include([ltoptions.m4]) | m4_include([ltversion.m4]) | m4_include([ltsugar.m4]) | m4_include([lt~obsolete.m4]) While that makes sense, I doubt that would work with the special build systems that I'm discussing, at least not in an automated way without patching those build systems more than necessary. I have something else in mind, but I'll need to try it out first. | Sure...just waiting for more input. Could you post the answer on cygwin-apps? | I have modified cygport's setup.hint on sources. Thank you. Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH+/aMpiWmPGlmQSMRCLeqAJ42Na5Iyxr2C3Bzs7vnuVWinav3uQCgxWgw K4mhjGWMeBAM1R92B3LsJQU= =FHgr -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Attn: cygport maintainer [was: Re: Libtool 2.2.2]
Yaakov (Cygwin Ports) wrote: Charles Wilson wrote: | I'm not so sure. I still think that calling LT_OUTPUT immediately after | LT_INIT is not exactly equivalent to 1.5 behavior. I think it is equivalent, seeing from a typical configure run with libtool 1.5: Looking at some of the other compatibility macros, how about the following instead: AU_DEFUN([AC_PROG_LIBTOOL], [LT_INIT LT_OUTPUT AC_DIAGNOSE([obsolete], [$0: Remove this warning and the call to LT_OUTPUT if you do not need libtool to exist before AC_OUTPUT.]) ]) AU_ALIAS([AM_PROG_LIBTOOL], [AC_PROG_LIBTOOL]) That looks OK to me. I'll include something like this in the next version of libtool2.2 (or libtool test: 2.2). | [*] But again, my recommedation is that cygport should NOT run | autoupdate in an automated way. Instead, the package maintainer should | run it, inspect the results, and fold those changes into .src.patch. Agreed. | m4_include([libtool.m4]) | m4_include([ltoptions.m4]) | m4_include([ltversion.m4]) | m4_include([ltsugar.m4]) | m4_include([lt~obsolete.m4]) While that makes sense, I doubt that would work with the special build systems that I'm discussing, at least not in an automated way without patching those build systems more than necessary. I have something else in mind, but I'll need to try it out first. For your packages, do whatever makes your life easier. g | Sure...just waiting for more input. Could you post the answer on cygwin-apps? Sure. -- Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Libtool 2.2.2 problems
Chuck, Well, I tried libtool 2.2.2 on a 1.5 package with autoreconf. Unfortunately it wouldn't build any shared libraries: /bin/sh ../libtool --tag=CC --mode=link gcc -O2 -pipe-o libgdasql-3.0.la -rpath /usr/lib -version-info 3:0:0 -no-undefined parser.lo lexer.lo sql_parser.lo mem.lo sql_display.lo sql_tree.lo -Wl,--export-dynamic -lgobject-2.0 -lgthread-2.0 -lgmodule-2.0 -lglib-2.0 -lintl -lxml2 -lz -liconv -lm *** Warning: linker path does not have real file for library -lbz2. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libbz2 and none of the candidates passed a file format test *** using a file magic. Last file checked: /lib/libbz2.dll.a [SNIP: Same message for libreadline, libz] *** The inter-library dependencies that have been dropped here will be *** automatically added whenever a program is linked with this library *** or is declared to -dlopen it. *** Since this library must not contain undefined symbols, *** because either the platform does not support them or *** it was explicitly requested with -no-undefined, *** libtool will only create a static version of it. libtool: link: ar cru .libs/libgdasql-3.0..dll.a .libs/parser.o .libs/lexer.o .libs/sql_parser.o .libs/mem.o .libs/sql_display.o .libs/sql_tree.o libtool: link: ranlib .libs/libgdasql-3.0..dll.a libtool: link: ( cd .libs rm -f libgdasql-3.0.la ln -s ../libgdasql-3.0.la libgdasql-3.0.la ) I see a few problems: 1) libtool seems not to want to link against non-libtoolized libraries, claiming that the file magic test fail on the import libs. 2) Why is the static library name have an extra .dll in it? This happens not only with a failed shared link, but also with a convenience lib: /bin/sh ../../libtool --tag=CC --mode=link gcc -O2 -pipe-o libgda_sql_delimiter-3.0.laparser.lo lexer.lo gda-sql-delimiter.lo gda-delimiter-tree.lo libtool: link: ar cru .libs/libgda_sql_delimiter-3.0..dll.a .libs/parser.o .libs/lexer.o .libs/gda-sql-delimiter.o .libs/gda-delimiter-tree.o libtool: link: ranlib .libs/libgda_sql_delimiter-3.0..dll.a libtool: link: ( cd .libs rm -f libgda_sql_delimiter-3.0.la ln -s ../libgda_sql_delimiter-3.0.la libgda_sql_delimiter-3.0.la ) Any ideas? Yaakov -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Attn: cygport maintainer [was: Re: Libtool 2.2.2]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Charles Wilson wrote:
| That should be taken up with the libtool maintainers. However, it has
| been their position, even in the libtool-1.4 and -1.5 days, that relying
| on that behavior was not recommended. Therefore they do not support it
| directly -- but instead provided the LT_OUTPUT macro for those
| packages that insist on ignoring their recommendations, or have really
| good reasons for doing so (such as running AC_COMPILE tests that need
| libtool).
If I need to add LT_OUTPUT already, then I might as well switch entirely
to the LT_* macros. The compatibility AC_PROG_LIBTOOL macro should be
just that: compatible with previous behaviour; otherwise, old packages
WILL break. This should not affect LT_INIT and the intended behaviour
for the future.
~From the way you put it, it sounds like I shouldn't even waste my time
asking upstream. If they won't accept this, can our libtool package be
patched accordingly, so that packages work after libtoolize as they did
with 1.5?
| IMO, no. autoupdate is not something that should be blindly done in an
| automated fashion, because you really should verify the results
| manually. I would recommend that, at least for now, maintainers
| approach it on a case-by-case basis -- but remember, except for this
| LT_OUTPUT thing (which can be added using foo-*.src.patch) you don't
| HAVE to use the new libtool2.2 interfaces; you don't HAVE to use
| autoupdate in order to use libtool2.2. You can continue to use
| AC_PROG_LIBTOOL exactly as you did with libtool1.5.
OK, that makes sense.
| For folks like you and Dr. Zell who maintain a LOT of packages, I'd
| recommend keeping libtool1.5 installed for a while. Let the rest of us
| with fewer packages deal with any possible libtool2.2 ripple.
I'm not sure exactly how widely tested 2.2 is, so I understand the
logic. But there are a few packages with some 2.x libtool included
(ImageMagick comes to mind), for which 1.5 is useless, and I don't want
to wait too long to switch.
| It's MOSTLY backwards compatible, with (AFAIK) the following exceptions:
| 1) the LT_OUTPUT thing
| 2) the libltdl library has had a few API changes -- some functions have
| been removed, others added. If your client uses those eliminated APIs,
| then you'll have to make actual code changes to use the libltdl from
| libtool-2.2.
I was looking more at the autoconf/automake side of libtool, but you
raise a good point. Where are the ltdl changes outlined, and how many
packages break due to those changes?
| As much as the libtool developers tried to maintain complete backwards
| compatibility, this IS a major new release and reflects over four years
| of development. It's impressive that the incompatibilities were kept as
| minor as they are.
I agree completely.
| Unfortunately, I think we are in for a certain amount of turbulence,
| just like back then. However, ac-2.5 and ac-2.13 were REALLY
| incompatible. The changes here are much less visible; most packages
| should be able to use either version of libtool with no *required*
| changes. Any autoupdate/code changes/configure.ac changes will be
| kinda-nice-but-not-really-necessary for most clients.
If AC_PROG_LIBTOOL can be compatible, and the ltdl API changes are
indeed minor, than libtool should be a single package, especially if
they can't be installed in parallel (unlike ac/am). It may be helpful
for 2.2 to be in testing for a little while.
| I see a lot of uninstall-libtool1.5/install-libtool2.2
| uninstall-libtool2.2/install-libtool1.5 cycles in our future.
That's really too much trouble for those of us with hundreds (or
thousands) of packages.
| I haven't done any investigation along these lines, but for some of us
| cygwin package maintainers, we might think about self-compiling
| /opt/libtool-2.2/{bin|share|lib} and /opt/libtool-1.5/{bin|share|lib}
| [*], uninstalling BOTH libtool1.5 and libtool2.2, and using
| /usr/share/aclocal/dirlist and $PATH to switch between them (dirlist
| entries go AFTER the compiled-in -acdir paths used by aclocal, so you
| have to uninstall the normal libtool packages make sure libtool.m4 and
| friends won't be found in /usr/share/aclocal/)
|
| Alternatively, you can keep the normal libtool package installed, but
| instead patch client Makefile.am's to add ACLOCAL_AMFLAGS with
| -I/opt/libtool-2.2/share/aclocal or -I/opt/libtool-1.5/share/aclocal AND
| using $PATH (this works because -I paths go BEFORE the compiled-in
| -acdir paths used by aclocal)
|
| But this sort of thing is only necessary for those (hopefully rare)
| packages where it actually MATTERS which version of libtool you use.
That's also pretty complicated. When would a package NOT work with 2.2?
| Even so, I hate to go back to the old libtool-stable/libtool-devel
| paradigm, but during this transition we -- cygwin package maintainers --
| might need to do so 'unofficially'. However, this is a lot of trouble,
| and
Attn: cygport maintainer [was: Re: Libtool 2.2.2]
Brian Dessent wrote: Angelo Graziosi wrote: and if cygport depend on libtool1.5, how can the user who needs libtool2.2 install it without uninstalling libtool1.5+cygport+...? I think cygport should remove its requires: libtoolx.y from its setup.hint. It currently lists that because the default src_compile() implementation calls cygautoreconf() which itself checks the to-be-built packages' configure.[in|ac] and checks that various autotools are installed. It doesn't do anything special with regards to libtool, except: if WANT_AUTOCONF=2.1 if configure.[in|ac] contains A[CM]_PROG_LIBTOOL issue a warning that libtool1.5 is incompatible with autoconf-2.13 CYGPORT CODE CHANGE: Now, with libtool2.2, that test needs to also check for LT_INIT, as well as the older A[CM]_PROG_LIBTOOL macros. Furthermore, you can still use cygport even without libtoolx.y installed: write your own src_compile() method that doesn't call cygautoreconf export LIBTOOL=no before calling cygautoreconf (or before calling the default src_compile) So, really, libtoolx.y is not a requirement of *cygport*, per se, but is a build-depends of whatever you are trying to use cygport to build. They would have to manually override the warning of setup in order to install libtool2.2+cygport. If one install libtool2.2 without removing anything, it overwrite libtool1.5, and I think this is a little confusing. And will break things, as the OP pointed out. Yes, it's not great but it's the best we can do. Feel free to suggest something less confusing, subject to the following constraints: - Both libtools can't exist on a system at once - Setup cannot express a mutual exclusivity, nor can it cause any package to be deselected The only thing I can think of is to wrap both libtool packages in a postinstall wrapper Ugh. No, thanks. In the short term it would probably make more sense to simply drop libtool from the cygport 'requires:' and instead document somewhere that you need one or the other installed. But you don't, really. See above. Cygport could potentially drop something in profile.d to do this check and alert the user if something's wrong, however I dislike the idea of penalizing every cygport user with yet another task at the start of every login shell. CYGPORT CODE CHANGE: No, instead cygport itself, inside cygautoreconf(), could perform that check. That is, if LIBTOOL != no, and configure.[ac|in] contains LT_INIT|A[CM]_PROG_LIBTOOL, then if ! check_prog libtool1.5 !check_prog libtool2.2 issue error message about missing libtool It could also be possible for a cygport postinstall to check for libtool and only if not found drop something in profile.d that displays a warning. No need to mess with profile.d; cygport itself can do the check. That way, only cygport users, when actually using cygport, are penalized by checking for libtool presence. Yet another option would be to fix setup to allow more complex dependencies to be expressed, but that's even more complicated as a) SHTDI and b) there's always going to be users not using the latest setup.exe even months/years after a new version is released. Yep, to both. In any case, there is no need to wait for the various modifications to cygport. We can (and should) remove the libtool1.5 require: from cygport's setup.hint immediately. (Where immediately means give Yaakov a decent interval to chime in on this thread...) -- Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Attn: cygport maintainer [was: Re: Libtool 2.2.2]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Chuck, I have yet to try libtool 2.2, but I'm sure that you have thoroughly tested it. Could you clarify a few things: *) Most packages still use a 1.5 libtool, if not older. Is LT_OUTPUT the default if the old-style AC_PROG_LIBTOOL macro is called? If it's not, it should be, as I know of a number of packages which rely on the libtool script during configure. *) Is running autoupdate recommended or beneficial when building a package using 1.5? *) If 2.2 is backwards compatible with 1.5, but they can't be installed in parallel, why not just rename all versions of the package to libtool? Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH+aEUpiWmPGlmQSMRCNzZAKCwVUZSnCfNT40qbcKMmSZk+YG8yQCgkBH6 MaRdX7OWU/E8oxNtBwYJMhs= =Jk2A -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Attn: cygport maintainer [was: Re: Libtool 2.2.2]
Yaakov (Cygwin Ports) wrote:
*) Most packages still use a 1.5 libtool, if not older. Is LT_OUTPUT
the default if the old-style AC_PROG_LIBTOOL macro is called?
No, it is not.
If it's
not, it should be, as I know of a number of packages which rely on the
libtool script during configure.
That should be taken up with the libtool maintainers. However, it has
been their position, even in the libtool-1.4 and -1.5 days, that relying
on that behavior was not recommended. Therefore they do not support it
directly -- but instead provided the LT_OUTPUT macro for those
packages that insist on ignoring their recommendations, or have really
good reasons for doing so (such as running AC_COMPILE tests that need
libtool).
*) Is running autoupdate recommended or beneficial when building a
package using 1.5?
IMO, no. autoupdate is not something that should be blindly done in an
automated fashion, because you really should verify the results
manually. I would recommend that, at least for now, maintainers
approach it on a case-by-case basis -- but remember, except for this
LT_OUTPUT thing (which can be added using foo-*.src.patch) you don't
HAVE to use the new libtool2.2 interfaces; you don't HAVE to use
autoupdate in order to use libtool2.2. You can continue to use
AC_PROG_LIBTOOL exactly as you did with libtool1.5.
For folks like you and Dr. Zell who maintain a LOT of packages, I'd
recommend keeping libtool1.5 installed for a while. Let the rest of us
with fewer packages deal with any possible libtool2.2 ripple.
For instance, if I wanted to try to use libtool2.2 on a particular
package, I might MANUALLY use autoupdate -- and then fold the (verified)
results into my .src.patch. I'd leave src_compile() and cygautoreconf
as-is.
*) If 2.2 is backwards compatible with 1.5,
It's MOSTLY backwards compatible, with (AFAIK) the following exceptions:
1) the LT_OUTPUT thing
2) the libltdl library has had a few API changes -- some functions
have been removed, others added. If your client uses those eliminated
APIs, then you'll have to make actual code changes to use the libltdl
from libtool-2.2.
As much as the libtool developers tried to maintain complete backwards
compatibility, this IS a major new release and reflects over four years
of development. It's impressive that the incompatibilities were kept as
minor as they are.
but they can't be installed
in parallel, why not just rename all versions of the package to libtool?
Well, I addressed this in another post, but nobody responded. It's here:
http://www.cygwin.com/ml/cygwin-apps/2008-04/msg00050.html
The FOSS community went thru this whole issue back during the
autoconf-2.13 to autoconf-2.5x transition. For a long time, you could
only have one or the other installed, until the distributions started
including wrapper scripts and installing both tools into different
locations/with different program names. (I believe cygwin was actually
the first to do this).
Unfortunately, I think we are in for a certain amount of turbulence,
just like back then. However, ac-2.5 and ac-2.13 were REALLY
incompatible. The changes here are much less visible; most packages
should be able to use either version of libtool with no *required*
changes. Any autoupdate/code changes/configure.ac changes will be
kinda-nice-but-not-really-necessary for most clients.
So for any particular client this transition is not a big deal. The real
problem is that any particular developer -- or cygwin package maintainer
-- probably works with a number of separate libtool client packages. And
not all of those are going to transition at the same time; nor is any
developer (cygwin package maintainer) going to want to brute force a
transition for all of his packages all at the same time.
I see a lot of uninstall-libtool1.5/install-libtool2.2
uninstall-libtool2.2/install-libtool1.5 cycles in our future.
=
I haven't done any investigation along these lines, but for some of us
cygwin package maintainers, we might think about self-compiling
/opt/libtool-2.2/{bin|share|lib} and /opt/libtool-1.5/{bin|share|lib}
[*], uninstalling BOTH libtool1.5 and libtool2.2, and using
/usr/share/aclocal/dirlist and $PATH to switch between them (dirlist
entries go AFTER the compiled-in -acdir paths used by aclocal, so you
have to uninstall the normal libtool packages make sure libtool.m4 and
friends won't be found in /usr/share/aclocal/)
Alternatively, you can keep the normal libtool package installed, but
instead patch client Makefile.am's to add ACLOCAL_AMFLAGS with
-I/opt/libtool-2.2/share/aclocal or -I/opt/libtool-1.5/share/aclocal AND
using $PATH (this works because -I paths go BEFORE the compiled-in
-acdir paths used by aclocal)
But this sort of thing is only necessary for those (hopefully rare)
packages where it actually MATTERS which version of libtool you use.
Even so, I hate to go back to the old libtool-stable/libtool-devel
Re: Libtool 2.2.2
Brian Dessent wrote: This shouldn't be too big of a problem as the libtool packages are only needed if you relibtoolize something -- which you normally do not when building from a tarball, only from a VCS checkout. Though building any cygport-ized package seems to force the issue since it likes to forcibly autoreconf -fvi. Perhaps I am missing something, but if you say it is incompatible with the libtool1.5 package, which means you have to manually deselect all other libtool packages if you select libtool2.2 and if cygport depend on libtool1.5, how can the user who needs libtool2.2 install it without uninstalling libtool1.5+cygport+...? If I try to uninstall libtool1.5, setup.exe says that cygport depend on it and stops the procedure at least one force it. If one install libtool2.2 without removing anything, it overwrite libtool1.5, and I think this is a little confusing. Suppose that an hypotetical user have not yet installed cygport and libtool* packages. Then this user install libtool2.2. Suppose now that the user needs also cygport: installing it, automatically libtool1.5 is chosen, overwriting libtool2.2! So the user thinks is using libtool2.2 instead, since installing cygport, is using libtool1.5! Cheers, Angelo. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Libtool 2.2.2
Angelo Graziosi wrote: and if cygport depend on libtool1.5, how can the user who needs libtool2.2 install it without uninstalling libtool1.5+cygport+...? They would have to manually override the warning of setup in order to install libtool2.2+cygport. If one install libtool2.2 without removing anything, it overwrite libtool1.5, and I think this is a little confusing. Yes, it's not great but it's the best we can do. Feel free to suggest something less confusing, subject to the following constraints: - Both libtools can't exist on a system at once - Setup cannot express a mutual exclusivity, nor can it cause any package to be deselected The only thing I can think of is to wrap both libtool packages in a postinstall wrapper (as is currently done with the gcc-mingw-* packages) that first checks if the other is installed before unpacking anything. Then it could choose to either uninstall the other package, or decline to install itself. This is messy in that a) cygcheck -c / cygcheck -l / cygcheck -f cease to work as expected for the package and b) it's a lot more work to maintain such a package. (a) could be worked around by rewriting the manifest so that after the postinstall is run it looks like a normal package. Suppose that an hypotetical user have not yet installed cygport and libtool* packages. Then this user install libtool2.2. Suppose now that the user needs also cygport: installing it, automatically libtool1.5 is chosen, overwriting libtool2.2! So the user thinks is using libtool2.2 instead, since installing cygport, is using libtool1.5! In the short term it would probably make more sense to simply drop libtool from the cygport 'requires:' and instead document somewhere that you need one or the other installed. Cygport could potentially drop something in profile.d to do this check and alert the user if something's wrong, however I dislike the idea of penalizing every cygport user with yet another task at the start of every login shell. It could also be possible for a cygport postinstall to check for libtool and only if not found drop something in profile.d that displays a warning. Yet another option would be to fix setup to allow more complex dependencies to be expressed, but that's even more complicated as a) SHTDI and b) there's always going to be users not using the latest setup.exe even months/years after a new version is released. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Libtool 2.2.2
Last night, I updated my Cygwin installation and received libtool 2.2.2 This afternoon. I tried building subversion 1.5 branch. I got to the first library, and libtool said it could not build a shared library. That only static libraries could be built. My exact configure went like this: ../configure --prefix=/usr --enable-shared I am build the httpd server and then neon 2.8 I won't use shared now. Not sure how I messed up Bobby -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Libtool 2.2.2
Bobby McNulty wrote: Last night, I updated my Cygwin installation and received libtool 2.2.2 Seeing as how libtool2.2 is not listed in any 'requires:' line you must have manually selected it in order for it to be installed. Per the release announcement, it is incompatible with the libtool1.5 package, which means you have to manually deselect all other libtool packages if you select libtool2.2. You can only have one of the two at any time installed, and there's no way for setup to enforce that which is why it's not listed in any 'requires:'. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Libtool 2.2.2
Brian Dessent wrote: Per the release announcement, it is incompatible with the libtool1.5 package, which means you have to manually deselect all other libtool packages if you select libtool2.2. You can only have one of the two at any time installed If this is the case, perhaps, there is some problem in setup.ini. cygport requires libtool1.5 and libguile17 requires libltdl3. So it looks that the set libtool1.5+libltdl3 cannot be removed in favor of libtool2.2+libltdl7 (if one needs cygport, libguile17+ dependences). Cheers, Angelo. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Libtool 2.2.2
Angelo Graziosi wrote: If this is the case, perhaps, there is some problem in setup.ini. cygport requires libtool1.5 and libguile17 requires libltdl3. So it looks that the set libtool1.5+libltdl3 cannot be removed in favor of libtool2.2+libltdl7 (if one needs cygport, libguile17+ dependences). I may not have been clear. The libltdl runtime packages should be fine on their own, it's just the libtool developer packages that are incompatible. I don't think there should be a problem if you have installed libltdl3+libltdl6+libltdl7+(one of libtool1.5 or libtool2.2). I'm not sure what libltdl6 is doing in the distro though as nothing 'requires:' it. This shouldn't be too big of a problem as the libtool packages are only needed if you relibtoolize something -- which you normally do not when building from a tarball, only from a VCS checkout. Though building any cygport-ized package seems to force the issue since it likes to forcibly autoreconf -fvi. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
