Re: Win32 libltdl issue

2005-04-27 Thread Charles Wilson
Howard Chu wrote: One other annoying gotcha when building with libtool and Win32 is that libtool (at least in the 1.x line) assumed that any lib*.a was a static library, and refused to link it into a DLL. It didn't account for the possibility that the library was actually a DLL import library.

Re: libtool: cygwin/mingw/pw update: enable-auto-image-base

2005-09-07 Thread Charles Wilson
Bob Friesenhahn wrote: The comment about pw is an understatement. It seems to me that 'pw' failed shortly after leaving the gate due to being a rebel without a cause. It failed years ago and support for it should be removed from libtool. Kind of a shame, in that Paul Sokolovsky was the guy

Re: FYI: 277-gary-rename-remaining-troublesome-ltdl-apis.diff

2005-10-26 Thread Charles Wilson
Eric Blake wrote: returning from the conquest Not quite. On a managed mount, cygwin_conv_to_full_win32_path (searchname, wpath); correctly returns the munged underlying Windows name, but earlier in the code, you appended a trailing dot. Since a managed mount munges the trailing dot, you are

Nit in func_win32_libid (branch-1.5)

2005-11-09 Thread Charles Wilson
This has been bugging me since we last looked at this piece of code (2005-09-25) and we didn't take the opportunity to fix it then. Should be obvious...also needed in ltmain.m4sh of HEAD. 2005-11-09 Charles Wilson [EMAIL PROTECTED] * ltmain.in (func_win32_libid): use $SED not sed

Re: cygwin dlopening backends

2005-11-12 Thread Charles Wilson
Ralf Wildenhues wrote: Please take a look at and test the following patches which should address (1), (2), and (3). I have not done a lot testing myself /yet/, so beware. Basic libtool-HEAD with this patch on cygwin (compiling in both dlopen and loadlibrary loaders) compiles and passes all

Re: cygwin dlopening backends

2005-11-13 Thread Charles Wilson
Ralf Wildenhues wrote: Hi Charles, That just leaves Eric's comments, and Ralf's point (4). I wonder if it would be a good idea to add --enable/--disable configure flags for every loader...with the default set of loaders determined on a per-platform basis. That's the most flexible (and

Re: cygwin dlopening backends

2005-11-13 Thread Charles Wilson
Charles Wilson wrote: No, I think the wrong-order problem was because of my (now abandoned) patch when packaging libtool for the cygwin distribution. I *believe* the current impl, when both loaders are compiled in, calls dlopen first. But I'll check... Hmm. The behavior I see is odd

Minor change for cygwin, libtool-1.5.22

2006-04-23 Thread Charles Wilson
-import, there are projects that try to do things the Microsoft Way with declspec, instead -- and use --disable-auto-import. As it happens, gettext post-0.14.5 will be one of those. -- Chuck 2006-04-22 Charles Wilson [EMAIL PROTECTED] * libtool.m4: define DLL_EXPORT for PIC objects

Re: cygwin/mingw: do not lie about hardcoding

2006-09-14 Thread Charles Wilson
Eric Blake wrote: According to Ralf: So, then the question is where is the Cygwin semantics documented (for both the link editor's behavior, as well as the runtime linker's) and does it have a form of hardcoding as well? And if yes, why are we not using it? I wish I knew this better. You

libltdl exports no symbols (cygwin)

2006-10-17 Thread Charles Wilson
declspec(dllexport) markings even on cygwin). This patch is against CVS on branch-1-5. I'll follow up with a similar patch for HEAD. 2006-10-17 Charles Wilson cygwin@cygwin.com * ltdl.c: be smarter about defining LT_GLOBAL_DATA. Ensure proper textmode fopen is used on cygwin

[mingw] updated tools

2006-11-04 Thread Charles Wilson
At one point there was some discussion about certain missing programs on mingw/msys: http://sourceforge.net/mailarchive/message.php?msg_id=13069136 http://www.mail-archive.com/libtool-patches@gnu.org/msg02115.html specifically, join and paste. These programs are now available as an

Re: libltdl exports no symbols (cygwin)

2007-01-28 Thread Charles Wilson
Ralf Wildenhues wrote: Hello Charles, Apologies for the huge delay. This patch is against CVS on branch-1-5. I'll follow up with a similar patch for HEAD. Sorry that *I* dropped the ball on a forward port to HEAD. I applied this patch now, with a tiny change: instead of # /* some

Re: libltdl exports no symbols (cygwin)

2007-01-30 Thread Charles Wilson
Ralf Wildenhues wrote: Hello Eric, Charles, all, * Eric Blake wrote on Tue, Jan 30, 2007 at 06:00:00PM CET: Should we also mention the side effect that you must now mark explicit exports, since you can no longer rely on auto-imports? This whole issue seems not good for branch-1-5. I'm

Re: preparing for 1.5.24

