Re: g++ and -nostdlib
On 11/8/2013 1:49 PM, Bob Friesenhahn wrote: Isn't it because libtool wants to control the order of the linking and assure that all dependencies (including static) are tracked/known and applied at the correct times? It wants to assure that static dependencies are linked into the dependent program rather than into some dependent shared library (and thus causing a problem). It was common (and perhaps still is) for the GNU C++ library to be delivered as a static library for Windows/MinGW because C++ exceptions were not handled properly when thrown by DLLs. Quite a lot of effort went into making this work the way it currently does. First libtool tries to take away all of the libraries which would be added automatically and then it applies the libraries that GCC says it would use at the correct time. One of my wishlist roundtuit items is to special-case this behavior for libtool + GNU toolchains. For that combo, instead of the procedure Bob outlines, and then using $LD to linkjust use the compiler driver (e.g. g++, or gfortran, or gcc) to link, WITHOUT -nostdlib [1]. We're already passing the ABI-modifying -m and -f flags anyway, and it would really REALLY simplify libtool's logic... [1] unless of course the end user put -nostdlib in $LDFLAGS or something. -- Chuck
Re: Windows Line Endings [WAS Re: [SCM] GNU Libtool branch, master, updated. v2.4.2-273-ge24f183]
On 10/5/2012 12:03 PM, Gary V. Vaughan wrote: And thanks for looking into it. Is there a legal way to get access to Windows and the various flavours of gcc and MSVC that libtool users care about, without spending hundreds of dollars on software I would never use for anything else? Yes. MS routinely provides virtual machine images for their OS's for testers to use. Naturally they are in VHD format for the windows-hosted VirtualPC product... WinXP, WinVista, Win7 (90 days [*]) http://www.microsoft.com/en-us/download/details.aspx?id=11575 [*] XP image has a hard-coded expiration date, and they usually upload a new version with a bumped expiry every so often. Current expiry is 13 Nov 2012. Vista and 7 are rolling expiration: 90 days from first activation. Windows Server 2012 (180 days) http://msdn.microsoft.com/en-us/evalcenter/hh708764.aspx?ocid=wt.mc_id=MEC_110_1_33 Windows 8 (90 days) http://msdn.microsoft.com/en-us/evalcenter/jj554510.aspx ...but you can run them on linux using VirtualBox: http://www.geekpowers.com/?p=121 After that, you can install into the virtual environment the free (as in beer) Visual Studio Express of your choice; right now 2010 and 2012beta seem to be available. Requires free as in beer registration to use past 30 days. http://www.microsoft.com/visualstudio/eng/downloads Note that after installing VSexpress, you have to install separately the Windows SDK -- or at least that used to be required with the old 2005 and 2008 versions. Dunno about 2010/2012. http://www.microsoft.com/en-us/download/details.aspx?id=8442 The expiration thing causes an annoyance redo factor if you only mess with this stuff once every six months and find you have to recreate everything each time. But...it doesn't cost any money. -- Chuck
Re: Windows Line Endings
On 10/5/2012 2:28 PM, Bob Friesenhahn wrote: I wouldn't recommend that anyone start with XP these days since it is 12 years old, patched beyond all repair, and quickly becoming defunct. Seconded. A virtual machine with stock XP will need several full days of running Windows Update to bring it up to SP3 + all latest patches. I know because I just re-created one a few weeks ago using an old XP install disk. On the other hand, $dayjob is still using XP. Corporate IT just okayed to transition to Win7 last month. g The virtual machine images, even the one for XP, come fully patched as of their date of release. For the XP one I mentioned earlier, that'd be July 2012. -- Chuck
Re: [PATCH] libtool: minimise forks per invocation on cygwin and mingw.
On 12/8/2011 5:21 AM, Gary V. Vaughan wrote: The recently pushed series of patches included the controversial introduction of an additional 3 forks per invocation, which might add a minute or two of wall-clock time to giant builds on windows. By assuming that windows will run shell scripts on some shell with all the modern optional features that libtool wants, this patch eliminates even those 3 new forks. Okay to push? Has anybody done a comparison between: cygwin + libtool + dash/posh (e.g. small, fast shell -- without XSI) cygwin + libtool + bash (e.g. big bloated slow shell -- with XSI) to see which is better? -- Chuck
Re: [PATCH] libtool: minimise forks per invocation on cygwin and mingw.
On 12/8/2011 11:22 AM, Eric Blake wrote:
On 12/08/2011 08:29 AM, Charles Wilson wrote:
cygwin + libtool + dash/posh (e.g. small, fast shell -- without XSI)
Umm, dash has XSI features (where XSI features covers things like
${var##prefix}). ... Meanwhile, libtool is using more than just XSI
extensions; for example, it is probing for bash's += variable append
extension.
Oh, I didn't realize. I was primarily thinking about += -- I thought it
was one of the XSI extensions, not a bash-specific thing, and I knew
dash did not support it.
--
Chuck
Re: [PATCH 01/10] tests: migrate legacy tests/cdemo tests to Autotest.
On 11/28/2011 12:12 PM, Charles Wilson wrote:
Attached, see test log for $host=cygwin. I had to use 'make -k check
gl_public_submodule_commit=' -- I'm not sure why, but perhaps your
working tree is using private gnulib mods?
I'll send testsuite.dir privately.
I've attached the test log for $host=mingw32. I'll send /that/
testsuite.dir privately, as well.
--
Chuck
make check-recursive
make[1]: Entering directory
`/c/cygwin-1.7/usr/src/packages/libtool/git/build-libtool-master-mingw'
GENtests/defs
Making check in .
make[2]: Entering directory
`/c/cygwin-1.7/usr/src/packages/libtool/git/build-libtool-master-mingw'
restore=: backupdir=.am$$ \
am__cwd=`pwd` CDPATH=${ZSH_VERSION+.}: cd ../libtool \
rm -rf $backupdir mkdir $backupdir \
if (/bin/sh
/c/cygwin-1.7/usr/src/packages/libtool/git/libtool/build-aux/missing --run
makeinfo --version) /dev/null 21; then \
for f in ../libtool/doc/libtool.info
../libtool/doc/libtool.info-[0-9] ../libtool/doc/libtool.info-[0-9][0-9]
../libtool/doc/libtool.i[0-9] ../libtool/doc/libtool.i[0-9][0-9]; do \
if test -f $f; then mv $f $backupdir; restore=mv; else :; fi; \
done; \
else :; fi \
cd $am__cwd; \
if /bin/sh
/c/cygwin-1.7/usr/src/packages/libtool/git/libtool/build-aux/missing --run
makeinfo -I doc -I ../libtool/doc \
-o ../libtool/doc/libtool.info ../libtool/doc/libtool.texi; \
then \
rc=0; \
CDPATH=${ZSH_VERSION+.}: cd ../libtool; \
else \
rc=$?; \
CDPATH=${ZSH_VERSION+.}: cd ../libtool \
$restore $backupdir/* `echo ./../libtool/doc/libtool.info | sed
's|[^/]*$||'`; \
fi; \
rm -rf $backupdir; exit $rc
make check-TESTS check-local
make[3]: Entering directory
`/c/cygwin-1.7/usr/src/packages/libtool/git/build-libtool-master-mingw'
make[4]: Entering directory
`/c/cygwin-1.7/usr/src/packages/libtool/git/build-libtool-master-mingw'
PASS: tests/link.test
PASS: tests/link-2.test
PASS: tests/nomode.test
PASS: tests/objectlist.test
PASS: tests/quote.test
PASS: tests/suffix.test
PASS: tests/tagtrace.test
==
All 7 tests passed
==
make[4]: Leaving directory
`/c/cygwin-1.7/usr/src/packages/libtool/git/build-libtool-master-mingw'
CC libltdl/loaders/libltdl_libltdlc_la-preopen.lo
CC libltdl/libltdl_libltdlc_la-lt__alloc.lo
CC libltdl/libltdl_libltdlc_la-lt_dlloader.lo
CC libltdl/libltdl_libltdlc_la-lt_error.lo
CC libltdl/libltdl_libltdlc_la-ltdl.lo
CC libltdl/libltdl_libltdlc_la-slist.lo
CCLD libltdl/libltdlc.la
## - ##
## GNU Libtool 2.4.2.133-fe91d-dirty test suite. ##
## - ##
Shell option parser generator.
1: short option splitting ok
2: enhanced shell short option splitting ok
3: long option splitting ok
4: XSI long option splitting ok
5: option appendingok
6: enhanced shell option appending ok
Libtoolize operation.
7: libtoolize macro installation ok
8: libtoolize macro directory mismatch error ok
9: libtoolize macro serial update FAILED (libtoolize.at:151)
10: libtoolize config files serial update FAILED (libtoolize.at:228)
11: diagnose missing LT_CONFIG_LTDL_DIR ok
12: copy ltdl.m4 with shared macro directoryok
13: correctly parse LTDL_INIT from configure.ac ok
14: diagnose missing LTDL_INIT invocation ok
15: upgrading verbatim style aclocal.m4 FAILED (libtoolize.at:594)
16: verbatim aclocal.m4 w/o AC_CONFIG_MACRO_DIR FAILED (libtoolize.at:685)
17: nonrecursive ltdl with AC_CONFIG_MACRO_DIR ok
18: subproject ltdl with unconventional layout ok
19: Subproject ltdl without GNU M4 ok
20: LIBTOOLIZE_OPTIONS ok
21: cleanup old installationok
Linking and loading.
22: link against a preloaded static library FAILED (demo.at:398)
23: build and dynamically load a module FAILED (demo.at:415)
24: preload static and dynamic module FAILED (demo.at:432)
25: deplibs_check_methodFAILED (demo.at:478)
26: disable fast installFAILED (demo.at:494)
27: force PIC objects FAILED (demo.at:510)
28: force non-PIC objects FAILED (demo.at:548)
29: hardcoding library path FAILED (demo.at:621)
30: binary relinking at install timeFAILED (demo.at:730)
31: uninstalled libraries have priority FAILED (demo.at:791)
32: linking with long file namesFAILED (demo.at:914)
Convenience
Re: [PATCH 01/10] tests: migrate legacy tests/cdemo tests to Autotest.
On 11/25/2011 11:57 PM, Gary V. Vaughan wrote: On 26 Nov 2011, at 11:39, Charles Wilson wrote: a) This is a big holiday weekend in the US, so...a bit more than 72 hours is indicated. Most of us will still be catching up on post-holiday $realjob stuff by the time 72 hours expires. Ah, didn't think of that. Sure, I will be busy myself for a week or two, so I won't push for at least a week, probably more. Thanks. b) cygwin? mingw? msvc? I'm afraid I don't have (or want) access to any Windows machines, so I'm afraid that I am relying on you guys to tell me if I screwed up. Of course I'm not expecting you to debug or fix my mistakes for me, and I'm not anticipating any new problems, since everything is merely migrated from legacy testsuite to Autotest testsuite, with minimal changes required to keep everything working on my main machines. Hrm, well, not so much. See below. Although I do normally have access to more machines, the flooding in Bangkok has made any use of my Internet connection other than email intolerably slow... hence the recent flurry of work on libtool (which I can do offline, queueing emails for when my connection is next up) Ah, well, $realjob's loss, our gain. to fill my time while I wait for things to get back to normal. The reason I'll be too busy to do much more of that over the next week or two, is that last night I actually had a full-speed connection to the US again, so I'm anticipating playing catchup at $realjob myself. Sorry if I seem a bit short, but I'm rather annoyed to see my queue get filled with hours upon hours of work in the middle of a holiday. Please don't feel that it's your responsibility to painstakingly pick through every patch I post... I'd be more than happy just to get the test logs from anything I put on alpha.gnu.org for the architectures I don't use to help me restabilize the code closer to a release. Full test logs for failed cygwin tests sent privately (1MB). Enjoy the rest of your holiday, and sorry for working so much on libtool recently: Well, I really wasn't complaining about the *work* per se -- it's great that somebody is finally tackling some of those gee-wouldn't-it-be-nice issues, like *FINALLY* switching over to autotest throughout, with all the attendant benefits. It's just I didn't want to have to run the testsuite, on three platforms, over the holidays in order to meet the 72hour deadline. although my objective with the recent modernisations has been to try to decruft libtool a little, and to make the barrier to contribution much lower than it is currently if at all possible. decrufting is good. I rarely have the chance to put a lot of time into libtool, and things will slow down considerably again now if my Internet connection really is back to (something like) normal again. Yep, when the tool mostly Just Works the motivation to allocate scarce resources (like personal free time) to it is somewhat lacking. I think that's true for all of us. I have another 20 or so patches left incubating in my unpublished queue, and I will be done for now after those are polished and pushed over the next month or two. Too bad. If your inet stayed down longer, I was going to suggest implementing the long-desired if $CC=gcc $gnuld == yes; then use compiler driver to link rather than ld, for all languages optimization -- thus getting rid of the predeps/postdeps/prelibs/postlibs kludginess for GNU compilers (incl. cygming). Oh well. :-) Attached, see test log for $host=cygwin. I had to use 'make -k check gl_public_submodule_commit=' -- I'm not sure why, but perhaps your working tree is using private gnulib mods? I'll send testsuite.dir privately. -- Chuck make check-recursive make[1]: Entering directory `/usr/src/packages/libtool/git/build-libtool-master' GEN../libtool/tests/defs.in GENtests/defs Making check in . make[2]: Entering directory `/usr/src/packages/libtool/git/build-libtool-master' make check-TESTS check-local make[3]: Entering directory `/usr/src/packages/libtool/git/build-libtool-master' make[4]: Entering directory `/usr/src/packages/libtool/git/build-libtool-master' PASS: tests/link.test PASS: tests/link-2.test PASS: tests/nomode.test PASS: tests/objectlist.test PASS: tests/quote.test PASS: tests/suffix.test PASS: tests/tagtrace.test == All 7 tests passed == make[4]: Leaving directory `/usr/src/packages/libtool/git/build-libtool-master' GEN../libtool/tests/package.m4 GEN../libtool/tests/testsuite CC libltdl/loaders/libltdl_libltdlc_la-preopen.lo CC libltdl/libltdl_libltdlc_la-lt__alloc.lo CC libltdl/libltdl_libltdlc_la-lt_dlloader.lo CC libltdl/libltdl_libltdlc_la-lt_error.lo CC libltdl/libltdl_libltdlc_la-ltdl.lo CC libltdl/libltdl_libltdlc_la-slist.lo CCLD libltdl/libltdlc.la ## - ## ## GNU Libtool 2.4.2.133-fe91d-dirty test suite
Re: [PATCH 04/25] syntax-check: fix violations and re-enable sc_cast_of_x_alloc_return_value.
On 11/15/2011 7:53 AM, Gary V. Vaughan wrote: * cfg.mk (local-checks-to-fix): Remove sc_cast_of_x_alloc_return_value from list of disabled checks. * libltdl/config/ltmain.m4sh (XMALLOC, XFREE): Unroll into their xmalloc and free expansions so that this syntax-check can find violations, and then fix them. * iibltdl/libltdl/lt__alloc.h (MALLOC, REALLOC): Renamed to xmalloc and xrealloc so that this syntax-check can find violations. Adjust all callers. (FREE, MEMREASSIGN): Removed. All callers unrolled into their former expansions, and violations of this syntax-check fixed. * libltdl/loaders/loadlibrary.c (LOCALFREE): Unrolled for consistency. Why do I get the feeling that the next time I try to build any .exe on cygwin/mingw with -Wall -Werror, I'm going to fail because all these (now removed) casts in the cwrapper source code were there specifically to suppress warnings... -- Chuck
Re: [PATCH 04/25] syntax-check: fix violations and re-enable sc_cast_of_x_alloc_return_value.
On 11/15/2011 11:36 AM, Charles Wilson wrote:
On 11/15/2011 7:53 AM, Gary V. Vaughan wrote:
* cfg.mk (local-checks-to-fix): Remove
sc_cast_of_x_alloc_return_value from list of disabled checks.
* libltdl/config/ltmain.m4sh (XMALLOC, XFREE): Unroll into their
xmalloc and free expansions so that this syntax-check can find
violations, and then fix them.
* iibltdl/libltdl/lt__alloc.h (MALLOC, REALLOC): Renamed to
xmalloc and xrealloc so that this syntax-check can find
violations. Adjust all callers.
(FREE, MEMREASSIGN): Removed. All callers unrolled into their
former expansions, and violations of this syntax-check fixed.
* libltdl/loaders/loadlibrary.c (LOCALFREE): Unrolled for
consistency.
Why do I get the feeling that the next time I try to build any .exe on
cygwin/mingw with -Wall -Werror, I'm going to fail because all these
(now removed) casts in the cwrapper source code were there specifically
to suppress warnings...
And speaking of casts and C/C++...suppose you have package foo and you
want to build foo with CC=g++ -- that ought to be legal, right?
pathto/foo-src/configure --prefix=... CC=g++
But that means on cygwin/mingw, if foo uses libtool then the cwrapper
will be built using ${CC} -- that is, g++. Bang; you're dead -- because
the cast is required with C++, isn't it? (IIRC it's not just a warning,
it's an error, if the cast is missing).
--
Chuck
Re: [PATCH 09/25] syntax-check: fix violations and re-enable sc_makefile_at_at_check.
On 11/15/2011 7:53 AM, Gary V. Vaughan wrote: tests/mdemo/Makefile.am -## use @LIBLTDL@ because some broken makes do not accept macros in targets +## use $(LIBLTDL) because some broken makes do not accept macros in targets This comment now makes zero sense. If you are now forcing the following rule: +$(LIBLTDL): $(top_distdir)/libtool \ then (a) remove the comment completely, and (b) document somewhere that we now require non-broken make which DOES allow $(macros) in targets. -- Chuck
Re: [PATCH 1/7] bootstrap: split into reusable parts.
On 11/5/2011 12:40 PM, Gary V. Vaughan wrote: By the end of this particular set, libtoolize will have moved from the kludgy sed based interrogation of configure.ac to probe the arguments to various important macros so that it can determine what files to copy and where... to the much more splendid and reliable M4 based tracing mechanism I originally wrote for bootstrap last year before adoption into gnulib stalled. IIUC, in the past libtoolize *itself* has not had any dependency on m4. Granted, it wasn't much use without autoconf, which needed m4, so most users of libtoolize would have had m4 installed anyway. But this change will add a *direct* dependency on m4, right? That's ok with me, as it makes no *real* difference, but it should be documented somewhere. -- Chuck
Re: Obsoleting LT_SCOPE
On 10/25/2011 6:51 AM, Gary V. Vaughan wrote: Do you forsee any issues on Windows with my doing that? Yes. I'm almost certain that modern gcc and hence cygwin and variants will continue to work correctly without LT_SCOPE, LTDL_DLL_IMPORT and friends, but I have no clue whether vendor compilers that currently work (or at least are supported and supposed to work) with the current release are relying on LT_SCOPE magic from libltdl. Modern gcc will be fine on cygwin, mingw, and mingw64. What will break completely is any version of Visual Studio, including 2010 -- which I'm fairly sure is not a museum piece. It would be a shame to obviate all of Peter's work getting libtool itself to work with MSVC, and then to break that platform's libltdl.dll. But I'll let Peter take point on this one. -- Chuck ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Obsoleting LT_SCOPE
On 10/25/2011 11:03 AM, Peter Rosin wrote: Gary V. Vaughan skrev 2011-10-25 14:17: I configures both the way I usually configure libtool for msvc, i.e. ../configure autobuild_mode=msvc CC=/c/cygwin/home/peda/automake/lib/compile cl CFLAGS=-MD -Zi -EHsc CXX=/c/cygwin/home/peda/automake/lib/compile cl CXXFLAGS=-MD -Zi -EHsc LD=link NM=dumpbin -symbols STRIP=: AR=/c/cygwin/home/peda/automake/lib/ar-lib lib RANLIB=: F77=no FC=no GCJ=no The testsuite result seems identical, with two good old failures: Be sure and check the exports from libltdl*.dll from before and after... -- Chuck ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Obsoleting LT_SCOPE
On 10/25/2011 11:51 AM, Gary V. Vaughan wrote: I have to bow to your superior knowledge of Windows, which I haven't used for development since Windows NT 4, but it feels weird that Libltdl really does twist itself into a pretzel for Windows... and yet all the other GNU projects I've looked at do no such thing (possibly because I haven't yet found another one that can be compiled with MSVC). Well, a couple of points: #1, libltdl is not normal: unlike most libraries, we provide explicit support for (a) linking externally, (b) incorporating as a subproject and linking locally (separate ./configure), and (c) incorporating as a submodule(?) and linking locally (combined ./configure). Very few other libraries support any such thing OOB. #2, I can think of one other GNU projects that support similar sub-inclusion: libintl. And /that/ library, and its cousin libiconv, also twist themselves into giant pretzels for Windows -- even moreso than libltdl. Bruno invented a whole new method of linking! http://www.haible.de/bruno/woe32dll.html BTW: one possible solution to this whole conundrum is to adopt Bruno's method [*], which works for both MSVC and gcc. The idea is to *always* declare exported symbols as declspec(dllimport), even when linking against the static library. The trick is, some additional build steps when building the library itself, to add the requisite import thunks to the static lib. See the URL above for more info. FWIW, Bruno has long said that this method would work better with just a few additional lines of code in libtool. However, as he's never actually posted just WHAT those additional lines of code would BE, I've been at a loss to move forward. That's been the status now for several years (not really high on my priority list). [*] without the -Wl,--disable-auto-import -- Chuck ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: [PATCH] Include _CRTIMP in _putenv() declaration in EXE wrapper sources.
On 6/23/2011 5:34 AM, Vadim Zeitlin wrote: Re-declaring _putenv() without _CRTIMP in strict ANSI mode when using MinGW resulted in a warning because of a conflict with the previous declaration that did use _CRTIMP. Simply add _CRTIMP to our declaration to avoid it. -int _putenv (const char *); +_CRTIMP int _putenv (const char *); Probably should also add __cdecl (for correctness, not warning suppression) in case the user has done a -mrtd. _CRTIMP int __cdecl _putenv (const char*); However, no need for __MINGW_NOTHROW, I think, because gcc does not appear to give this warning when redeclarations only differ by missing attributes (in this case, __attribute__ ((__nothrow__)) ). The larger issue, of course, is that we need to implement LT_WRAPPER_CFLAGS variable (*), that strips out warning flags and especially -Werror and its other-compiler analogues from the user's C[,PP,XX]FLAGS -- otherwise, we will continue to hit this problem over and over. This is the third or fourth time we've had to update the c-wrapper code for similar issues. (*) Dunno what the correct name should be. LT_CFLAGS_FOR_BUILD or similar is /wrong/, because the wrapper is actually built for $host. -- Chuck
Re: libtool shouldn't switch to creating static library if it can't create the shared one under Windows
On 6/23/2011 11:03 AM, Vadim Zeitlin wrote: On Thu, 23 Jun 2011 09:24:35 -0500 (CDT) Bob Friesenhahn bfrie...@simple.dallas.tx.us wrote: BF On Thu, 23 Jun 2011, Vadim Zeitlin wrote: BF BF I.e. it created a shared library with undefined symbols without any BF problems because it never actually passed -no-undefined to g++/ld. BF BF In actual practice, it seems difficult or impossible to build programs BF under systems like Linux with -no-undefined. I didn't know this but doesn't this make the situation even worse? I.e. because of the above you can't even recommend people to use -no-undefined by default. So the default behaviour will remain the current one, i.e. no DLLs at all under Windows. No, what it means is that, IF the project maintainers want to support shared libraries (DLLs) on win32, then they must do the following -- and this is true regardless of whether libtool is involved. 1) Ensure that when building for win32, that the various object files that will be combined into the DLL, as well as the library dependencies (-lwhatever) are such that there WILL BE no undefined symbols, at least *when building for win32*. Otherwise, ld will refuse to create the DLL. This may involve restructuring the code, and possibly changing the division of labor between various DLLs if your project has multiple interdependent ones. It is *very* difficult to build stuff on win32 where you have circular dependencies between DLLs, or between DLLs and an EXE -- not impossible, just very difficult. (*) Now, if you are going to go thru all that trouble to support win32...you'd just be making a lot of extra work for yourself to maintain TWO separate library structures -- one for win32 (and, btw, AIX) where everything is no undefined symbols clean, and one for everything else where undefined symbols are allowed. So...most projects that end up in this place (**), finally decide to restructure their shared libraries for *ALL* platforms. Notice I haven't said anything about libtool yet. 2) Once you've gone thru the exercise in #1, now you might as well add -no-undefined unconditionally to your libtool invocation -- if you are using libtool, that is. Remember, all the stuff in #1 is required just to build DLLs on win32 *at all*, libtool or no libtool. (*) You basically have to create an export file for DLL A (or the EXE), and an import lib for it. THEN, you can build DLL B as normal, and specify -lDLLA (or -lEXE). Finally, you build the real DLL A (or EXE), and specify -lDLLB. Libtool has /no/ direct mechanism to support this. (**) Except for those that use a plugin architecture, where the plugin DLLs *must* be able to call back to the EXE. That's really tricky, and they usually end up using another solution, of which there are several (see http://edll.sourceforge.net/ for a good description of several different approaches). But that's outside the scope of our discussion here. -- Chuck ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool shouldn't switch to creating static library if it can't create the shared one under Windows
On 6/20/2011 3:32 AM, Marco atzeri wrote: Hi Chuck, I guess func_win32_libid() is not failing but the gcc/linker is smarter than libtool expect; or that autoconf is misleading libtool. /lib/gcc/i686-pc-cygwin/4.3.4/libgfortran.a /lib/gcc/i686-pc-cygwin/4.3.4/libgfortran.dll.a /lib/gcc/i686-pc-cygwin/4.3.4/libgfortran.la /lib/gcc/i686-pc-cygwin/4.3.4/libgfortranbegin.a /lib/gcc/i686-pc-cygwin/4.3.4/libgfortranbegin.la libgfortran is available as dynamic and static, while libgfortranbegin is only static libgfortranbegin.a is included as object in the build of the dll/exe, while libgfortran.dll.a is used for the linking with cyggfortran-3.dll Hm. This is a big, general problem: it means you libtool can't build ANY fortran DLLs -- because they will all need libfortranbegin.a IIRC, the fortran startup object used to be *an object*, so it didn't trigger this problem. We're really collecting more and more reasons to rewrite the support in libtool for the gcc compiler to just use $(CC) (or $CXX, etc) to link, and NOT muck around with detecting all these objects and compiler runtime libs and crud -- which we currently do so that libtool can link using $(LD) directly. Now, even if we DID do that, it won't fix the problem below: Similar thing happens for the few libraries that are available only as static like SuiteSparse checking for ccolamd in -lccolamd result: yes so CCOLAMD_LIBS = -lccolamd But Suitesparse libs are only static: /usr/lib/libamd.a /usr/lib/libbtf.a /usr/lib/libcamd.a /usr/lib/libccolamd.a /usr/lib/libcholmod.a /usr/lib/libcolamd.a /usr/lib/libcsparse.a /usr/lib/libcxsparse.a /usr/lib/libklu.a /usr/lib/libspqr.a /usr/lib/libumfpack.a so they are included as objects in the dll build. Well, in this case, libtool is doing what it is programmed to do: don't allow DLLs to depend on static libs. As I said earlier, this is in general a good rule for win32. You've found a case where this heuristic fails, and violating it does not /appear/ to cause any problems for this particular application. I think, in this case, overriding the autoconf variable as you are doing is actually the right procedure! I'm leery of making this a configure option (--allow-static-deps) because then the uninitiated might use it all the time...and invariably they WILL run into the problems I warned about. For your notice, building octave with lt_cv_deplibs_check_method=pass_all works fine and the program pass all the tests, while without it the program is unusable. But we still have the problem with fortran DLLs in general. Sigh. -- Chuck ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool shouldn't switch to creating static library if it can't create the shared one under Windows
On 6/17/2011 10:19 AM, Vadim Zeitlin wrote: On Thu, 16 Jun 2011 19:10:39 -0500 (CDT) Bob Friesenhahn bfrie...@simple.dallas.tx.us wrote: BF Most projects using libtool come from Unix/Linux where auto-import BF is the default so it can be seen that most projects already depend on BF it My personal experience seems to contradict it. Maybe because auto-import is relatively recent It was developed back in 2000, and all cygwin and mingw compilers since that date have supported it, EXCEPT for the old msys gcc-2.95.1 toolkit which was used to create *msys* executables up until 2009. or maybe because most originally Unix projects that target Windows (meaning not only Cygwin but usually MinGW as well and sometimes even MSVC) need to fix other Windows-specific issues anyhow and so do make the relatively small extra effort to add the necessary declspecs too. This. IF -- and usually ONLY if -- the upstream maintainers have ported to *msvc* FIRST, then they have added the declspec stuff. Then, when it comes to supporting mingw, they have a choice: do things the unix way and DON'T activate the declspec stuff and use autoimport instead, OR, do things the MSVC way. My experience has been that this decision usually goes the win32 way, but a significant fraction go the unix way for mingw. The alternate path is this: the upstream maintainers port to mingw FIRST, and fix the obvious things like using _mkdir(one arg) instead of mkdir(two, args) -- but don't want to uglify their headers with declspec. THEN, they port to msvc and are forced to uglify. At that point, they have a new choice: do they retrofit the declspec stuff for their existing mingw build, or not. Most do not. Obviously, packages developed originally on/for windows have the declspec stuff, and usually keep it turned on for msvc and mingw. Anyhow, this is purely anecdotal and it's going to be hard to find an objective way of determining whether it's the case. True. A more interesting question is if the current situation with libtool can be improved because I continue to believe that getting a static library when you're trying to build a shared one can be very unexpected. And this can be the case even under Unix where there would be presumably too much resistance to change the way --disable-static works if it is controversial even under Windows where I thought it would be obviously correct. So it seems the only solution with any chance of acceptance would be to add a different option doing what I want, e.g. --enable-shared-only. Or maybe allow --enable-shared=(yes|no|only)? No, I think --disable-static, if specified, should actually *disable static*. That should be sufficient. If it's not doing that, then it's a bug IMO. -- Chuck ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool shouldn't switch to creating static library if it can't create the shared one under Windows
On 6/17/2011 11:03 AM, Marco atzeri wrote: Sorry Chuck, but I can assure you that I am linking against shared dlls, but the detection is incorrect. Well, then that's a bug. Can you give an example of a foo.a, foo.dll.a, and foo-N.dll (plus the -lfoo incantation) you're using for which the detection fails? Maybe we can figure out why func_win32_libid() is failing. -- Chuck ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Shared library versioning
On 6/16/2011 2:50 PM, Lasse Collin wrote:
About -version-info vs. -version-number: *If* it turns out that all
operating systems supported by Libtool should use a versioning style
that is essentially the same as version_type=linux, could
-version-number become the recommended option to set the library
version?
Oh, please god, no. On windows and cygwin, where (a) symlinks can't be
used for DLL resolution, and (b) there is no ld.conf/ld.so to manage
versions, we REALLY depend on a sane numbering system, because it gets
embedded into both the name of the DLL and its clients. (Remember:
unlike the *nix schemes, no redirecting via symbolic links is allowed)
Major:minor:revision is easier to understand than current:revision:age,
Major:minor:revision artificially entangles package release numbering
with API/ABI changes. Typically when one 'goes up' so does the other,
but not always -- and not by the same increment.
And what if...your package has two different libraries, and only one of
them had an ABI change?
which in practice is (major+minor):revision:minor.
ONLY if you slavishly follow the one particular scheme for your package
version numbering. I'll point out that linux itself (the kernel)
doesn't follow that scheme. Nor does TeX. And what if you increment
package $major because your *application* has had a major new
functionality addition, AND its command line interface has changed...but
the DLL hasn't changed at all? Why should the DLL soname be changed
just because one of its clients has a new set of cmdline options?
Actually, that particular scheme ('bump major for ABI breaks; bump minor
for significant new features, bump micro for bugfixes') is honored more
in the breach than actually followed...Many projects appear to
(accidentally?) break library ABIs with minorver updates...and sometimes
majorver updates don't modify the ABI at all but simply represent a big
new feature addition -- or a promotion to 'stable' (**)
Using a scheme that
is easier to understand would hopefully reduce mistakes in library
versioning.
No, it just ensures that the version numbers associated with shared
libraries will ALSO be infected with marketing-induced version inflation.
current:revision:age is VERY simple -- if you bother to read the libtool
manual (a tall order, for some project maintainers, I'll grant you).
But the key point is, *library* version numbers should be entirely
unrelated (*) to the *package* version numbers (**).
(*) except in the most vague sense of 'when ones goes up, the other one
might go up too. Maybe.'
(**) Which is why I was mildly annoyed when xz-5.0-final was published,
and included a wholly unnecessary version bump from 0:0:0 to 5:0:0.
Granted, it helped *me* out because I was already using 1:0:0 on cygwin
due to an ABI change in the prereleases. Anyway, my annoyance was only
mild, because you had announced that soname plan LONG before the event,
so we were well prepared for it.
--
Chuck
___
https://lists.gnu.org/mailman/listinfo/libtool
Re: -no-undefined vs gcc 4.6.0
On 3/19/2011 6:25 AM, LRN wrote: I expect to find a lot of libtool-using projects that will require such hacks or workarounds, because `unrecognized option '-no-undefined'' is very common. Ah, but actually -no-undefined should be added by the upstream maintainers, in Makefile.am, to libfoo_la_LDFLAGS. It is a *description* of the library -- which is true regardless of the host platform the library is being built for. It is a claim by the library designer that: This library, when linked, will not reference any symbols, unless they are defined either in its own source objects or in other explicitly listed dependencies In order to build a library on win32/cygwin, libtool requires that the library designer assure it of this fact. So, either a library DOES or DOES NOT satisfy the claim: if it doesn't, then it can't be built on windows without massive surgery. If it does, then it does no harm to tell ALL platforms that it does so -- thus, upstream should add -no-undefined to their Makefile.am/libfoo_la_LDFLAGS. This declaration is usually NOT passed via an explicit variable statement on the make or configure command line. -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Stop relink searching host directory when installation prefix provided
On 1/17/2011 8:23 AM, Martin Panter wrote: On 16 January 2011 17:23, Charles Wilson wrote: Actually, Ralf's example (or one very similar to it) is the *primary* use of DESTDIR. It's how many packaging tools -- like rpm, or cygport on cygwin -- create installable binary packages. Agreed, that example already tends to work with unmodified Libtool. I want to get cross-compiled installable binary packages working as well. Right, but if you remove the $DESTDIR/$libdir from the relink command, then you'd break these native builds (because, e.g. /usr/lib is still in the compiler's default search path). For instance, suppose you're building gettext: it installs several so's (with interesting dependencies between them) AND a bunch of executables that depend on THOSE so's. If you use $DESTDIR, and need to relink, but don't include $DESTDIR/$libdir in the -L spec, then you'd relink the executables (and so's with internal dependencies) against the versions installed by gettext-$OLDVER in /usr/lib. If the new apps depend on any added/new interfaces...boom. -- Chuck
Re: Stop relink searching host directory when installation prefix provided
On 1/16/2011 12:13 PM, Ralf Wildenhues wrote: (I for one often do 'make install DESTDIR=/tmp/dest' merely to tar up the installation tree to be scp'ed to another machine where the NFS share is mounted rw.) Actually, Ralf's example (or one very similar to it) is the *primary* use of DESTDIR. It's how many packaging tools -- like rpm, or cygport on cygwin -- create installable binary packages. -- Chuck
Re: func_convert_file_cygwin_to_w32 woes
On 1/7/2011 3:02 AM, Peter Rosin wrote: Den 2011-01-06 21:29 skrev Ralf Wildenhues: * Peter Rosin wrote on Tue, Jan 04, 2011 at 05:44:58PM CET: Before I tie up the lose ends with this patch, I wonder if Ralf (or someone else) could tell me if I should also fix the other assignments of old_archive_cmds -- such as in the below snippet -- or is that completely irrelevant? I wouldn't change them without being sure that the changes are necessary. Well, they are necessary, but in cases which are, errhm, convoluted... Such as: win32-hosted cross-tools (I mean native win32 here, not dependent on Cygwin or MSYS) for targeting irix (or whatever) and running them from Cygwin (or Wine) instead of MSYS. I think I'll skip the extra changes, as someone doing the above needs a clue-bat anyway. Err...that's not really uncommon. Take the following fer-instance: 1) You use a vendor-provided gcc for your fav embedded target 1a) naturally, it's a MinGW-$foo cross compiler 2) But, you like to work from a cygwin shell because it doesn't suck as bad as dosbox, and provides tools that MSYS does not. Now, MOST of the time, if you're using a vendor-provided compiler, you're also going to use the vendor-provided IDE, so...the fact that you like to play in the cygwin shell doesn't matter; the IDE doesn't use your shell anyway. But...if you step outside of the IDE...say, you just want to use the normal configure/make process with --host=$foo CC=/path/to/vendor/bin/gcc, since you don't really want to set up an IDE project for $third-party-package-with-perfectly-good-autoconfigury, do you really need a cluebat? Don't do that, download and install the (limited in functionality compared to cygwin) MSYS environment, even though you are not using real MinGW gcc, but a vendor toolchain? Or...a few more, already identified and well-understood changes in libtool? -- Chuck
Re: func_convert_file_cygwin_to_w32 woes
On 1/7/2011 1:18 PM, Ralf Wildenhues wrote: Err...that's not really uncommon. [...] OK, but I still would accept those kinds of changes to code for little-used system only when someone has actually *tested* them in that particular situation, and found the code to be erroneous prior patch and working afterwards. We've been pestering other users to try out our patches for a good reason, I don't see why this should be treated less strict. OK, I'll add it to my list to create a mingw-linux compiler at home, and use it to build (e.g.) libtool-enabled libpng from a cygwin shell. (mingw-linux as a stand-in for mingw-$embedded since I can only do this sort of thing at home, rather than at work where I have access to mingw-$embedded). Or maybe I'll look into an Android dev env (which is mingw-android) instead, and try to use it from cygwin. But...it probably won't happen soon. -- Chuck
Re: Fix cwrapper test failure with --disable-static.
On 11/10/2010 1:29 PM, Ralf Wildenhues wrote: -AT_CHECK([$LIBTOOL --mode=compile --tag=CC $CC $CPPFLAGS $CFLAGS -c m.c], - [], [ignore], [ignore]) +AT_CHECK([$CC $CPPFLAGS $CFLAGS -c m.c], [], [ignore], [ignore]) AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o m1$EXEEXT m.$OBJEXT foo/liba.la], [], [ignore], [ignore]) Wouldn't a better fix be to change the link command to reference m.lo instead of m.$OBJEXT ? -- Chuck
Re: Fix cwrapper test failure with --disable-static.
On 11/10/2010 4:07 PM, Ralf Wildenhues wrote:
* Charles Wilson wrote on Wed, Nov 10, 2010 at 09:46:54PM CET:
Wouldn't a better fix be to change the link command to reference m.lo
instead of m.$OBJEXT ?
That would be an alternative, but it would mean that we (needlessly) use
PIC code on systems where non-PIC is turned off by default (or
--disable-static was used).
I thought that in those cases, the .lo file would redirect to the
regular, non-pic .o but I guess what actually happens is that you get
neither the .lo NOR the .libs/.o pic file, and you see only the non-pic .o.
automake-generated code also compiles
program sources without libtool, so the change was, to me, the canonical
one.
Meh...only if the target is explicitly *.o If it's .lo, then
$(LTCOMPILE) is used, and then libtool generates either or both of the
.o's itself, as determined by the system defaults and/or
--enable-{shared,static}.
Is there a portability issue associated with it?
I don't think so. It was simply a stylistic question: we're testing
libtool, so...use libtool. :-)
--
Chuck
Re: DLL creation and static libs
On 11/2/2010 2:14 AM, Ralf Wildenhues wrote: OTOH, if the w32 maintainers agree, then we can also give in and allow linking against static libraries plainly. I tried the trivial patch (set deplibs_check_method to pass_all) a while ago but that caused a number of test failures, so somebody would at least have to look into this issue. the problem is there are TWO different libuuid's. There's the one that is part of the win32 api, and simply contains a number of static objects that represent UUIDs of elements of the Windows OS. [1] Then, there's the unix-derived one that provides routines for *generating* new UUIDs. [2] [1] On cygwin this is /usr/lib/w32api/libuuid.a (On mingw, it's /usr/lib/libuuid.a). In both cases, it IS a static library, not an import library. [2] On cygwin, this is /usr/lib/libuuid.[a,dll.a]. To my knowledge, there is no corresponding element for mingw. So...the special casing is going to be pretty complex, because you don't want to treat cygwin's unix-derived /usr/lib/libuuid* differently than any other library, but mingw's /usr/lib/libuuid.a and cygwin's /usr/lib/w32api/libuuid.a would both need the special treatment. (FYI: we'd also need to add similar logic to binutils' ld, to special case the auto-export). -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: [PATCH] tests: don't use assert/abort on MSVC as they are interactive.
On 10/20/2010 2:31 AM, Peter Rosin wrote:
Den 2010-10-05 13:33 skrev Peter Rosin:
I have implemented exactly that and just posted this to the MinGW patch
tracker:
http://sourceforge.net/tracker/index.php?func=detailaid=3081421group_id=2435atid=302435
The silence is deafening.
Chuck, have you looked at this?
Yes, I have -- but MSYS patches are Cesar's domain. I guess I could
ping him...
wait...
Looks like Cesar responded earlier today. Coincidence?
I understand wanting to keep the current (popup-showing) behavior for
most MSYS process trees, since many users may rely on that information
to indicate real problems.
I wish there was some way to activate your patch other than launching
the top-level shell/window thru a run.exe-like starter app...but since
it has to be done before any other msys apps in the process tree start,
that means it probably should be done inside msys.bat itself (via an
--option?) somehow.
However, msys.bat launches its target (either rxvt or bash) via the
win32 program start.exe. So, we could launch the target using EITHER
start.exe OR your wrapper, depending on --no-popups. But then the
wrapper would need to be a lot smarter (e.g. use CreateProcess instead
of execve, so that it can set the CONSOLE hiding flags...but then, THAT
would use a different startup path inside msys.dll, and your patch
wouldn't activate!)
So, I don't think there is a better way than
error_mode.exe -cgf C:/mingw/msys/1.0/msys.bat [--rxvt]
if we (MSYS) want to preserve existing popup-showing behavior at all --
which I think we do. MAYBE the following (pseudo-bat-code, where
MSYS_NOPOP is set based on --no-popups arg to .bat file):
if x%MSYS_NOPOP% == x goto startrp
start %WD%error_mode -cgf /bin/rxvt {other args}
exit
:startrp
start %WD%rxvt {other args}
exit
with similar changes for the --no-rxvt case. It's sorta clunky, but it
might work.
But...that's something for the msys-dvlpr list to hash out.
Technically, I think your patch is fine.
--
Chuck
[SCM] GNU Libtool branch, master, updated. v2.4-10-gb76bfa8
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.
The branch, master has been updated
via b76bfa87f56ee9491b77a10ce6fcfd3ec09bd7c8 (commit)
from c161010e9deec544410a3e91d105d07ed9ec9911 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
commit b76bfa87f56ee9491b77a10ce6fcfd3ec09bd7c8
Author: Roumen Petrov bugtr...@roumenpetrov.info
Date: Sun Oct 3 17:15:17 2010 -0400
Add test case for 69e77671 (cwrapper PATH manipulation order)
* tests/cwrapper.at: Add new test 'cwrapper and installed shared
libraries.'
Signed-off-by: Charles Wilson libt...@cwilson.fastmail.fm
---
Summary of changes:
ChangeLog |6
tests/cwrapper.at | 67 +
2 files changed, 73 insertions(+), 0 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index c0492fe..9caba84 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2010-10-07 Roumen Petrov bugtr...@roumenpetrov.info
+
+ Add test case for 69e77671 (cwrapper PATH manipulation order)
+ * tests/cwrapper.at: Add new test 'cwrapper and installed shared
+ libraries.'
+
2010-10-04 Peter Rosin p...@lysator.liu.se
cwrapper: split long lines when dumping the wrapper script.
diff --git a/tests/cwrapper.at b/tests/cwrapper.at
index cd618dc..6e8cf3c 100644
--- a/tests/cwrapper.at
+++ b/tests/cwrapper.at
@@ -194,4 +194,71 @@ AT_CHECK([grep ' *fputs' $objdir/lt-usea.c /dev/null])
# Check for no overly long fputs.
AT_CHECK([grep ' *fputs.\{250\}' $objdir/lt-usea.c], [1])
+
+AT_CLEANUP
+
+
+AT_SETUP([cwrapper and installed shared libraries])
+AT_KEYWORDS([libtool])
+
+# make sure existing libtool is configured for shared libraries
+AT_CHECK([$LIBTOOL --features | grep 'enable shared libraries' || exit 77],
+[], [ignore])
+
+LDFLAGS=$LDFLAGS -no-undefined
+
+inst=`pwd`/inst
+libdir=$inst/lib
+bindir=$inst/bin
+mkdir $inst $libdir $bindir
+
+# Build the library in a separate directory to avoid the special case
+# of loading from the current directory.
+
+mkdir foo
+cd foo
+# build and install old library version
+AT_DATA([a.c], [[
+int liba_ver (void) { return 1; }
+]])
+AT_CHECK([$LIBTOOL --mode=compile --tag=CC $CC $CPPFLAGS $CFLAGS -c a.c],
+ [], [ignore], [ignore])
+AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -version-info=0.0.0 -o
liba.la -rpath $libdir a.lo],
+ [], [ignore], [ignore])
+AT_CHECK([$LIBTOOL --mode=install $lt_INSTALL liba.la $libdir],
+ [], [ignore], [ignore])
+
+# build a new library version
+AT_DATA([a.c], [[
+int liba_ver (void) { return 2; }
+]])
+AT_CHECK([$LIBTOOL --mode=compile --tag=CC $CC $CPPFLAGS $CFLAGS -c a.c],
+ [], [ignore], [ignore])
+AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -version-info=0.0.0 -o
liba.la -rpath $libdir a.lo],
+ [], [ignore], [ignore])
+
+cd ..
+
+# build and run test application
+AT_DATA([m.c], [[
+extern int liba_ver (void);
+int main (void)
+{
+ int r = (liba_ver () == 2) ? 0 : 1;
+ return r;
+}
+]])
+
+AT_CHECK([$LIBTOOL --mode=compile --tag=CC $CC $CPPFLAGS $CFLAGS -c m.c],
+ [], [ignore], [ignore])
+
+AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o m1$EXEEXT m.$OBJEXT
foo/liba.la],
+ [], [ignore], [ignore])
+LT_AT_EXEC_CHECK([./m1], [0], [ignore], [ignore], [])
+
+AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o m2$EXEEXT m.$OBJEXT
foo/liba.la -L$inst/lib],
+ [], [ignore], [ignore])
+LT_AT_EXEC_CHECK([./m2], [0], [ignore], [ignore], [])
+
+
AT_CLEANUP
hooks/post-receive
--
GNU Libtool
Re: [PATCH] Add test case for 69e77671 (cwrapper PATH manipulation order)
On 10/4/2010 1:14 AM, Ralf Wildenhues wrote:
OK with nits addressed. You may want to use a ChangeLog and/or --author
entry that suitably documents the main author of the patch.
Updated and pushed as attached.
--
Chuck
diff --git a/ChangeLog b/ChangeLog
index c0492fe..9caba84 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2010-10-07 Roumen Petrov ...
+
+ Add test case for 69e77671 (cwrapper PATH manipulation order)
+ * tests/cwrapper.at: Add new test 'cwrapper and installed shared
+ libraries.'
+
2010-10-04 Peter Rosin ...
cwrapper: split long lines when dumping the wrapper script.
diff --git a/tests/cwrapper.at b/tests/cwrapper.at
index cd618dc..6e8cf3c 100644
--- a/tests/cwrapper.at
+++ b/tests/cwrapper.at
@@ -194,4 +194,71 @@ AT_CHECK([grep ' *fputs' $objdir/lt-usea.c /dev/null])
# Check for no overly long fputs.
AT_CHECK([grep ' *fputs.\{250\}' $objdir/lt-usea.c], [1])
+
+AT_CLEANUP
+
+
+AT_SETUP([cwrapper and installed shared libraries])
+AT_KEYWORDS([libtool])
+
+# make sure existing libtool is configured for shared libraries
+AT_CHECK([$LIBTOOL --features | grep 'enable shared libraries' || exit 77],
+[], [ignore])
+
+LDFLAGS=$LDFLAGS -no-undefined
+
+inst=`pwd`/inst
+libdir=$inst/lib
+bindir=$inst/bin
+mkdir $inst $libdir $bindir
+
+# Build the library in a separate directory to avoid the special case
+# of loading from the current directory.
+
+mkdir foo
+cd foo
+# build and install old library version
+AT_DATA([a.c], [[
+int liba_ver (void) { return 1; }
+]])
+AT_CHECK([$LIBTOOL --mode=compile --tag=CC $CC $CPPFLAGS $CFLAGS -c a.c],
+ [], [ignore], [ignore])
+AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -version-info=0.0.0 -o
liba.la -rpath $libdir a.lo],
+ [], [ignore], [ignore])
+AT_CHECK([$LIBTOOL --mode=install $lt_INSTALL liba.la $libdir],
+ [], [ignore], [ignore])
+
+# build a new library version
+AT_DATA([a.c], [[
+int liba_ver (void) { return 2; }
+]])
+AT_CHECK([$LIBTOOL --mode=compile --tag=CC $CC $CPPFLAGS $CFLAGS -c a.c],
+ [], [ignore], [ignore])
+AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -version-info=0.0.0 -o
liba.la -rpath $libdir a.lo],
+ [], [ignore], [ignore])
+
+cd ..
+
+# build and run test application
+AT_DATA([m.c], [[
+extern int liba_ver (void);
+int main (void)
+{
+ int r = (liba_ver () == 2) ? 0 : 1;
+ return r;
+}
+]])
+
+AT_CHECK([$LIBTOOL --mode=compile --tag=CC $CC $CPPFLAGS $CFLAGS -c m.c],
+ [], [ignore], [ignore])
+
+AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o m1$EXEEXT m.$OBJEXT
foo/liba.la],
+ [], [ignore], [ignore])
+LT_AT_EXEC_CHECK([./m1], [0], [ignore], [ignore], [])
+
+AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o m2$EXEEXT m.$OBJEXT
foo/liba.la -L$inst/lib],
+ [], [ignore], [ignore])
+LT_AT_EXEC_CHECK([./m2], [0], [ignore], [ignore], [])
+
+
AT_CLEANUP
Re: GNU Libtool 2.4 released [stable]
On 10/1/2010 4:22 PM, Alon Bar-Lev wrote:
On Fri, Oct 1, 2010 at 3:35 PM, Charles Wilson
please-don't-feed-the-spammers wrote:
^^^
Please, over the past three months there were hundreds of messages
discussing sysroot and how it shoold be handled. While libtool's
support is not yet complete, what IS there is the result of those
discussions. Please read them; I have a suspicion you don't quite grok
what sysroot is really FOR, so your assumptions about how it
should/shouldn't/does/doesn't work are somewhat flawed.
You assume wrong.
I use cross compilers as much as I use native ones.
Then why was your example, demonstrating how sysroot should work,
shown as using native tools? I don't know of a single distributor that
enables sysroot support in their native toolchain.
And...sysroot support, per se, is still very very new even in GCC. But,
gcc cross compilers with sysroot support is the primary milieu for which
libtool's own sysroot stuff was implemented.
This why I waited and followed for long libtool's lacking support in
these environments.
I guess you know better and sure that all OK, this ends the discussion
before it started.
No. It's just that your statements, and your *example*, lead one to
believe that you were approaching the sysroot issue from a perspective
OTHER than the one for which libtool's implementation was designed.
IF you have an issue with that design, AND you were following for long
libtool's development of it...why didn't you chime in three months ago?
Anyway, sysroot and cross compile sysroot can be the same, however,
making the cross compiler sysroot dirty, may cause undesirable
results, especially in build machines.
See, this is exactly what I'm talking about. The whole POINT of
libtool's sysroot is so that you CAN install the built libs into the
compiler's sysroot, so that they can be automatically used there when
building OTHER libs and apps that depend on them. It's not making it
dirty...
Here comes the DESTDIR to the
rescue.
And you can STILL use DESTDIR if you like. However, if you are trying
to create *multiple* sysroots that can be used by the same compiler (at
different times, obviously)...then you can do this:
set CFLAGS+=--sysroot=/my/sysroot1
(similar for CPPFLAGS, CXXFLAGS, LDFLAGS, etc)
That way, your compiler will use the correct sysroot. Then, you can
also ensure that *libtool* knows to turn on sysroot support for
linking .la files, by configuring whatever it is you are building with
libtool's --with-sysroot=/my/sysroot1 option.
(I'm not sure if you can get away with just --with-sysroot; it OUGHT to
work, since `$(CC) $(CFLAGS) -print-sysroot` (that is, `gcc
--sysroot=/a/b/c -print-sysroot` should return '/a/b/c', but I'm not
sure about that.)
But you know better...
Possibly. Possibly not. I do know that I've been participating in this
discussion for months now, and testing multiple libtool patchsets
related to sysroot in dozens of configurations with a handful of cross
compilers on a couple of $build platforms...and you have been silent.
So I have no idea what you do or do not know. All I can go by is what
you've said in this thread.
Which didn't start off well:
Also, why not take the value of the sysroot from the DESTDIR automake
variable?
DESTDIR != sysroot. It is similar, but *different*, and behaves in a
different way. (And I'm talking here about how gcc/binutils use the
term; regardless of how libtool addresses the issue). With DESTDIR, you
still have to ensure that your CFLAGS includes
-I$DESTDIR/$prefix/include and LDFLAGS includes
-L$DESTDIR/$prefix/lib. Worse, those paths leak into your compiled
results. With sysroot, IF it is done correctly, you shouldn't need to
specify EITHER of those things, since $sysroot/$prefix/{include,lib} is
already IN the (cross)compiler's default search path. So, no leakage;
all you need is to tell the compiler that it ought to use $DESTDIR for
the sysroot. (And, of course, if you use the default sysroot, you don't
need to tell it anything; it'll Just Work(tm)).
What if I wanted to build an SDK for linux-mingw, that a client
(developer) could install in THEIR compiler's (default) sysroot on
linux? I'd need a DESTDIR in /tmp/ where I could package it up, but
underneath that DESTDIR I'd still need to see both the sysroot and the
prefix:
/tmp/my-build/usr/i686-pc-mingw32/sys-root/mingw/{include,lib,...}
^ ^^^
DESTDIR sysrootprefix (on $host)
Then, I'd create my RPM/deb from /tmp/my-build, so that Sally can
install on her linux box, and it would all end up in
/usr/i686-pc-mingw32/sys-root/mingw/{include,lib,...}
just like it's supposed to. Then, when she uses her i686-pc-mingw32-gcc
to build the bar.exe client of libfoo (for the mingw $host), the new
libs and headers will be found. Now, the libfoo.la file in
/usr/i686-pc-mingw32/sys-root/mingw/lib
might contain
Re: GNU Libtool 2.4 released [stable]
On 9/30/2010 7:19 AM, Paolo Bonzini wrote: Note that it's perfectly possible to use .la files on the final system that didn't go through libtool --mode=finish, as long as all the packages you compile are upgraded to Libtool 2.4 (and IIUC, cygwin's packaging system for example is already re-libtoolizing each package, so it's not that hard to do this). Except that we still haven't added '=' support to libltdl. -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: [PATCH] tests: don't use assert/abort on MSVC as they are interactive.
On 9/29/2010 4:06 AM, Peter Rosin wrote: Cygwin is always running with this error mode (I think), MSYS is not. Cygwin no longer supports Win9x, MSYS does. Will this patch cause any issues if people try to use libtool + MSYS on a Win9x system? -- Chuck
Re: [PATCH] tests: don't use assert/abort on MSVC as they are interactive.
On 9/29/2010 10:15 AM, Peter Rosin wrote: Den 2010-09-29 15:47 skrev Charles Wilson: Will this patch cause any issues if people try to use libtool + MSYS on a Win9x system? I don't foresee any problems, because SetErrorMode is really old. You were worrying about the entry point not being there, right? Right. Sadly, MSDN no longer even references things that old; from reading it, you'd think that *nothing* existed prior to w2k, and *every* current entry point was brand new with that version. SetErrorMode: Minimum Supported Client: Windows 2000 Professional So it's no longer even possible to discover exactly HOW old an API is, if it predates w2k. At least, not via MSDN. -- Chuck
Re: [PATCH] tests: import variables for MSVC.
On 9/23/2010 6:25 PM, Peter Rosin wrote: I don't know how to set up the defines so that EXTERN becomes 1. extern when you use a static library 2. extern when you build a static library 3. extern declspec(dllimport) when you use a shared library 4. extern declspec(dllexport) when you build a shared library I could fix 2 and 4, but separating 1 and 3 is not possible. Since extern declspec(dllimport) works everywhere with MSVC I'm taking the easy option with this patch. Or should I add -DBUILDING_FOO to Makefile.am and variations of the below to the code? That is the typical approach. The drawback -- usually an acceptable one -- is that if you are building a stack of dependent DLLs: EXE -- C.DLL - B.DLL -- A.DLL Then (a) you must link exe using .obj's compiled as pic (e.g. with -DDLL_EXPORT, even tho the EXE *itself* is not a shared library). libtool does this by default IIRC. (b) You MUST link EXE against shared C.DLL and shared A.DLL; you can't link against static C.lib and B.lib, but dynamic A.DLL, or vice versa (because DLL_EXPORT, for EXE's objs, either IS, or IS NOT, defined). We already enforce the restriction that C.DLL can't depend on B.lib, so that complication is a non-issue. #ifdef _MSC_VER # ifdef BUILDING_FOO # ifdef DLL_EXPORT # define EXTERN extern declspec(dllexport) # endif # else # define EXTERN extern declspec(dllimport) # endif #endif #ifndef EXTERN # define EXTERN extern #endif More indepth review against your revised version. -- Chuck
Re: [PATCH] tests: import variables for MSVC.
On 9/24/2010 8:44 AM, Peter Rosin wrote:
Yes indeed, I intended __declspec. I have revised the patch so that it
handles building correctly (dllexport for dlls, not for static) and
using the best way possible (still dllimports from from both dlls and
static libs).
Well, I'm confused. The linker really ought to fail in this case, since
dllimport mangles the symbol name IIRC -- and the mangled name is not
present in the static lib.
For Cygwin I removed some dead code in tests/pdemo,
similar code was deleted from tests/demo back in 2002 (see commit
45d16ee8bf4559d6b976bfd4d6482767f16eac95). I have verified that the
Cygwin related cleanup does not affect the Cygwin testsuite results.
Always good to know.
With this patch, the old testsuite SKIPs cdemo-undef and tagdemo-undef,
FAILs demo-deplibs(1) and all the rest PASS (on MSYS/MSVC). So it is
looking really nice.
That's great. (Still confused, tho).
That documentation would be nice, yes, and I plan to write something about
that eventually. Is it a prerequisite for pushing this?
IMO, we should probably document it before 2.4.2...
Of course, if libtool can somehow help with this any more, so much the
better. But I'm less optimistic on this than I was those five years
ago. :-/
Yes, and with auto-import in place for gnu tools on w32, the itch is gone
for a whole bunch of people.
Well, Bruno Haible still hates auto-import. He has wanted a certain
patch in libtool for a long time, but I still don't understand whether
doing so would break existing expectations and force everybody to use
his method, or if it would basically have no effect for most of us yet
enable his method...
http://www.haible.de/bruno/woe32dll.html
Also, may I remind you that you promised a number of testsuite additions
before the release.
I have been digging in the archives for quite a bit, but I'm only finding
http://lists.gnu.org/archive/html/libtool-patches/2010-09/msg00266.html
What else have I promised?
I think it was kinda given that the new functionality would need tests
(for anything not also covered by existing ones). Maybe manifests
('course, IIRC the end user needs to explicitly set MT before running
the testsuite, which is kindof odd).
Some of the promised tests are on my plate, and relate to
non-msvc-specific stuff, which msvc leverages.
Patch (as revised) is fine with me.
--
Chuck
Re: [PATCH] tests: import variables for MSVC.
On 9/24/2010 8:13 PM, Roumen Petrov wrote:
About pre-processor flags - better is C code to start with #define
BUIILD_FOO instead -DBUIILD_FOO in makefile.
No, actually, it is not better. The reason is, any given C file *might*
be used in a library, or it *might* be used in an application -- or
both, depending on compile flags. For instance, suppose you have a
utility library, where each function has a built-in self test:
int some_util_function() {
}
#if defined(PACKAGE_FOO_TESTING)
int main(int argc, char *argv[])
{
}
#endif
You wouldn't want to unconditionally define BUILDING_LIBUTIL in this
case. Now, certainly, you could do some magic like
#if !defined(PACKAGE_FOO_TESTING)
# define BUILDING_LIBUTIL
#endif
but...(a) this is a deliberately simple example, and (b) there's a
better way.
There is *one place* in the package where you KNOW which files are being
compiled for inclusion in a library, and which are not: and that's the
Makefile (or Makefile.am, or cmakefiles.list, or whatever) -- NOT the C
code itself. Why should you duplicate that knowledge in the source code
itself? What happens when you refactor a big library into multiple,
smaller libraries? With the Makefile approach, you simply reassign when
.c's go with which libfoo_SOURCES, and each libfoo_la_CFLAGS has a
different -DBUILDING_* -- and you don't have to modify any of the .c's
at all (you'd have to modify some .h's, but you'd need to do THAT
regardless).
Your way, this refactoring requires coupled changes in each and every .c
file -- because you put knowledge (about which library each .c file
belongs to -- inside each .c file itself, and that's the wrong place for
that knowledge. It *belongs* in the buildsystem (e.g. the Makefile).
--
Chuck
Re: [PATCH] tests: import variables for MSVC.
On 9/24/2010 8:06 PM, Roumen Petrov wrote: I would like to propose different macros for export/import of variables in format: #define XXX(type)decorator_before type decorator_after Why? Peter's formula is practically universal in most packages I have seen (ncurses is the only exception that springs to mind). What advantage does using an unusual decorator structure bring? It's not as if we're going to, in our demo/test code, start using __stdcall decorator_afters, are we? (Remember that we're only talking about how the test code is structured, not how libtool requires client code to be written. Clients would still be free if they chose to, to use XXX(type) macros). -- Chuck
Re: [PATCH] tests: import variables for MSVC.
On 9/24/2010 2:53 PM, Ralf Wildenhues wrote: Den 2010-09-24 19:30 skrev Charles Wilson: That is the typical approach. The drawback -- usually an acceptable one -- is that if you are building a stack of dependent DLLs: EXE -- C.DLL - B.DLL -- A.DLL Then (a) you must link exe using .obj's compiled as pic (e.g. with -DDLL_EXPORT, even tho the EXE *itself* is not a shared library). libtool does this by default IIRC. Huh? But automake won't go this way usually. With bin_PROGRAMS = foo foo_SOURCES = foo.c foo_LDADD = libc.la foo will be linked with foo.o (*not* created by libtool), and neither foo.lo nor .libs/foo.o will ever be created. Err...maybe you are right. I've been so used to auto-import (and now, even the warnings are suppressed with modern cygwin and mingw gcc/binutils), that I'm just used to it simply working. If I understand the process, the above would fail if libc.la had a shared library, but we linked foo using -disable-auto-import (e.g. or we were talking about MSVC.) More in my reply to Peter's message. -- Chuck
Re: [PATCH] tests: import variables for MSVC.
On 9/24/2010 2:46 PM, Peter Rosin wrote: Now I'm also confused. That's not good. /me double checks (see below) WHAT? It doesn't work as I stated!?! *ponders that for a bit* *scratches head* Ahh, you said libtool does this by default IIRC. If that's actually the case than that is what has have me fooled for years. Pay close attention to how libtool compiles (the single, only) main.o. Does it get the picflag (-DDLL_EXPORT) or not? As I've always understood it, *without* auto-import magic, you MUST have the following: 1) shared: a) a dll, compiled with declspec(dllexport) [or, create the DLL with an explicit .def file listing the exported symbols] b) the client *must* be compiled with declspec(dllimport) decorators on all symbols the client wants to use from the DLL 2) static a) a lib. Nothing should be compiled with declspec(dllexport), and obviously there is no .def file involved b) the client must NOT be compiled with declspec(dllimport) -- because then you get the missing __imp__foo error. So, your test case below doesn't surprise me. What DOES surprise me, is that it ever worked at all with MSVC (or gcc + -disable-auto-import), since it appears that Ralf is correct and the *_PROGRAM objects are built in only one mode. Whether that is picflag (-DDLL_EXPORT) or not, one or the other linking modality should fail (static linking if main.o is compiled with -DDLL_EXPORT; dynamic linking if main.o is NOT compiled with -DLL_EXPORT). So, yeah, I'm a little confused as well. I think you need to do some archeology on the *_PROGRAM objects (nm -B or whatever the equivalent is in msvc land), and figure out what symbols are undefined. I'd take a hard look at demo/. NOTE: Bruno Haible's method worked around this by ALWAYS defining symbols in a library as declspec(dllimport), when building the library shared, building the library static, OR building a client. BUT...to make linking the DLL itself work (with internal references to these dllimported symbols!), he uses some nm and asm magic to (a) manually define the __imp_* redirection symbol values and set them to point to the address of the actual symbol, and (b) explicitly export each exported symbol using an asm .drective, even tho it was marked dllimport. It's really rather clever, but I've never really figured out how to merge it into the typical auto*/libtool process (Bruno's libiconv and gettext do it, but with a lot of Makefile.am hackery). Second, I don't know if it would work with MSVC easily; certainly the asm magic would need modification. Third, it almost *requires* to build *everything* with --disable-auto-import. Which would NOT go over well with the larger community. So, I've never pursued it, and obviously Bruno hasn't pushed the issue. *deep sigh* Thanks for setting me straight. What now? Is the patch still good? (with a reworded changelog of course) Well, I think so. It's possible we might need a follow-on patch for strict correctness -- but this patch appears to be correct as far as it goes. But now I'm really confused. What made the original patch work? It had #define EXTERN extern __declspec(dllimport) unconditionally for MSVC. And that patch also had two SKIPs and one FAIL (libfoo.a vs. foo.lib). I.e. the exact same result, which means I can't be completely wrong. Or is the testsuite not doing any static builds? But that seems highly unlikely indeed. WTF? Look really closely at how hell_static.exe is built in demo/. But, to sum up, I see no problems with THIS patch, as far as it goes. With regards to Ralf's question re: _MSC_VER. Well, technically you'd probably be more correct to do: #if (defined(_WIN32) || defined(_WIN32_WCE)) !defined(__GNUC__) ... rather than _MSC_VER; that formula would indicate any win32 or wince platform, using any compiler EXCEPT gcc -- because only gcc has auto-import on win32. But nobody does that; pretty much all source code with pretensions of both cross-platform use, AND windows support, uses _MSC_VER (*badly* ported code uses _WIN32 to mean MSVC which causes no end of cygwin and mingw headaches!). Because of that, IIUC most users of other compilers for win32 (Intel C/C++, Watcom, Borland, etc) either (a) routinely s/_MSC_VER/__WATCOMC__/g, or (b) add -D_MSC_VER anyway. -- Chuck
Re: bogus warning 'seems to be moved'
Just FYI... I don't think the following scenario applies to either of you, but I ran into the warning in the case described below -- and the warning is valid (e.g. we shouldn't try to fix MY case). I was using a cross compiler with sysroot support (cygwin-mingw) to build cygwin's setup.exe. I was linking against some pre-built libraries (compression, gpg) built using that cross compiler, but using an older, pre-sysroot-support version of libtool. (E.g. these libs are NOT the mingw-libfoo packages currently available from cygwin.com). Anyway, so what I had was: /usr/i686-pc-mingw32/sys-root/mingw/lib/liblzma.la etc, but -- because the lib was built using a non-sysroot libtool, the .la file specifies libdir='/mingw/lib' NOT libdir='=/mingw/lib' So, when building setup.exe using a libtool that supports --with-sysroot, it (quite rightly) complains that liblzma.la appears to be moved -- because it (a) is NOT in /mingw/lib, and (b) doesn't have the magic '=' sysroot marker. This is as designed. The fix is for me to rebuild liblzma et al using a sysroot-capable libtool. Just wanted to point out this scenario, which has similar symptoms as those reported by Marco and Dave, but is NOT an error. -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: bogus warning 'seems to be moved'
On 9/24/2010 12:45 AM, Marco Atzeri wrote: I am not sure to follow your explanation. on cygwin $cd /usr/lib I'm cross building, using $build_os=cygwin, but $host_os=mingw32, and a cross compiler. I am *not* building natively. In this situation, and with the new sysroot support in libtool, .la files will have a magic marker like this: -L=/some/path, or libdir='=/some/path'. The extra '=' symbol is interpreted by (new) libtool, WHEN it too is told that sysroots are active, to mean: pretend /some/path is prefixed by whatever the sysroot of the current compiler is; e.g. 'i686-pc-mingw32-gcc -print-sysroot' might report: /usr/i686-pc-mingw32/sys-root So, if the .la file in /usr/i686-pc-mingw32/sys-root/mingw/lib/foo.la claims that its libdir should be =/mingw/lib, libtool will magically prepend the compiler's sysroot, and interpret the libdir specification AS IF it said libdir='/usr/i686-pc-mingw32/sys-root/mingw/lib' and not libdir='=/mingw/lib' Since that IS where the .la file is located, all is well and no warning is printed. However, WITHOUT sysroot support in libtool (or if the .la file doesn't have the magic '=' marker) none of this occurs, and libtool will print the warning. But...that's what it is supposed to do in this case. Now, I'm talking ONLY about a cross build situation. See (latest 2.4 libtool) info. There's a whole section about it. -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: [PATCH] msvc: eliminate spaces in the library search path.
On 9/21/2010 1:33 PM, Ralf Wildenhues wrote: Hi Peter, * Peter Rosin wrote on Tue, Sep 21, 2010 at 09:37:16AM CEST: I know it's late for the release, but I'd like to squeeze this one in too, if at all possible. After all, it doesn't affect anything but MSVC. I have questions: What does Charles have to say to this? Well, in principle -- so long as this code is activated only when $CC is MSVC -- the patch as revised is fine with me. What is $LIB? Is this an API you just made up? If not, where is it documented? Hmm, we used it before, so I guess that's not new. LIB and INCLUDE are MSVC's mechanisms for setting search paths; it's not something we libtoolers picked. + do +IFS=$lt_save_ifs +# Let DOS variable expansion print the short 8.3 style file name. +lt_path=`cd $lt_path cmd //C for %i in (.) do @echo %~si` Can you explain what this command does? I mean, no need to change the patch, but I don't understand the %~si syntax and I can only infer the %i and (...) bits, but can't tell whether they are correct, work by accident, or something else. I'm willing to believe you, but it would be nice to know for sure. See http://thread.gmane.org/gmane.comp.gnu.mingw.user/34276 Can the command fail? Sure -- if lt_path doesn't exist. I don't know if that is an issue in this particular case. It will also fail on Win9x (where cmd.exe doesn't exist, and command.com is supposed to be used). However, we already have that problem in func_convert_core_msys_to_w32. One workaround would be to use the %COMSPEC% variable in both cases, but...I'd rather go with cmd in both places, and then worry about %COMSPEC% after the release, and only if we get complaints. +sys_lib_search_path_spec=$sys_lib_search_path_spec $lt_path + done + IFS=$lt_save_ifs + # Convert to MSYS style. + sys_lib_search_path_spec=`$ECHO $sys_lib_search_path_spec | sed -e 's||/|g' -e 's| \\([[a-zA-Z]]\\):| /\\1|g' -e 's|^ ||'` Yes, sadly msys does not provide a program analogous to cygpath. So, we can go msys-win32 by exploiting msys's autoconvert behavior (by running a native win32 program cmd.exe with the args to be converted). But we can't go the other direction -- so, fun with sed scripts. The downside of this is that only the standard representation of paths will be used (e.g. C:/foo - /c/foo, etc). If there are any special mount points defined in MSYS's /etc/fstab -- for instance C:\PROGRA~1\MICROS~2/vizstudio You'll get /c/PROGRA~1/MICROS~2/whatever instead of /vizstudio/whatever. In practice, this should make no difference -- and there really isn't any way around it, without improvements/additions to MSYS. + ;; +cygwin*) + # Convert to unix form, then to dos form, then back to unix form + # but this time dos style (no spaces!) so that the unix form looks + # like /cygdrive/c/PROGRA~1:/cygdr... + sys_lib_search_path_spec=`cygpath --path --unix $LIB` + sys_lib_search_path_spec=`cygpath --path --dos $sys_lib_search_path_spec` + sys_lib_search_path_spec=`cygpath --path --unix $sys_lib_search_path_spec | $SED -e s/$PATH_SEPARATOR/ /g` Can any of the cygpath commands fail? What about LT_CYGPATH? If $build_os is cygwin, then cygpath.exe IS in the $PATH (or there is something *extremely* broken about your cygwin installation). So, for $build=cygwin, we can invoke cygpath directly. LT_CYGPATH is used when $build != cygwin, but there is a cygwin somewhere that is accessible. We can't use the func_conv functions here, because we're (a) going backwards in two cases, and (b) using the --dos flag instead of --windows or --mixed even when we're going in the right direction. + ;; +*) + sys_lib_search_path_spec=$LIB + if $ECHO $sys_lib_search_path_spec | [$GREP ';[c-zC-Z]:/' /dev/null]; then What if there is only a single directory in the path spec? Then there won't be a ';', and we'll use the else clause -- is that the right thing to do? +# It is most probably a Windows format PATH. +sys_lib_search_path_spec=`$ECHO $sys_lib_search_path_spec | $SED -e 's/;/ /g'` + else +sys_lib_search_path_spec=`$ECHO $sys_lib_search_path_spec | $SED -e s/$PATH_SEPARATOR/ /g` + fi -- Chuck
Re: 2.4 Release in 24hrs
On 9/20/2010 1:41 PM, Ralf Wildenhues wrote: I'd really appreciate if you guys could send build logs to the autobuild server... Here's what I use, more or less, to create the logs: ( ../libtool/configure [OPTIONS] \ make \ make -k check cat test-suite.log tests/testsuite.log if tail tests/testsuite.log | grep '^| ' /dev/null; then :; else sed 's/^/| /' config.log fi ) logfile $sanitize logfile mail libtool_autobuild.josefsson.org logfile with the underscore replaced by @. For now, OPTIONS includes autobuild_mode=bla if there is anything special about the build. See, that's what was missing. You had asked about a month ago for me to save all the logs from my various tests...but I had no idea what to DO with them. Anyway, those are all a month out of date, so I'll test the 2.4 release on those platforms and submit new reports. We should probably create some sort of reporting script (post 2.4, of course) and mention it (and its usage) in HACKING. Perhaps also in the message you get at the end of the new testsuite when there are failing tests. Right now that message says (for instance): = Please send `tests/testsuite.log' and all information you think might help: To: bug-libtool_gnu.org Subject: [GNU Libtool 2.2.11a] testsuite: 78 112 failed You may investigate any problem if you feel able to do so, in which case the test suite provides a good starting point. Its output may be found below `tests/testsuite.dir'. = -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: 2.4 Release in 24hrs
On 9/21/2010 9:21 PM, Gary V. Vaughan wrote: I don't recall having done so in a while but, according to bootstrap: # It is okay for the bootstrap process to require unreleased autoconf # or automake, as long as any released libtool will work with at least # the newest stable versions of each. Generally, newer versions offer # better features, and configure.ac documents oldest version of each # required for bootstrap (AC_PREREQ, and AM_INIT_AUTOMAKE). And in the release template in HACKING: You will then need to have recent (possibly as yet unreleased) versions of Automake and Autoconf installed to bootstrap the checked out sources yourself. So, I will install git automake at the front of my PATH, and if the release process works, then I'll go ahead and use it for the release. OK. If it's documented, then that's fine. Is there a better way to save rebootstrappers from accidental downgrade than specifying AM_INIT_AUTOMAKE([1.11a]) in libtool's configure.ac? Pity Automake doesn't use gnulibs `git-version-gen' so that I could specify the particular revision with the compile script patch that we want at libtool bootstrap time. Well, now that I think about it, it doesn't REALLY matter (to me). The only case, at this time, in which you need the compile script IN libtool to be latest-n-greatest is if you are building libtool itself using cl.exe/MSVC. I'm not. So...it doesn't matter if I downgrade the compile script by rebootstrapping with released automake. -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: 2.4 Release in 24hrs
On 9/20/2010 11:31 AM, Bob Friesenhahn wrote: On Sun, 19 Sep 2010, Charles Wilson wrote: MinGW/MSYS: old -- All 122 tests passed (2 tests were not run) new -- 108 tests behaved as expected. 12 tests were skipped. With Charles Wilson's assistance, I updated my MinGW environment to the latest, but using the latest TDM GCC 4.5.1 compiler (only C C++ supported). These were the results: ERROR: 102 tests were run, 6 failed (4 expected failures). 18 tests were skipped. The test which failed (twice) was the C++ exception handling test. Similar tests also failed in the GraphicsMagick test suite so it seems that C++ exceptions are unreliable with this compiler. This is really strange. TDM's builds include special support *specifically* addressing C++ exception handling when linking against the static libstdc++ (and, IIUC, linking against the shared libstdc++ Just Works(tm) for both TDM and mingw.org compilers). IIRC, TDM's compilers link against static libstdc++ by default, and mingw.org's link against the shared libstdc++ by default -- but I'll need to double check that. Bob, if I were you I'd raise this as a bug on TDM's sf page: http://tdm-gcc.tdragon.net/bugs http://sourceforge.net/tracker/?group_id=200665atid=974439 because if it works with mingw.org, but fails with TDM...well, that's a TDM bug, since John E. attempts to allow working exceptions-across-dll-boundaries for BOTH -static-libstdc++ and -shared-libstdc++. (Note that mingw.org's g++ WILL fail to propagate exceptions across the DLL boundary unless -shared-libgcc, which is the default for -shared-libstdc++, which itself is the default. Not sure about -static-libstdc++ with -shared-libgcc, but -static-libstdc++ -static-libgcc is right out. However, since it *works* with mingw.org, I don't think a screwup related to these flags is the culprit.) As a side note, I find that the GNU make delivered with current MinGW is at least 60X slower than before. It takes GNU make 2.5 minutes before it does any actual work (while building GraphicsMagick), which represents most of the compilation time with the previous make. A one-year old Cygwin make takes maybe 1.5 seconds to start working when given the same environment. And for this, I'd appreciate it if you could open a bug at mingw.org's tracker: http://sourceforge.net/tracker/?group_id=2435atid=102435 -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: 2.4 Release in 24hrs
On 9/19/2010 11:45 AM, Bob Friesenhahn wrote: Unfortunately, my MinGW testing is not so successful. The testing still quits part-way through with some sort of make-related issue (as reported in detail previously). Odd. My last test on MinGW was very successful. This was version 1.3266 (ef56e98f3 IIRC). I'll give it another go @ f0584085. -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: 2.4 Release in 24hrs
On 9/19/2010 3:27 PM, Bob Friesenhahn wrote: The 'make' used is GNU make 3.79.1. Yikes. Where did THAT come from? MSYS has provided at least make-3.81 for several years; the current msys make is 3.82. There is a 'mingw32-make' which is GNU make 3.82, but does not seem to work under MSYS. Right. mingw32-make is for when you do NOT have msys installed, and just want to use a makefile with MinGW gcc. Obviously, without msys, you can't run configure scripts, or generate Makefile's from Makefile.in's, etc -- or use libtool. Just as obviously, when building libtool itself, you darned well better have msys installed, so mingw32-make is not appropriate. Besides, mingw32-make doesn't grok msys-style pathnames. I sounds like your msys installation is WAY out of date. What I would suggest is the following: 1) download and install mingw-get (get the .zip file, and unpack it somewhere innocuous like C:\Temp\MinGW-Installer -- NOT C:\MinGW, because we don't want to disturb your existing TDM mingw compiler. You do not want to use easier mingw-get-inst wrapper, because it will automatically also install mingw.org's gcc, and you're using TDM. You *could* use mingw-get-inst, but (a) you'd have to pick a different installation directory, and (b) by default, your new msys would be in C:\mingw-inst-dir\msys\1.0, NOT C:\msys\1.0. 2) edit C:\Temp\MinGW-Installer\var\lib\mingw-get\data\profile.xml (if it doesn't exist, copy default.xml). You should change the following two lines: sysroot subsystem=mingw32 path=%R / sysroot subsystem=MSYS path=%R/msys/1.0 / To this: sysroot subsystem=mingw32 path=%R / sysroot subsystem=MSYS path=C:/msys/1.0 / The default configuration will install a new MinGW into whereever mingw-get is, and a new MSYS into whereever mingw-get-is/msys/1.0. You don't want that...so you have to edit the defaults. You might want to move your existing msys installation out of the way. Then, from a cmd prompt, cd to C:\Temp\MinGW-Installer\bin and do this: mingw-get update mingw-get install mingw-dtk The first command updates all of the locally cached package manifests to the latest version. The second command downloads and installs a selection to tools that will closely mimic the old MSYS-DTK package -- into C:\msys\1.0\*. However, as mingw-dtk (and the old MSYS-DTK) collection includes mingw-ish autoconf/automake/libtool, THOSE tools will get installed into wherever-mingw-get-is/*. It's up to you whether you should brute force copy these files over onto your existing TDM C:\MinGW or not (but do NOT put them into C:\msys\1.0!!!) Alternatively, of course, you could edit the mingw32 subsystem path specification in profile.xml, and install THOSE components directly into C:\MinGW. After that, you need to edit C:\msys\1.0\etc\fstab to add C:\MinGW /mingw as usual...but that's old hat. -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: 2.4 Release in 24hrs
On 9/19/2010 12:57 PM, Charles Wilson wrote: On 9/19/2010 11:45 AM, Bob Friesenhahn wrote: Unfortunately, my MinGW testing is not so successful. The testing still quits part-way through with some sort of make-related issue (as reported in detail previously). Odd. My last test on MinGW was very successful. This was version 1.3266 (ef56e98f3 IIRC). I'll give it another go @ f0584085. MinGW/MSYS: old -- All 122 tests passed (2 tests were not run) new -- 108 tests behaved as expected. 12 tests were skipped. MinGW.org gcc 4.5.0 MinGW.org binutils 2.20.51.20100613 MSYS 1.0.15(0.47/3/2) 2010-07-06 22:04 i686 Msys make-3.81-3 (not 3.82! I should probably update...) msys-bash-3.1.17-3 msys-coreutils-5.97-3 msys-m4-1.4.14-1 mingw-runtime-3.18 (/mingw/include/_mingw.h) w32api-3.14(/mingw/include/w32api.h) -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
[SCM] GNU Libtool branch, master, updated. v2.2.10-186-g301c4cf
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.
The branch, master has been updated
via 301c4cf24f5ddaa565ffb773906247deb1319aa2 (commit)
from 254f5280e6cb6f69b17b581e0febbb73cd02b606 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
commit 301c4cf24f5ddaa565ffb773906247deb1319aa2
Author: Charles Wilson libt...@cwilson.fastmail.fm
Date: Fri Sep 17 12:28:46 2010 -0400
Document libtool variable to_host_file_cmd.
* doc/libtool.texi (libtool script contents:to_host_file_cmd): Document
variable.
(libtool script contents:to_tool_file_cmd): Prefer `build platform'
to `build system'; Ditto `host platform'.
Signed-off-by: Charles Wilson libt...@cwilson.fastmail.fm
---
Summary of changes:
ChangeLog|8
doc/libtool.texi | 14 --
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 44a76e2..334a5d0 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,11 @@
+2010-09-17 Charles Wilson libt...@cwilson.fastmail.fm
+
+ Document libtool variable to_host_file_cmd.
+ * doc/libtool.texi (libtool script contents:to_host_file_cmd):
+ Document variable.
+ (libtool script contents:to_tool_file_cmd): Prefer `build platform'
+ to `build system'; Ditto `host platform'.
+
2010-09-16 Charles Wilson libt...@cwilson.fastmail.fm
Fix sh.test failure introduced in 72064249
diff --git a/doc/libtool.texi b/doc/libtool.texi
index a3555dc..0d3ff7f 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -6822,11 +6822,21 @@ Linker flag (passed through the C compiler) used to
generate thread-safe
libraries.
@end defvar
+...@defvar to_host_file_cmd
+If the toolchain is not native to the build platform (e.g.@: if you are using
+MSYS to drive the scripting, but are using the MinGW native Windows compiler)
+this variable describes how to convert file names from the format used by the
+build platform to the format used by host platform. Normally set to
+...@samp{func_convert_file_noop}, libtool will autodetect most cases in which
+other values should be used. On rare occasions, it may be necessary to
override
+the autodetected value (@pxref{Cygwin to MinGW Cross}).
+...@end defvar
+
@defvar to_tool_file_cmd
-If the toolchain is not native to the build system (e.g.@: if you are using
+If the toolchain is not native to the build platform (e.g.@: if you are using
some Unix to drive the scripting together with a Windows toolchain running
in Wine) this variable describes how to convert file names from the format
-used by the build system to the format used by the toolchain. Normally set
+used by the build platform to the format used by the toolchain. Normally set
to @samp{func_convert_file_noop}.
@end defvar
hooks/post-receive
--
GNU Libtool
[SCM] GNU Libtool branch, master, updated. v2.2.10-187-g69e7767
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project GNU Libtool. The branch, master has been updated via 69e77671311ab54de44ba24ff5dbf5568bf1221d (commit) from 301c4cf24f5ddaa565ffb773906247deb1319aa2 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit 69e77671311ab54de44ba24ff5dbf5568bf1221d Author: Charles Wilson libt...@cwilson.fastmail.fm Date: Fri Sep 17 12:23:28 2010 -0400 Fix order of PATH manipulation in cwrapper and shwrapper * libltdl/config/ltmain.m4sh (func_emit_cwrapperexe_src:main): Call lt_update_exe_path before lt_update_lib_path, to ensure that the temporary rpath values (which include the OBJDIRs of uninstalled libtool libraries) precede installation and final -rpath directories. (func_emit_wrapper): Prepend $dllsearchpath to PATH before prepending $temp_rpath to $shlibpath_var; similar rationale as above. Reported by Jon Turney jon.tur...@dronecode.org.uk Signed-off-by: Charles Wilson libt...@cwilson.fastmail.fm --- Summary of changes: ChangeLog | 11 +++ libltdl/config/ltmain.m4sh | 26 +- 2 files changed, 28 insertions(+), 9 deletions(-) diff --git a/ChangeLog b/ChangeLog index 334a5d0..17e50cf 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,16 @@ 2010-09-17 Charles Wilson libt...@cwilson.fastmail.fm + Fix order of PATH manipulation in cwrapper and shwrapper + * libltdl/config/ltmain.m4sh (func_emit_cwrapperexe_src:main): Call + lt_update_exe_path before lt_update_lib_path, to ensure that the + temporary rpath values (which include the OBJDIRs of uninstalled + libtool libraries) precede installation and final -rpath directories. + (func_emit_wrapper): Prepend $dllsearchpath to PATH before prepending + $temp_rpath to $shlibpath_var; similar rationale as above. + Reported by Jon Turney jon.tur...@dronecode.org.uk + +2010-09-17 Charles Wilson libt...@cwilson.fastmail.fm + Document libtool variable to_host_file_cmd. * doc/libtool.texi (libtool script contents:to_host_file_cmd): Document variable. diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh index 7bbca85..4f5bbb3 100644 --- a/libltdl/config/ltmain.m4sh +++ b/libltdl/config/ltmain.m4sh @@ -3293,6 +3293,18 @@ func_exec_program () if test -f \\$progdir/\$program\; then + # fixup the dll searchpath if we need to. + # + # Fix the DLL searchpath if we need to. Do this before prepending + # to shlibpath, because on Windows, both are PATH and uninstalled + # libraries must come first. + if test -n $dllsearchpath; then + $ECHO \ +# Add the dll search path components to the executable PATH +PATH=$dllsearchpath:\$PATH + + fi + # Export our shlibpath_var if we have one. if test $shlibpath_overrides_runpath = yes test -n $shlibpath_var test -n $temp_rpath; then $ECHO \ @@ -3307,14 +3319,6 @@ func_exec_program () fi - # fixup the dll searchpath if we need to. - if test -n $dllsearchpath; then - $ECHO \ -# Add the dll search path components to the executable PATH -PATH=$dllsearchpath:\$PATH - - fi - $ECHO \ if test \\$libtool_execute_magic\ != \$magic\; then # Run the actual program with our arguments. @@ -3703,8 +3707,12 @@ EOF lt_setenv (BIN_SH, xpg4); /* for Tru64 */ lt_setenv (DUALCASE, 1); /* for MSK sh */ - lt_update_lib_path (LIB_PATH_VARNAME, LIB_PATH_VALUE); + /* Update the DLL searchpath. EXE_PATH_VALUE ($dllsearchpath) must + be prepended before (that is, appear after) LIB_PATH_VALUE ($temp_rpath) + because on Windows, both *_VARNAMEs are PATH but uninstalled + libraries must come first. */ lt_update_exe_path (EXE_PATH_VARNAME, EXE_PATH_VALUE); + lt_update_lib_path (LIB_PATH_VARNAME, LIB_PATH_VALUE); lt_debugprintf (__FILE__, __LINE__, (main) lt_argv_zero: %s\n, nonnull (lt_argv_zero)); hooks/post-receive -- GNU Libtool
[PATCH] Fix order of PATH manipulation in cwrapper and shwrapper
* libltdl/config/ltmain.m4sh (func_emit_cwrapperexe_src:main): Call lt_update_exe_path before lt_update_lib_path, to ensure that the temporary rpath values (which include the OBJDIRs of uninstalled libtool libraries) precede installation and final -rpath directories. (func_emit_wrapper): Prepend $dllsearchpath to PATH before prepending $temp_rpath to $shlibpath_var; similar rationale as above. Reported by Jon Turney jon.tur...@dronecode.org.uk --- As promised here: http://lists.gnu.org/archive/html/libtool-patches/2010-09/msg00191.html Tested on cygwin; no regressions: old: All 122 tests passed (2 tests were not run) new: 111 tests behaved as expected. 9 tests were skipped. OK to push? libltdl/config/ltmain.m4sh | 31 ++- 1 files changed, 22 insertions(+), 9 deletions(-) diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh index 7bbca85..2371a14 100644 --- a/libltdl/config/ltmain.m4sh +++ b/libltdl/config/ltmain.m4sh @@ -3293,6 +3293,22 @@ func_exec_program () if test -f \\$progdir/\$program\; then + # fixup the dll searchpath if we need to. + # + # For Windows, this must occur prior to any manipulation of + # $shlibpath (which, ON Windows, is PATH). That way, we ensure + # that the $dllsearchpath value is prepended to $PATH first, and + # that the temporary rpath values (which contain the actual + # location of uninstalled DLLs, in their respective OBJDIR + # directories) are prepended second. This ensures that just-built + # uninstalled libraries supersede installed ones. + if test -n $dllsearchpath; then + $ECHO \ +# Add the dll search path components to the executable PATH +PATH=$dllsearchpath:\$PATH + + fi + # Export our shlibpath_var if we have one. if test $shlibpath_overrides_runpath = yes test -n $shlibpath_var test -n $temp_rpath; then $ECHO \ @@ -3307,14 +3323,6 @@ func_exec_program () fi - # fixup the dll searchpath if we need to. - if test -n $dllsearchpath; then - $ECHO \ -# Add the dll search path components to the executable PATH -PATH=$dllsearchpath:\$PATH - - fi - $ECHO \ if test \\$libtool_execute_magic\ != \$magic\; then # Run the actual program with our arguments. @@ -3703,8 +3711,13 @@ EOF lt_setenv (BIN_SH, xpg4); /* for Tru64 */ lt_setenv (DUALCASE, 1); /* for MSK sh */ - lt_update_lib_path (LIB_PATH_VARNAME, LIB_PATH_VALUE); + /* For Windows, this order is important: it ensures that the $dllsearchpath + value is prepended first, and that the temporary rpath values (which + contain the actual location of uninstalled DLLs, in their respective + OBJDIR directories) are prepended second. This ensures that just-built + uninstalled libraries supersede installed ones. */ lt_update_exe_path (EXE_PATH_VARNAME, EXE_PATH_VALUE); + lt_update_lib_path (LIB_PATH_VARNAME, LIB_PATH_VALUE); lt_debugprintf (__FILE__, __LINE__, (main) lt_argv_zero: %s\n, nonnull (lt_argv_zero)); -- 1.7.1
Re: [PATCH] Copy over DLL_EXPORT handling from C to C++ for non-GCC on w32.
On 9/17/2010 12:53 PM, Ralf Wildenhues wrote: let the review sprint begin ... Meh -- no more patches from me in the near term. I promised two small patches yesterday, delivered today. Whether they are reviewed and pushed before the release or not doesn't matter that much. -- Chuck
Re: [PATCH 2/2] Move portable shell tests from the old to the new testsuite.
On 9/17/2010 1:23 PM, Ralf Wildenhues wrote: And since IIRC Gary wanted to do the release this weekend, I wonder whether this isn't more safely pushed to after the relase. WDYT? FWIW, I agree that this patch should be postponed until after the release. I'm agnostic on whether tests -- such as this one -- should be moved from the old test suite to the new one. It's not as if the old test suite will EVER go away, is it, since it serves as a collection of demos. OTOH, the new test suite is a nicer framework all around... -- Chuck
Re: [PATCH] Document libtool variable to_host_file_cmd.
On 9/17/2010 1:30 PM, Ralf Wildenhues wrote: * Charles Wilson wrote on Fri, Sep 17, 2010 at 06:28:46PM CEST: OK to push? OK. Why the s/system/platform/ changes though? I see that libtool.texi uses platform a lot, and also uses system quite a bit but not quite as often. Other GNU documentation I think prefers system however. Or are you trying to make a distinction between both terms? Yes, the GNU Build System is already mentioned (with an xref to the definition in another manual). It refers to the whole autoconf/automake/libtool process flow, as distinct from imake or scons or whatever. IMO, using 'build system' to refer to the $build platform could be confused with that term. If other GNU documentation uses the same phrase to mean two different things, that doesn't mean we should do so as well. In that case, they should probably be defined somewhere (and I'd venture to say that they are not good terms to try to differentiate, because most users will not think there could be a difference). We don't have a choice; the GNU Build System has already been given that name by others, and we can't change that. Our only choice is whether to use a term that could be confused with it: 'build system' or not. I say not, whenever possible -- but I'm not doctrinaire about it. I'm not about to go thru all of libtool.texi with a red pen, changing 'build system' everywhere I see it...but to_host_file_cmd and to_tool_file_cmd are so similar -- and defvar'ed so close together, that I thought they should use similar terminology. -- Chuck
Re: [PATCH] Document libtool variable to_host_file_cmd.
On 9/17/2010 1:30 PM, Ralf Wildenhues wrote: * Charles Wilson wrote on Fri, Sep 17, 2010 at 06:28:46PM CEST: OK to push? OK. Pushed. -- Chuck
Re: [PATCH] Fix order of PATH manipulation in cwrapper and shwrapper
On 9/17/2010 2:12 PM, Ralf Wildenhues wrote: * Charles Wilson wrote on Fri, Sep 17, 2010 at 06:23:28PM CEST: * libltdl/config/ltmain.m4sh (func_emit_cwrapperexe_src:main): Call lt_update_exe_path before lt_update_lib_path, to ensure that the temporary rpath values (which include the OBJDIRs of uninstalled libtool libraries) precede installation and final -rpath directories. (func_emit_wrapper): Prepend $dllsearchpath to PATH before prepending $temp_rpath to $shlibpath_var; similar rationale as above. Reported by Jon Turney jon.tur...@dronecode.org.uk This is OK. I mention a nit below. Pushed: with this # Fix the DLL searchpath if we need to. Do this before prepending # to shlibpath, because on Windows, both are PATH and uninstalled # libraries must come first. and this /* Update the DLL searchpath. EXE_PATH_VALUE ($dllsearchpath) must be prepended before (that is, appear after) LIB_PATH_VALUE ($temp_rpath) because on Windows, both *_VARNAMEs are PATH but uninstalled libraries must come first. */ which isn't really shorter than the previous version, but is probably a little more clear, and models the new shwrapper commentary more closely. I won't be able to do the test case before the release, especially not today... -- Chuck
[SCM] GNU Libtool branch, master, updated. v2.2.10-185-g254f528
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.
The branch, master has been updated
via 254f5280e6cb6f69b17b581e0febbb73cd02b606 (commit)
from 3d4f9e324590737af07de73ce4d4eefea85fb16e (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
commit 254f5280e6cb6f69b17b581e0febbb73cd02b606
Author: Charles Wilson libt...@cwilson.fastmail.fm
Date: Thu Sep 16 22:53:47 2010 -0400
Fix sh.test failure introduced in 72064249
* libltdl/config/ltmain.m4sh (func_mode_link): Avoid poor syntax.
Signed-off-by: Charles Wilson libt...@cwilson.fastmail.fm
---
Summary of changes:
ChangeLog |6 ++
libltdl/config/ltmain.m4sh |2 +-
2 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 37f6c84..44a76e2 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2010-09-16 Charles Wilson libt...@cwilson.fastmail.fm
+
+ Fix sh.test failure introduced in 72064249
+ * libltdl/config/ltmain.m4sh (func_mode_link): Avoid poor
+ syntax.
+
2010-09-16 Ralf Wildenhues ralf.wildenh...@gmx.de
tests: avoid localization failure due to unstable compiler messages.
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 18f0f39..7bbca85 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -7362,7 +7362,7 @@ EOF
try_normal_branch=no
;;
esac
- if test $try_normal_branch = yes \
+ if test $try_normal_branch = yes \
{ test $len -lt $max_cmd_len \
|| test $max_cmd_len -le -1; }
then
hooks/post-receive
--
GNU Libtool
Re: w32 pending?
On 9/16/2010 1:28 PM, Ralf Wildenhues wrote: do I see it right that there are no pending w32 patches for before the next Libtool release any more (after the one I just acked)? My most recent cygwin-special libtool release has the following four patches: 0001-cygwin-mingw-Create-UAC-manifest-files.patch 0002-Pass-various-runtime-library-flags-to-GCC.patch 0003-Fix-linking-with-fstack-protector.patch 0004-cygwin-mingw-Fix-order-of-PATH-manipulation-in-cwrap.patch Of these, 0001 and 0002 have already been posted on this list, but there was quite a bit of discussion and no resolution was reached. For 0002, personally I think TRTTD is to stop using ld and instead use the compiler driver to link, when using the GNU tools -- but that's definitely a think-about-it-after-this-release item. This also applies with regards to 0003. For 0001, I had hoped that we could piggyback on Peter's manifest tool support instead of a hack like this, but it doesn't appear to be the case. I don't think it is worth holding up the release in order to figure out this issue. 0004...is very simple, and fixes a specific problem: http://cygwin.com/ml/cygwin/2010-07/msg00608.html I've pasted the current version of this patch inline, but I'll to rebase, retest, and post officially later. I also need to document the '$to_host_file_cmd' variable, as Peter has documented the similar '$to_tool_file_cmd' variable. Other than that, there are a number of items on our TODO list (additional test cases, always room for better/more documentation, etc), but nothing that needs to block the release. I'll post the two promised patches tonight (0004-rebased, plus simple libtool.texi patch). [cygwin|mingw] Fix order of PATH manipulation in cwrapper * libltdl/config/ltmain.m4sh (func_emit_cwrapperexe_src:main): Call lt_update_exe_path before lt_update_lib_path, to ensure that the local OBJDIR(s) supersedes any -rpath directories. Reported by Jon Turney ... --- a/libltdl/config/ltmain.m4sh +++ b/libltdl/config/ltmain.m4sh @@ -3677,8 +3677,12 @@ EOF lt_setenv (BIN_SH, xpg4); /* for Tru64 */ lt_setenv (DUALCASE, 1); /* for MSK sh */ - lt_update_lib_path (LIB_PATH_VARNAME, LIB_PATH_VALUE); + /* For Windows, this order is important: it ensures that any -rpath + values are prepended first, and then the local OBJDIR directory(ies) + is prepended second -- ensuring that just-built libraries supersede + installed ones. */ lt_update_exe_path (EXE_PATH_VARNAME, EXE_PATH_VALUE); + lt_update_lib_path (LIB_PATH_VARNAME, LIB_PATH_VALUE); lt_debugprintf (__FILE__, __LINE__, (main) lt_argv_zero: %s\n, nonnull (lt_argv_zero)); -- Chuck
Re: w32 pending?
On 9/16/2010 2:55 PM, Ralf Wildenhues wrote: This looks ok, but wouldn't the shell wrapper need this as well, seeing that it could be run on w32 too (IIRC)? You're right. I had looked at this before, and erroneously concluded that the shell wrapper was DTRT. But...it isn't. Also, my changelog is wrong, as is the /*comment*/ (but the guts of the patch is right) It's actually $dllsearchpath that's causing problems; $temp_rpath needs to win because it is manipulated by libtool to include the directory of linked .la files (including the ones linked from $OBJDIR). The issue with user-specified -rpath's is a red herring; those aren't used by the wrapper system at all; $temp_rpath is for *temporary* rpaths...like $OBJDIR. (Oddly, I got this right in my description of the problem at http://cygwin.com/ml/cygwin/2010-07/msg00608.html). Just as a reminder, here's how these two _VALUEs are assigned: func_to_host_path $dllsearchpath: const char * EXE_PATH_VALUE = $func_to_host_path_result; func_to_host_path $temp_rpath const char * LIB_PATH_VALUE = $func_to_host_path_result; So, what happens WITH this patch, is $dllsearchpath is prepended first, then $temp_rpath (so $temp_rpath wins) -- which is what we want (contrary to my earlier /*comments*/.) Here are the variable values for the mdemo wrapper: const char * LIB_PATH_VARNAME = PATH; const char * LIB_PATH_VALUE = /usr/src/packages/libtool/22/libtool-2.2.11a-1/build/tests/mdemo/.libs:; // e.g. $temp_rpath const char * EXE_PATH_VARNAME = PATH; const char * EXE_PATH_VALUE = /usr/src/packages/libtool/22/libtool-2.2.11a-1/build/tests/mdemo/.libs:/usr/src/packages/libtool/22/libtool-2.2.11a-1/build/_inst-mdemo/lib:/usr/src/packages/libtool/22/libtool-2.2.11a-1/build/_inst-mdemo/bin:; // e.g. $dllsearchpath Now, in THIS instance, $OBJDIR appears in both (and is first in the latter var), so it wouldn't matter whether EXE_PATH_VALUE or LIB_PATH_VALUE ends up first in the $PATH (e.g. is prepended last). Per John's original report, we actual had (reconstructed from the debug output): const char * LIB_PATH_VALUE = /opt/jhbuild/build/pixman/pixman/.libs:; // e.g. $temp_rpath const char * EXE_PATH_VALUE = /opt/jhbuild/install/lib:/opt/jhbuild/install/bin:/opt/jhbuild/build/pixman/pixman/.libs:; // e.g. $dllsearchpath It looks like $OBJDIR *also* shows up in both vars, but the order within $dllsearchpath varies. However, I haven't seen a case where $temp_rpath doesn't start with $OBJDIR, even when linking against various .la's from various installed/non-installed locations, or when using various -L arguments. This isn't to say there IS no such case, just that *I* don't recall seeing one. *Currently*, in the shell wrapper, here's what is going on: $shlibpath_var=\$temp_rpath\$$shlibpath_var\ PATH=$dllsearchpath:\$PATH That's not right; we want $temp_rpath to win here, too. Also, of course, testsuite exposure should follow eventually. Obviously. If I can get myself so confused while doing the right thing, we really need a testsuite addition to keep it fixed. :-) -- Chuck
Re: w32 pending?
On 9/16/2010 3:52 PM, Vincent Torri wrote:
do I see it right that there are no pending w32 patches for before
the next Libtool release any more (after the one I just acked)?
there is a mingw-w64 issue i have mentioned 2 times, with a debug log of
libtool.
This is the Warning: linker path does not have real file for library
-lole32. problem, right?
libole32.a and friends are all part of the Win32 API, and are installed
by a proper mingw64 native non-multilib toolchain in ${prefix}/lib IIRC
-- and that dir is included in the compiler/linker's search path
automatically.
What would really help is if you could look at your (failing) libtool
script, and see what 'sys_lib_search_path_spec' is set to -- AND (a)
where libole32.a actually lives in your setup, plus (b) what 'gcc
-print-search-dirs' reports (where, 'gcc' is the actual compiler,
whatever it is called, that you are using).
Anyway, then we could try and figure out what libtool can't find
libole32.a...
(*) I assume you're using a native non-multilib toolchain (you didn't
specify).
--
Chuck
[PATCH] Fix sh.test failure introduced in 72064249
* libltdl/config/ltmain.m4sh (func_mode_link): Avoid poor syntax.
---
Without this, sh.test fails. Committed as obvious (no, really, this time).
--
Chuck
libltdl/config/ltmain.m4sh |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 18f0f39..7bbca85 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -7362,7 +7362,7 @@ EOF
try_normal_branch=no
;;
esac
- if test $try_normal_branch = yes \
+ if test $try_normal_branch = yes \
{ test $len -lt $max_cmd_len \
|| test $max_cmd_len -le -1; }
then
--
1.7.1
Re: [PATCH] maint: ship .xz, not .lzma
On 9/14/2010 2:04 AM, Gary V. Vaughan wrote: I'm curious to know what the history of lzma and xz is that makes this desirable though. Here's some documentation I put together for the cygwin xz package: xz This package provides a data compression library and utilities supporting the .xz and .lzma file formats, which use the LZMA compression algorithm. LZMA provides high compression ratios and very fast decompression, with minimal memory requirements for decompression. XZ Utils is the latest generation of this software, supplanting the older LZMA Utils. The cygwin xz package replaces and obsoletes the cygwin lzma package. LZMA Utils (and its own antecedent, the LZMA SDK) provided the 'lzma' tool, which supported the 'LZMA-Alone' file format usually indicated by the extension '.lzma'. Internally, this file format used what is now called the LZMA1 compression algorithm. XZ Utils provides the xz tool, which supports the new .xz file format usually indicated by the extension '.xz'. Internally, it uses a variation of the original LZMA compression algorithm, called LZMA2. However, the new xz tool also seamlessly supports the older .lzma files and LZMA1 compression. History: 1. LZMA SDK First there was the LZMA SDK. Upstream, it shipped no libraries; only a few executables such as 'lzma'. The source code was provided for public use (under a variety of licenses), but it was expected that developers would incorporate the source code directly into their own projects. This is not The Unix Way. The LZMA SDK was tightly coupled with the 7zip compression program, and both were developed on and solely for the Windows platform. 7zip -- but not the LZMA SDK -- was ported to Unix under the auspices of the p7zip (Portable 7zip) project. (As an aside, p7zip was then ported to cygwin...to come full circle). However, it should be clear that the file format used by 7zip (and p7zip) was completely different from the one supported by the LZMA SDK's 'lzma' tool. The latter used what was called the 'LZMA-Alone' format, which consisted of 13 bytes of header information followed by a raw lzma-compressed byte-stream. 7zip, on the other hand, used a much more complicated file format capable of hosting multiple files, spanned archives, and other features. The only similarity is that the core data compression algorithm used by both is LZMA. 2. LZMA Utils Eventually, a unix port of the LZMA SDK appeared, in the form of the LZMA Utils distribution, which reorganized the original source code, and provided the decompression code in library form (liblzmadec). It also provided a version of the 'lzma' program, but with a completely different command-line interface. The LZMA Utils version consciously mimicked the command-line options of the familiar gzip and bzip2 tools, while the original LZMA SDK version was...different. Very different. This is because the LZMA SDK's tool was originally intended just as a test and development utility, to help refine the algorithm. So, it has a number of 'compression guru' options that no sane user cares to use, and very few of the 'normal user' options that they would. LZMA Utils: (Lasse Collin) lzma -d foo.tar.lzma uncompress to (implied) foo.tar, and remove original compressed file. lzma foo.tar compress to (implied) foo.tar.lzma, and remove original uncompressed file. Supports familiar tuning options like -0 .. -9 Sends output data to stdout using -c Could be invoked under alternate names (symlinks) for different behavior: unlzma == lzma -d (uncompress) lzcat == lzma -dc (uncompress to stdout) LZMA SDK: (Igor Pavlov) lzma d foo.tar.lzma foo.tar lzma e foo.tar foo.tar.lzma mode d/e is the required first non-option argument both input and output files must be specified stdout? what's that? Finally, LZMA Utils also shipped a number of helpful scripts similar to the familiar ones from gzip and bzip2: lzdiff/lzcmp, lzgrep/lzegrep/lzfgrep, lzless/lzmore So, the LZMA SDK version was hardly suitable for replacing or augmenting the existing bzip2 and gzip compression programs on unix systems, expecially as the most common use was in conjuction with tar. But tar expects compression programs to satisfy a common command-line argument format, and to be able to manipulate data on standard streams. Most linux distributions have standardized on LZMA Utils. The lzma tool from both LZMA SDK and LZMA Utils each support the LZMA-Alone (.lzma) file format, as does the liblzmadec library from LZMA Utils. However, the .lzma file format (e.g. LZMA-Alone) is not sufficient for modern needs, as it (1) had no 'signature bytes' so compressed files were difficult to automatically detect and verify, (2) it had no provision for
Re: [PATCH] maint: ship .xz, not .lzma
On 9/14/2010 11:02 AM, Bob Friesenhahn wrote: On Tue, 14 Sep 2010, Gary V. Vaughan wrote: No objections. I'm curious to know what the history of lzma and xz is that makes this desirable though. I am curious to know if XZ Utils has now achieved a proper stable release or if it will be perpetually in a prototype like state. Well, the 4.999.9beta is supposedly the final beta. However, it was released 2009-08-27 (e.g. a year ago) -- so, in order to keep that promise (!) the webpage now says: A snapshot from the git repository is available too, and is generally recommended over 4.999.9beta. xz-4.999.9beta-180-ge23e.tar.gz (1114 KiB) How that differs from a new RC/beta I don't know, but there you go. Anyway, if you check the git logs, you'll see that most of the recent changes have been stabilization and documentation, so I think it is asymptotically converging on an actual release. Of course you know the problem with asymptotes... Its code is quite large and quite obtuse. Meh. Most of that is for the alternate compression schemes (e.g. there are schemes tuned specifically for compressing mips binary code, and x86 binary code, etc). The core LZMA compression and XZ file format handling is maybe only 1.5x-2x bzip2. Take a look at the xz-embedded repo; it includes only the XZ and core LZMA stuff: git clone http://git.tukaani.org/xz-embedded.git Also, I remain curious to know why 'lzip' has never been considered as a suitable replacement. Lzip accomplishes the same thing with 10 times less code, and better fits the traditions previously established by gzip and bzip2. I'm not sure that last clause (...better fits...) is true. Surely, the LZMA SDK code and utilities were...different. But the LZMA Utils and its successor XZ Utils were *specifically* written to follow the gzip/bzip2 traditions. When I added xz support to cygwin's setup.exe via liblzma, the glue code to do so was VERY similar to the corresponding .gz and .bz2 glue code... Ditto when similar glue was added to BSD's libarchive. Its only limitation is that it requires a C++ compiler. The claim is made that it is not portable because it does not come with a megabyte-sized configure script, but it does not need such a huge configure script because it only uses portable ANSI interfaces, similar to the way gzip only requires ANSI C. This sort of decision-making results in people feeling that GNU software is excessively complex bloatware. Personal politics and status has become more important than proper technical analysis. Err...I don't think I want to get into a religious war. (I will say this, tho: requiring a 1MB C++ runtime library like libstdc++.so at *runtime* is not _my_ usual approach when trying to create non-bloated software, and hardly makes up for the savings of not having a 1MB configure script at *build* time. Sure, on real unix you'll already have that runtime lib installed, but lzma/xz was pitched on unix as usable on embedded systems and in-kernel too...the same can't be said for lzip) The fact is, whether we @ libtool like it or not, .lzma compression had been adopted by most other GNU projects as the next great compression scheme (whether it really WAS or not, is debatable as all such assertions are). When the two primary forces behind lzma-on-unix (Igor Pavlov and Lasse Collin) got together to formulate the xz extension, the early .lzma adopters -- e.g. many GNU projects -- followed along. As one of those GNU projects, automake added support for dist-lzma -- and later dist-xz, not dist-lzip. That's where we are. If you want to start an xz-vs-lzip fight, propose the appropriate support for dist-lzip on automake-patches and fight it there. :-) -- Chuck
[SCM] GNU Libtool branch, master, updated. v2.2.10-175-gef56e98
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.
The branch, master has been updated
via ef56e98f3bb4ed780a08bced638f8adf673c0041 (commit)
from 048979e10ffcbe67dad11e3b58365ecc66232e5a (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
commit ef56e98f3bb4ed780a08bced638f8adf673c0041
Author: Charles Wilson libt...@cwilson.fastmail.fm
Date: Sun Sep 12 09:19:51 2010 -0400
When assigning $linklib value, honor [-all]-static[-libtool-libs]
* libltdl/config/ltmain.m4sh (func_mode_link): When prefer_static_libs
and static library exists, ensure old_library name is used as $linklib.
Fixes failure on mingw when both static and shared libraries are
present.
Signed-off-by: Charles Wilson libt...@cwilson.fastmail.fm
---
Summary of changes:
ChangeLog |9 +
libltdl/config/ltmain.m4sh | 12 +---
2 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index b9abe8a..6b76340 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,12 @@
+2010-09-12 Charles Wilson libt...@cwilson.fastmail.fm
+
+ When assigning $linklib value, honor [-all]-static[-libtool-libs]
+
+ * libltdl/config/ltmain.m4sh (func_mode_link): When prefer_static_libs
+ and static library exists, ensure old_library name is used as $linklib.
+ Fixes failure on mingw when both static and shared libraries are
+ present.
+
2010-09-12 Ralf Wildenhues ralf.wildenh...@gmx.de
tests: work around zsh use of $options variable.
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 509a421..6036f4f 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -5652,9 +5652,15 @@ func_mode_link ()
# Get the name of the library we link against.
linklib=
- for l in $old_library $library_names; do
- linklib=$l
- done
+ if test -n $old_library
+ { test $prefer_static_libs = yes ||
+test $prefer_static_libs,$installed = built,no; }; then
+ linklib=$old_library
+ else
+ for l in $old_library $library_names; do
+ linklib=$l
+ done
+ fi
if test -z $linklib; then
func_fatal_error cannot find name of link library for \`$lib'
fi
hooks/post-receive
--
GNU Libtool
[PATCH] [cygwin|mingw] Correct static lib symbol extraction failure.
* libltdl/config/ltmain.m4sh (func_mode_link): When prefer_static_libs,
ensure old_library name is used as linklib when possible.
---
This patch corrects the (long-standing?) failure of mdemo-exec.test on
mingw, but also some non-fatal anomalies in cygwin on the same tests.
Basically, when dlopen'ing static libraries, but when both shared and
static libs exist, the extracted symbol names put into the
lt__PROGRAM__LTX_preloaded_symbols array were mistakenly extracted from
the import library instead of the static one. For PE/COFF, this makes
a difference; and on mingw that difference caused the mdemo_static test
to fail.
Test results:
cygwin
--
old test suite: All 122 tests passed (2 tests were not run)
new test suite: 111 tests behaved as expected. 9 tests were skipped.
mingw
-
old test suite: All 122 tests passed (2 tests were not run)
new test suite: 108 tests behaved as expected. 12 tests were skipped.
OK to push?
--
Chuck
libltdl/config/ltmain.m4sh | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index d8e0fe1..6ae2e43 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -5650,9 +5650,15 @@ func_mode_link ()
# Get the name of the library we link against.
linklib=
- for l in $old_library $library_names; do
- linklib=$l
- done
+ if test -n $old_library
+ { test $prefer_static_libs = yes ||
+test $prefer_static_libs,$installed = built,no; }; then
+ linklib=$old_library
+ else
+ for l in $old_library $library_names; do
+ linklib=$l
+ done
+ fi
if test -z $linklib; then
func_fatal_error cannot find name of link library for \`$lib'
fi
--
1.7.1
Re: [PATCH] [cygwin|mingw] Correct static lib symbol extraction failure.
On 9/12/2010 10:20 AM, Ralf Wildenhues wrote: Hi Charles, * Charles Wilson wrote on Sun, Sep 12, 2010 at 03:19:51PM CEST: * libltdl/config/ltmain.m4sh (func_mode_link): When prefer_static_libs, ensure old_library name is used as linklib when possible. --- This patch corrects the (long-standing?) failure of mdemo-exec.test on mingw, but also some non-fatal anomalies in cygwin on the same tests. Basically, when dlopen'ing static libraries, but when both shared and static libs exist, the extracted symbol names put into the lt__PROGRAM__LTX_preloaded_symbols array were mistakenly extracted from the import library instead of the static one. For PE/COFF, this makes a difference; and on mingw that difference caused the mdemo_static test to fail. Why does the patch have [cygwin|mingw] in the summary? It changes a code path that is shared by most systems out there, no? I'd rather see a 'Fixes foo on Cygwin and MinGW' in the details, so that when searching the summary log later, this patch isn't mistaken for a w32-only one. OK, I'll change the summary before committing. I think the patch is right, but this is one that *really* needs wide range testing on several hosts. Since I'm about to tick off another round of testing, I suggest you commit it so that it can be included in the testing. OK. -- Chuck
Re: [PATCH] [cygwin|mingw] Correct static lib symbol extraction failure.
On 9/12/2010 10:25 AM, Ralf Wildenhues wrote: Also, $linklib is used for several other things. It would seem prudent to make sure it is clear that this is a very intrusive patch, or use another helper variable to make it less intrusive. Oh, I think linklib was *wrong* no matter what. If you requested static (either via -static, -all-static, or -static-libtool-libs), AND you have an $old_library name...then by golly you ARE going to link against that $old_library. So, when assigning $linklib, you really should take into consideration all those factors. Prior to this patch, $linklib was always set to the last element of $library_names -- and was only set to $old_library if there WERE no dynamic libs, and all you HAD was the static lib. It didn't care about the various -static options AT ALL. -- Chuck
Re: [PATCH] [cygwin|mingw] Correct static lib symbol extraction failure.
On 9/12/2010 10:20 AM, Ralf Wildenhues wrote:
I suggest you commit it so that it can be included
in the testing.
Pushed as:
When assigning $linklib value, honor [-all]-static[-libtool-libs]
* libltdl/config/ltmain.m4sh (func_mode_link): When prefer_static_libs
and static library exists, ensure old_library name is used as $linklib.
Fixes failure on mingw when both static and shared libraries are
present.
---
ChangeLog |9 +
libltdl/config/ltmain.m4sh | 12 +---
2 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index b9abe8a..6b76340 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,12 @@
+2010-09-12 Charles Wilson ...
+
+ When assigning $linklib value, honor [-all]-static[-libtool-libs]
+
+ * libltdl/config/ltmain.m4sh (func_mode_link): When prefer_static_libs
+ and static library exists, ensure old_library name is used as $linklib.
+ Fixes failure on mingw when both static and shared libraries are
+ present.
+
2010-09-12 Ralf Wildenhues ...
tests: work around zsh use of $options variable.
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 509a421..6036f4f 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -5652,9 +5652,15 @@ func_mode_link ()
# Get the name of the library we link against.
linklib=
- for l in $old_library $library_names; do
- linklib=$l
- done
+ if test -n $old_library
+ { test $prefer_static_libs = yes ||
+test $prefer_static_libs,$installed = built,no; }; then
+ linklib=$old_library
+ else
+ for l in $old_library $library_names; do
+ linklib=$l
+ done
+ fi
if test -z $linklib; then
func_fatal_error cannot find name of link library for \`$lib'
fi
--
1.7.1
Re: [PATCH] Correct typo: $sharedlib_from_linklib_cmd missing '_cmd'
On 9/11/2010 2:47 AM, Peter Rosin wrote: Den 2010-09-11 07:02 skrev Charles Wilson: OK to push as obvious? To me, pushing as obvious is the same as pushing without asking (and when I do, I make damn sure I don't push anything bad). This makes me curious, what does it mean to you? It means other than ensuring that I didn't do something stupid like breaking 'make', I didn't try to do any before/after testing to prove that this fixed whatever the typo apparently broke. But the change is obviously correct, and should't really need that kind of justification. However...I don't have the authority to push *anything* without approval, so I *can't* simply say pushed as obvious. -- Chuck
Re: [PATCH] Correct typo: $sharedlib_from_linklib_cmd missing '_cmd'
On 9/11/2010 4:16 AM, Ralf Wildenhues wrote: OK to push. Pushed. -- Chuck
Re: [PATCH 6/7] Convert file name to toolchain format when invoking $NM.
On 9/10/2010 9:11 AM, Peter Rosin wrote: func_cygming_gnu_implib_p - 6. Dead code. Needs the sharedlib_from_linklib - sharedlib_from_linklib_cmd typo fix. So, a previous testsuite deficiency that should not hold back this patch. func_cygming_gnu_implib_p and func_cygming_ms_implib_p -- 7. Dead code. Needs the sharedlib_from_linklib - sharedlib_from_linklib_cmd typo fix. So, a previous testsuite deficiency that should not hold back this patch. As I explained, this is not dead code. dead code is code that can never be executed under any circumstances. These code paths can be executed, if (1) you are on cygming and have an old binutils whose dlltool doesn't support --identify, and (2) you link using -dlopen foo.dll.a. (2) isn't that uncommon, even if we don't do it in the test suite. (1) is unlikely...and getting more so every day -- but not impossible. It's...mostly dead. Mostly dead is slightly alive. With all dead, well, with all dead there's usually only one thing you can do...Go through his clothes and look for loose change. -- Chuck
Re: [PATCH 6/7] Convert file name to toolchain format when invoking $NM.
On 9/10/2010 10:07 AM, Peter Rosin wrote: It's dead, you need the below patch to animate it. There is no sane way you can influence the sharedlib_from_linklib variable. Well, that's just a bug with a known but uncommitted patch. So he's stopped breathing, but it's nothing a little CPR won't fix. -- Chuck
Re: [PATCH 6/7] Convert file name to toolchain format when invoking $NM.
On 9/9/2010 5:47 AM, Peter Rosin wrote:
Anyway, both fail in pretty much the same way for me:
can't open the module tests/mdemo/foo1.la!
error was: The specified module could not be found.
can't open the module tests/mdemo/foo1!
error was: The specified module could not be found.
can't open the module tests/mdemo/libfoo2.la!
error was: The specified module could not be found.
can't open the module tests/mdemo/libfoo2!
error was: The specified module could not be found.
Yes.
The problem is in how mdemo_static.exeS.c is constructed;
lt__PROGRAM__LTX_preloaded_symbols contains header entries for each
-dlpreopen'ed library, but they are:
{cygsub-0.dll, (void *) 0},
when they should be
{libsub.a, (void *) 0},
Manually making that change and re-linking fixes the error. I just need
to track down *why* the wrong library name is being used and fix it,
without breaking mdemo.exeS.c (the one that dlpreopens the DLLs, and
SHOULD be specifying 'cygsub-0.dll' etc).
--
Chuck
Re: [PATCH 6/7] Convert file name to toolchain format when invoking $NM.
On 9/9/2010 3:19 AM, Peter Rosin wrote: Den 2010-09-09 06:18 skrev Charles Wilson: Peter, a question about your current patch series: with it only partially committed, do you expect errors? Are we waiting for some other change upon which the current series depends, before it all just works again...or are things fubared now? I wouldn't knowingly have committed anything half-assed like that. I expected things to be better now that they were before. Sorry, I just lost track of the thread of the various conversations. When you presented a chain of 7 patches, and then they weren't all committed simultaneously, I started to wonder (1-4, then later 5, then even later 6, and 7 still hasn't been). Right now, I'm seeing a regression just building libltdl. It builds correctly the first time -- but when I try to run the old test suite, a rule gets triggered to rebuild libltdl.al: I suspect that there is a mismatch between the targets (and deps) in the Makefile (and the .deps/*.P files), and the new pre-converted filenames being generated by $to_tool_file_cmd. That might very well be the cause, as I didn't think of that case at all. Well, it was broke, you just didn't notice that low max_cmd_len failed in more ways than you assumed. That part is fixed. You're right. I didn't mean to sound so accusatory... I'm wondering if, when $build=MSYS, we could turn off all of the libtool to_tool_file_cmd stuff, EXCEPT when generating the contents of an @file. I agree, we should implement some kind of lazy strategy for MSYS, so that we don't do any needless conversions. (I like lazy. Lazy is good.) You know, just fix the broken stuffwithout breaking other, previously working, stuff? ...like this. At first, I thought *every* -exec test was broken, and I was quite flummoxed. But that was PIBKAC. After a clean rebuild, I saw that it was only the ever-painful mdemo-*-exec tests that were failing (along with new mdemo-*-make test failures). So, it wasn't nearly as bad as I originally thought...but I didn't revise my entire partially composed message to suit the new facts. Sorry about that. (I mean, you're basically removing the whole point of msys; why not just use cygwin instead, if you're not going to let msys do for you what it was designed to do?) You know, I did think that was what I was doing, fixing broken stuff without breaking other previously working stuff. I have been running the testsuite to death lately and can't understand how this failure has gone undetected. But it's clearly there. My bad, and sorry for the inconvenience. No, I should have done more testing and validation of your patch series in its new incarnation. I just didn't have time with all the sysroot testing in 57 varieties (plus building and rebuilding multiple cross compiler and sys-root contents...for multiple $host/$build combinations...), then my latest gigantopatch, ... And besides, I *had* tested an earlier incarnation, hadn't I? Surely that was good enough. I mean, nothing could possibly have changed in libtool over two years that would cause a working patch series to regress after a simple rebase -- or, as in your case, a 95% rewrite -- correct? Not. Sigh. It's my own fault; I should have done more testing earlier. -- Chuck
Re: [PATCH 6/7] Convert file name to toolchain format when invoking $NM.
On 9/9/2010 11:33 AM, Peter Rosin wrote: Ok, I bisected the failure to e83da49a1faf9df1c7e351df9e9b175 [cygwin|mingw] fix dlpreopen with --disable-static You know, just fix the broken stuff...without[couldn't resist] Oh, I know. This was *precisely* what that patch was supposed to fix, and DID fix back in the depths of time when it was first created, and -- I thought -- continued to fix in modern libtool. Only now, I *guess* because of some additional intervening changes in other parts of libtool, it no longer actually fixed it! However, because it DID fix the issue on cygwin -- or, rather, did not re-break it -- AND the mingw (re)failure was hidden behind a separate fault, I didn't realize the patch no longer actually FIXED the problem it was intended to fix, on mingw. So...the patch didn't break any new tests that weren't already failing (for other reasons) on mingw -- but neither did it actually fix what it claimed to. At least on mingw. aarrggh. Now, it confuses me that you state that your bisection hit that commit; I'm VERY surprised that mdemo actually worked on mingw, PRIOR to that commit. After all, the point of that patch was to correct the FAILURE of that particular test! So, somewhere between 2009-01 and e83da49a, some OTHER change to libtool fixed (?) the mdemo test on mingw/msys. Sigh. I think this whole issue arose because of the delay in reviewing that patch. Something changed underneath it, and instead of fixing the problem, the patch (re)broke it. And I didn't notice because (a) stuff continued to work on cygwin, and (b) there was another failure, in the same test, on mingw, which hid the fact that the updated patch (re)broke another aspect of that test. Maybe you knew that this patch was the cause of the regression, but I didn't understand that until I bisected the regression. Your comment a few message back: Den 2010-09-09 00:14 skrev Charles Wilson: (However, there is an unfixed bug here; apparently something has changed in libtool between when this patch was created, and when it was committed, such that the static lib part no longer works properly; this is why on cygwin and mingw the mdemo-exec tests STILL fail. Very frustrating. I plan to track this down in the next day or so). came into new light. I mean, this patch probably refers to the above mentioned commit, right? Yes, it does. I'm no expert on git bisect; if it's not to much trouble, could you attempt to determine when, after 2009-01, mdemo started to work on mingw/msys? (Actually, localizing that on cygwin might be good enough, if you don't have msysgit installed) P.S. In my defense, the patch in question fixed *multiple* issues with the whole symbol extraction behavior when both static and shared libs exist; some of which were just bad practice but wouldn't actually cause mdemo to fail. See the description here: http://lists.gnu.org/archive/html/libtool-patches/2010-06/msg00163.html -- Chuck
Re: [PATCH] Fix dependency tracking for MSYS/MinGW.
On 9/9/2010 4:59 AM, Peter Rosin wrote: As discussed in that other thread, namely http://lists.gnu.org/archive/html/libtool-patches/2010-09/msg00105.html I accidentally broke MSYS/MinGW. Here's an improved version of the patch shown in that message to fix the build issue. Sorry again. Ok to push? I can't approve, but it does appear to fix the mdemo-make failure on MinGW/MSYS. Running full test suite (MinGW/MSYS) now. Should be finished in four or five hours. Then on to the mdemo-exec/MinGW/MSYS problem as discussed in the other thread. -- Chuck
Re: [PATCH] Fix dependency tracking for MSYS/MinGW.
On 9/9/2010 12:57 PM, Charles Wilson wrote: On 9/9/2010 4:59 AM, Peter Rosin wrote: As discussed in that other thread, namely http://lists.gnu.org/archive/html/libtool-patches/2010-09/msg00105.html I accidentally broke MSYS/MinGW. Here's an improved version of the patch shown in that message to fix the build issue. Sorry again. Ok to push? I can't approve, but it does appear to fix the mdemo-make failure on MinGW/MSYS. Running full test suite (MinGW/MSYS) now. Should be finished in four or five hours. Mmm...much faster PC... Full test results (of the second version of this patch; the one that was the first one posted with this subject line): MinGW/MSYS: === old: 2 of 104 tests failed (2 tests were not run) As expected, the two failures are the mdemo exec tests: FAIL: tests/mdemo-exec.test FAIL: tests/mdemo2-exec.test new: 102 tests behaved as expected. 18 tests were skipped. I know a slightly different version of this patch has already been pushed, but I figure test results are never a bad thing. -- Chuck
Re: [PATCH 6/7] Convert file name to toolchain format when invoking $NM.
On 9/9/2010 3:56 PM, Ralf Wildenhues wrote: I understand that you're doing a difficult bug hunt here, and 6/7 is the only unapplied patch of this series (right?). I've looked at 6/7 again, and conclude that it has a low chance of regressing. I agree. If it makes things easier for you, then I'm fine with you going ahead and applying the patch. I don't think the uncommitted portions of Peter's series affect this particular bug hunt (now that the one regression has been corrected). This one is all me. :-( OTOH, I'm sure Peter would be very happy to push his remaining patches... Secondly, I can help with unsupervised git bisect if you need. In http://lists.gnu.org/archive/html/bug-libtool/2010-09/msg6.html, I posted a bisect script for a slightly different bug; for your case, you should adjust reconfdirs (for efficiency) and TESTS and the failure grep. In the 'git bisect start' command line, you need to specify one known-bad and one known-good revision. I'll take a look, but it may actually be faster to do it old-school: just trace thru the failing case in git master-NOW, figure out what's going wrong, and fix it. Last but not least, IIUC then you've complained about possibly multiple failures masking. Is this specifically about the stresstest? To alleviate this in the future, we can modify stresstest to fan it out into several test groups (so separate issues have a higher chance of producing separate failures), or modify it so it runs all tests (even if some failed earier) and summarizes the failing instances at the end. Naw, it's not stresstest. It's just mdemo (and mdemo-2) really push all the various bits of libtool and libltdl very hard. It's a very good test that way. The problem is we've/I've been too complacent about known failures in that test on MinGW/MSYS. Sure...it had known failures -- but by ignoring them, more unknown failures crept in and were hidden by the known ones. Now that we're trying to fix it...we discover that the leftover mashed potatoes in the fridge grew their own mold ecosystem... -- Chuck
Re: [PATCH 7/7] Prefer $NM @file over calculating the cmd line length.
On 9/8/2010 4:54 PM, Peter Rosin wrote: Hmmm, but @file makes it harder than necessary to debug on MSYS, since the automatic command line conversion make the n...@file branch work there. And the @file branch is probably bad for performance on MSYS too, FYI, the patch that adds @/looks/like/a/unix/path to the list of stuff that MSYS automatically converts to C:/msys-inst-root/dos/format/ was accepted and committed a yesterday. So it looks like MSYS-1.0.16 will include this feature...but we don't really have a schedule for when that will be released. since the manual forking conversion is so much slower than the automatic command line conversion. I think some kind of lazy conversion strategy -- like the one in 'compile' -- would be a worthwhile optimization. So, right now on MSYS you still manually convert @unix-path to @dos-format, right? If so, once MSYS-1.0.16 is released should libtool just assume that support is present and require msys-latest, or would an additional feature test be required? -- Chuck
Re: [PATCH 6/7] Convert file name to toolchain format when invoking $NM.
On 9/8/2010 6:14 PM, Charles Wilson wrote: On 9/8/2010 5:52 PM, Peter Rosin wrote: sharedlib_from_linklib_cmd, which is not used anywhere according # no lafile. user explicitly requested -dlpreopen import library. $sharedlib_from_linklib $dlprefile ^ Looks like something got dropped somewhere. (However, there is an unfixed bug here; apparently something has changed in libtool between when this patch was created, and when it was committed, such that the static lib part no longer works properly; this is why on cygwin and mingw the mdemo-exec tests STILL fail. Very frustrating. I plan to track this down in the next day or so). Hmm...I wonder...is this the cause of the mdemo-exec regression? I don't THINK so, because that testcase uses the .la files and not the .dll.a ones IIRC, but it should probably be fixed regardless. I'll find out... -- Chuck
Re: [PATCH 6/7] Convert file name to toolchain format when invoking $NM.
On 9/8/2010 5:52 PM, Peter Rosin wrote: Den 2010-09-05 23:29 skrev Ralf Wildenhues: * Peter Rosin wrote on Sun, Sep 05, 2010 at 10:02:11PM CEST: Subject: [PATCH 6/7] Convert file name to toolchain format when invoking $NM. * libltdl/config/ltmain.m4sh (func_generate_dlsyms) (func_win32_libid, func_cygming_gnu_implib_p) (func_cygming_ms_implib_p): When using the name lister to find symbols in files, convert the file names to a format appropriate for the tool. You're gonna hate me for this, I already know, but: does this patch fix testsuite failures, are all code paths covered? If not, we need to improve the test suite. If yes, please mention them in the log, thanks. Those in func_cygming_gnu_implib_p and func_cygming_ms_implib_p appear to be dead code. Both functions are only called from func_cygming_dll_for_implib_fallback which only use is that it is assigned to the cache variable lt_cv_sharedlib_from_linklib_cmd whose value is in turn only assigned to the LT_DECL variable sharedlib_from_linklib_cmd, which is not used anywhere according to my searching. Err...yes it is, around line 2546 in ltmain.m4sh: for dlprefile in $dlprefiles; do func_verbose extracting global C symbols from \`$dlprefile' func_basename $dlprefile name=$func_basename_result case $host in *cygwin* | *mingw* | *cegcc* ) # if an import library, we need to obtain dlname if func_win32_import_lib_p $dlprefile; then func_tr_sh $dlprefile eval curr_lafile=\$libfile_$func_tr_sh_result dlprefile_dlbasename= if test -n $curr_lafile func_lalib_p $curr_lafile; then # Use subshell, to avoid clobbering current variable values dlprefile_dlname=`source $curr_lafile echo $dlname` if test -n $dlprefile_dlname ; then func_basename $dlprefile_dlname dlprefile_dlbasename=$func_basename_result else # no lafile. user explicitly requested -dlpreopen import library. $sharedlib_from_linklib $dlprefile dlprefile_dlbasename=$sharedlib_from_linklib_result fi Now, this happens only when -dlprepen foo.dll.a (as opposed to foo.la). AND sharedlib_from_linklib is only assigned to func_cygming_dll_for_implib_fallback when dlltool does not support the --identify and --identify-strict options. All *current* binutils packages shipped by MinGW, MinGW64, and cygwin support that option. So to trigger this, you have to a) configure with lt_cv_sharedlib_from_linklib_cmd=func_cygming_dll_for_implib_fallback b) link using -dlpreopen /path/to/foo.dll.a I've actually done that manually sometime in the last six months or so, but I don't remember exactly when. It worked then... My initial plan was to remove _fallback and its supporting functions about a year after the first official release of libtool containing this stuff (gak, that giant sed script is AWFUL...) We haven't even HAD that official release yet, so it's still a bit premature to remove it, IMO. :-) (However, there is an unfixed bug here; apparently something has changed in libtool between when this patch was created, and when it was committed, such that the static lib part no longer works properly; this is why on cygwin and mingw the mdemo-exec tests STILL fail. Very frustrating. I plan to track this down in the next day or so). -- Chuck
Re: [PATCH] [cygwin|mingw|cross-compile]: Path conversion support.
On 7/18/2010 9:07 PM, Charles Wilson wrote:
linux-cygwin cross:
old: 2 of 112 tests failed (12 tests were not run)
FAIL: tests/demo-hardcode.test
FAIL: tests/depdemo-relink.test
new: AWFUL again -- but there's an explanation
88 tests were run, 28 failed (3 expected failures).
29 tests were skipped.
I was using my new, sysroot-less linux-cygwin cross compiler, so
I expected good results just like the last time I used this compiler.
However, UNLIKE last time, I went ahead an set LT_CYGPATH to point to
my wine/cygwin cygpath.exe. Well, as has been demonstrated, it coredumps
a lot -- and prints lots of gobbledygook. The new testsuite doesn't like
gobbledygook. LAST time, I left LT_CYGPATH unset, so libtool simply
skipped that part of the test.
I'll re-run again, without LT_CYGPATH set, just to be sure...
FWIW, ensuring LT_CYGPATH is not set doesn't actually make the testsuite
performance any better. You have to actually turn off binfmt. Here's why:
m4_define([LT_AT_EXEC_CHECK],
[lt_exe=$1; if test -f $1$EXEEXT; then lt_exe=$lt_exe$EXEEXT; fi
AT_CHECK([if $lt_exe $5; then :; else lt_status=$?; ]dnl
[ m4_ifval([$2], [test $lt_status != $2 ])]dnl
[ test X$host != X$build test -x $lt_exe exit 77; ]dnl
[ exit $lt_status; fi],[$2],[$3],[$4])
])
The way LT_AT_EXEC_CHECK works is:
* ALWAYS try to run the executable
if it passes, great
* otherwise, compare the exit status with a provided value
if it matches the expected value, great
* otherwise, if crossbuilding and the exe exists and is
marked executable, then
* at least building the app succeeded: SKIP
* otherwise, return with the exit status of the app
The problem occurs because with cygwin-1.7 + Wine, running apps (almost)
always fails, but Wine itself returns a successful error code. But...the
stdout/stderr values are definitely NOT what the test which CALLED
LT_AT_EXEC_CHECK expects.
The only way I've found to make this work is to turn off binfmt, so
that Wine is NOT used to launch the cygwin exe -- linux tries to run the
.exe itself. This, of course, fails...and that allows the 'if
crossbuilding' clause to kick in, and the test is marked SKIP.
Note that this is already documented in the recent changes to
libtool.texi -- I just hadn't spelled it out in a message to this list,
and I'd promised to post the best-case linux-cygwin test results, so...
However, LT_AT_EXEC_CHECK *is* doing the right thing here. We *want* to
first try to run the (possibly foreign) $host executable. What if
$build=x86_64-pc-linux-gnu and $host=i686-pc-linux-gnu? That should
work, and we shouldn't just assume it won't and automatically SKIP. Or
better yet, $build=i686- vs. $host=i386-?
I think this is a Wine bug; I'll report it upstream. But for now...on
the linux-cygwin case, I'll always be reporting testsuite results with
binfmt disabled.
And linux-mingw results with binfmt enabled...
linux-cygwin:
==
old testsuite: 2 of 114 tests failed (10 tests were not run)
FAIL: tests/demo-hardcode.test
FAIL: tests/demo-relink.test
demo-relink should be marked SKIP if cross compiling
I don't really know why demo-hardcode failed; I don't think hardcoding
is supported in PE/COFF executables, so what gives?
demo-hardcode.test: === Finding libtool.m4's guesses at hardcoding values
= Searching for hardcoded library directories in each program
.libs was not hardcoded in `hc-direct', as libtool expected
.libs was not hardcoded in `hc-libflag', which fooled libtool
`hc-libpath' was not linked properly, as libtool expected
.libs was not hardcoded in `hc-minusL', as libtool expected
I think this is wrong, for both cygwin and mingw:
hardcode_libdir_flag_spec=-L\$libdir
-L just sets the search path during linking, and has nothing to do with
a runtime-hardcoded path. For reference, native linux (ELF) has this:
hardcode_libdir_flag_spec=\${wl}-rpath \${wl}\$libdir
new testsuite:
ERROR: 63 tests were run,
4 failed (2 expected failures).
57 tests were skipped.
The two unexpected failures were:
38: Link order test FAILED (link-order.at:121)
112: Run tests with low max_cmd_len FAILED (cmdline_wrap.at:43)
38 seems to be an oversight in the sysroot support, but I haven't
thought about it too much:
libtool: link: warning: library
`/home/me/tmp/libtool/_build-linux-cygwin-cross-sysroot/tests/testsuite.dir/038/old/lib/liba.la'
was moved.
libtool: link: cannot find the library
`/opt/devel/cygwin/i686-pc-cygwin/sys-root/home/me/tmp/libtool/_build-linux-cygwin-cross-sysroot/tests/testsuite.dir/038/old/lib/libb.la'
or unhandled argument
`=/home/cwilson/tmp/libtool/_build-linux-cygwin-cross-sysroot/tests/testsuite.dir/038/old/lib/libb.la'
Note that it's expecting my entire build area to have been relocated
underneath my compiler's sysroot
Re: [PATCH 6/7] Convert file name to toolchain format when invoking $NM.
Peter, a question about your current patch series: with it only partially committed, do you expect errors? Are we waiting for some other change upon which the current series depends, before it all just works again...or are things fubared now? Right now, I'm seeing a regression just building libltdl. It builds correctly the first time -- but when I try to run the old test suite, a rule gets triggered to rebuild libltdl.al: (cd ../..; make `echo ../../libltdl/libltdlc.la | sed 's,.*\.\./libltdl/,libltdl/,g'`) make[1]: Entering directory `/c/cygwin-1.7/usr/src/packages/libtool/git/build-mingw' make[1]: *** No rule to make target `..\\libtool\\libltdl\\loaders\\preopen.c', needed by `libltdl/loaders/libltdl_libltdlc_la-preopen.lo'. Stop. Going to the top level and simply typing 'make' also triggers the error: $ make make all-recursive make[1]: Entering directory `/c/cygwin-1.7/usr/src/packages/libtool/git/build-mingw' make[2]: Entering directory `/c/cygwin-1.7/usr/src/packages/libtool/git/build-mingw' make[2]: *** No rule to make target `..\\libtool\\libltdl\\loaders\\preopen.c', needed by `libltdl/loaders/libltdl_libltdl_la-preopen.lo'. Stop. make[2]: Leaving directory `/c/cygwin-1.7/usr/src/packages/libtool/git/build-mingw' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/c/cygwin-1.7/usr/src/packages/libtool/git/build-mingw' make: *** [all] Error 2 This is with MSYS/MinGW (but the git tree is over on my cygwin installation, since I only have cygwin-git installed). I suspect that there is a mismatch between the targets (and deps) in the Makefile (and the .deps/*.P files), and the new pre-converted filenames being generated by $to_tool_file_cmd. Basically, it appears that this is case where if-it-ain't-broke-don't-fix-it should have applied, and MSYS/MinGW was *not* broke. At least, not anywhere except inside @file contents, and maybe the actual name OF that @file (this latter case is the reason behind the recent msys-1.0.16 change). I'm wondering if, when $build=MSYS, we could turn off all of the libtool to_tool_file_cmd stuff, EXCEPT when generating the contents of an @file. You know, just fix the broken stuffwithout breaking other, previously working, stuff? (I mean, you're basically removing the whole point of msys; why not just use cygwin instead, if you're not going to let msys do for you what it was designed to do?) I've put off trying to track down the error wrt mdemo until after this is resolved; I can't really compare the behavior of the (previously working) mdemo-static-make/mdemo-static-exec and the broken static subcase of mdemo-make/mdemo-exec, when neither one will actually build any longer... -- Chuck
Re: [PATCH 1/7] Add file name conversion from $build to toolchain.
[meta-request: in the future, could you not use whatever option it is that causes the entire patch message to be stored at attachment to the actual message...this is a little awkward to reply-to:] On 9/5/2010 3:58 PM, Peter Rosin wrote: nothing ...which means all replies have to manually cut-n-paste-as-quotation which is painful. Unless somebody knows what option to set in TBird to DTRT? On 9/5/2010 3:58 PM, Peter Rosin wrote: +...@defvar to_tool_file_cmd Urk. I guess I ought to go ahead and define to_host_file_cmd... You might also want to add a line or two to the new section concerning the lying cygwin-mingw case: ...To force the correct file name conversion in this situation, you should do the following _before_ running configure: export lt_cv_to_host_file_cmd=func_convert_file_cygwin_to_w32 ...Unless you plan to do all of that as part of some other pure-doc patch. -- Chuck
Re: [PATCH 1/7] Add file name conversion from $build to toolchain.
On 9/5/2010 5:20 PM, Ralf Wildenhues wrote: Hi Peter, * Peter Rosin wrote on Sun, Sep 05, 2010 at 09:58:58PM CEST: Subject: [PATCH 1/7] Add file name conversion from $build to toolchain. * configure.ac: Ensure to_tool_file_cmd is available to Makefile. * libltdl/m4/libtool.m4 (_LT_PATH_CONVERSION_FUNCTIONS): Add cache variable lt_cv_to_tool_file_cmd that describes how to convert file names from $build to toolchain format. * libltdl/config/ltmain.m4sh (func_to_tool_file): New function that utilizes the above. * Makefile.am: Ensure to_tool_file_cmd is included in TEST_ENVIRONMENT so that it is passed to (old testsuite) tests. * testsuite.at: Ensure to_tool_file_cmd is passed as a variable setting on the configure line for (new testsuite) tests. * doc/libtool.texi (libtool script content): Update with to_tool_file_cmd description. OK pending the issues that Charles had with the patch, plus nits below. Actaully, if you read my recent reply closely, I don't have any issues with *the patch* that Peter sent. Only (1) the way the patch was sent to the mailing list, (2) a note to myself that *I* need to document to_host_file_cmd, and (3) the single comment about adding to the docu -- which could be part of this patch series or a later patch, as far as I am concerned. -- Chuck
Re: [PATCH] Adjust naming of MSVC import libraries.
On 9/4/2010 4:52 AM, Peter Rosin wrote: If you are using -lfoo, then you *must* use 'compile' as well as cl does not know about the -l option. So, I was thinking that 'compile' instead of just transforming -lfoo into foo.lib would walk the library search path (in the same order as cl would) and replace -lfoo with either of foo.lib or foo.dll.lib depending on which was found first and possibly also modified by any -static or -shared flags (also not supported by cl, so -static and -shared would have to be completely handled by 'compile' and would only affect -lfoo handling, at least in my current thinking). Remember that -static and -shared, the gcc options, are not antonyms: `-static' On systems that support dynamic linking, this prevents linking with the shared libraries. `-shared' Produce a shared object which can then be linked with other objects to form an executable. The former deals with what entities you will link to; the latter deals with what type of output entity you will create. For our current discussion, you would really only need to implement -static handling; by default the search would prefer foo.dll.lib (but would accept kernel32.lib). With -static, the search would accept only foo.lib. As with cygming, the link phase for -static would never try to verify that foo.lib was actually a static library and not an import lib; it would have to be a name-based search only (for the reasons you describe below). -shared, obviously, would need to be translated into the appropriate option to tell cl.exe to create a .dll (as opposed to an .exe). Note that -shared can't trigger 'compile' to always replace -lfoo with foo.dll.lib since a bunch of system libraries are shared but still named according as foo.lib (as Microsoft is obviously not following my naming convention). I think other system libraries are static and also named according to foo.lib, so it would do no good to prefer the import lib by naming it foo.lib and name the static lib something like foo.s.lib. Right. That's the same conclusion we reached wrt .dll.a vs. .a Agreed. And the testsuite runs have finished and results are the same. I still want to push this. I have no objections anymore, but I can't approve it. -- Chuck
Re: [PATCH 7/7] Prefer $NM @file over calculating the cmd line length.
FYI, I just proposed the following for MSYS (when launching native apps, like the MinGW binutils/gcc, or MSVC tools): http://thread.gmane.org/gmane.comp.gnu.mingw.msys/4820 2010.09.04 Charles Wilson ... * path.cc (msys_p2w): Support conversion of @file arguments. If we're lucky, it'll be in MSYS-1.0.16. -- Chuck
Re: [PATCH] Adjust naming of MSVC import libraries.
On 9/3/2010 7:59 AM, Peter Rosin wrote: So, I'm now proposing this naming scheme instead: static lib: foo.lib shared lib: foo-2.dll import lib: foo.dll.lib which is a lot more consistent with the MinGW naming, i.e.: static lib: libfoo.a shared lib: libfoo-2.dll import lib: libfoo.dll.a The only reason MinGW could do this, is that when we developed the cygmingw naming scheme, we simultaneously updated both gcc and ld to understand the new names, and imposed a search order: For instance, when ld is called with the argument `-lxxx' it will attempt to find, in the first directory of its search path, libxxx.dll.a xxx.dll.a libxxx.a xxx.lib cygxxx.dll (*) libxxx.dll xxx.dll before moving on to the next directory in the search path. (*) Actually, this is not `cygxxx.dll' but in fact is `prefi.dll', where `prefix' is set by the `ld' option `--dll-search-prefix=prefix'. This way, non-libtool unixish makefiles could always use -lfoo, regardless of whether they were linking to a static lib or dynamic lib. We can't similarly change the behavior of cl.exe -- unless you want to build THAT logic into the `compile' script (or is there a `linker' script)? On the negative side we have: * Inconsistent naming of import libs when comparing with other MSVC libraries. They are typically named as the static lib, but so are static libs, when that's what's shipped. Pick your poison. Right. So anybody who uses libtool to build a core library, but then wants to build an application (which doesn't use libtool) that links against that DLL, will have to modify their makefile rules to say -lfoo.dll. Really, what this means is that non-libtool clients of libfoo will have to put detection machinery (in autoconf?) to determine whether libfoo.a or libfoo.dll.a exists; Makefile.in will have to use a subst variable so that either -lfoo or -lfoo.dll is specified in the Makefile... This would include most of libtool's own built-in tests, I would think. Unless `compile'/`linker' becomes a lot smarter, and abstracts all that. (Actually, now that I think about this some more, modifying these scripts to implement search rules is probably a bad idea; they need to implement the SAME search rules as the underlying tool (cl.exe in this case), otherwise you'd get inconsistent results. So, scratch that idea). Besides, it's better to do this now, before the first release of libtool with MSVC support, than after. Well, that's true. I have some misgivings about this plan, but you know best. -- Chuck
Re: [PATCH] Adjust naming of MSVC import libraries.
On 9/3/2010 1:42 PM, Peter Rosin wrote:
Den 2010-09-03 18:05 skrev Charles Wilson:
This way, non-libtool unixish makefiles could always use -lfoo,
regardless of whether they were linking to a static lib or dynamic lib.
Well, -lfoo didn't work for both static and shared libs in non-libtooled
use cases before this patch either, so status quo...
For MSVC.
Your assertion is not true for cygwin/gcc, mingw/gcc, or msys/gcc.
We can't similarly change the behavior of cl.exe -- unless you want to
build THAT logic into the `compile' script (or is there a `linker' script)?
The thought did cross my mind. But not right now. (There is no 'linker'
script, so I would put it in the 'compile' script.)
On the negative side we have:
* Inconsistent naming of import libs when comparing with other MSVC
libraries. They are typically named as the static lib, but so are
static libs, when that's what's shipped. Pick your poison.
Right. So anybody who uses libtool to build a core library, but then
wants to build an application (which doesn't use libtool) that links
against that DLL, will have to modify their makefile rules to say -lfoo.dll.
Or rename the import library files. But that's no fun either.
Right. I think VizStudio handles this by putting treating the static
and shared libraries as different configurations; separate configs have
separate build dirs...even if the static library and the import library
have the same name (and it's usually up to the end user to set up
client's -L paths to point to the correct location of those libs based
on the desired configuration; e.g. by including ${CONFIGURATION_NAME} in
the -L path, I believe).
I've seen VizStudio-built projects use several different arrangements
for delivering these SDK-style items to end users; separate dirs, or --
as you suggest -- separate names (usually something like
'foo_shared.lib') FFTW punts completely, and ships .def files
(instructing users to create their own import libs using the toolchain
mechanism of their choice; obviously then, the choice of import library
NAME is up to the end user).
Really, what this means is that non-libtool clients of libfoo will have
to put detection machinery (in autoconf?) to determine whether libfoo.a
or libfoo.dll.a exists; Makefile.in will have to use a subst variable so
that either -lfoo or -lfoo.dll is specified in the Makefile...
But this was true before this patch too, but with s/-lfoo\.dll/-lfoo-2/
(which is worse since you have to keep track of the version as well).
Ah, yes, now I see. Surely, your mechanism is a strict improvement over
that.
This would include most of libtool's own built-in tests, I would think.
Unless `compile'/`linker' becomes a lot smarter, and abstracts all that.
(Actually, now that I think about this some more, modifying these
scripts to implement search rules is probably a bad idea; they need to
implement the SAME search rules as the underlying tool (cl.exe in this
case), otherwise you'd get inconsistent results. So, scratch that idea).
It's probably hard to get right, yes. But I'm not scratching it without
at least looking at it a bit more.
Well, my point is, unless EVERYTHING *always* uses the compile script --
including all autoconf (or Cmake, scons, etc etc) tests to determine
system characteristics like what library is installed where under which
name -- you will get very hard to find/fix inconsistencies in behavior.
Unless...
it doesn't matter, because the compile script and the underlying tool
(cl.exe in this case) use the same search rules. But if they both use
the same search rules, then why bother implementing those rules in the
compile script at all? Just pass the args on verbatim to cl.exe!)
Besides, it's better to do this now, before the
first release of libtool with MSVC support, than after.
Well, that's true. I have some misgivings about this plan, but you know
best.
I don't really like it either. Not this way and not the way it was before
the patch, but there is no good way to do it when you have to feed the
exact library file name to MSVC.
right.
Hmmm, unless you put shared libs in one
set of directories and static libs in one set and play games with the
library search path.
As I mentioned above, that's the way VizStudio does it.
But that seems very hard too, and on top of that it
would be a MSVC-only solution and therefore a hard sell.
Yes, IMO this would be a large architectural change to the way libtool
operates.
I think adding a
matching library search to 'compile' is the best way forward (but again,
not now).
Matching what? If it matches cl.exe (e.g. cl -lfoo does the same thing
as compile -lfoo), in terms of locating foo.lib -- then compile won't
be able to behave differently by saying oooh, he's linking shared,
let me look for foo.dll.lib first...okay, there it is...
Suddenly, `compile's behavior doesn't match cl.exe's.
Doing the library search with this new naming is simpler too
Re: [PATCH 0/7] Support for toolchains that are not $host-native.
On 9/2/2010 9:06 AM, Peter Rosin wrote: However, my previous suggestion with a naive_slashify instead of naive_backslashify doesn't work either since MSYS turns @c:/foobar into @c;c:\msys\1.0\foobar (or something similar, that was from memory) which we must avoid at all cost. cygpath -m (instead of -w) is fine on Cygwin though since Cygwin doesn't clobber @c:/foobar for us. Maybe we can work around this by sanitizing the input files in ar-lib, but that seems a bit horrible to me... I'll see if I can fix this somehow. Suggestions welcome. Actually, I think MSYS's heuristic for determining whether an argument contains a path -- and whether that path is already a dos-style one -- should be improved so that args which match the regex '^...@[[:alpha:]]:[/\]' are understood as dos-style abspaths. I'll look into that. Oh, wait. We'd also need to add exceptions for all of MSVC's command switches, which prohibit spaces between the switch and that path: -FoC:/bob/, -FeD:/fred, etc. Ick. I dunno if that's worth the effort -- or if it would even be accepted. After all, MSYS's reason for existence is to support MinGW, not MSVC... I could justify adding the '@' heuristic, because MinGW ar can use it, but the rest... What do you think, Peter? -- Chuck
Re: [PATCH] Path conversion documentation
On 9/2/2010 3:05 AM, Gary V. Vaughan wrote: On 2 Sep 2010, at 12:40, Charles Wilson wrote: 'Course, I notice that I screwed up the date in the ChangeLog. Could the next person to commit a change to that file, please fix it? -2010-09-31 ... +2010-09-01 ... Might be unnecessary... Well, we aren't yet using your use-gnulib branch, and right now the ChangeLog contains an inaccurate date. So, since I'm *sure* somebody is going to commit something to master between now and the release... In my use-gnulib branch, I'm wondering whether to incorporate gitlog-to-changelog, and have it generate the current year's ChangeLog at distribution time. However the first few months of the year don't have suitable gitlog's to convert nicely. I can think of a few options: i) wait until next year ii) post process the output of gitlog-to-changelog for now IF we want to use gitlog to create the ChangeLog, then either of these is fine with me. However, see below. iii) fix the gitlog entries -- if that's even viable? I don't think (iii) will work. You can play all sorts of games with filter-branch, but...I managed to screw up three different git clones before I gave that up as a bad idea (I was trying to fix the author of a commit that was not the final entry). Comments? It does seem like gitlog and ChangeLog duplicate the same info, so it would definitely be nice to reduce dvlpr workload. However, I have noticed that you /just can't/ do the following -- which is actually required by the GCS: Two people worked on a single patch, or someone submitted it, and then one of the people with commit access modified the patch slightly. The GCS says you should do this, in the ChangeLog: === 2010-09-02 John Original Submitter ... Steve Committer Rewrite ... === can't do this * file (func): comment Signed-off-by: Steve Committer Rewrite ... === Also, for trivial commits without a copyright assignment, the GCS says you should do this: === 2010-09-02 Sally No Assignment ... (tiny change) * file (func): comment Signed-off-by: Mark Committer ... === Now, MAYBE the committer can do that by munging the --author='...'; I've never tried and I'm not sure how thoroughly git checks the --author argument. -- Chuck
Re: git log - changelog
On 9/2/2010 5:08 PM, Eric Blake wrote: On 09/02/2010 03:00 PM, Charles Wilson wrote: Two people worked on a single patch, or someone submitted it, and then one of the people with commit access modified the patch slightly. The GCS says you should do this, in the ChangeLog: === 2010-09-02 John Original Submitter... Steve Committer Rewrite...=== can't do this Well, if you go by git's Signed-off-by tags as a way of generating those lines, it would be possible. Ah, but then how do you distinguish between a chain of Signed-off-by labels -- as in the Linux kernel, where various subsystem maintainers also have to sign off on patches, in the sense of I certify that this is OK, and it has proper approvals, and has been reviewed, (FSF: and the author has a copyright assignment). vs. and I modified the actual contents of the patch a little bit -- Chuck
Re: [PATCH 4/7] Use func_to_tool_file instead of fix_srcfile_path.
On 9/1/2010 5:30 PM, Ralf Wildenhues wrote: * Peter Rosin wrote on Wed, Sep 01, 2010 at 10:33:59PM CEST: * libltdl/config/ltmain.m4sh (func_mode_compile): Replace the fix_srcfile_path hook with a call to func_to_tool_file. * libltdl/m4/libtool.m4 (_LT_LINKER_SHLIBS) [cygwin,mingw,pw32] [cegcc]: Drop fix_srcfile_path. The patch series is lacking libtool.texi updates. Well, I assume Peter will get the same leniency I did, to provide documentation at a later date, provided later is pretty soon? I imagine he'd want to wait until after my new docu is committed first, so he can extend some of the new sections as appropriate. That should happen later today. -- Chuck
Re: [PATCH 1/7] Add file name conversion from $build to toolchain.
On 9/1/2010 4:32 PM, Peter Rosin wrote: +AC_MSG_CHECKING([how to convert $build file names to toolchain format]) +AC_CACHE_VAL(lt_cv_to_tool_file_cmd, +[#assume ordinary cross tools, or native build. +lt_cv_to_tool_file_cmd=func_convert_file_noop +case $host in + *mingw* ) +case $build in + *mingw* ) # actually msys +lt_cv_to_tool_file_cmd=func_convert_file_msys_to_w32 +;; +esac +;; +esac Repeating Ralf's commentary to me, if you're using $host then you should use *-*-mingw*; if you want to use mingw* in the various match patterns then you should use $host_os. -- Chuck
Re: [PATCH] Path conversion documentation
On 8/30/2010 4:20 PM, Ralf Wildenhues wrote:
* Charles Wilson wrote on Mon, Aug 30, 2010 at 09:45:00PM CEST:
Thanks for the review.
My pleasure.
Pushed as attached.
'Course, I notice that I screwed up the date in the ChangeLog. Could
the next person to commit a change to that file, please fix it?
-2010-09-31 ...
+2010-09-01 ...
--
Chuck
diff --git a/ChangeLog b/ChangeLog
index 63d4b74..44d0f47 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2010-09-31 Charles Wilson ...
+
+ Path conversion documentation
+ * doc/libtool.texi (Platform quirks): Add new subsections
+ 'Cross compiling' and 'File name conversion'.
+
2010-09-01 Ralf Wildenhues Ralf.Wildenhues@gmx.de
tests: avoid spurious pic_flag test failure on HP-UX 10.20.
diff --git a/doc/libtool.texi b/doc/libtool.texi
index a3f1c59..573536e 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -223,6 +223,8 @@ Platform quirks
* Reloadable objects:: Binding object files together.
* Multiple dependencies:: Removing duplicate dependent libraries.
* Archivers:: Programs that create static archives.
+* Cross compiling:: Issues that arise when cross compiling.
+* File name conversion::Converting file names between platforms.
@end detailmenu
@end menu
@@ -5750,6 +5752,8 @@ write your own.
* Reloadable objects:: Binding object files together.
* Multiple dependencies:: Removing duplicate dependent libraries.
* Archivers:: Programs that create static archives.
+* Cross compiling:: Issues that arise when cross compiling.
+* File name conversion::Converting file names between platforms.
@end menu
@node References
@@ -5875,6 +5879,420 @@ must be used to ``bless'' the created library before linking against it,
with the @kbd{ranlib lib@var{name}.a} command. Some systems, like Irix,
use the @code{ar ts} command, instead.
+@node Cross compiling
+@subsection Cross compiling
+@cindex cross compile
+
+Most build systems support the ability to compile libraries and applications
+on one platform for use on a different platform, provided a compiler capable
+of generating the appropriate output is available. In such cross compiling
+scenarios, the platform on which the libraries or applications are compiled
+is called the @dfn{build platform}, while the platform on which the libraries
+or applications are intended to be used or executed is called the
+@dfn{host platform}.
+@ref{GNU Build System,, The GNU Build System, automake, The Automake Manual},
+of which libtool is a part, supports cross compiling via arguments passed to
+the configure script: @option{--build=...} and @option{--host=...}. However,
+when the build platform and host platform are very different, libtool is
+required to make certain accommodations to support these scenarios.
+
+In most cases, because the build platform and host platform differ, the
+cross-compiled libraries and executables can't be executed or tested on the
+build platform where they were compiled. The testsuites of most build systems
+will often skip any tests that involve executing such foreign executables when
+cross-compiling. However, if the build platform and host platform are
+sufficiently similar, it is often possible to run cross-compiled applications.
+Libtool's own testsuite often attempts to execute cross-compiled tests, but
+will mark any failures as @emph{skipped} since the failure might simply be due
+to the differences between the two platforms.
+
+In addition to cases where the host platform and build platform are extremely
+similar (e.g. @samp{i586-pc-linux-gnu} and @samp{i686-pc-linux-gnu}), there is
+another case in which cross-compiled host applications may be executed on the
+build platform. This is possible when the build platform supports an emulation
+or API-enhanced environment for the host platform. One example of this
+situation would be if the build platform were MinGW, and the host platform were
+Cygwin (or vice versa). Both of these platforms can actually operate within a
+single Windows instance, so Cygwin applications can be launched from a MinGW
+context, and vice versa---provided certain care is taken. Another example
+would be if the build platform were GNU/Linux on an x86 32bit processor, and
+the host platform were MinGW. In this situation, the
+@uref{http://www.winehq.org/, Wine} environment can be used to launch Windows
+applications from the GNU/Linux operating system; again, provided certain care
+is taken.
+
+One particular issue occurs when a Windows platform such as MinGW, Cygwin, or
+MSYS is the host or build platform, while the other platform is a Unix-style
+system. In these cases, there are often conflicts between the format of the
+file names and paths expected within host platform libraries and executables,
+and those employed on the build platform.
+
+This situation is best described using a concrete example: suppose the build
Re: [PATCH] Remove clcommit.m4sh.
On 8/31/2010 10:53 PM, Gary V. Vaughan wrote: Does anyone else use the commit script? * clcommit.m4sh: Removed. This script was written to help keep ChangeLog and commit messages in sync when committing to CVS, and is an anachronism now that Libtool uses git. Okay to push? --- ChangeLog |7 + clcommit.m4sh | 375 - 2 files changed, 7 insertions(+), 375 deletions(-) delete mode 100644 clcommit.m4sh Don't you also need to patch Makefile.maint to remove references to this file? (There's a comment referring to it in mailnotify.m4sh too, but that's not important). -- Chuck
[SCM] GNU Libtool branch, master, updated. v2.2.10-137-gf91cf56
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.
The branch, master has been updated
via f91cf561abf175642e6c20299bea7d5199913133 (commit)
from 7f41a19bc95d266cf0761bdad21e1821335cd442 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
commit f91cf561abf175642e6c20299bea7d5199913133
Author: Charles Wilson libt...@cwilson.fastmail.fm
Date: Mon Aug 30 02:04:33 2010 -0400
Update path conversion warning messages
* libltdl/config/ltmain.m4sh (func_convert_file_check): Update
comments and warning message.
(func_convert_path_check): Update warning message.
Signed-off-by: Charles Wilson libt...@cwilson.fastmail.fm
---
Summary of changes:
ChangeLog |7 +++
libltdl/config/ltmain.m4sh |8
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index c6c2447..d730232 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2010-08-30 Charles Wilson libt...@cwilson.fastmail.fm
+
+ Update path conversion warning messages
+ * libltdl/config/ltmain.m4sh (func_convert_file_check): Update
+ comments and warning message.
+ (func_convert_path_check): Update warning message.
+
2010-08-29 Peter Rosin p...@lysator.liu.se
Fix typo when renaming path conversion functions.
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 32860c7..6948138 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -794,14 +794,14 @@ func_convert_core_msys_to_w32 ()
# func_convert_file_check ARG1 ARG2
-# Verify that ARG1 (a path in $build format) was converted to $host format in
-# ARG2. Otherwise, emit an error message, but continue (resetting
+# Verify that ARG1 (a file name in $build format) was converted to $host
+# format in ARG2. Otherwise, emit an error message, but continue (resetting
# func_to_host_file_result to ARG1).
func_convert_file_check ()
{
$opt_debug
if test -z $2 test -n $1 ; then
-func_error Could not determine host path corresponding to
+func_error Could not determine host file name corresponding to
func_error \`$1'
func_error Continuing, but uninstalled executables may not work.
# Fallback:
@@ -819,7 +819,7 @@ func_convert_path_check ()
{
$opt_debug
if test -z $4 test -n $3; then
-func_error Could not determine the host path(s) corresponding to
+func_error Could not determine the host path corresponding to
func_error \`$3'
func_error Continuing, but uninstalled executables may not work.
# Fallback. This is a deliberately simplistic conversion and
hooks/post-receive
--
GNU Libtool
Re: [PATCH] Path conversion documentation
On 8/30/2010 2:48 PM, Ralf Wildenhues wrote:
* Charles Wilson wrote on Mon, Aug 30, 2010 at 01:50:12AM CEST:
OK to push?
Looks fine to me too, only one or two issues are not markup or typo
nits (but I have been very nitpicky below).
I expected that. This is really only a first draft with little in the
way of editing. I'm surprised at how few nits, or even major criticisms,
there are.
Thanks for writing this,
Sure. Hopefully it also provides an appropriate spot (subsubsection
under Platform quirks:Cross compiling) for a discussion of sysroot.
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -223,6 +223,8 @@ Platform quirks
* Reloadable objects:: Binding object files together.
* Multiple dependencies:: Removing duplicate dependent libraries.
* Archivers:: Programs that create static archives.
+* Cross compiling:: Issues that arise when cross compiling.
+* File name/path conversion:: Converting filenames between platforms.
FWIW, I would s/\/path// but only because I find the result more
readable and as informative.
Ack. Should filenames be 'file names', as well?
@@ -5875,6 +5879,383 @@ must be used to ``bless'' the created library before
linking against it,
with the @kbd{ranlib l...@var{name}.a} command. Some systems, like Irix,
use the @code{ar ts} command, instead.
+...@node Cross compiling
+...@subsection Cross compiling
+...@cindex cross compile
+
+Most build systems support the ability to compile libraries and applications
+on one platform (the @code{$build} system) for use on a different platform (the
I don't much like variable references that include the $, because that
ties you to a particular language, whereas here, you are talking about
concepts rather than languages. standards.texi just use 'the build
system'. Here, since you're defining the term, you could use
@dfn{build system} or maybe @emph, and later on just use it without
markup.
Yeah, I really didn't know how to indicate that I'm talking both of a
concept, and some variable that libtool itself is sensitive to. I tried
@var, but that just looked wrong. This is a good place to introduce
terms; I'll use @dfn and reword as recommended in the texinfo docu:
Use the command only in passages whose purpose is to
introduce a term which will be used again or which the reader ought to
know. Mere passing mention of a term for the first time does not
deserve `...@dfn'.
+...@code{$host} system) -- provided a compiler capable of generating the
Likewise for `host system', and instances below.
Ack.
+appropriate output is available. The GNU Build System
+...@url{http://www.gnu.org/software/hello/manual/automake/GNU-Build-System.html},
@uref please, and how about putting `GNU Build System' in the second
argument of @uref, and in the first argument, replacing all single
slashes with /@/ so they are line-wrapped nicely in the PDF.
Actually, why not make this a normal inter-manual reference like
@ref{GNU Build System,, The GNU Build System, automake, The Automake
Manual}
that way it will render well in all outputs?
OK. The problem with @ref is that it *must* be followed by a . or ,
This is not a problem in this instance, but it is a problem in others.
+foriegn executables when cross-compiling. However, if the @code{$build} and
foreign
Ack.
+operate within a single Win32 instance, so Cygwin applications can be launched
Either s/Win32/w32/ globally in your patch, or use Windows, as
recommended by the GCS.
I'll use Windows (even though it will drive RMS crazy) -- except when
referring to the libtool function names.
+from a MinGW context, and vice versa -- provided certain care is taken. Another
+example would be if @code{$build} were linux on an @samp{x86} 32bit processor,
Either GNU/Linux, or you write out a full triple like above.
Ack.
+and @code{$host} were MinGW. In this situation, the WINE
+...@url{http://www.winehq.org/} environment can be used to launch Win32
@uref{http://www.winehq.org/, Wine}, and s/WINE/Wine/ globally
WINE is an acronym, in classic recursive style: WINE Is Not an Emulator.
But, it does appear the upstream folks have stopped capitalizing it, so...
I noticed one other thing at the winehq site:
Myth 9: Wine is for Linux only
OK, as of now Wine does not run on many platforms: just Linux, MacOS
X, FreeBSD and Solaris. Still, this is not 'Linux only'.
I guess I'll need to reword a few things.
No need to double-quote Win32 here, and if there were, literal
double-quotes are almost always wrong in texinfo; that's what ``these''
are for.
Ack.
+applications from the linux operating system; again, provided certain care is
GNU/Linux
Ack.
+taken.
+
+One particular issue occurs when a Win32 platform such as MinGW, Cygwin, MSYS,
+or MSVC is the @code{$host} or @code{$build}, while the other platform is a
unix
Unix should be capitalized here and below, and I think you mean
`Unix
