Re: g++ and -nostdlib

2013-11-08 Thread Charles Wilson
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

Re: Windows Line Endings [WAS Re: [SCM] GNU Libtool branch, master, updated. v2.4.2-273-ge24f183]

2012-10-05 Thread Charles Wilson
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

Re: Windows Line Endings

2012-10-05 Thread Charles Wilson
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

Re: [PATCH] libtool: minimise forks per invocation on cygwin and mingw.

2011-12-08 Thread Charles Wilson
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

Re: [PATCH] libtool: minimise forks per invocation on cygwin and mingw.

2011-12-08 Thread Charles Wilson
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

Re: [PATCH 01/10] tests: migrate legacy tests/cdemo tests to Autotest.

2011-11-29 Thread Charles Wilson
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

Re: [PATCH 01/10] tests: migrate legacy tests/cdemo tests to Autotest.

2011-11-28 Thread Charles Wilson
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

Re: [PATCH 04/25] syntax-check: fix violations and re-enable sc_cast_of_x_alloc_return_value.

2011-11-15 Thread Charles Wilson
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

Re: [PATCH 04/25] syntax-check: fix violations and re-enable sc_cast_of_x_alloc_return_value.

2011-11-15 Thread Charles Wilson
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

Re: [PATCH 09/25] syntax-check: fix violations and re-enable sc_makefile_at_at_check.

2011-11-15 Thread Charles Wilson
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

Re: [PATCH 1/7] bootstrap: split into reusable parts.

2011-11-05 Thread Charles Wilson
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

Re: [PATCH 1/3] maint: rename `libltdl/config' directory to standard `build-aux'.