2007-02-17 Thread Charles Wilson
--export-dynamic. From a brief look at the bfd/ld source code, this ld option seems to be ELF-specific. 2007-02-17 Charles Wilson ... * mdemo/configure.ac: add platform-specific variable RESTORE_AUTOEXPORT, and define appropriately on mingw and cygwin

Re: preparing for 1.5.24

2007-02-18 Thread Charles Wilson
Ralf Wildenhues wrote: Hello Charles, Charles Wilson writes: - It would help me greatly if someone could look into the Cygwin and MinGW mdemo* failures; and documentation updates if needed. Solution in this case is to turn auto-export back on Or to mark all symbols as to be exported

Re: HEAD: NEWS rewrite and update

2007-02-24 Thread Charles Wilson
Charles Wilson wrote: Here are my results: It would help to actually attach the test log. -- Chuck make check-recursive make[1]: Entering directory `/usr/src/libtool/20/bob/libtool2.0-2.1a-1/build' rm -f tests/defs.tmp tests/defs; \ input=defs.m4sh; \ sed -e 's,@EGREP

Re: HEAD: NEWS rewrite and update

2007-02-24 Thread Charles Wilson
Ralf Wildenhues wrote: Please also send tests/testsuite.log (after or before the re-run, both are interesting). It has more details. Thanks! old one attached. -- Chuck libtool-HEAD-20070205-cygwin-testsuite.log.bz2 Description: Binary data

Re: export.at failure on MinGW

2007-02-26 Thread Charles Wilson
Ralf Wildenhues wrote: I suggest this patch to fix the export test on MinGW. It did not fail on Cygwin due to auto-import, but on MinGW it did for the data objects. That is odd, because mingw supports auto-import too. (However, it might be off by default, since libraries created that way

Re: HEAD: static.at rewrite for w32

2007-02-26 Thread Charles Wilson
Ralf Wildenhues wrote: OK, with this it passes for me on Cygwin and MinGW. And doesn't fail on GNU/Linux either. So I committed this. Cheers, Ralf 2007-02-25 Ralf Wildenhues [EMAIL PROTECTED] * tests/static.at: Forgot to fix PATH for the first func_test_exec invocation. So

Re: mdemo ltdl failure

2007-03-16 Thread Charles Wilson
Well, once I got the cygwin1.dbg stuff worked out, it was pretty easy to track down: it is a bug in newlib's argz_insert: Charles Wilson wrote: Here's the code from newlib's argz_insert: error_t _DEFUN (argz_insert, (argz, argz_len, before, entry), char **argz _AND size_t

Re: mdemo ltdl failure

2007-04-18 Thread Charles Wilson
Charles Wilson wrote: Charles Wilson wrote: Charles Wilson wrote: I'll whip up a patch and post it to the newlib list. So, I posted the following: http://sourceware.org/ml/newlib/2007/msg00271.html However, there's no telling how long it'll be before a new cygwin kernel is released

[cygwin, libtool] use shell function to emit wrapper scripts and wrapper.exe source [Was: Re: .exe magic]

2007-04-18 Thread Charles Wilson
[Added libtool-patches to CC list. Discussion of this patch should probably drop libtool and cygwin] Ralf Wildenhues wrote: * Charles Wilson wrote on Wed, Apr 18, 2007 at 08:49:31PM CEST: Caveat: over a year after the message referenced above, but libtool2.0 is STILL in code-slush, so

Re: mdemo ltdl failure

2007-04-18 Thread Charles Wilson
Bob Friesenhahn wrote: On Wed, 18 Apr 2007, Charles Wilson wrote: [snip long description of ugly runtime test] See http://lists.gnu.org/archive/html/libtool-patches/2007-03/msg00030.html After discussion with Bob F, I've reimplemented this fix without the actual runtime test. Instead

Re: [cygwin, libtool] use shell function to emit wrapper scripts and wrapper.exe source [Was: Re: .exe magic]

2007-04-18 Thread Charles Wilson
Charles Wilson wrote: Okay, here's the first bit. It's pretty simple. Testing is in progress (and in conjuction with the new argz fix I just posted to libtool-patches), but looks good so far: the new wrapper scripts are identical to old ones generated without this patch. Test results -- old

Re: mdemo ltdl failure

2007-04-19 Thread Charles Wilson
Ralf Wildenhues wrote: * Charles Wilson wrote: This is because the test is just too ugly for words, not to mention brittle. Trying to tease out malloc issues outside of a dedicated malloc testsuite is just plain silly. I think the biggest problem with the previous patch

Re: [cygwin, libtool] use shell function to emit wrapper scripts and wrapper.exe source

2007-04-19 Thread Charles Wilson
Ralf Wildenhues wrote: * Charles Wilson wrote: Test results -- new tests. Unexpected failures: 14: Java convenience archives FAILED (convenience.at:273) 16: Link order of deplibs. FAILED (link-order2.at:129) 49: Run tests with low max_cmd_len FAILED (cmdline_wrap.at:42

Re: [cygwin, libtool] use shell function to emit wrapper scripts and wrapper.exe source

2007-04-19 Thread Charles Wilson
in the ChangeLog entry. I'll apply the reposted patch then. Done. -- Chuck 2007-04-19 Charles Wilson [EMAIL PROTECTED] * libltdl/config/ltmain.m4sh (func_mode_link): move wrapper script generation from here... (func_emit_libtool_wrapper_script): to this new function

Re: mdemo ltdl failure

2007-04-19 Thread Charles Wilson
that the results will be the same as (4) and (5). ChangeLog: 2007-04-19 Charles Wilson [EMAIL PROTECTED] * libltdl/argz_.h: ensure error_t definition is obtained in same mechanism system argz.h would have. * libltdl/libltdl/lt__glibc.h: also detect

Re: mdemo ltdl failure

2007-04-19 Thread Charles Wilson
Charles Wilson wrote: Under case (1), currently running the new-style testsuite. Will report that later in a follow-up message. I expect the following: 14: Java convenience archives FAILED (convenience.at:273) 16: Link order of deplibs. FAILED (link-order2.at:129) 49: Run

[cygwin] cwrapper emits wrapper script

2007-04-20 Thread Charles Wilson
1' somewhere, but that's outside the scope of this patch. ___ ChangeLog: 2007-04-20 Charles Wilson [EMAIL PROTECTED] * ltmain.m4sh (func_emit_libtool_wrapper_script): add code block to handle cases when wrapper script

[cygwin] eliminate wrapper script from '.' for win32

2007-04-22 Thread Charles Wilson
: 2007-04-22 Charles Wilson [EMAIL PROTECTED] * libltdl/config/ltmain.m4sh (func_ltwrapper_script_p): new function detects if $1 is a libtool sh wrapper (func_ltwrapper_executable_p): new function detects if $1 is a libtool executable wrapper

Re: [cygwin] cwrapper emits wrapper script

2007-04-23 Thread Charles Wilson
Ralf Wildenhues wrote: * Charles Wilson wrote on Sat, Apr 21, 2007 at 03:03:02AM CEST: When the wrapper foo.exe is launched, it generates a new wrapper script .libs/foo_ltshwrapper Hmm, I'm wondering whether we should keep prefixing within .libs. Maybe .libs/ltsh-foo ? WDYT? Meh, I

Re: mdemo ltdl failure

2007-04-24 Thread Charles Wilson
Ralf Wildenhues wrote: * Charles Wilson wrote on Fri, Apr 20, 2007 at 12:25:27AM CEST: Ralf suggests testing this patch on solaris. I can't, but if Ralf does then I expect that the results will be the same as (4) and (5). Done. AS_CASE was a problem, as it's not in Autoconf-2.59. !!! I

Re: [cygwin] cwrapper emits wrapper script

2007-04-24 Thread Charles Wilson
Ralf Wildenhues wrote: * Ralf Wildenhues wrote on Tue, Apr 24, 2007 at 08:53:46AM CEST: * Charles Wilson wrote on Tue, Apr 24, 2007 at 04:34:41AM CEST: Ralf Wildenhues wrote: for (i=0; iargc+1; i++) { -DEBUG((main) newargz[%d] : %s\n,i,newargz[i]); +LTWRAPPER_DEBUGPRINTF((main

Re: [cygwin] cwrapper emits wrapper script

2007-04-24 Thread Charles Wilson
Ralf Wildenhues wrote: Certainly. I was merely trying to not infer that you'd have to do even more work than the lot that you're already doing. Of course if you're ambitious go for it. ;-) Thanks for fixing the MinGW case here. Sure. Hmm, maybe one after the `rm -f $prefix/bin/...' and

