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]
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
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
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
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
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
CVSROOT:/sources/libtool
Module name:libtool
Changes by: Charles Wilson cwilson08/03/13 04:46:09
Modified files:
. : ChangeLog
libltdl/config : ltmain.m4sh
Log message:
* libltdl/config/ltmain.m4sh (func_emit_cwrapperexe_src) [file
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
Ralf Wildenhues wrote:
Does anybody see easy ways out?
Well, for the second problem there are two solutions. (1) always ensure
that the script is emitted with unix line endings, or (2) specify
$TARGETSHELL=/emulation/environment/sh when cross-compiling.
Obviously, (2) is the easiest,
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
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
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
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
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
CVSROOT:/sources/libtool
Module name:libtool
Changes by: Charles Wilson cwilson07/07/16 22:53:06
Modified files:
. : ChangeLog
tests : cdemo-exec.test demo-deplibs.test
demo-exec.test demo-inst.test demo
CVSROOT:/sources/libtool
Module name:libtool
Changes by: Charles Wilson cwilson07/07/13 07:21:39
Modified files:
. : ChangeLog
libltdl/config : ltmain.m4sh
libltdl/m4 : libtool.m4
Log message:
* libltdl/m4/libtool.m4
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
CVSROOT:/sources/libtool
Module name:libtool
Changes by: Charles Wilson cwilson07/06/19 06:22:02
Modified files:
. : AUTHORS ChangeLog
Log message:
* AUTHORS: Add myself.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/libtool
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
CVSROOT:/sources/libtool
Module name:libtool
Changes by: Charles Wilson cwilson07/06/19 05:43:16
Modified files:
. : ChangeLog
libltdl/config : ltmain.m4sh
tests : destdir.at
Log message:
* libltdl/config
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
CVSROOT:/sources/libtool
Module name:libtool
Changes by: Charles Wilson cwilson07/06/17 20:16:04
Modified files:
. : ChangeLog
libltdl/m4 : libtool.m4
Log message:
* libltdl/m4/libtool.m4 (LT_CMD_MAX_LEN): ensure stderr
/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
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
}
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
.
___
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
CVSROOT:/sources/libtool
Module name:libtool
Changes by: Charles Wilson cwilson07/06/07 08:47:12
Modified files:
. : ChangeLog
libltdl/config : ltmain.m4sh
Log message:
* ltmain.m4sh (func_emit_libtool_wrapper_script): add
CVSROOT:/sources/libtool
Module name:libtool
Changes by: Charles Wilson cwilson07/06/07 08:50:17
Modified files:
. : ChangeLog
libltdl/config : ltmain.m4sh
Log message:
* ltmain.m4sh (func_emit_libtool_cwrapperexe_source
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
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
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
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
[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 May 4, 2007, Charles Wilson wrote:
Ping?
http://lists.gnu.org/archive/html/libtool-patches/2007-04/msg00088.html
Ping.
--
Chuck
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
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
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.
*
Ping?
http://lists.gnu.org/archive/html/libtool-patches/2007-04/msg00088.html
--
Chuck
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
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
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:
--%
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
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:
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
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
[added libtool to CC list]
Corinna Vinschen wrote:
On Apr 18 04:49, Charles Wilson wrote:
The current .exe behavior has benefited from many years of tweaking and
fine-tuning, across many different packages (cygwin, gcc, gdb, binutils,
automake, autoconf, libtool, bash, coreutils, ...) to work
[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
Charles Wilson wrote:
I'd still like to be able to build my convenience library as both pic
and non-pic tho. And I still want to prevent libiberty.a(non-pic) from
getting the --whole-archive treatment when it comes to libbfd.a.
...
Several systems simply don't allow to mix PIC and non-PIC
of them.
Agreed. While I was considering the problem, I kept getting the feeling
that either (1) I was missing something, or (2) this was very win32
specific: it's a problem only for platforms that require -no-undefined
for shared libraries, which I think is only win32 and AIX.
* Charles Wilson
Charles Wilson wrote:
I completely understand the motivation for the meat of this, speaking in
the hypothetical sense, but why would you ever want to build libbfd
shared?
I did --enable-shared at the top level, and bfd is the first one that
failed. I'm really more interested in the runtime
[EMAIL PROTECTED] wrote:
On Mon, 26 Mar 2007 20:39:24 +0200, Ralf Wildenhues said:
AFAICS, this can only happen if libltdl was treated with automake-1.9
and the tests run with automake-1.10 in place, so that the toplevel
package (named subproject-demo-2.1a) is treated with 1.10.
I'm not 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
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
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:
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
--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 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
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
there is a 'S:' drive.
Report by Charles Wilson.
Yep, that fixes the problem too: tested on both cygwin and mingw.
--
Chuck
___
http://lists.gnu.org/mailman/listinfo/libtool
When building pcre (which uses libtool --export-symbols-regex) I get the
following error (libtool cvs branch 1.5, 20061014 checkout):
/bin/sh ./libtool --mode=link gcc -export-symbols-regex '^[^_]' -I.
-I/c/msys/1.0/local/src/pcre/cygports/pcre-6.7-1/src/pcre-6.7 -rpath
/usr/lib -no-undefined
On Mon, 11 Dec 2006 18:36:56 +0100, Ralf Wildenhues
[EMAIL PROTECTED] said:
Hello Charles,
Thanks for the bug report.
[[ bug report and export_filter variable fix snipped ]]
The above looks like a cleaner approach to me than the second one you
offer; but it means we'd need to change
On Tue, 12 Dec 2006 01:03:41 +0100, Ralf Wildenhues said
Or we need to make sure the extra expansion does not matter.
Arguably, this is a hack, but in practice it may be enough for now.
I had to create a directory /s to expose the bug -- do you have an
S: drive?
Hmm. As a matter of fact, I
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
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
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
-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
Olly Betts wrote:
Does the cygwin packaging chooser have the concept of dependencies?
Yes.
I've only used it briefly once some time ago, and I can't remember
much about it. But if it does, then libtool should really depend on
file.
The official libtool package for cygwin (e.g. the one you
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
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
401 - 500 of 542 matches
Mail list logo