2011-11-01 Thread Charles Wilson
On 11/1/2011 10:57 AM, Stefano Lattarini wrote: Is `ln -s' portable to e.g., MinGW? Or is the bootstrapping process not meant to work there anyway, so we can just not care? No, bootstrapping is supposed to work (and, until quite recently, did work) under MinGW/MSYS. Current breakage is

Re: Obsoleting LT_SCOPE

2011-10-25 Thread Charles Wilson
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

Re: Obsoleting LT_SCOPE

2011-10-25 Thread Charles Wilson
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

Re: Obsoleting LT_SCOPE

2011-10-25 Thread Charles Wilson
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

Re: [PATCH] Include _CRTIMP in _putenv() declaration in EXE wrapper sources.

2011-06-23 Thread Charles Wilson
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

Re: libtool shouldn't switch to creating static library if it can't create the shared one under Windows

2011-06-23 Thread Charles Wilson
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

Re: libtool shouldn't switch to creating static library if it can't create the shared one under Windows

2011-06-21 Thread Charles Wilson
On 6/21/2011 8:29 AM, Vadim Zeitlin wrote: Charles Wilson don't feed spammers writes: 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. Just to confirm: no, currently it doesn't do

Re: libtool shouldn't switch to creating static library if it can't create the shared one under Windows

2011-06-20 Thread Charles Wilson
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

Re: libtool shouldn't switch to creating static library if it can't create the shared one under Windows

2011-06-18 Thread Charles Wilson
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

Re: libtool shouldn't switch to creating static library if it can't create the shared one under Windows

2011-06-17 Thread Charles Wilson
On 6/17/2011 3:46 AM, Marco atzeri wrote: on cygwin lt_cv_deplibs_check_method=pass_all is my workaround at configure stage to bypass incorrect libtool detection of system capabilities and to allow shared libs building. It's not about system capabilities in this case. It's about the fact

Re: libtool shouldn't switch to creating static library if it can't create the shared one under Windows

2011-06-17 Thread Charles Wilson
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

Re: Shared library versioning

2011-06-16 Thread Charles Wilson
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

Re: -no-undefined vs gcc 4.6.0

2011-03-19 Thread Charles Wilson
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

Re: Stop relink searching host directory when installation prefix provided

2011-01-17 Thread Charles Wilson
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

Re: Stop relink searching host directory when installation prefix provided

2011-01-16 Thread Charles Wilson
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.

Re: func_convert_file_cygwin_to_w32 woes

2011-01-07 Thread Charles Wilson
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

Re: func_convert_file_cygwin_to_w32 woes

2011-01-07 Thread Charles Wilson
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

Re: Fix cwrapper test failure with --disable-static.

2010-11-10 Thread Charles Wilson
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

Re: Fix cwrapper test failure with --disable-static.

2010-11-10 Thread Charles Wilson
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

Re: DLL creation and static libs

2010-11-02 Thread Charles Wilson
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

Re: [PATCH] tests: don't use assert/abort on MSVC as they are interactive.

2010-10-20 Thread Charles Wilson
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,

[SCM] GNU Libtool branch, master, updated. v2.4-10-gb76bfa8

2010-10-07 Thread Charles Wilson
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

Re: [PATCH] Add test case for 69e77671 (cwrapper PATH manipulation order)

2010-10-07 Thread Charles Wilson
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 ---

Re: GNU Libtool 2.4 released [stable]

2010-10-01 Thread Charles Wilson
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

Re: GNU Libtool 2.4 released [stable]

2010-09-30 Thread Charles Wilson
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: [PATCH] tests: don't use assert/abort on MSVC as they are interactive.

2010-09-29 Thread Charles Wilson
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.

2010-09-29 Thread Charles Wilson
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

Re: [PATCH] tests: import variables for MSVC.

2010-09-24 Thread Charles Wilson
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

Re: [PATCH] tests: import variables for MSVC.

2010-09-24 Thread Charles Wilson
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

Re: [PATCH] tests: import variables for MSVC.

2010-09-24 Thread Charles Wilson
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

Re: [PATCH] tests: import variables for MSVC.

2010-09-24 Thread Charles Wilson
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

Re: [PATCH] tests: import variables for MSVC.

2010-09-24 Thread Charles Wilson
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

Re: [PATCH] tests: import variables for MSVC.

2010-09-24 Thread Charles Wilson
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

Re: bogus warning 'seems to be moved'

2010-09-23 Thread Charles Wilson
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

Re: bogus warning 'seems to be moved'

2010-09-23 Thread Charles Wilson
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

Re: [PATCH] msvc: eliminate spaces in the library search path.

2010-09-21 Thread Charles Wilson
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

Re: 2.4 Release in 24hrs

2010-09-21 Thread Charles Wilson
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

Re: 2.4 Release in 24hrs

2010-09-21 Thread Charles Wilson
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

Re: 2.4 Release in 24hrs

2010-09-20 Thread Charles Wilson
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

Re: 2.4 Release in 24hrs

2010-09-19 Thread Charles Wilson
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

Re: 2.4 Release in 24hrs

2010-09-19 Thread Charles Wilson
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.

Re: 2.4 Release in 24hrs

2010-09-19 Thread Charles Wilson
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

[SCM] GNU Libtool branch, master, updated. v2.2.10-186-g301c4cf

2010-09-17 Thread Charles Wilson
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

[SCM] GNU Libtool branch, master, updated. v2.2.10-187-g69e7767

2010-09-17 Thread Charles Wilson
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

[PATCH] Fix order of PATH manipulation in cwrapper and shwrapper

2010-09-17 Thread Charles Wilson
* 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

Re: [PATCH] Copy over DLL_EXPORT handling from C to C++ for non-GCC on w32.

2010-09-17 Thread Charles Wilson
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.

2010-09-17 Thread Charles Wilson
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

Re: [PATCH] Document libtool variable to_host_file_cmd.

2010-09-17 Thread Charles Wilson
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

Re: [PATCH] Document libtool variable to_host_file_cmd.

2010-09-17 Thread Charles Wilson
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

2010-09-17 Thread Charles Wilson
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

[SCM] GNU Libtool branch, master, updated. v2.2.10-185-g254f528

2010-09-16 Thread Charles Wilson
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

Re: w32 pending?

2010-09-16 Thread Charles Wilson
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:

Re: w32 pending?

2010-09-16 Thread Charles Wilson
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

Re: w32 pending?

2010-09-16 Thread Charles Wilson
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

[PATCH] Fix sh.test failure introduced in 72064249

2010-09-16 Thread Charles Wilson
* 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

Re: [PATCH] maint: ship .xz, not .lzma

2010-09-14 Thread Charles Wilson
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

Re: [PATCH] maint: ship .xz, not .lzma

2010-09-14 Thread Charles Wilson
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

[SCM] GNU Libtool branch, master, updated. v2.2.10-175-gef56e98

2010-09-12 Thread Charles Wilson
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

[PATCH] [cygwin|mingw] Correct static lib symbol extraction failure.

2010-09-12 Thread Charles Wilson
* 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

Re: [PATCH] [cygwin|mingw] Correct static lib symbol extraction failure.

2010-09-12 Thread Charles Wilson
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

Re: [PATCH] [cygwin|mingw] Correct static lib symbol extraction failure.

2010-09-12 Thread Charles Wilson
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

Re: [PATCH] [cygwin|mingw] Correct static lib symbol extraction failure.

2010-09-12 Thread Charles Wilson
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

Re: [PATCH] Correct typo: $sharedlib_from_linklib_cmd missing '_cmd'

2010-09-11 Thread Charles Wilson
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

Re: [PATCH] Correct typo: $sharedlib_from_linklib_cmd missing '_cmd'

2010-09-11 Thread Charles Wilson
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.

2010-09-10 Thread Charles Wilson
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

Re: [PATCH 6/7] Convert file name to toolchain format when invoking $NM.

2010-09-10 Thread Charles Wilson
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

Re: [PATCH 6/7] Convert file name to toolchain format when invoking $NM.

2010-09-09 Thread Charles Wilson
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

Re: [PATCH 6/7] Convert file name to toolchain format when invoking $NM.

2010-09-09 Thread Charles Wilson
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

Re: [PATCH 6/7] Convert file name to toolchain format when invoking $NM.

2010-09-09 Thread Charles Wilson
, 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

Re: [PATCH] Fix dependency tracking for MSYS/MinGW.

2010-09-09 Thread Charles Wilson
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

Re: [PATCH] Fix dependency tracking for MSYS/MinGW.

2010-09-09 Thread Charles Wilson
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

Re: [PATCH 6/7] Convert file name to toolchain format when invoking $NM.

2010-09-09 Thread Charles Wilson
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

Re: [PATCH 7/7] Prefer $NM @file over calculating the cmd line length.

2010-09-08 Thread Charles Wilson
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

Re: [PATCH 6/7] Convert file name to toolchain format when invoking $NM.

2010-09-08 Thread Charles Wilson
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

Re: [PATCH 6/7] Convert file name to toolchain format when invoking $NM.

2010-09-08 Thread Charles Wilson
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)

Re: [PATCH] [cygwin|mingw|cross-compile]: Path conversion support.

2010-09-08 Thread Charles Wilson
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

Re: [PATCH 6/7] Convert file name to toolchain format when invoking $NM.

2010-09-08 Thread 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? Right now, I'm seeing a regression just building

Re: [PATCH 1/7] Add file name conversion from $build to toolchain.

2010-09-05 Thread Charles Wilson
[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

Re: [PATCH 1/7] Add file name conversion from $build to toolchain.

2010-09-05 Thread Charles Wilson
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

Re: [PATCH] Adjust naming of MSVC import libraries.

2010-09-04 Thread Charles Wilson
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)

Re: [PATCH 7/7] Prefer $NM @file over calculating the cmd line length.

2010-09-04 Thread Charles Wilson
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

Re: [PATCH] Adjust naming of MSVC import libraries.

2010-09-03 Thread Charles Wilson
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:

Re: [PATCH] Adjust naming of MSVC import libraries.

2010-09-03 Thread Charles Wilson
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

Re: [PATCH 0/7] Support for toolchains that are not $host-native.

2010-09-02 Thread Charles Wilson
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

Re: [PATCH] Path conversion documentation

2010-09-02 Thread Charles Wilson
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

Re: git log - changelog

2010-09-02 Thread Charles Wilson
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

Re: [PATCH 4/7] Use func_to_tool_file instead of fix_srcfile_path.

2010-09-01 Thread Charles Wilson
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]

Re: [PATCH 1/7] Add file name conversion from $build to toolchain.

2010-09-01 Thread Charles Wilson
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

Re: [PATCH] Path conversion documentation

2010-09-01 Thread Charles Wilson
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

  1   2   3   4   5   6   >