Re: preparing for 1.5.24

2007-04-24 Thread Charles Wilson
Ralf Wildenhues wrote: Thanks also for the documentation suggestion. Slightly rewritten suggestion to come up. Ping? [antecedent reposted below] -- Chuck Around line 3546 [probably 4476, now] in libtool.texi, something like: --%

Re: mdemo ltdl failure

2007-04-25 Thread Charles Wilson
Charles Wilson wrote: I'll generate and test an additional patch addressing Bruno's concerns. Attached. Re-ran *all* of the tests described here: http://lists.gnu.org/archive/html/libtool-patches/2007-04/msg00073.html with identical results. I did not bump the argz.m4 serial again (I'm

Re: [cygwin] cwrapper emits wrapper script

2007-04-27 Thread Charles Wilson
should be applied first, then libtool-use-GCS-for-cwrapper-20070427.patch -- so in the real ChangeLog, the following two entries should be reversed. 2007-04-27 Charles Wilson [EMAIL PROTECTED] * ltmain.m4sh (func_emit_libtool_wrapper_script): add code block to handle cases when

Re: [cygwin] cwrapper emits wrapper script

2007-05-04 Thread Charles Wilson
Ping? http://lists.gnu.org/archive/html/libtool-patches/2007-04/msg00088.html -- Chuck

