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.
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
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
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
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
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
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
-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
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
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
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
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
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
--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
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
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
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
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
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
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
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
[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
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
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
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
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
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
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
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
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
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
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
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
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:
--%
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
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
Ping?
http://lists.gnu.org/archive/html/libtool-patches/2007-04/msg00088.html
--
Chuck
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.
*
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
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
On May 4, 2007, Charles Wilson wrote:
Ping?
http://lists.gnu.org/archive/html/libtool-patches/2007-04/msg00088.html
Ping.
--
Chuck
[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
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
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
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
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
.
___
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
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
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,
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
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
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,
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
}
/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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
, 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
#
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
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]
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
Roumen Petrov wrote:
libtool 2.2.4 patched with both patches still fail:
...
(lt_setenv) setting 'PATH' to
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
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
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
[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
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
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
Eric Blake wrote:
Eric Blake ebb9 at byu.net writes:
| + /* otherwise ... */
| + newargz[++newargc] = xstrdup (argv[i]);
Shouldn't you handle -- as the end of wrapper options, in case the user
really wants to pass --lt-env-* as the first option to the wrapped executable?
This
* libltdl/config/ltmain.m4sh (func_emit_cwrapperexe_src)
[file scope]: Defined all option strings in terms of macro
LTWRAPPER_OPTION_PREFIX. Similarly defined all option string
lengths in terms of macro LTWRAPPER_OPTION_PREFIX_LENGTH.
[main]: Modified option parsing algorithm to pass -- on to
1 - 100 of 423 matches
Mail list logo
