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/