Re: HEAD: fix the inherited_linker_flags regression

2007-05-08 Thread Charles Wilson
Ralf Wildenhues wrote (on 2007-04-23): 2007-04-11 Ralf Wildenhues .. * libltdl/config/ltmain.m4sh (func_mode_link): Fix accumulation of `inherited_linker_flags' entries from multiple deplibs, by adding $new_inherited_linker_flags only once, only in link pass. *

Re: HEAD: fix the inherited_linker_flags regression

2007-05-10 Thread Charles Wilson
Ralf Wildenhues wrote: Interesting. After running the failed test, please post the output of cd tests/testsuite.dir/09 ../../../libtool --debug -n --mode=link --tag=CC gcc -framework Cocoa \ -framework ApplicationServices -o libbaz.la baz.lo libboth.la \ -no-undefined -rpath

Darwin issue?

2007-05-24 Thread Charles Wilson
Gcc just imported libtool from CVS HEAD today (well, actually, from CVS HEAD as of 2007-03-18, but who's counting?). Almost immediately, there was a bug report from a Darwin user and a patch for ltmain.sh. Could somebody with more knowledge about Darwin than me ( == 0.01 ) pleas take a

Re: [cygwin] cwrapper emits wrapper script

2007-05-25 Thread Charles Wilson
On May 4, 2007, Charles Wilson wrote: Ping? http://lists.gnu.org/archive/html/libtool-patches/2007-04/msg00088.html Ping. -- Chuck

Re: New libtool is in the GCC and Src trees.

2007-05-28 Thread Charles Wilson
[libtool-patches: please render assistance...SOS!] Andreas Schwab wrote: The GCC and src trees have been updated with the new libtool. Let me know if you run into problems. Please also commit the version of ltdl.m4 that you used. Apologies for not catching this; I /thought/ about asking

Re: [cygwin] cwrapper emits wrapper script

2007-06-01 Thread Charles Wilson
On Fri, 25 May 2007 11:27:08 -0400, Charles Wilson said: On May 4, 2007, Charles Wilson wrote: Ping? http://lists.gnu.org/archive/html/libtool-patches/2007-04/msg00088.html Ping. If it's Friday, it must be time for: Ping * 3. -- Chuck

Re: [cygwin] cwrapper emits wrapper script

2007-06-02 Thread Charles Wilson
Noah Misch wrote: I don't speak for the Libtool maintainers, but I'll throw out my impressions of the patch, in case it might help move things along. Not using Cygwin or MSYS myself these days, I trust that the patch improves things there as you say it does. It seems fairly harmless from the

Re: [cygwin] cwrapper emits wrapper script

2007-06-06 Thread Charles Wilson
Peter O'Gorman wrote: Could you please resend the patch itself, I am having issues with stripping the html markup from these links. (well, I can strip the html, but the resulting patch is not applying.) Attached. -- Chuck 2007-04-27 Charles Wilson [EMAIL PROTECTED] * ltmain.m4sh

Re: [cygwin] cwrapper emits wrapper script

2007-06-07 Thread Charles Wilson
Peter O'Gorman wrote: On Wed, 2007-06-06 at 10:25 -0400, Charles Wilson wrote: 2007-04-27 Charles Wilson [EMAIL PROTECTED] * ltmain.m4sh (func_emit_libtool_wrapper_script): add code block to handle cases when wrapper script is in $objdir

[patch] fix nits in recent cwrapper patch

2007-06-08 Thread Charles Wilson
. ___ Changelog: 2007-06-08 Charles Wilson ... * ltmain.m4sh (func_emit_libtool_wrapper_script): take an argument to specify value assigned to WRAPPER_SCRIPT_BELONGS_IN_OBJDIR in the emitted script. (func_emit_libtool_cwrapperexe_source) [file scope

Re: [patch] fix nits in recent cwrapper patch

2007-06-08 Thread Charles Wilson
Bob Friesenhahn wrote: I don't see any problems. If you will commit these changes, I will test them right away in my own builds. I'd like to hear from those who raised the original issues in each case, first -- e.g. Noah/Peter for the WRAPPER_SCRIPT_BELONGS_IN_OBJDIR changes, Erick for the

Re: [patch] fix nits in recent cwrapper patch

2007-06-08 Thread Charles Wilson
Eric Blake wrote: s/Erick/Eric/, but that's okay (I've seen worse butchering of my name, as short as it is, and I'm sure I've done worse to those with longer names :) Sorry... (func_emit_libtool_cwrapperexe_source) [LTWRAPPER_DEBUGPRINTF]: declare as a function, not a macro,

Re: [patch] fix nits in recent cwrapper patch

2007-06-08 Thread Charles Wilson
Noah Misch wrote: You can write this more simply: if (stat (path, st) = 0 st.st_mode (S_IXUSR | S_IXGRP | S_IXOTH)) D'oh! You're right. (Or even `access (path, X_OK) == 0', if MSYS has that.) Err, well, sorta. What you're really asking is if the C runtime library(ies) exposed by

