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/