[patch] win32: eliminate wrapper script in main build dir

2007-06-10 Thread Charles Wilson
passed 52 tests behaved as expected. 2 tests were skipped. CHANGELOG = 2007-04-22 Charles Wilson [EMAIL PROTECTED] * libltdl/config/ltmain.m4sh (func_ltwrapper_script_p): new function detects if $1

Re: [patch] win32: eliminate wrapper script in main build dir

2007-06-16 Thread Charles Wilson
Noah Misch wrote: Overall, the patch looks suitable. Some minor comments: +func_ltwrapper_executable_p_result=no +if ! func_ltwrapper_script_p $1 ; then The `!' operator is not portable; use `if X; then :; else'. You could instead add a different magic string to executables,

Re: [patch] win32: eliminate wrapper script in main build dir

2007-06-16 Thread Charles Wilson
Ralf Wildenhues wrote: Let's keep as much code once as possible, and kill some superfluous quotes: func_ltwrapper_executable_p () { func_ltwrapper_exec_suffix= case $1 in *.exe) ;; *) func_ltwrapper_exec_suffix=.exe ;; esac grep $magic $1$func_ltwrapper_exec_suffix /dev/null }

Re: Using getconf to set max_cmd_len

2007-06-17 Thread Charles Wilson
/null` The patch is all good (thanks!) except someone please put `getconf ARG_MAX' in a subshell so that if it does not exist, the shell error output is redirected as well (both branches). OK to apply (both branches)? 2007-06-17 Charles Wilson ... Ralf Wildenhues

Re: Using getconf to set max_cmd_len

2007-06-18 Thread Charles Wilson
Ralf Wildenhues wrote: * Charles Wilson wrote on Sun, Jun 17, 2007 at 10:20:24PM CEST: Committed (to HEAD and branch-1-5). my sendmail hiccuped when trying to send the notification to libtool-commit for branch-1-5, though. I can try to reconstruct that message manually and send it, if you

Re: [patch] win32: eliminate wrapper script in main build dir

2007-06-18 Thread Charles Wilson
Charles Wilson wrote: This passes all expected tests on linux (native). On cygwin (native) it fails 14,16,32, and 54, which is the expected behavior. I'll test [with export INSTALL=/usr/bin/install.exe to ensure that I don't get spurious failures for 35 39 43 46] on mingw (native

Re: [patch] Add self to AUTHORS

2007-06-19 Thread Charles Wilson
Peter O'Gorman wrote: On Tue, 2007-06-19 at 02:26 -0400, Charles Wilson wrote: Peter O'Gorman wrote: Reminds me, please add yourself to AUTHORS and contribute.html. (see Noah's commits). Done, for AUTHORS. Concerning contribute.html, does the commit script work when called from a foreign

Re: [2/11] Native MSVC support (strip-cwrapper)

2007-07-12 Thread Charles Wilson
Peter Rosin wrote: * libltdl/config/ltmain.m4sh (func_mode_link): Strip the cwrapper using $STRIP instead of relying on the tools to support -s, which MSVC doesn't. This looks OK to me (tested on cygwin and linux with no regressions). However, I don't know what the

Followup patch: fix mingw cross-compile regressions

2007-07-12 Thread Charles Wilson
in the appropriate places. Tested on cygwin (native) and linux (native) with no regressions. However, I have NOT tested it in Ralf's use case, which is what it is intended to fix -- somebody else needs to make sure I haven't actually made things worse, there. ChangeLog 2007-07-11 Charles Wilson

Re: [2/11] Native MSVC support (strip-cwrapper)

2007-07-12 Thread Charles Wilson
Ralf Wildenhues wrote: This looks OK to me (tested on cygwin and linux with no regressions). Me too. Please apply this one. I assumed you meant me, so I applied it. (Does Peter have commit access?) FWIW, I'd rather have at least the hairy bits postponed until shortly afterwards. ACK.

Re: [4/11] Native MSVC support (file-magic-glob)

2007-07-12 Thread Charles Wilson
Peter Rosin wrote: * libltdl/m4/libtool.m4 (_LT_CHECK_MAGIC_METHOD), libltdl/config/ltmain.m4sh (func_mode_link): On Windows, find potential libs regardless of file name case. Hmm. Well, this one might pose some problems. On cygwin, there exists something called

Re: Followup patch: compute dirname and basename at once, when both are needed

2007-07-12 Thread Charles Wilson
Charles Wilson wrote: Err...I don't have access to a solaris box at present. Here's the updated patch untested. I'll kick off a test (cygwin) and report back later. No regressions on cygwin (native) or linux (native) -- but the newest bits are only exercised on solaris with SHELL=/bin/sh

Re: [4/11] Native MSVC support (file-magic-glob)

2007-07-18 Thread Charles Wilson
Peter Rosin wrote: On Tue, Jul 17, 2007 at 06:48:38AM -0600, Eric Blake wrote: I still think searching for libs case-insensitively on cygwin is wrong - the philosophy of cygwin is to be a Linux emulation, where case matters; and even though you can't have dual case files without a managed

Re: [3/11] Native MSVC support (msvc-cwrapper)

2007-07-18 Thread Charles Wilson
Charles Wilson wrote: If it sounds like I'm taking myself into platform #ifdefs for the cwrapper...you're right. Looks OK. In case it wasn't clear, I think this patch should go in sooner rather than later, as it also fixes an existing problem in the cwrapper w.r.t. intptr_t. -- Chuck

Re: [3/11] Native MSVC support (msvc-cwrapper)

2007-07-19 Thread Charles Wilson
Ralf Wildenhues wrote: Hello Charles, Peter, In case it wasn't clear, I think this patch should go in sooner rather than later, as it also fixes an existing problem in the cwrapper w.r.t. intptr_t. I don't mind the patch going in, but isn't +# define _stat stat the wrong way around, or at

Re: unused variable in chase_symlinks

2007-07-22 Thread Charles Wilson
Eric Blake wrote: On cygwin, I'm getting a lot of these warnings (on CVS head M4, one for each of the 42 gnulib tests): creating test-isnanl-nolibm.exe ./.libs/lt-test-isnanl-nolibm.c: In function `chase_symlinks': ./.libs/lt-test-isnanl-nolibm.c:499: warning: unused variable `rv' due to

Re: unused variable in chase_symlinks

2007-07-23 Thread Charles Wilson
Eric Blake wrote: Here's what I'm committing. I verified that diff -b shows no change, and I am also attaching the results filtered through cat -A to make the change obvious. 2007-07-23 Eric Blake [EMAIL PROTECTED] * libltdl/config/ltmain.m4sh: Whitespace cleanup. Looks ok to

Re: Libtool head test status

2008-03-08 Thread Charles Wilson
Ralf Wildenhues wrote: Now, in that test, the toplevel configure script chooses $top_srcdir/INSTALL (yes, the text file) as install script. I suspect this is because you have /uhome/src/gnu/libtool-head in the $PATH, the beginning of testsuite.log reveals that. Why is that, did you add that

Re: cross compilation to w32

2008-03-12 Thread Charles Wilson
Ralf Wildenhues wrote: Is fcntl.h available unconditionally on w32? Back to at least Visual C++ 6.0, mingw-runtime-1.2 (we're at 3.14 now), and cygwin since at least 1996. I think that qualifies as unconditionally. -- Chuck

Re: Patch for cygwin: autoupdate and objdump

2008-04-19 Thread Charles Wilson
Charles Wilson wrote: Not only that, but this may fix another possible bug on Linux ELF systems, as there is a test on that platform (line 2461 after the patch) which uses OBJDUMP, which I don't see where it would have been defined. Ah...found the OTHER other thread where the OBJDUMP issue

Re: Patch for cygwin: autoupdate and objdump

2008-04-25 Thread Charles Wilson
Charles Wilson wrote: http://lists.gnu.org/archive/html/libtool-patches/2008-04/msg00098.html 2008-04-19 Charles Wilson ... Yaakov Selkowitz ... * libltdl/m4/libtool.m4 (_LT_DECL_OBJDUMP): new macro ensures that $OBJDUMP is always defined sanely. (_LT_SYS_DYNAMIC_LINKER

Patch for cygwin: silence cwrapper compilation warnings

2008-04-25 Thread Charles Wilson
, but not #3. Reported by Yaakov Selkowitz. I'm not sure if all the documentation needs to be duplicated for all three functions, but... Test suite on cygwin in progress. -- Chuck 2008-04-25 Charles Wilson ... Ensure cwrapper compiles without warnings under -std=c99: * libltdl

Re: Patch for cygwin: silence cwrapper compilation warnings

2008-04-25 Thread Charles Wilson
Charles Wilson wrote: 2008-04-25 Charles Wilson ... Ensure cwrapper compiles without warnings under -std=c99: * libltdl/config/ltmain.m4sh (func_emit_wrapper_part1): new function. (func_emit_wrapper_part2): new function. (func_emit_wrapper): delegate to new functions

Re: Patch for cygwin: autoupdate and objdump

2008-04-29 Thread Charles Wilson
Ralf Wildenhues wrote: 2008-04-19 Charles Wilson ... Yaakov Selkowitz ... * libltdl/m4/libtool.m4 (_LT_DECL_OBJDUMP): new macro ensures that $OBJDUMP is always defined sanely. (_LT_SYS_DYNAMIC_LINKER): call it. (_LT_CHECK_MAGIC_METHOD): call it. (AU_DEFUN

Re: Patch for cygwin: silence cwrapper compilation warnings

2008-04-29 Thread Charles Wilson
Charles Wilson wrote: 2008-04-25 Charles Wilson ... Ensure cwrapper compiles without warnings under -std=c99: * libltdl/config/ltmain.m4sh (func_emit_wrapper_part1): new function. (func_emit_wrapper_part2): new function. (func_emit_wrapper): delegate to new functions

Re: [Patch] cwrapper invokes target directly

2008-04-29 Thread Charles Wilson
Charles Wilson wrote: 2008-04-26 Charles Wilson ... [mingw|cygwin] Modify cwrapper to invoke target directly. * libltdl/config/ltmain.m4sh (func_to_native_path): new function. If $host is mingw, and $build is mingw or cygwin, convert path to mingw native format

Re: [Patch] cwrapper invokes target directly

2008-04-29 Thread Charles Wilson
Bob Friesenhahn wrote: I forgot that you have the ability to do this by yourself. Ralf says that he has been busy and will soon be unavailable for a week or two. Meanwhile, Gary is wanting to cut a new release on (or before) May 3rd. Since we are trying to pop out new libtool releases a lot

Re: libltdl and cygwin 1.7.0

2008-04-30 Thread Charles Wilson
On Wed, 30 Apr 2008 17:03:19 + (UTC), Eric Blake [EMAIL PROTECTED] said: Cygwin 1.7.0 will change the size of MAX_PATH in its headers, but the old cygwin_conv_to_* API silently suffers from buffer overrun if more than 256 bytes occur in the conversion. As a result, cygwin developers

[PATCH] Ensure $OBJDUMP is defined

2008-05-05 Thread Charles Wilson
2008-05-05 Charles Wilson ... Yaakov Selkowitz ... Ensure $OBJDUMP is defined * libltdl/m4/libtool.m4 (_LT_DECL_OBJDUMP): new macro ensures that $OBJDUMP is always defined sanely. (_LT_SYS_DYNAMIC_LINKER): call it. (_LT_CHECK_MAGIC_METHOD

[PATCH] Ensure cwrapper compiles without warnings under -std=c99.

2008-05-05 Thread Charles Wilson
2008-05-05 Charles Wilson ... Ensure cwrapper compiles without warnings under -std=c99. * libltdl/config/ltmain.m4sh (func_emit_wrapper_part1): new function. (func_emit_wrapper_part2): new function. (func_emit_wrapper): delegate to new functions

[PATCH] [mingw|cygwin] Modify cwrapper to invoke target directly.

2008-05-05 Thread Charles Wilson
2008-05-05 Charles Wilson ... * libltdl/config/ltmain.m4sh (func_to_native_path): new function. If $host is mingw, and $build is mingw or cygwin, convert path to mingw native format. (func_to_native_pathlist): new function. Ditto, for :-separated

[PATCH] Ensure $OBJDUMP is defined

2008-05-06 Thread Charles Wilson
2008-05-05 Charles Wilson ... Yaakov Selkowitz ... Ensure $OBJDUMP is defined * libltdl/m4/libtool.m4 (_LT_DECL_OBJDUMP): new macro ensures that $OBJDUMP is always defined sanely. (_LT_SYS_DYNAMIC_LINKER): call it. (_LT_CHECK_MAGIC_METHOD

[PATCH] Ensure cwrapper compiles without warnings under -std=c99.

2008-05-06 Thread Charles Wilson
2008-05-05 Charles Wilson ... Ensure cwrapper compiles without warnings under -std=c99. * libltdl/config/ltmain.m4sh (func_emit_wrapper_part1): new function. (func_emit_wrapper_part2): new function. (func_emit_wrapper): delegate to new functions

[PATCH] [mingw|cygwin] Modify cwrapper to invoke target directly.

2008-05-06 Thread Charles Wilson
2008-05-05 Charles Wilson ... * libltdl/config/ltmain.m4sh (func_to_native_path): new function. If $host is mingw, and $build is mingw or cygwin, convert path to mingw native format. (func_to_native_pathlist): new function. Ditto, for :-separated

[PATCH] Ensure $OBJDUMP is defined

2008-05-06 Thread Charles Wilson
2008-05-05 Charles Wilson ... Yaakov Selkowitz ... Ensure $OBJDUMP is defined * libltdl/m4/libtool.m4 (_LT_DECL_OBJDUMP): new macro ensures that $OBJDUMP is always defined sanely. (_LT_SYS_DYNAMIC_LINKER): call it. (_LT_CHECK_MAGIC_METHOD

Re: [PATCH] Ensure $OBJDUMP is defined

2008-05-06 Thread Charles Wilson
Ralf Wildenhues wrote: * Charles Wilson wrote on Tue, May 06, 2008 at 02:23:05AM CEST: 2008-05-05 Charles Wilson ... Yaakov Selkowitz ... Ensure $OBJDUMP is defined * libltdl/m4/libtool.m4 (_LT_DECL_OBJDUMP): new macro ensures that $OBJDUMP is always

Re: [PATCH] Ensure cwrapper compiles without warnings under -std=c99.

2008-05-06 Thread Charles Wilson
Eric Blake wrote: According to Charles Wilson on 5/5/2008 6:23 PM: | -# func_emit_wrapper arg | +# func_emit_wrapper_part1 arg Since you provide a default, I'd show that arg is optional, as in: # func_emit_wrapper_part1 [arg=no] Ack. Is func_emit_wrapper_part1_arg1 even used? Why not just

Re: [PATCH] Ensure cwrapper compiles without warnings under -std=c99.

2008-05-06 Thread Charles Wilson
Ralf Wildenhues wrote: In addition to Eric's review, here's some extremely picky nits: -# func_emit_wrapper arg +# func_emit_wrapper_part1 arg Isn't that .libs/_libs aka $objdir here? This is not new here, but further below. Capitalization, period at end of the sentence. #

Re: [PATCH] [mingw|cygwin] Modify cwrapper to invoke target directly.

2008-05-06 Thread Charles Wilson
Eric Blake wrote: According to Charles Wilson on 5/5/2008 6:23 PM: | 2008-05-05 Charles Wilson ... | | * libltdl/config/ltmain.m4sh (func_to_native_path): I've become accustomed to using a 1-line summary in my ChangeLog messages prior to the first '* file:' line; that way, the summary can

Re: [PATCH] [mingw|cygwin] Modify cwrapper to invoke target directly.

2008-05-06 Thread Charles Wilson
Ralf Wildenhues wrote: Hi Charles, You can simplify the remaining part of the ChangeLog entry: or even to this: (func_emit_cwrapperexe_src) [lt_setenv, lt_extend_str] [lt_split_name_value, lt_opt_process_env_set] [lt_opt_process_env_prepend, lt_opt_process_env_append]

Re: [PATCH] [mingw|cygwin] Modify cwrapper to invoke target directly.

2008-05-09 Thread Charles Wilson
Charles Wilson wrote: 2008-05-05 Charles Wilson ... * libltdl/config/ltmain.m4sh (func_to_native_path): new function. If $host is mingw, and $build is mingw or cygwin, convert path to mingw native format. (func_to_native_pathlist): new function. Ditto

Re: [PATCH] [mingw|cygwin] Modify cwrapper to invoke target directly.

2008-05-10 Thread Charles Wilson
Roumen Petrov wrote: libtool 2.2.4 patched with both patches still fail: ... (lt_setenv) setting 'PATH' to

Re: [PATCH] [mingw|cygwin] Modify cwrapper to invoke target directly.

2008-05-10 Thread Charles Wilson
Roumen Petrov wrote: Hi Charles, About following comment: /* execv doesn't actually work on mingw as expected on unix */ Actually execXXX on microsoft windows create a new process and it is not mingw problem. What about to substitute mingw with windows ? Disagree. The FSF discourages to

Re: [PATCH] Ensure cwrapper compiles without warnings under -std=c99.

2008-05-11 Thread Charles Wilson
Gary V. Vaughan wrote: On 6 May 2008, at 22:47, Charles Wilson wrote: Unresolved: (1) whether func_emit_wrapper_part1 should even TAKE an argument (2) whether the cwrapper src, when printing a const char*, should use puts() in preference to printf(%s,...) Please go ahead and choose however

Re: [PATCH] [mingw|cygwin] Modify cwrapper to invoke target directly.

2008-05-13 Thread Charles Wilson
Charles Wilson wrote: Cygwin: passes 115 (9 skip) on old test suite only two unexpected failures on new test suite -- but 25 and 72 are actually expected on cygwin. Mingw (msys): no regressions over previous results: old test suite: fails demo-exec after demo-shared (helldl) fails the fortran

[PATCH] [mingw] Add cross-compile support to cwrapper

2008-05-14 Thread Charles Wilson
[mingw] Add cross-compile support to cwrapper * libltdl/config/ltmain.m4sh (func_to_host_path): If present, use winepath to convert from $build to $host if $host is mingw and $build is neither mingw (msys) nor cygwin. Also update comments. (func_to_host_pathlist): Ditto. --- This is a follow-on

Re: [PATCH] [mingw] Add cross-compile support to cwrapper

2008-05-17 Thread Charles Wilson
Roumen Petrov wrote: Charles Wilson wrote: [mingw] Add cross-compile support to cwrapper May be the patch can be more simple. In a previous post I confirm that for the wine emulator is enough items in path list, where every item is absolute path from build system, to be separated by DOS

Re: [PATCH] [mingw] Add cross-compile support to cwrapper

2008-05-20 Thread Charles Wilson
your proposed modifications are optimizations. Lets go upstream. By this do you mean 'push to the git repo'? I'd rather wait for Ralf to get back and comment; should be later this week I think. Roumen Petrov wrote: Charles Wilson wrote: But I'm not sure that supporting changing the mapping

  1   2   3   4   5   >