Re: Improve versioning algorithm description
Bob Friesenhahn wrote: On Wed, 23 Sep 2009, Ralf Wildenhues wrote: The most important question is whether it is correct, not only for Linux. That's what I'm not yet certain about. Something tells me that it is not correct for Windows. Ralf's description is correct also for Windows. Under Windows I see a lack of versioning and libtool adds a simple number like name-7.dll to the name. Not all OSs support library versioning, so in that case applications would continue using the older library and freshly compiled applications would use the newer library. Thru the magic of 'c-a', on windows we can represent one dimensional compatibility (that is, backwards compatibility) with a single number. That is: old app -- old dll, ok. old app -- new compatible dll, ok new app -- new compatible dll, ok new app -- old dll, maybe ok, maybe not. The old dll may not be forward compatible with new applications, even though the new dll is backwards compatible with old applications, and thus both DLLs have the same single number. From Ralf's three cases: case 1) no API change at all, c and a do not change -- DLL is forward- and backward- compatible, and 'c-a' remains constant so DLL name doesn't change. This is correct behavior. case 2) API additions only. DLL is backwards-compatible, but not forward-compatible. Both c and a are incremented, so 'c-a' does not change, and DLL name doesn't change. This is correct behavior. case 3) API deletions or modifications. DLL is not compatible. c in incremented, and a is set to 0. No matter how you slice it, 'c-a' will change -- and the DLL name will change with it. This is correct behavior. See this page for a good example: http://home.att.net/~perlspinr/libversioning.html -- Chuck
Re: bindir for libtool
Roumen Petrov wrote: I would like to share code and test case performed by me to add bindir support to libtool. The patch for libtool is attached as file libtool-origin-bindir.patch. The patch propose absolute path for dlname in la-file. Thank you for following through on this. The attached file bootstrap.sh is the test case for a dlopen application. Bootstrap script apply following patched to test source tree . - libtool-libltdl.patch (non required . help to trace dlopen) - makefile-bindir_rule.patch - changed to automake rules, i.e. add bindir flag to libtool. It would be better if the testcase were implemented as part of the automated testsuite, rather than as a standalone test. However, I understand wanting to get some feedback on the code, before spending more time integrating the test. Charles Wilson in mails threads add a note that for GNU Coding Standard. Libtool create lai-files in link mode. So in install mode is too late to change prefix,bindir or libdir. libdir in installed la-file point to libdir directory as is set before in link mode. Well, yeah: The GNU Coding Standard should allow us to do this, for any package that uses libtool (well, for *any* package, but we only care about the ones that use libtool on /this/ list!) $ configure --prefix=/foo make $ make install prefix=/some/tmp/dir/foo and the .la files in /some/tmp/dir/foo/lib/* should contain paths that use the *original* /foo, and not updated to the new fake prefix. If I understand the GCS correctly. For install mode the above patch install libraries in correct location - libdir for library related files and DLL in bindir. Note that libdir in la-file left unchanged during install. As result dll can't be found even dlname contain relative path. I'm addressing the simple case when user try to override prefix for install. Well, this is a bit unfair to you Roumen, but...given that (a) the *primary* motivation for fixing this, right this minute, is so that gcc-4.5.0 can get this fix in time for the end of stage 1 (this weekend), and (b) gcc has already merged Dave's patch: http://gcc.gnu.org/ml/gcc-patches/2009-08/msg01073.html I believe that the best way forward *for now* is for libtool to accept Dave's version -- even though it doesn't fix the problem case *you* are concerned about. This should help ease merging gcc--libtool down the road, especially if we THEN add some additional changes, somewhat along the lines of your suggestion, which gcc can pick up and easily merge *after* their stage 1 closes. I realize this is a bit of tail wagging the dog (why should gcc's modifying their semi-fork of libtool affect how we modify the official version?) but (a) gcc is, honestly, a REALLY BIG tail, and (b) libtool is a relatively small dog, so it does make some sense to accommodate their needs -- especially as Ralf has been intimately involved over the last months updating gcc's autoconf/automake/(libtool?) support. My preference going forward would be: 1) assuming no further objections (and, I believe Dave has adequately address ALL objections /except/ Roumen's), merge Dave's patch forthwith. 2) Begin a discussion about how to accommodate Roumen's concerns, which have not been addressed by Dave's changes, but without breaking Dave's (that is, gcc's) use of the -bindir option. I'd suggest, perhaps, adding a *different* libtool option, e.g. -abs-bindir, that works semantically as Roumen desires. Then, later, gcc may choose to use either -bindir or -abs-bindir, whatever seems best to them. I'm probably overlooking something with this suggestion, but I'd prefer if, rather than extending this thread and delaying #1 above any longer, we postpone discussion of how what I've just said is all wrong until after #1, and we're into the discussion of #2. -- Chuck
Re: [PATCH, take 4][cygwin|mingw] Control where win32 DLLs get installed.
Roumen Petrov wrote:
I'm concerned that we can't implement a working portable(cross-platform)
relative path calculation.
In the general case, Roumen, you are correct: there IS no portable
mechanism to compute relative paths when non-portable constructs such as
symbolic links are/may-be involved.
This is not the general case. This is a libtool- and DLL- specific
installation issue; we should not try to rewrite the entire auto* suite
to accommodate a wacky *hypothetical* installation tree organization not
currently supported by any GNU toolset, to fix one small corner case in
libtool.
Frankly, your hypothetical worry is not even a problem that libtool
should attempt to work around, for two reasons:
1) If the installation --prefix (AND DESTDIR/${prefix} as well!) is not
fully created PRIOR to build, then you cannot assume that when it IS
created, it will contain symbolic links, nor will you have ANY idea
where those future, hypothetical symbolic links will hypothetically
point to. So any attempt to use canonical_path or realpath (as opposed
to abspath) is doomed to failure, EVEN on those systems where (a)
realpath/canonical_path is supported, and (b) symbolic links are supported.
2) The current system is just as broken NOW, as libtool with Dave's fix
would be in your hypothetical case. In fact, the current system is EVEN
WORSE than any situation you have yet dreamed up. ../bin is WRONG, even
on non-symlink systems, even with pre-created installation trees, even
when they do or do not contain symlinks: if --bindir and --libdir are
not _exactly_ siblings under the same parent.
We've just been fortunate, because in 99.999% of the cases, --bindir and
--libdir ARE siblings, and are both directly under ${exec_prefix}.
Except for one, really BIG, exception: gcc (and three or four others
Yaakov has mentioned).
So, Dave's patch fixes the current problem, and does NOT make your
hypothetical (and completely unfixable anyway; see #1) case any worse.
The only possibility of fixing your complaint is to change the .la
format to specify the full absolute path to the dlname. Doing THAT
would, instead, break DESTDIR and GNU Coding Standard-required 'make
install prefix=${override_prefix}' installs, without a lot of additional
changes to the .la-.lai installation process. And even then,
computing accurately these absolute paths and fully resolving any
hypothetical symbolic links would require the installation tree (whether
$(prefix), ${override_prefix}, or DESTDIR/${prefix}) to be fully created
prior to 'make'.
Not. Gonna. Happen.
If you can come up with a mechanism to use absolute paths in dlname,
which does not break any of the known installation modes, works whether
the installation tree(s) are pre-created or NOT, and whether the final
installation tree contains symlinks or NOT, AND solves the issue with
getting DLLs on w32 into the correct directory AND that the installed
.la file correctly describes its location...
Then please show us the code. And the test results. On as many systems
as Dave has, especially including mingw, cygwin, linux, and various
cross environments.
Oh, and please make sure you do all of this before the GCC 4.5 stage 1
development window closes, currently scheduled for the end of August.
Otherwise, please stop letting the perfect (IMO, the perfectly
impossible) be the enemy of the good.
:) :) :) Dave, you even don't understand what is wrong.
With respect, Roumen, I believe it is you that are misdiagnosing the
problem.
--
Chuck
Re: [PATCH, take 4][cygwin|mingw] Control where win32 DLLs get installed.
Roumen Petrov wrote:
Dave Korn wrote:
Roumen Petrov wrote:
I think that processing of '..' in a path is too naive. It will fail to
produce correct results on filesystems with links.
As I explained to Eric, this function implements 'abspath', not
'realpath',
and given that we can't assume any of the directories even exist when
we have
to do this at link time, before installation, I don't see how we could
hope to
do any different.
You may test you function with following example:
[snip]
)
Yes, it is clear that there are cases, with oddly-constructed
pre-existing trees that contain symlinks, where abspath != realpath.
But, keep your eye on the ball: right now DLLs get installed into the
wrong directory, even in relatively normal setups:
--libdir=/usr/lib/subdir/
(--bindir=/usr/bin)
Current behavior assumes that bindir (e.g., where the DLL actually
gets installed) is /usr/lib/subdir/../bin. This is clearly wrong, and
broken regardless of whether you have an odd symlink-infested /usr. The
existing logic basically only works if both bindir and libdir are the
defaults, AND there are no funky symlinks.
So...
Dave's patch doesn't make things any worse than they already are for
non-default libdir/bindir, even for symlink-infested installation trees.
Broken before, fixed after, unless bad symlink problems -- in which
case it MAY still be broken, and maybe NOT. But if you're mucking about
with symlinks to make the logical installation tree differ from the
physical installation tree, well...IMO you're just asking for trouble.
But it's not fair to Dave to ask him to solve ALL pre-existing problems
with libtool's installation logic. He's trying to solve one problem,
while (hopefully) at the same time not making other pre-existing
problems worse.
I think his patch satisfies those requirements.
Sure.
Currently for gcc 4.4.0 (target i486-mingw32 build ${ARCH}-pc-linux) non
prefixed binaries from PREFIX/TARGET/bin don't work for me. As
example gcc can't find cc1. May be is same issue.
To resolve issue I use following additional links:
# cd $PREFIX
# l ./i486-mingw32/lib/gcc
lrwxrwxrwx 1 ./i486-mingw32/lib/gcc - ../../lib/gcc/
# l ./i486-mingw32/libexec
lrwxrwxrwx 1 ./i486-mingw32/libexec - ../libexec/
So...you're saying that gcc's installation paths are somewhat busted in
that the driver executables can't locate the backend executables, when
cross + non-default-prefix + odd-symlink-structure? OK.
So, why is this relevant to changes that *Dave* needs to make in the
patch for *libtool* with regards to *DLLs*? (Unless, you're simply
agreeing with Dave's statement that yeah, lots of GNU-style
installations can break when you muck with the installation tree in
unsupported ways. But if so, then...what's the objection to Dave's
patch, again?)
So I don't think this is likely to cause any problem except in really
bizarre corner-cases where someone's already trying something dubious,
is it?
So to me function like XX_abspath has to work.
Why? abspath != realpath. That's the point. If you're arguing that
all GNU installation tools should use realpath to canonicalize all paths
before use, well...maybe that discussion should be held, in some other
thread with a broader audience as it affects MUCH more than just
libtool. But (a) your desired behavior is not the case now, in a lot of
places other than libtool, (b) doing it your way will badly break
DESTDIR installations and any installation where the target installation
directory tree is not fully created at build/installation time (c) and
you'll get a lot of pushback from automake/autoconf on that.
Summary: in what way does Dave's patch make libtool behavior worse than
current? Given that I don't believe it does, yet his patch definitely
fixes issues that occur at present in much more common contexts, I'm
trying to clarify whether you believe your comments represent a reason
to block until rework, or accept as-is, Dave's current patch.
--
Chuck
Re: [PATCH+Assign request][cygwin|mingw] Control where win32 DLLs get installed.
Dave Korn wrote:
[ Please Cc me on replies, I'm not subbed up to list. ]
Windows DLLs, unlike Linux DSOs, have to live in the bin directory (or
elsewhere on $PATH), not the lib dir. Libtool handles this at --link time by
setting the dlname in the generated .la file to a relative path
../bin/$dlname, working on the assumption that the library .la file will be
installed into $prefix/lib, and this causes the DLL to be installed to
$prefix/bin.
That heuristic fails
Note, for the rest of the libtool team -- there is also a pending patch
not yet posted to this list, complementary to Dave's, from Yaakov
Selkowitz. Yaakov's patch improves the heuristic for many common cases,
eliminating some cases where Dave's -bindir option might be used.
However, even Yaakov's improvement doesn't solve the specific case vis.
gcc. Besides, no matter how smart a heuristic is, there are cases where
it fails -- so providing a specific control to override the heuristic is
kinda necessary. So, IMO, both Yaakov's and Dave's patch -- in some
form, are appropriate and complementary.
The attached patch provides a way to resolve this problem, by adding a
-bindir option to libtool's --link mode command line.
Dave, I'm sorry I wasn't able to get to this in time to save you the
effort, but thanks for following thru. Comments inline, but I have no
official authority to actually approve anything.
diff --git a/Makefile.am b/Makefile.am
index a18955e..129b890 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -494,7 +494,8 @@ TESTSUITE_AT = tests/testsuite.at \
tests/configure-iface.at \
tests/stresstest.at \
tests/cmdline_wrap.at \
- tests/darwin.at
+ tests/darwin.at \
+ tests/win32.at
EXTRA_DIST += $(srcdir)/$(TESTSUITE) $(TESTSUITE_AT)
$(srcdir)/tests/package.m4
OK.
diff --git a/libltdl/config/general.m4sh b/libltdl/config/general.m4sh
old mode 100644
new mode 100755
index 4bc304c..96072e2
--- a/libltdl/config/general.m4sh
+++ b/libltdl/config/general.m4sh
@@ -98,6 +98,49 @@ func_dirname_and_basename ()
func_basename_result=`$ECHO ${1} | $SED -e $basename`
}
+# func_relative_path libdir bindir
+# generates a relative path from libdir to bindir, intended
+# for supporting installation of windows DLLs into -bindir.
+# call:
+# dirname: Compute the dirname of FILE. If nonempty,
+# add APPEND to the result, otherwise set result
+# to NONDIR_REPLACEMENT.
+# value returned in $func_dirname_result
+func_relative_path ()
+{
+ local tlibdir tbindir tcancelled
We can't use the 'local' keyword. You need to uglify these variables, e.g.
func_relative_path_tlibdir
func_relative_path_tbindir
func_relative_path_tcancelled
+ func_relative_path_result=
+ tlibdir=${1%%/}
+ tbindir=${2%%/}
We can't use these, even tho they are technically supported by posix sh.
(Actually, we kinda can -- IF m4 says so. What happens is you abstract
the call into a function -- like func_stripname -- and then use m4 to
generate the appropriate contents of that function. For cygwin/bash, it
happens that the contents of func_stripname() actually do use the %, #
posixisms. But, in client code, you have to do
func_stripname '' '/' $1
tlibdir=$func_stripname_result
func_stripname '' '/' $2
tbindir=$func_stripname_result
+ while :; do
+# check if we have found a prefix of bindir
+tcancelled=${tbindir##$tlibdir}
Again, we can't do this (nor ${foo:=.}). See below...
+if test x$tcancelled != x$tbindir ;
+then
+ # Found a matching prefix, exit loop.
+ func_relative_path_result=${func_relative_path_result:=.}
+ break
+fi
+func_dirname $tlibdir
+tlibdir=${func_dirname_result}
+if test x$tlibdir = x ;
+then
+ # Have to descend all the way to the root!
+ func_relative_path_result=../$func_relative_path_result
+ break
+fi
+func_relative_path_result=../$func_relative_path_result
+ done
while :; do
# check if we have found a prefix of bindir
case $tbindir in
$tlibdir* ) # found a matching prefix
func_stripname $tlibdir '' $tbindir
tcancelled=$func_stripname_result
if test -z $func_relative_path_result; then
func_relative_path_result=.
fi
break
;;
*) func_dirname $tlibdir
tlibdir=${func_dirname_result}
if test x$tlibdir = x ; then
# Have to descend all the way to the root!
func_relative_path_result=../$func_relative_path_result
break
fi
func_relative_path_result=../$func_relative_path_result
;;
esac
done
+ # Now calculate path; take care to avoid doubling-up slashes.
+ func_relative_path_result=${func_relative_path_result%%/}${tcancelled%%/}
Re: [PATCH+Assign request][cygwin|mingw] Control where win32 DLLs get installed.
Dave Korn wrote: Well, I did really want to make it a test of nothing other than the -bindir functionality, in fact it's more or less just a test of the corner cases for func_relative_path! Using -rpath seems to work as far as supplying an input value for $install_libdir and that's all I really want to achieve here: set $install_libdir and $bindir and make sure that chunk of code DTRT. I think it'll be OK, won't it, even if it is a bit unusual? After looking at the code flow in libtool more closely, it appears that you are correct. All you really care about here is that install_libdir is set to something odd compared to -bindir's argument, and -rpath does that. And your way, the tests are MUCH faster. -- Chuck
[PATCH] Add --lt-* options to shell wrapper
* libltdl/config/ltmain.m4sh (func_emit_wrapper)
[func_parse_lt_options]: New function.
[func_opts_contain_lt]: New function.
[func_lt_dump_args]: New function.
[func_exec_program_core]: New function, refactored from [main].
[func_exec_program]: New function.
[main]: Call func_parse_lt_options early. Use func_exec_program.
(func_emit_cwrapperexe_src) [main]: Reword error message to
align with (upcoming) documentation.
---
For symmetry, support --lt-debug and --lt-dump-script in the shell
wrapper, as well as in the cwrapper.
In this patch series, I've kept the --lt-dump-script option
for now, and even added support for that option to the wrapper
script. I think the option is useful, and I agree that symmetry
between w-script and w-exe is important. However, Ralf said:
I'd consider documenting --lt-dump-script the cementation of
a bad API.
So, as a compromise we could could modify this documentation patch
to just not /document/ that option, while retaining all the other
documentation/discussion of the w-exe and the --lt-debug option.
There are four patches in this series:
1. Remove unneeded functions and options from cwrapper
committed: 75765d58c38c55ef069ef100732c1e978f4151a6
2. [PATCH] Enable runtime cwrapper debugging; add tests
http://lists.gnu.org/archive/html/libtool-patches/2009-06/msg00039.html
pending...
3. [PATCH] Add --lt-* options to shell wrapper
(this post. obviously no URL yet, and obviously pending...)
4. [PATCH] Document wrapper changes
(next post. also no URL yet, and also obviously pending...)
Together, these four obsolete and (I hope) address all of the comments
for
[PATCH] Document and test LT_DEBUGWRAPPER cwrapper macro
http://lists.gnu.org/archive/html/libtool-patches/2009-06/msg00031.html
as well as addressing the comments recieved so far in review of #2.
I'm posting #3 and #4 on the off chance that, for whatever reasons,
approval for #2 has been held up waiting for these two promised patches.
I'm really hoping to get my pending patch set reviewed and merged in the
near future, as the current cygwin patch queue is a bit ridiculous at 72kB...
8 files changed, 1271 insertions(+), 242 deletions(-)
libltdl/config/ltmain.m4sh | 150 ++--
1 files changed, 130 insertions(+), 20 deletions(-)
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index d8c5749..881aef5 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -2401,7 +2401,134 @@ func_fallback_echo ()
_LTECHO_EOF'
}
ECHO=\$qECHO\
- fi\
+ fi
+
+# Very basic option parsing. These options are (a) specific to
+# the libtool wrapper, (b) are identical between the wrapper
+# /script/ and the wrapper /executable/ which is used only on
+# windows platforms, and (c) all exist in the --lt- namespace
+# (application programs are unlikely to have options which match
+# this pattern).
+#
+# There are only two supported options: --lt-debug and
+# --lt-dump-script. There is, deliberately, no --lt-help.
+#
+# The first argument to this parsing function should be the
+# script's $0 value, followed by $@.
+lt_option_debug=
+func_parse_lt_options ()
+{
+ lt_script_arg0=\$0
+ shift
+ for lt_opt
+ do
+case \\$lt_opt\ in
+--lt-debug) lt_option_debug=1 ;;
+--lt-dump-script)
+lt_dump_D=\`\$ECHO \X\$lt_script_arg0\ | $SED -e 's/^X//' -e
's%/[^/]*$%%'\`
+test \X\$lt_dump_D\ = \X\$lt_script_arg0\ lt_dump_D=.
+lt_dump_F=\`\$ECHO \X\$lt_script_arg0\ | $SED -e 's/^X//' -e
's%^.*/%%'\`
+cat \\$lt_dump_D/\$lt_dump_F\
+exit 0
+ ;;
+--lt-*)
+\$ECHO \Unrecognized --lt- option: '\$lt_opt'\ 12
+exit 1
+ ;;
+esac
+ done
+}
+
+# Sets opts_contain_lt_result to \yes\ if the
+# supplied arguments contain any elements in the
+# --lt-* namespace. Empty otherwise.
+opts_contain_lt_result=
+func_opts_contain_lt ()
+{
+ opts_contain_lt_result=
+ for lt_option
+ do
+case \\$lt_option\ in
+--lt-*) opts_contain_lt_result=yes
+break ;;
+*) ;;
+esac
+ done
+}
+
+# Used when --lt-debug. Prints its arguments to stdout
+# (redirection is the responsibility of the caller)
+func_lt_dump_args ()
+{
+ lt_dump_args_N=1;
+ for lt_arg
+ do
+\$ECHO \(main) newargz[\$lt_dump_args_N] : \$lt_arg\
+lt_dump_args_N=\`expr \$lt_dump_args_N + 1\`
+ done
+}
+
+# Core function for launching the target application
+func_exec_program_core ()
+{
+
+ case $host in
+ # Backslashes separate directories on plain windows
+ *-*-mingw | *-*-os2* | *-cegcc*)
+$ECHO \
+ if test -n \\$lt_option_debug\; then
+\$ECHO \(main) lt_argv_zero : \$progdir\$program\ 12
+func_lt_dump_args \${1+\\...@\} 12
+ fi
+ exec \\$progdir\$program\ \${1+\\...@\}
+
+;;
+
+ *)
+$ECHO \
+ if test -n \\$lt_option_debug\; then
+\$ECHO \(main) lt_argv_zero : \$progdir/\$program\ 12
+func_lt_dump_args \${1+\\...@\} 12
+
[PATCH] Document wrapper changes.
* NEWS: Indicate new feature and incompatibility.
* doc/libtool.texi [Linking executables]: Mention wrapper
executables, in addition to wrapper scripts. Add menu referencing
subsection 'Wrapper executables for programs'.
[Wrapper executables for programs]: New subsection. Documents
cwrapper rationale and command line options.
---
This patch adds documentation for the new wrapper command line
options (which apply to both the wrapper /script/ and to the
wrapper /executable/). However, because the options are of
primary interest with respect to the wrapper exes, I've kept
the documentation in the page specific for those, with a note
that the script also supports the options.
In this patch series, I've kept the --lt-dump-script option
for now, and even added support for that option to the wrapper
script. I think the option is useful, and I agree that symmetry
between w-script and w-exe is important. However, Ralf said:
I'd consider documenting --lt-dump-script the cementation of
a bad API.
So, as a compromise we could could modify this documentation patch
to just not /document/ that option, while retaining all the other
documentation/discussion of the w-exe and the --lt-debug option.
There are four patches in this series:
1. Remove unneeded functions and options from cwrapper
committed: 75765d58c38c55ef069ef100732c1e978f4151a6
2. [PATCH] Enable runtime cwrapper debugging; add tests
http://lists.gnu.org/archive/html/libtool-patches/2009-06/msg00039.html
pending...
3. [PATCH] Add --lt-* options to shell wrapper
(just posted. Hasn't propagated to the archive yet, so no URL.
Obviously, still pending...)
4. [PATCH] Document wrapper changes
(this post. Obviously no URL yet, and also obviously pending...)
Together, these four obsolete and (I hope) address all of the comments
for
[PATCH] Document and test LT_DEBUGWRAPPER cwrapper macro
http://lists.gnu.org/archive/html/libtool-patches/2009-06/msg00031.html
as well as addressing the comments recieved so far in review of #2.
I'm posting #3 and #4 on the off chance that, for whatever reasons,
approval for #2 has been held up waiting for these two promised patches.
NEWS | 11
doc/libtool.texi | 69 -
2 files changed, 78 insertions(+), 2 deletions(-)
diff --git a/NEWS b/NEWS
index 5a57891..64f27b6 100644
--- a/NEWS
+++ b/NEWS
@@ -12,6 +12,17 @@ New in 2.2.8 2009-??-??: git version 2.2.7a, Libtool team:
- New libtool command line flag --no-verbose, which disables only
the extra verbose output messages and has no effect on the
default informational messages.
+ - Wrapper scripts and wrapper executables for programs linked against
+uninstalled shared libraries now support command-line options --lt-debug
+and --lt-dump-script.
+
+* Important incompatible changes:
+
+ - The wrapper command line option support described above introduces the
+following incompatibility: the wrapper will remove any command line
+options that begin with '--lt-*' from the argument list before launching
+(uninstalled) programs. Any '--lt-*' option on the command line not
+recognized by the wrapper will result in an error.
* Changes in supported systems or compilers:
diff --git a/doc/libtool.texi b/doc/libtool.texi
index a7872c6..8fa6f59 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -790,8 +790,9 @@ Note that libtool added the necessary run-time path flag,
as well as
@cindex wrapper scripts for programs
@cindex program wrapper scripts
Notice that the executable, @code{hell}, was actually created in the
-...@file{@value{objdir}} subdirectory. Then, a wrapper script was created
-in the current directory.
+...@file{@value{objdir}} subdirectory. Then, a wrapper script (or, on
+certain platforms, a wrapper executable @pxref{Wrapper executables}) was
+created in the current directory.
Since libtool created a wrapper script, you should use libtool to
install it and debug it too. However, since the program does not depend
@@ -845,6 +846,70 @@ price of being dynamic is eight kilobytes, and the payoff
is about four
kilobytes. So, having a shared @file{libhello} won't be an advantage
until we link it against at least a few more programs.
+...@menu
+* Wrapper executables:: Wrapper executables for some platforms.
+...@end menu
+
+...@node Wrapper executables
+...@subsection Wrapper executables for programs
+...@cindex wrapper executables for programs
+...@cindex program wrapper executables
+
+Some platforms, notably those hosted on Windows such as Cygwin
+and MinGW, use a wrapper executable rather than a wrapper script
+to ensure proper operation of programs linked by libtool against
+uninstalled shared libraries. The wrapper executable thus performs
+the same function as the wrapper script used on other platforms, but
+allows to satisfy the @command{make} rules for the program, whose
+name ends in @code{$(EXEEXT)}. The actual program executable
Re: [PATCH] Enable runtime cwrapper debugging; add tests
Charles Wilson wrote:
I'll follow up this patch with another to add support for
--lt-debug
--lt-dump-script
to the shell wrapper. --lt-debug will do very little other than $ECHO
the full path to the program executable and its arguments.
--lt-dump-script will simply { cat $0 exit 0 }
See just-posted [PATCH] Add --lt-* options to shell wrapper
Then I'll revise and retitle the remainder of
[PATCH] Document and test LT_DEBUGWRAPPER cwrapper macro
http://lists.gnu.org/archive/html/libtool-patches/2009-06/msg00031.html
as appropriate.
See just-posted [PATCH] Document wrapper changes.
Ping x2 ?
--
Chuck
Re: [PATCH] Document and test LT_DEBUGWRAPPER cwrapper macro
End thread. This patch has been obsoleted by: 1. Remove unneeded functions and options from cwrapper committed: 75765d58c38c55ef069ef100732c1e978f4151a6 2. [PATCH] Enable runtime cwrapper debugging; add tests http://lists.gnu.org/archive/html/libtool-patches/2009-06/msg00039.html pending... 3. [PATCH] Add --lt-* options to shell wrapper just posted. pending... 4. [PATCH] Document wrapper changes just posted. pending... -- Chuck
Re: [PATCH] [cygwin|mingw] fix dlpreopen with --disable-static take 6
Charles Wilson wrote: * libltdl/config/general.m4sh: Update copyright year. (func_tr_sh): New function. * libltdl/config/ltmain.m4sh (func_generate_dlsyms) [cygwin|mingw]: Obtain DLL name corresponding to import library by using value stored in unique variable libfile_$(transliterated implib name). If that fails, use $sharedlib_from_linklib_cmd to extract DLL name from import library directly. Also, properly extract dlsyms from the import library. (func_mode_link) [cygwin|mingw]: Prefer to dlpreopen DLLs over static libs when both are available. When dlpreopening DLLs, use linklib (that is, import lib) as dlpreopen file, rather than DLL. Store name of associated la file in unique variable libfile_$(transliterated implib name) for later use. (func_win32_libid): Accomodate pei-i386 import libs as well as pe-i386. (func_cygming_dll_for_implib): New function. (func_cygming_dll_for_implib_fallback): New function. (func_cygming_dll_for_implib_fallback_core): New function. (func_cygming_gnu_implib_p): New function. (func_cygming_ms_implib_p): New function. * libltdl/m4/libtool.m4 (_LT_CMD_GLOBAL_SYMBOLS): Adjust sed expressions for lt_cv_sys_global_symbol_to_c_name_address and lt_cv_sys_global_symbol_to_c_name_address_lib_prefix as trailing space after module name is optional. (_LT_LINKER_SHLIBS) [cygwin|mingw][C++]: Set exclude_expsyms correctly for $host. Simplify regular expression in export_symbols_cmds. (_LT_LINKER_SHLIBS) [cygwin|mingw|pw32][C]: Set exclude_expsyms correctly for $host. Enable export_symbols_cmds to identify DATA exports by _nm_ prefix. (_LT_CHECK_SHAREDLIB_FROM_LINKLIB): New macro sets sharedlib_from_linklib_cmd variable. (_LT_DECL_DLLTOOL): New macro ensures DLLTOOL is always set. --- Reposted without change from -take5, here: http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg00232.html This patch has been in use in the cygwin distribution since 2009-02-20. Ping? FYI, the cygwin distribution recently (Jul 4) released an updated binutils package (2.19.51) for cygwin-1.7. This version supports the --identify and --identify-strict options -- so, at least on cygwin-1.7 we won't be using the func_cygming_dll_for_implib_fallback function. Now, with the redesign proposed by Ralf back in January and implemented (take 3? take 4? I forget), we ordinarily use NEITHER func_cygming_dll_for_implib_fallback nor dlltool --identify-strict because, in the ordinary case, we have a libtool .la file and use it to track implib-dll. NOW, the only time either of these two methods is used, is when someone specifies explicitly an implib or DLL on the link command passed to libtool: libtool mode=link /my/path/foo.dll.a -lbar-3.dll BUT...it's still nice that the (faster, less kludgy) dlltool method can now be used on cygwin-1.7. (No, the standard toolchain from the mingw.org guys doesn't yet support --identify-strict, so it still uses the fallback). -- Chuck
Re: [PATCH] [cygwin|mingw] Create UAC manifest files.
Ralf Wildenhues wrote: But IANAL, so... Me neither. I'm not making up these rules either, so please discuss them with the FSF if you have an issue with them. Nope, no issue. I didn't realize the FSF treated patches cumulatively. You're right, Yaakov has submitted a number of these small patches. -- Chuck
Re: [PATCH] [CXX] Use correct export_dynamic_flag_spec for PE-COFF $hosts
Ralf Wildenhues wrote:
* Charles Wilson wrote on Wed, Jul 01, 2009 at 06:48:52AM CEST:
but
as far as I can tell we don't actually have separate cases for those
other languages' linker requirements at present. There's just C++, and
everything else:
Yes. What I am asking is do these variables actually get set for
'everything else' or not? Presumably all it should take you to verify
that would be to inspect the output of this, in the top build directory
of Libtool:
for tag in F77 FC GCJ; do
./libtool --tag=$tag --config | grep '^export_dynamic_flag_spec='
done
$ for tag in F77 FC GCJ; do
echo $tag: `./libtool --tag=$tag --config | grep
'^export_dynamic_flag_spec='`
done
F77: export_dynamic_flag_spec=\${wl}--export-all-symbols
export_dynamic_flag_spec=\${wl}--export-all-symbols
FC: export_dynamic_flag_spec=\${wl}--export-all-symbols
export_dynamic_flag_spec=\${wl}--export-all-symbols
GCJ: export_dynamic_flag_spec=\${wl}--export-all-symbols
export_dynamic_flag_spec=\${wl}--export-all-symbols
('course, for that to work properly, I had to download and actually
install GCJ, before rebuilding libtool with this patch)
Given the above, I'm taking this:
OK to push?
Yes, but {please check as above}
As approval.
Presuming there WAS a need for a separate setting for F77 or FC or
GCJ...er, where exactly would such things go?
In or in macros called from the _LT_LANG_*_CONFIG macros.
Thanks,
Chuck
[PATCH] [CXX] Use correct export_dynamic_flag_spec for PE-COFF $hosts
* libltdl/m4/libtool.m4 (_LT_LANG_CXX_CONFIG) [cygwin*|mingw*|pw32*|cegcc*]:
Define export_dynamic_flag_spec as -Wl,--export-all-symbols here as well
(see commit 5f2bbb494a2753afb2878c399cfd8316b7403a5b).
Signed-off-by: Charles Wilson ...
---
Originally posted by Yaakov Selkowitz on the cygwin list. Seems
obvious to me, especially given 5f2bbb494a2753afb2878c399cfd8316b7403a5b.
OK to push?
--
Chuck
libltdl/m4/libtool.m4 |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 0777d4d..f45a630 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -5632,6 +5632,7 @@ if test $_lt_caught_CXX_error != yes; then
# _LT_TAGVAR(hardcode_libdir_flag_spec, $1) is actually meaningless,
# as there is no search path for DLLs.
_LT_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir'
+_LT_TAGVAR(export_dynamic_flag_spec, $1)='${wl}--export-all-symbols'
_LT_TAGVAR(allow_undefined_flag, $1)=unsupported
_LT_TAGVAR(always_export_symbols, $1)=no
_LT_TAGVAR(enable_shared_with_static_runtimes, $1)=yes
--
1.6.3.2
Re: [PATCH] [cygwin|mingw] Create UAC manifest files.
Eric Blake wrote: Do we need to worry about deleting *.manifest files at the appropriate 'make *clean' level? Hmm. Yes, the one in the build directory (for the wrapper, or the real exe if building without dependencies on uninstalled DLLs) probably should be. The one in .libs/ not so much, because the catchall rm -rf .libs will take care of it. +# Create the UAC manifests first if necessary +case $output_name in + *instal*|*patch*|*setup*|*update*) +func_emit_exe_manifest $cwrapper.manifest +func_emit_exe_manifest $output_path/$objdir/$output_name.exe.manifest Would it be more efficient to use tee or cp, rather than two calls to func_emit_exe_manifest? Well, you're not guaranteed to have tee on MSYS. The current code is two forks: each function call forks a 'cat' process. Either of your proposals is also two forks: one 'cat', and one 'tee' or 'cp'. So I don't think it makes much difference. Does the .manifest need +x permissions? I seem to recall that it does, but I'm not sure. -- Chuck
Re: [PATCH] [CXX] Use correct export_dynamic_flag_spec for PE-COFF $hosts
Ralf Wildenhues wrote: Yes but can you please check that you don't need to add another 3 patches for F77, FC, GCJ? Well, the whole tag-based mechanism in libtool makes my teeth ache, but as far as I can tell we don't actually have separate cases for those other languages' linker requirements at present. There's just C++, and everything else: m4_defun([_LT_LINKER_SHLIBS], ... m4_if([$1], [CXX], [ c++ _LT_TAGVAR stuff ], [ other _LT_TAGVAR stuff ]]) Presuming there WAS a need for a separate setting for F77 or FC or GCJ...er, where exactly would such things go? -- Chuck
Re: [PATCH] [mingw] Improve sys_lib_search_path_spec detection.
Bob Friesenhahn wrote: On Mon, 29 Jun 2009, Charles Wilson wrote: OK to push? This patch seems like it offers considerable improvement. Please push it. Thanks, pushed. -- Chuck
[PATCH] Finish adding alias for obsoleted AC_LIBTOOL_RC macro.
* libltdl/m4/libtool.m4: Add reminder comment concerning aclocal-1.4 backwards compatibility. * libltdl/m4/lt~obsolete.m4: Remove unnecessary AC_DEFUN. --- Pushed as pre-approved. -- Chuck ChangeLog |8 libltdl/m4/libtool.m4 |1 + libltdl/m4/lt~obsolete.m4 |1 - 3 files changed, 9 insertions(+), 1 deletions(-) diff --git a/ChangeLog b/ChangeLog index e5b40ca..2b7ba3e 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,11 @@ +2009-06-28 Charles Wilson libt...@cwilson.fastmail.fm + + Finish adding alias for obsoleted AC_LIBTOOL_RC macro. + + * libltdl/m4/libtool.m4: Add reminder comment concerning + aclocal-1.4 backwards compatibility. + * libltdl/m4/lt~obsolete.m4: Remove unnecessary AC_DEFUN. + 2009-06-27 Charles Wilson libt...@cwilson.fastmail.fm Add alias for obsoleted AC_LIBTOOL_RC macro. diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4 index 0777d4d..1fe09d2 100644 --- a/libltdl/m4/libtool.m4 +++ b/libltdl/m4/libtool.m4 @@ -866,6 +866,7 @@ dnl AC_DEFUN([AC_LIBTOOL_CXX], []) dnl AC_DEFUN([AC_LIBTOOL_F77], []) dnl AC_DEFUN([AC_LIBTOOL_FC], []) dnl AC_DEFUN([AC_LIBTOOL_GCJ], []) +dnl AC_DEFUN([AC_LIBTOOL_RC], []) # _LT_TAG_COMPILER diff --git a/libltdl/m4/lt~obsolete.m4 b/libltdl/m4/lt~obsolete.m4 index 544ae45..bf92b5e 100644 --- a/libltdl/m4/lt~obsolete.m4 +++ b/libltdl/m4/lt~obsolete.m4 @@ -77,7 +77,6 @@ m4_ifndef([AC_DISABLE_FAST_INSTALL], [AC_DEFUN([AC_DISABLE_FAST_INSTALL])]) m4_ifndef([_LT_AC_LANG_CXX], [AC_DEFUN([_LT_AC_LANG_CXX])]) m4_ifndef([_LT_AC_LANG_F77], [AC_DEFUN([_LT_AC_LANG_F77])]) m4_ifndef([_LT_AC_LANG_GCJ], [AC_DEFUN([_LT_AC_LANG_GCJ])]) -m4_ifndef([AC_LIBTOOL_RC], [AC_DEFUN([AC_LIBTOOL_RC])]) m4_ifndef([AC_LIBTOOL_LANG_C_CONFIG], [AC_DEFUN([AC_LIBTOOL_LANG_C_CONFIG])]) m4_ifndef([_LT_AC_LANG_C_CONFIG], [AC_DEFUN([_LT_AC_LANG_C_CONFIG])]) m4_ifndef([AC_LIBTOOL_LANG_CXX_CONFIG], [AC_DEFUN([AC_LIBTOOL_LANG_CXX_CONFIG])]) -- 1.6.1.2
[PATCH] [mingw] Improve sys_lib_search_path_spec detection.
* libltdl/m4/libtool.m4 (_LT_SYS_DYNAMIC_LINKER): Fix handling
of dos-style paths when parsing $CC -print-search-dirs output.
---
It appears that this particular behavior has been broken for quite some time.
Currently, libtool mangles $CC -print-search-dirs badly on mingw:
sys_lib_search_path_spec= =c /mingw/bin/../lib/gcc/mingw32/4.4.0-dw2/;c
/mingw/bin/../lib/gcc/;/usr/lib/gcc/mingw32/4.4.0-dw2/;c
/mingw/bin/../lib/gcc/mingw32/4.4.0-dw2/../../../../mingw32/lib/mingw32/4.4.0-dw2/;c
/mingw/bin/../lib/gcc/mingw32/4.4.0-dw2/../../../../mingw32/lib/;c
/mingw/bin/../lib/gcc/mingw32/4.4.0-dw2/../../../mingw32/4.4.0-dw2/;c
/mingw/bin/../lib/gcc/mingw32/4.4.0-dw2/../../../;/mingw/lib/mingw32/4.4.0-dw2/;/mingw/lib/
with the attached patch:
sys_lib_search_path_spec=c:/mingw/lib/gcc/mingw32/4.4.0-dw2 c:/mingw/lib/gcc
c:/mingw/mingw32/lib c:/mingw/lib /mingw/lib
Furthermore, as the old code destroyed the earlier (multilib-capable) version of
sys_lib_search_path_spec and replaced it with the broken version (line 2181
below),
by moving the special handling for dos-style paths up the the multilib-handling
area, we may -- MAY -- see some benefits with regards to mingw64/mingw32
multilib
behavior. That's just a guess, tho.
Currently running regression tests on MSYS-1.0.12 + mingw-4.4.0-dw2 (TDM
version).
OK to push, if no regressions from earlier behavior on mingw?
--
Chuck
libltdl/m4/libtool.m4 | 27 +++
1 files changed, 11 insertions(+), 16 deletions(-)
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 1fe09d2..b6862a0 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -1986,7 +1986,11 @@ if test $GCC = yes; then
darwin*) lt_awk_arg=/^libraries:/,/LR/ ;;
*) lt_awk_arg=/^libraries:/ ;;
esac
- lt_search_path_spec=`$CC -print-search-dirs | awk $lt_awk_arg | $SED -e
s/^libraries:// -e s,=/,/,g`
+ case $host_os in
+mingw* | cegcc*) lt_sed_strip_eq=s,=\([[A-Za-z]]:\),\1,g ;;
+*) lt_sed_strip_eq=s,=/,/,g ;;
+ esac
+ lt_search_path_spec=`$CC -print-search-dirs | awk $lt_awk_arg | $SED -e
s/^libraries:// -e $lt_sed_strip_eq`
case $lt_search_path_spec in
*\;*)
# if the path contains ; then we assume it to be the separator
@@ -2031,6 +2035,12 @@ BEGIN {RS= ; FS=/|\n;} {
if (lt_foo != ) { lt_freq[[lt_foo]]++; }
if (lt_freq[[lt_foo]] == 1) { print lt_foo; }
}'`
+ # AWK program above erroneously prepends '/' to C:/dos/paths
+ # for these hosts.
+ case $host_os in
+mingw* | cegcc*) lt_search_path_spec=`$ECHO $lt_search_path_spec |\
+ $SED 's,/\([[A-Za-z]]:\),\1,g'` ;;
+ esac
sys_lib_search_path_spec=`$ECHO $lt_search_path_spec | $lt_NL2SP`
else
sys_lib_search_path_spec=/lib /usr/lib /usr/local/lib
@@ -2178,21 +2188,6 @@ m4_if([$1], [],[
mingw* | cegcc*)
# MinGW DLLs use traditional 'lib' prefix
soname_spec='${libname}`echo ${release} | $SED -e
's/[[.]]/-/g'`${versuffix}${shared_ext}'
- sys_lib_search_path_spec=`$CC -print-search-dirs | $SED
'/^libraries:/!d; s///; s,=/,/,g'`
- case $sys_lib_search_path_spec in
- *\;[c-zC-Z]:*)
-# It is most probably a Windows format PATH printed by
-# mingw gcc, but we are running on Cygwin. Gcc prints its search
-# path with ; separators, and with drive letters. We can handle the
-# drive letters (cygwin fileutils understands them), so leave them,
-# especially as we might pass files found there to a mingw objdump,
-# which wouldn't understand a cygwinified path. Ahh.
-sys_lib_search_path_spec=`$ECHO $sys_lib_search_path_spec | $SED -e
's/;/ /g'`
-;;
- *)
-sys_lib_search_path_spec=`$ECHO $sys_lib_search_path_spec | $SED -e
s/$PATH_SEPARATOR/ /g`
- ;;
- esac
;;
pw32*)
# pw32 DLLs use 'pw' prefix rather than 'lib'
--
1.6.1.2
Re: [PATCH] [mingw] Improve sys_lib_search_path_spec detection.
Charles Wilson wrote: * libltdl/m4/libtool.m4 (_LT_SYS_DYNAMIC_LINKER): Fix handling of dos-style paths when parsing $CC -print-search-dirs output. --- Currently running regression tests on MSYS-1.0.12 + mingw-4.4.0-dw2 (TDM version). OK to push, if no regressions from earlier behavior on mingw? On MSYS-1.0.12 with gcc-4.4.0dw2 (TDM): = OLD: 2 of 114 tests failed (10 tests were not run) FAIL: tests/f77demo-exec.test (after f77demo-static.test) FAIL: tests/fcdemo-exec.test (after fcdemo-static.test) NOTE: in this configuration, all of the other f77 and fc tests were skipped. The real bug here is why these weren't skipped also; but I don't think it has anything to do with this patch. NEW: 82 tests behaved as expected. 6 tests were skipped. However, a lot of these were reported as expected failure because my MSYS-1.0.12 installation does not have any of the other autotools installed. So, I also ran the test suite under the older setup: On MSYS-1.0.11 with gcc-3.4.5 (mingw.org): = OLD: 4 of 106 tests failed (18 tests were not run) FAIL: tests/demo-exec.test [*] FAIL: tests/f77demo-static.test [**] FAIL: tests/f77demo-conf.test [**] FAIL: tests/f77demo-shared.test [**] [*] after demo-shared. This is fixed by one of my other recent patches. [**] these failures have been around a while on mingw. Note the missing g77.exe below: checking for Fortran 77 libraries of g77... -L/usr/lib -L/bin/../lib/gcc-lib/i686-pc-msys/2.95.3-1 -L/bin/../lib/gcc-lib -L/usr /lib/gcc-lib/i686-pc-msys/2.95.3-1 -L/bin/../lib/gcc-lib/i686-pc-msys/2.95.3-1/../../../../i686-pc-msys/lib -L/usr/lib/gcc-lib/i 686-pc-msys/2.95.3-1/../../../../i686-pc-msys/lib -lg2c -lmsys-1.0 -luser32 -lkernel32 -ladvapi32 -lshell32 checking for dummy main to link with Fortran 77 libraries... unknown So, that's something else to fix, but it's not related to this patch AFAICT. NEW: 8 failed (3 expected failures). 4 tests were skipped. 34: search-path.at:25 sys_lib_search_path libtool 71: recursive.at:60compiling softlinked libltdl libtoolize autoconf automake 72: recursive.at:80compiling copied libltdl libtoolize autoconf automake 73: recursive.at:100 installable libltdl libtoolize autoconf automake 86: cmdline_wrap.at:28 Run tests with low max_cmd_len recursive Now, 34 is ironic. However, it is because I don't have an accessible zlib installed, so naturally the link never succeeds. But, it's at least testing all the right directories: 34. search-path.at:25: testing ... libtool: link: /mingw/src/libtool/libtool-2.2.7a/libltdl/config/compile gcc -g -O2 -o .libs/main.exe main.o -Lc:/MinGW/lib/gcc/ mingw32/3.4.5 -lz c:\MinGW\bin\..\lib\gcc\mingw32\3.4.5\..\..\..\..\mingw32\bin\ld.exe: cannot find -lz collect2: ld returned 1 exit status Repeated with different -L options: -Lc:/MinGW/lib/gcc/ -LC:/MinGW/lib/gcc/ -Lc:/MinGW/mingw32/ -LC:/MinGW/mingw32/ -L/mingw/lib -Lc:/MinGW/lib - -LC:/MinGW/lib -L/lib (actually, that directory list is *wrong* -- because mingw gcc 3.4.5's specs file is wrong. It should never search /lib, that's msys stuff. But...it does: libraries: =c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/;c:/MinGW/bin/../lib/gcc/;C:/MinGW/lib/gcc/mingw32/3.4.5/;/usr/lib/gcc/mingw32 /3.4.5/;c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../mingw32/lib/mingw32/3.4.5/;c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../.. /../../mingw32/lib/;C:/MinGW/lib/gcc/mingw32/3.4.5/../../../../mingw32/lib/mingw32/3.4.5/;C:/MinGW/lib/gcc/mingw32/3.4.5/../../. ./../mingw32/lib/;/mingw/lib/mingw32/3.4.5/;/mingw/lib/;c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../mingw32/3.4.5/;c:/MinGW/b in/../lib/gcc/mingw32/3.4.5/../../../;C:/MinGW/lib/gcc/mingw32/3.4.5/../../../mingw32/3.4.5/;C:/MinGW/lib/gcc/mingw32/3.4.5/../. ./../;/lib/mingw32/3.4.5/;/lib/;/usr/lib/mingw32/3.4.5/;/usr/lib/ So, the bug there is actually in gcc-3.4.5... 71: C:\msys\1.0\local\bin\autoheader: line 159: exec: C:\msys\1.0\local\bin\autoheader-2.61: not found This is because 'the autoconf wrapper couldn't find the actual autoconf with the specified version'. It's actually a wrapper script bug. 72: same wrapper script bug. 73: ditto. 86: just a repeat of #34 above. = OK to push? -- Chuck
Re: [PATCH] [mingw] Improve sys_lib_search_path_spec detection.
Vincent Torri wrote: On MSYS-1.0.12 with gcc-4.4.0dw2 (TDM): 1.0.12 ?? There is only 1.0.11 RC (on the mingw.org wiki) afaik. Where did you get that version ? You're right. It's 1.0.11 and 1.0.10, not 1.0.12 and 1.0.11. Sorry, it's late. -- Chuck
Re: [PATCH] Add alias for obsoleted AC_LIBTOOL_RC macro.
Ralf Wildenhues wrote:
* Charles Wilson wrote on Wed, Jun 24, 2009 at 02:32:16AM CEST:
* libltdl/m4/libtool.m4: Add alias for obsoleted
macro AC_LIBTOOL_RC.
OK,
Pushed.
but *really*, the project thould move to Libtool 2.2.x.
Push them, please.
OK, with or without an additional change to lt~obsolete.m4?
No idea what you mean with this.
My previous reply seemed to go astray...
lt~obsolete.m4 supplies only empty, non-functional aliases for old,
public libtool macros that have been removed. It currently has this:
m4_ifndef([AC_LIBTOOL_RC], [AC_DEFUN([AC_LIBTOOL_RC])])
Can that line stay, or should it be removed, now that
libltdl/m4/libtool.m4 will provide a non-empty, functional alias for
AC_LIBTOOL_RC? I dug thru the git log, but I really could not figure
out why this was put in lt~obsolete in the first place, instead of
treated like the other AC_LIBTOOL_{lang} macros...
If desired, I'll prepare another patch to remove that alias defn from
lt~obsolete.
--
Chuck
Re: [PATCH] Enable runtime cwrapper debugging; add tests
Charles Wilson wrote:
* libltdl/config/ltmain.m4sh (func_emit_cwrapperexe_src)
[ltwrapper_debugprintf]: Renamed to...
[lt_debugprintf]: this. Only print messages if lt_debug != 0.
[file scope]: Add constants and variables to support new --lt-debug
option. Remove LTWRAPPER_DEBUGPRINTF macro.
[main]: Consolidate option parsing. Ensure first use of lt_debugprintf
occurs after option parsing. Add stanza to parse for --lt-debug and
set lt_debug variable.
[all]: Use lt_debugprintf () instead of LTWRAPPER_DEBUGPRINTF (()).
* tests/cwrapper.at: Add new tests for --lt-debug and -DLT_DEBUGWRAPPER.
---
Another fragment arising from review of
http://lists.gnu.org/archive/html/libtool-patches/2009-06/msg00031.html
Lightly tested by running tests/demo-shared.test tests/demo-make.test
tests/demo-exec.test and cwrapper.at.
Ok to push?
Ping?
I'll follow up this patch with another to add support for
--lt-debug
--lt-dump-script
to the shell wrapper. --lt-debug will do very little other than $ECHO
the full path to the program executable and its arguments.
--lt-dump-script will simply { cat $0 exit 0 }
Then I'll revise and retitle the remainder of
[PATCH] Document and test LT_DEBUGWRAPPER cwrapper macro
http://lists.gnu.org/archive/html/libtool-patches/2009-06/msg00031.html
as appropriate.
--
Chuck
[PATCH] Add alias for obsoleted AC_LIBTOOL_RC macro.
* libltdl/m4/libtool.m4: Add alias for obsoleted macro AC_LIBTOOL_RC. --- Seems obvious to me, unless this bit m4_ifndef([AC_LIBTOOL_RC], [AC_DEFUN([AC_LIBTOOL_RC])]) should be removed from lt~obsolete.m4. As it is, the following configure.ac is just non-functional: ... AC_LIBTOOL_WIN32_DLL AC_PROG_LIBTOOL AC_LIBTOOL_RC ... because LT_LANG([Windows Resource]) is never called. I ran across this error trying to add support for resources (.rc) files on the cygwin build of xz, where that project is still using libtool-1.5.22 but my development environment is 2.2.7a. OK, with or without an additional change to lt~obsolete.m4? -- Chuck libltdl/m4/libtool.m4 |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4 index 6beb125..0777d4d 100644 --- a/libltdl/m4/libtool.m4 +++ b/libltdl/m4/libtool.m4 @@ -860,6 +860,7 @@ AU_DEFUN([AC_LIBTOOL_CXX], [LT_LANG(C++)]) AU_DEFUN([AC_LIBTOOL_F77], [LT_LANG(Fortran 77)]) AU_DEFUN([AC_LIBTOOL_FC], [LT_LANG(Fortran)]) AU_DEFUN([AC_LIBTOOL_GCJ], [LT_LANG(Java)]) +AU_DEFUN([AC_LIBTOOL_RC], [LT_LANG(Windows Resource)]) dnl aclocal-1.4 backwards compatibility: dnl AC_DEFUN([AC_LIBTOOL_CXX], []) dnl AC_DEFUN([AC_LIBTOOL_F77], []) -- 1.6.3.2
Re: [PATCH] Remove unneeded functions and options from cwrapper
Ralf Wildenhues wrote: * Charles Wilson wrote on Mon, Jun 22, 2009 at 02:07:13AM CEST: Ok to push? OK, thanks. Pushed. -- Chuck
Re: [PATCH] Document and test LT_DEBUGWRAPPER cwrapper macro
Ralf Wildenhues wrote:
* Charles Wilson wrote on Sun, Jun 21, 2009 at 08:25:00PM CEST:
(the shwrapper in .libs/ is intended to be ephemeral, and as an
implementation detail may be deleted after the link is completed.)
Why is it intended to be ephemeral? What do we gain from removing it
besides more implementational complexity through --lt-dump-script?
(This is an honest question. I'm probably just away from the code too
long to know the answer right away. Thanks.)
I guess it *could* stick around. But then you might get into timestamp
issues where the $var replacements in the shwrapper don't match the ones
in the cwrapper...However, for *libtool's* purposes, there's no reason
that the else clause below couldn't be used in all cases.
# note: this script will not be executed, so do not chmod.
if test x$build = x$host ; then
$cwrapper --lt-dump-script $func_ltwrapper_scriptname_result
else
func_emit_wrapper no $func_ltwrapper_scriptname_result
fi
ephemeral or not, you'd still be recreating the .libs/shwrapper every
time, which solves the out-of-sync possibility/problem.
So, in that respect, we could remove --lt-dump-script (although I like
the early warning this gives you on native builds that, for whatever
reason, $cwrapper just can't execute at all, regardless of any issues
with the program executable).
However, .libs/shwrapper is still an internal implementation detail. We
could get rid of it entirely at some point, clobber it after final link,
whatever. The same is NOT true of the wrapper in the $builddir (whether
shell or c). It will be present, if the app links against uninstalled
shared libraries.
However, the cwrapper is inherently fragile in
cross-build-and-run-immediately-from-emulation setups. (Heck,
*everything* is inherently fragile in that situation). So,
--lt-dump-script provides yet another way for the poor end user to
figure out what's going wrong, if something DOES go wrong (when they
can't rely on .libs/some-private-thing).
Thanks for explaining. The paragraph is ok, but the term target
executable is not; in GNU toolchain lingo, target is only relevant
when you create a cross compiler. Please use something like program
executable or so. And I agree with you that the final sentence should
be something like
The wrapper executable then launches the program.
Ack.
I don't like that we document that we have pathlist conversion
functions. (I also have issues with the actual functions, but let's
discuss that in the thread where you posted the patch.) I guess it's
ok to state that we convert paths, but I think we should limit the
documentation to what the user should have to know.
Aside, `$host' looks a bit ugly. The GCC just writes plain `host'; I'm
not sure whether that is sufficiently clear at this point in the Libtool
manual, but using the dollar sign is definitely not the best thing.
Maybe using terms like `host system' or `executable for the host system'
is a better choice?
OK. So, there's nothing factually incorrect about that section I wrote,
but you have issues with whether certain elements should be present in
the docu at all, and other stylistic issues. I can go along with your
recommendations.
but actually I'd just patch the wrapper executable to allow for
debugging at run time, and kill this debug mode. Do we have a
pending patch for this already?
No. I can easily do that; the code is already structured to make that
possible. But isn't this adding another platform-specific behavior? Or
do you want me to add --lt-debug to the shwrapper, as well?
Sure, that would be consistent. Of course, it is an incompatible
change, and requires a NEWS entry.
Ack. I'll revise
http://lists.gnu.org/archive/html/libtool-patches/2009-06/msg00039.html
pending additional review comments in its thread.
+Finally, the wrapper executable supports a number of command line
+options. All of these options are in the @code{--lt-} namespace, and
s/are in the @code{--lt-} namespace/begin with @code{--lt-}/
Ack. However, if we remove --lt-dump-script and do not add --lt-debug,
then the whole section could go away, because there would be no --lt-
options.
So then this part would only be added as part of a patch to add
--lt-debug.
Given that I suspect the --lt-debug change itself will get merged before
the surrounding documentation changes, I'd prefer to just go with that.
That is, keep all the docu changes in the same patch which documents the
cwrapper stuff AND the --lt-debug/LT_DEBUGWRAPPER addendums. Merge the
final --lt-debug patch itself sans docu. Merge the combo docu patch as
revised soon after.
The testsuite additions look ok to me if we keep the -DLT_DEBUGWRAPPER
thing, you could commit them as a separate patch.
...or revise to test explicitly the --lt-debug switch, if you'd prefer
to go that direciton.
Well, what direction do you prefer? Is --lt-debug good enough for you?
I kept them both
Re: [PATCH] Document and test LT_DEBUGWRAPPER cwrapper macro
Ralf Wildenhues wrote:
* Charles Wilson wrote on Fri, Jun 19, 2009 at 07:55:03PM CEST:
Now there has been some reluctance about this patch in the past;
presumably worry about documenting the --lt- options somehow cements
them as an API that must be forever supported
Yes, this is a problem.
(and also perhaps
because the wrapper *script* doesn't support these options, so
why have arg differences between the two wrapper implementations?)
Yes, this is another problem. We should not add to platform specific
semantics more than necessary. As long as the environment variable
flags are not supported everywhere,
they aren't. so, strike one.
or the wrapper is not created for
executables that don't link against uninstalled libraries (are they?),
they aren't. so, strike two.
they should not be documented. Or we even take them out.
Ok, only two strikes. But they're out anyway. I'll post a patch to do so.
Taking them out would be ok with me. If you do it, be sure to do it in
a separate commit so that they can be re-added if/when they are
supported for all uninstalled programs on all systems.
I'll do that first, before revising and reposting the documentation
patch. I still think these env-manipulation features can be useful, but
as they haven't proven so yet, there's no reason to keep them around
just in case. If we need 'em later, they're in the repo.
1) remove all of those bits from the documentation
2) only document the --lt-dump-script option
What should --lt-dump-script be documented for? What use do you
consider this useful for a libtool user?
In some cases (cross-builds, until we get all that straightened out), it
is useful to use a script wrapper itself on $build, to launch the target
(in WINE? remotely?) I know that when the cwrapper.exe is, for whatever
reason, not launching the target, manually doing cwrapper.exe
--lt-dump-script, and then using that script directly, can help debug
problems. Sure, if it happens it means there's a bug in the cwrapper,
OR a misconfiguration in the user's (emulation?) environment, but...how
can you track it down without subdividing the problem a little?
--lt-dump-script helps you do that.
(the shwrapper in .libs/ is intended to be ephemeral, and as an
implementation detail may be deleted after the link is completed.)
I'd consider documenting --lt-dump-script the cementation of a bad API.
This shouldn't be needed by the user, and it encourages more platform-
specific code on the user end.
It's platform-specific *debug* support, for a platform-specific behavior
(the cwrapper). See below vis. runtime debugging.
3) remove all those bits, AND remove their implementation
a) might be troublesome as --lt-dump-script is quite useful,
AND we still use it explicitly within libtool
4) only document the --lt-dump-script-option, AND remove
the implementations of the other --lt- options.
5) Add a blurb to the documentation that --lt- options to
the cwrapper are unstable and subject to change.
6) Add all --lt-* implementations to the wrapper script
7) Add --lt-dump-script implementation to the wrapper script
If changes to this patch must be made, then I lean towards #2 or #5.
#4 might also be ok, since those functions haven't proven useful over
the past year, plus it would shrink the size of ltmain.sh quite a bit.
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -790,8 +790,9 @@ Note that libtool added the necessary run-time path
flag, as well as
@cindex wrapper scripts for programs
@cindex program wrapper scripts
Notice that the executable, @code{hell}, was actually created in the
-...@file{@value{objdir}} subdirectory. Then, a wrapper script was created
-in the current directory.
+...@file{@value{objdir}} subdirectory. Then, a wrapper script (or, on
+certain platforms, a wrapper executable @pxref{Wrapper executables}) was
+created in the current directory.
OK.
@@ -845,6 +846,97 @@ price of being dynamic is eight kilobytes, and the
payoff is about four
kilobytes. So, having a shared @file{libhello} won't be an advantage
until we link it against at least a few more programs.
+...@menu
+* Wrapper executables:: Wrapper executables for certain platforms.
some platforms
Ack.
+...@end menu
+
+...@node Wrapper executables
+...@subsection Wrapper executables for programs
+...@cindex wrapper executables for programs
+...@cindex program wrapper executables
+
+Some platforms, notably those hosted on win32 such as cygwin
Windows (see standards.info for a rationale)
Cygwin
Ack.
+and mingw, use a wrapper executable rather than a wrapper script. It
MinGW
Ack.
+performs the same function, but is necessary so that @code{make}
@command{make}
Ack.
+rules for target executables (whose names end in @code{$(EXEEXT)})
+are satisfied. Recall that the actual target executable is created
+in @value{objdir} as @co...@value{objdir
[PATCH] Remove unneeded functions and options from cwrapper
* libltdl/config/ltmain.m4sh (func_emit_cwrapperexe_src)
[lt_opt_process_env_set]: Remove.
[lt_opt_process_env_prepend]: Remove.
[lt_opt_process_env_append]: Remove.
[lt_split_name_value]: Remove.
[file scope]: Don't declare removed functions. Remove
constants and defines related to eliminated commandline
options.
[main]: Remove code related to eliminated commandline
options --lt-env-set, --lt-env-prepend, --lt-env-append.
---
A fragment arising from the review of
http://lists.gnu.org/archive/html/libtool-patches/2009-06/msg00031.html
The commandline options --lt-env-set, --lt-env-prepend,
and --lt-env-append may be useful in the future, but have not
proven so during the year in which they have been provided
by the cwrapper. Furthermore, these options are not yet
supported by the shell wrapper. Therefore, to eliminate
at least some of the inconsistencies between the two wrapper
implementations, this patch removes them entirely.
This has the added benefit of reducing the code size of
the cwrapper by 15%. There is still some remaining code
that, while functional, looks a little odd now that the
three --lt-env-* options are gone. There will be a followup
patch to add --lt-debug and clean that oddness up a little
bit.
Lightly tested by running tests/demo-shared.test tests/demo-make.test
tests/demo-exec.test, but that sanity check should be sufficient.
Ok to push?
--
Chuck
libltdl/config/ltmain.m4sh | 144
1 files changed, 0 insertions(+), 144 deletions(-)
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 6f44d35..ebd3909 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -2877,10 +2877,6 @@ char *strendzap (char *str, const char *pat);
void lt_fatal (const char *message, ...);
void lt_setenv (const char *name, const char *value);
char *lt_extend_str (const char *orig_value, const char *add, int to_end);
-void lt_opt_process_env_set (const char *arg);
-void lt_opt_process_env_prepend (const char *arg);
-void lt_opt_process_env_append (const char *arg);
-int lt_split_name_value (const char *arg, char** name, char** value);
void lt_update_exe_path (const char *name, const char *value);
void lt_update_lib_path (const char *name, const char *value);
char **prepare_spawn (char **argv);
@@ -2937,18 +2933,6 @@ static const char *ltwrapper_option_prefix =
LTWRAPPER_OPTION_PREFIX;
static const char *dumpscript_opt = LTWRAPPER_OPTION_PREFIX
dump-script;
-static const size_t env_set_opt_len = LTWRAPPER_OPTION_PREFIX_LENGTH + 7;
-static const char *env_set_opt = LTWRAPPER_OPTION_PREFIX env-set;
- /* argument is putenv-style foo=bar, value of foo is set to bar */
-
-static const size_t env_prepend_opt_len = LTWRAPPER_OPTION_PREFIX_LENGTH + 11;
-static const char *env_prepend_opt = LTWRAPPER_OPTION_PREFIX
env-prepend;
- /* argument is putenv-style foo=bar, new value of foo is bar${foo} */
-
-static const size_t env_append_opt_len = LTWRAPPER_OPTION_PREFIX_LENGTH + 10;
-static const char *env_append_opt = LTWRAPPER_OPTION_PREFIX env-append;
- /* argument is putenv-style foo=bar, new value of foo is ${foo}bar */
-
int
main (int argc, char *argv[])
{
@@ -3073,51 +3057,6 @@ EOF
newargc=0;
for (i = 1; i argc; i++)
{
- if (strncmp (argv[i], env_set_opt, env_set_opt_len) == 0)
-{
- if (argv[i][env_set_opt_len] == '=')
-{
- const char *p = argv[i] + env_set_opt_len + 1;
- lt_opt_process_env_set (p);
-}
- else if (argv[i][env_set_opt_len] == '\0' i + 1 argc)
-{
- lt_opt_process_env_set (argv[++i]); /* don't copy */
-}
- else
-lt_fatal (%s missing required argument, env_set_opt);
- continue;
-}
- if (strncmp (argv[i], env_prepend_opt, env_prepend_opt_len) == 0)
-{
- if (argv[i][env_prepend_opt_len] == '=')
-{
- const char *p = argv[i] + env_prepend_opt_len + 1;
- lt_opt_process_env_prepend (p);
-}
- else if (argv[i][env_prepend_opt_len] == '\0' i + 1 argc)
-{
- lt_opt_process_env_prepend (argv[++i]); /* don't copy */
-}
- else
-lt_fatal (%s missing required argument, env_prepend_opt);
- continue;
-}
- if (strncmp (argv[i], env_append_opt, env_append_opt_len) == 0)
-{
- if (argv[i][env_append_opt_len] == '=')
-{
- const char *p = argv[i] + env_append_opt_len + 1;
- lt_opt_process_env_append (p);
-}
- else if (argv[i][env_append_opt_len] == '\0' i + 1 argc)
-{
- lt_opt_process_env_append (argv[++i]); /* don't copy */
-}
- else
-lt_fatal (%s missing required argument, env_append_opt);
- continue;
-}
Re: [PATCH] Ensure LT_PATH_LD works when called before LT_INIT
Ralf Wildenhues wrote: * Charles Wilson wrote on Fri, Jun 19, 2009 at 07:33:22PM CEST: * libltdl/m4/libtool.m4 (LT_PATH_LD): AC_REQUIRE _LT_PROG_ECHO_BACKSLASH. Original patch by Yaakov Selkowitz. As he explained: This patch seems like an obvious fix to me. Ok to push? Yes, thank you. Can you either make Yaakov --author of this patch, with a (tiny change) note, or credit him in the log entry? In my repo, he is already listed as the author (I'm listed as --signed-off). I didn't have the (tiny change) notation tho. I'll add that before pushing. -- Chuck
Re: [PATCH] Ensure LT_PATH_LD works when called before LT_INIT
Charles Wilson wrote: In my repo, he is already listed as the author (I'm listed as --signed-off). I didn't have the (tiny change) notation tho. I'll add that before pushing. Pushed. -- Chuck
[PATCH] [cygwin|mingw] fix dlpreopen with --disable-static take 6
* libltdl/config/general.m4sh: Update copyright year.
(func_tr_sh): New function.
* libltdl/config/ltmain.m4sh (func_generate_dlsyms) [cygwin|mingw]:
Obtain DLL name corresponding to import library by using value
stored in unique variable libfile_$(transliterated implib name).
If that fails, use $sharedlib_from_linklib_cmd to extract DLL
name from import library directly. Also, properly extract dlsyms
from the import library.
(func_mode_link) [cygwin|mingw]: Prefer to dlpreopen DLLs
over static libs when both are available. When dlpreopening
DLLs, use linklib (that is, import lib) as dlpreopen file,
rather than DLL. Store name of associated la file in
unique variable libfile_$(transliterated implib name)
for later use.
(func_win32_libid): Accomodate pei-i386 import libs
as well as pe-i386.
(func_cygming_dll_for_implib): New function.
(func_cygming_dll_for_implib_fallback): New function.
(func_cygming_dll_for_implib_fallback_core): New function.
(func_cygming_gnu_implib_p): New function.
(func_cygming_ms_implib_p): New function.
* libltdl/m4/libtool.m4 (_LT_CMD_GLOBAL_SYMBOLS): Adjust sed
expressions for lt_cv_sys_global_symbol_to_c_name_address and
lt_cv_sys_global_symbol_to_c_name_address_lib_prefix
as trailing space after module name is optional.
(_LT_LINKER_SHLIBS) [cygwin|mingw][C++]:
Set exclude_expsyms correctly for $host. Simplify regular
expression in export_symbols_cmds.
(_LT_LINKER_SHLIBS) [cygwin|mingw|pw32][C]: Set exclude_expsyms
correctly for $host. Enable export_symbols_cmds to identify
DATA exports by _nm_ prefix.
(_LT_CHECK_SHAREDLIB_FROM_LINKLIB): New macro sets
sharedlib_from_linklib_cmd variable.
(_LT_DECL_DLLTOOL): New macro ensures DLLTOOL is always set.
---
Reposted without change from -take5, here:
http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg00232.html
This patch has been in use in the cygwin distribution since 2009-02-20.
libltdl/config/general.m4sh | 19 -
libltdl/config/ltmain.m4sh | 226 +++
libltdl/m4/libtool.m4 | 62 +++-
3 files changed, 282 insertions(+), 25 deletions(-)
diff --git a/libltdl/config/general.m4sh b/libltdl/config/general.m4sh
index 4bc304c..e839070 100644
--- a/libltdl/config/general.m4sh
+++ b/libltdl/config/general.m4sh
@@ -1,6 +1,6 @@
m4_if([general.m4sh -- general shell script boiler plate -*- Autoconf -*-
- Copyright (C) 2004, 2005, 2007, 2008 Free Software Foundation, Inc.
+ Copyright (C) 2004, 2005, 2007, 2008, 2009 Free Software Foundation, Inc.
Written by Gary V. Vaughan, 2004
This file is part of GNU Cvs-utils.
@@ -412,5 +412,22 @@ func_show_eval_locale ()
fi
fi
}
+
+# func_tr_sh
+# Turn $1 into a string suitable for a shell variable name.
+# Result is stored in $func_tr_sh_result. All characters
+# not in the set a-zA-Z0-9_ are replaced with '_'. Further,
+# if $1 begins with a digit, a '_' is prepended as well.
+func_tr_sh ()
+{
+ case $1 in
+ [0-9]* | *[!a-zA-Z0-9_]*)
+func_tr_sh_result=`$ECHO $1 | $SED 's/^\([0-9]\)/_\1/;
s/[^a-zA-Z0-9_]/_/g'`
+;;
+ * )
+func_tr_sh_result=$1
+;;
+ esac
+}
]])
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 6f44d35..9353376 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -2007,10 +2007,49 @@ extern \C\ {
func_verbose extracting global C symbols from \`$dlprefile'
func_basename $dlprefile
name=$func_basename_result
- $opt_dry_run || {
- eval '$ECHO : $name $nlist'
- eval $NM $dlprefile 2/dev/null | $global_symbol_pipe '$nlist'
- }
+ case $host in
+ *cygwin* | *mingw* | *cegcc* )
+ # if an import library, we need to obtain dlname
+ if func_win32_import_lib_p $dlprefile; then
+ func_tr_sh $dlprefile
+ eval curr_lafile=\$libfile_$func_tr_sh_result
+ dlprefile_dlbasename=
+ if test -n $curr_lafile func_lalib_p $curr_lafile; then
+ # Use subshell, to avoid clobbering current variable values
+ dlprefile_dlname=`source $curr_lafile echo $dlname`
+ if test -n $dlprefile_dlname ; then
+ func_basename $dlprefile_dlname
+ dlprefile_dlbasename=$func_basename_result
+ else
+ # no lafile. user explicitly requested -dlpreopen import
library.
+ eval '$sharedlib_from_linklib $dlprefile'
+ dlprefile_dlbasename=$sharedlib_from_linklib_result
+ fi
+ fi
+ $opt_dry_run || {
+ if test -n $dlprefile_dlbasename ; then
+ eval '$ECHO : $dlprefile_dlbasename $nlist'
+ else
+ func_warning Could not compute DLL name from $name
+ eval '$ECHO : $name $nlist'
+ fi
+ eval
[PATCH] [cygwin]: Add cross-compile support to cwrapper take 5
* libltdl/config/general.m4sh: Update copyright year. (func_tr_sh): New function. * libltdl/config/ltmain.m4sh (func_generate_dlsyms) [cygwin|mingw]: Obtain DLL name corresponding to import library by using value stored in unique variable libfile_$(transliterated implib name). If that fails, use $sharedlib_from_linklib_cmd to extract DLL name from import library directly. Also, properly extract dlsyms from the import library. (func_mode_link) [cygwin|mingw]: Prefer to dlpreopen DLLs over static libs when both are available. When dlpreopening DLLs, use linklib (that is, import lib) as dlpreopen file, rather than DLL. Store name of associated la file in unique variable libfile_$(transliterated implib name) for later use. (func_win32_libid): Accomodate pei-i386 import libs as well as pe-i386. (func_cygming_dll_for_implib): New function. (func_cygming_dll_for_implib_fallback): New function. (func_cygming_dll_for_implib_fallback_core): New function. (func_cygming_gnu_implib_p): New function. (func_cygming_ms_implib_p): New function. * libltdl/m4/libtool.m4 (_LT_CMD_GLOBAL_SYMBOLS): Adjust sed expressions for lt_cv_sys_global_symbol_to_c_name_address and lt_cv_sys_global_symbol_to_c_name_address_lib_prefix as trailing space after module name is optional. (_LT_LINKER_SHLIBS) [cygwin|mingw][C++]: Set exclude_expsyms correctly for $host. Simplify regular expression in export_symbols_cmds. (_LT_LINKER_SHLIBS) [cygwin|mingw|pw32][C]: Set exclude_expsyms correctly for $host. Enable export_symbols_cmds to identify DATA exports by _nm_ prefix. (_LT_CHECK_SHAREDLIB_FROM_LINKLIB): New macro sets sharedlib_from_linklib_cmd variable. (_LT_DECL_DLLTOOL): New macro ensures DLLTOOL is always set. -- This is a repost of the take 4 patch originally posted here: http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg00232.html This patch has been in use in the cygwin distribution since 2009-02-20. I've rewritten the original patch notes from -take1...-take4, so that a more coherent story can be told, for folks just joining this thread or who have forgotten all the surrounding context... Another good summary (if I do say so myself) of the problem, and history, that the attached patch addresses can be found here: [CFT] libtool on nix-cygwin cross, with wine http://www.cygwin.com/ml/cygwin/2009-02/msg00555.html (Ignore the rest of the thread; there was not a single on-topic reply.) Definition: works, or for the cwrapper to work properly in this context means that you can, from the $build environment, execute the cwrapper program, and eventually the actual target executable will be successfully launched. In all known cases involving the cwrapper (e.g $host is win32-related -- except maybe cegcc but that's another issue), *compiling* in a cross environment with those $hosts always works just fine. It's launching the uninstalled target executables that is at issue throughout this post. Unix - mingw cross builds need special support when creating the cwrapper source code in order for the cwrapper to work properly under the wine environment. This was originally described here: http://lists.gnu.org/archive/html/libtool-patches/2008-04/msg00164.html (that patch is already part of libtool, in a modified form). However, the full explanation is: 1) On win32 $host we need an executable wrapper, rather than the normal shell script wrapper, for dynamically linked executables. This is because the automake rules' target is foo$(EXEEXT). a) it is a bad idea to lie to win32 OS by naming a file that is NOT a PE/COFF executable foo.exe so we can't just rename foo (the shell script) as foo.exe. So, because we need to support native builds on cygwin, mingw, and friends, we have to care about this case, and not simply emit the shell wrapper as foo$(EXEEXT). 2) We have long had this cwrapper. It used to coexist in the same directory with the shell script wrapper. The cwrapper would exec the shell wrapper, which did all the work, and then launched the actual target. a) This doesn't work for cygwin-1.5 where CYGWIN variable contains the flag transparent_exe. Since transparent_exe is now the default behavior for cygwin-1.7 (due to be released within 2 wks) this foo + foo.exe in same directory will very shortly be broken. b) So, a year or so ago, the cwrapper was modified to do all the work itself (setting PATH/LD_LIBRARY_PATH, etc), and to directly invoke the target. Similarly, libtool no longer creates the shell wrapper with the target's name (there is still a shell wrapper on these $hosts, but it goes in .libs/ and is named ltshwrapper_foo. This was the original goal, anyway, because it's just kinda silly to have two levels of wrappers to get to the target exe. c) One wrinkle: the cwrapper is a $host executable, not a $build one. So, for instance when $host=$mingw, the
Re: [PATCH] [cygwin]: Add cross-compile support to cwrapper take 5
Charles Wilson wrote: ... a long correct message but with the wrong changelog. sorry. Here's the correct changelog. - Refactor cwrapper cross-compile support; Add cygwin. * libltdl/m4/libtool.m4 (_LT_PATH_CONVERSION_FUNCTIONS): New function sets libtool variable $to_host_path_cmd, and employs cache. AC_SUBSTs $to_host_path_cmd, as well. (_LT_SETUP): Require it. * tests/testsuite.at: Ensure to_host_path_cmd is passed as a variable setting on the configure line for (new testsuite) tests. * Makefile.am: Ensure to_host_path_cmd is included in TEST_ENVIRONMENT so that it is passed to (old testsuite) tests. * libltdl/config/ltmain.m4sh (func_cygpath): New function. (func_init_to_host_pathlist_cmd): New function. (func_to_host_path): Refactored to... (now uses eval $to_host_path_cmd). (func_wine_to_win32_path): Here. New function. (func_msys_to_win32): Here. New function. (func_path_convert_check): Here. New function. (func_noop_path_convert): Here. New function. (func_msys_to_mingw_path_convert): Here. New function. (func_cygwin_to_mingw_path_convert): Here. New function. (func_nix_to_mingw_path_convert): Here. New function. (func_msys_to_cygwin_path_convert): New function. (func_nix_to_cygwin_path_convert): New function. (func_to_host_pathlist): Refactored to... (now uses eval $to_host_pathlist_cmd and func_init_to_host_pathlist_cmd). (func_pathlist_convert_check): Here. New function. (func_pathlist_front_back_pathsep): Here. New function. (func_wine_to_win32_pathlist): Here. New function. (func_noop_pathlist_convert): Here. New function. (func_msys_to_mingw_pathlist_convert): Here. New function. (func_cygwin_to_mingw_pathlist_convert): Here. New function. (func_nix_to_mingw_pathlist_convert): Here. New function. (func_msys_to_cygwin_pathlist_convert): New function. (func_nix_to_cygwin_pathlist_convert): New function.
[PATCH] Improve compatibility with older automake
* libltdl/m4/lt~obsolete.m4: Add AC_DEFUNs for _LT_PREPARE_SED_QUOTE_VARS and _LT_PROG_ECHO_BACKSLASH. Report by Yaakov Selkowitz. aclocal-1.8 and older fail: aclocal: macro `_LT_PREPARE_SED_QUOTE_VARS' required but not defined aclocal: macro `_LT_PROG_ECHO_BACKSLASH' required but not defined autoreconf-2.63: aclocal failed with exit status: 1 Tested by running aclocal-1.8 successfully, but didn't do a full bootstrap. Still, the fix seems obvious...okay to push? Chuck --- libltdl/m4/lt~obsolete.m4 |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/libltdl/m4/lt~obsolete.m4 b/libltdl/m4/lt~obsolete.m4 index b60bbd2..5f6a956 100644 --- a/libltdl/m4/lt~obsolete.m4 +++ b/libltdl/m4/lt~obsolete.m4 @@ -92,3 +92,5 @@ m4_ifndef([AC_LIBTOOL_CONFIG], [AC_DEFUN([AC_LIBTOOL_CONFIG])]) m4_ifndef([_LT_AC_FILE_LTDLL_C], [AC_DEFUN([_LT_AC_FILE_LTDLL_C])]) m4_ifndef([_LT_REQUIRED_DARWIN_CHECKS], [AC_DEFUN([_LT_REQUIRED_DARWIN_CHECKS])]) m4_ifndef([_LT_AC_PROG_CXXCPP], [AC_DEFUN([_LT_AC_PROG_CXXCPP])]) +m4_ifndef([_LT_PREPARE_SED_QUOTE_VARS], [AC_DEFUN([_LT_PREPARE_SED_QUOTE_VARS])]) +m4_ifndef([_LT_PROG_ECHO_BACKSLASH], [AC_DEFUN([_LT_PROG_ECHO_BACKSLASH])]) -- 1.6.1.2
[PATCH] Use correct export_dynamic_flag_spec for PE-COFF $hosts
* libltdl/m4/libtool.m4 (_LT_LINKER_SHLIBS) [cygwin*|mingw*|pw32*|cegcc*]:
Define export_dynamic_flag_spec as -Wl,--export-all-symbols, as required
by GNU ld for PE-COFF.
Original patch by Yaakov Selkowitz. As he explained:
On Cygwin, the --export-all-symbols linker flag is required;
--export-dynamic has no effect
(see http://sourceware.org/bugzilla/show_bug.cgi?id=6744).
This patch fixes two problems:
(1) LT_SYS_DLOPEN_SELF returns a false negative;
(2) Using the -export-dynamic libtool flag does not affect the
resulting binary.
Tested in combination with several other cygwin patches, as part of the
recent cygwin official 2.2.7a-N libtool release(s):
http://cygwin.com/ml/cygwin-announce/2009-03/msg00080.html
http://cygwin.com/ml/cygwin-announce/2009-03/msg00081.html
No regressions. Okay to push?
---
libltdl/m4/libtool.m4 |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 477f6e3..15612c0 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -4275,6 +4275,7 @@ _LT_EOF
# _LT_TAGVAR(hardcode_libdir_flag_spec, $1) is actually meaningless,
# as there is no search path for DLLs.
_LT_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir'
+ _LT_TAGVAR(export_dynamic_flag_spec, $1)='${wl}--export-all-symbols'
_LT_TAGVAR(allow_undefined_flag, $1)=unsupported
_LT_TAGVAR(always_export_symbols, $1)=no
_LT_TAGVAR(enable_shared_with_static_runtimes, $1)=yes
--
1.6.1.2
[PATCH] [cygwin] Improve operation with gcc4
* libltdl/m4/libtool.m4 (_LT_SYS_DYNAMIC_LINKER) [cygwin*]:
Add w32api to sys_lib_search_path_spec without overriding gcc's
own search path.
Original patch by Yaakov Selkowitz. As he explained:
With gcc4 providing shared libs, it should now perfectly legitimate to
add any of these libs to the libtool link command. Right now, though,
libtool can't find these libraries because $sys_lib_search_path_spec is
hard-coded to ignore it, and libtool will refuse to link against any
library it can't find (even though the linker itself can).
Instead, this patch simply adds /usr/lib/w32api to the default
gcc-specific search path. The m4_if() makes sure that w32api is added
only once, as is done with Darwin a few lines later.
Tested in combination with several other cygwin patches, as part of the
recent cygwin official 2.2.7a-N libtool release(s):
http://cygwin.com/ml/cygwin-announce/2009-03/msg00080.html
http://cygwin.com/ml/cygwin-announce/2009-03/msg00081.html
No regressions. Okay to push?
---
libltdl/m4/libtool.m4 |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 15612c0..63e831e 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -2156,7 +2156,8 @@ cygwin* | mingw* | pw32* | cegcc*)
cygwin*)
# Cygwin DLLs use 'cyg' prefix rather than 'lib'
soname_spec='`echo ${libname} | sed -e 's/^lib/cyg/'``echo ${release} |
$SED -e 's/[[.]]/-/g'`${versuffix}${shared_ext}'
- sys_lib_search_path_spec=/usr/lib /lib/w32api /lib /usr/local/lib
+m4_if([$1], [],[
+ sys_lib_search_path_spec=$sys_lib_search_path_spec /usr/lib/w32api])
;;
mingw* | cegcc*)
# MinGW DLLs use traditional 'lib' prefix
--
1.6.1.2
Re: [PATCH] Use correct export_dynamic_flag_spec for PE-COFF $hosts
Bob Friesenhahn wrote: No regressions. Okay to push? If you are sure that --export-all-symbols will work with older (within reason) Cygwin and MinGW installs, then this seems ok to push. I do see support for --export-all-symbols in my archaic MinGW install so the risk of problems seems low. auto-export was added more than 10 years ago: Mon Nov 9 16:41:30 1998 DJ Delorie ... * emultempl/pe.em (gld_i386_list_options): list dll-specific options. * pe-dll.c (process_def_file): auto-export everything if nothing is otherwise exported. and IIRC --export-all-symbols was part of that addition. I know I updated the (scanty, at the time) documentation for --export-all-symbols in 2001: 2001-08-02 Charles Wilson ... * ld.texinfo: add additional documentation for --export-all-symbols. Document --out-implib, --enable-auto-image-base, --disable-auto-image-base, --dll-search-prefix, --enable-auto-import, and --disable-auto-import. * ldint.texinfo: Add detailed documentation on auto-import implementation. So I think we're good... -- Chuck
Re: [PATCH] Improve compatibility with older automake
Bob Friesenhahn wrote: Tested by running aclocal-1.8 successfully, but didn't do a full bootstrap. Still, the fix seems obvious...okay to push? Since the fix seems obvious, please do. Pushed. -- Chuck
Re: FYI: latest official cygwin libtool
Peter Rosin wrote: Den 2009-02-24 04:04 skrev Charles Wilson: 01-fix-dlpreopen-with-disable-static.patch 02-refactor-cwrapper-cross-compile-and-add-cygwin.patch 03-document-and-test-cwrapper-macro.patch 04-pr-dumpbin-link-support.patch 05-pr-lib-prefix-for-archive-name-ltdl.patch 06-pr-preload-heed-libname_spec.patch 07-pr-add-func_to_tool_path.patch 08-pr-use-LT_AR-internally-and-convert-filenames-to-host-format.patch 09-pr-allow-ms-lib-archiver.patch You did notice that [3] use-LT_AR... depends on [1] allow-ms-lib..., so why did you not cherry-pick them (or whatever you did) in that order? Because I'm not a git whiz. I didn't cherry pick them, and when I attempted to create a topic branch to merge all these changes, I seriously hosed it, and got a ton of changes I didn't want. So, I explicitly (and manually) created patches from the commits I wanted: git diff rev1..rev2 And then manually merged them into a new topic branch. Then committing them to that branch. So, the only way I noticed that 08-pr-use-LT_AR needed 09-pr-allow-ms, was after I had manually merged 08-, my branch was broken. I figured out why, found the appropriate patch (e.g. single commit) that fixed the issue, and manually applied that patch to my topic branch. I guess I could've THEN done a rebase -i, and reordered the commits. But I didn't. You have also included some bits of [2] libtool-ar in your use-LT_AR... commit, but not all of it, which seems like a mistake since [3] depends on [2] as well. As is, I don't expect use-LT_AR... to work as I intended... I was afraid of that. I *thought* -- but was wrong -- that ALL of the pr-ms patches were independent and consisted of a single commit on their individual topic branch, so that I could just pick the ones I thought (a) wouldn't break cygwin/mingw native, (b) were relatively easy to (manually) merge, and (c) had significant interaction with my re-re-re-re-re-revised pending patches, such that they *needed* to be harmonized. Under those assumptions, then picking 5 (or 6, as it turned out) of your patches and doing a little janitor/harmonization work on them would (a) help you, (b) not break anything, and (c) incrementally add some functionality -- even if untested in my build. And then I discovered that the patches were not so independent, after all (08- vs. 09-). But, I'd come far enough -- and cygwin passed all of ITS regressions after a solid WEEK [*] of testing -- that I didn't want to revert them and release cygwin with only my three patches, nor did I want to let my janitor/harmonization efforts disappear into the aether. So, I went with what I had (even it it added only partial, and maybe -- as you point out -- /broken/ -- new functionality; since the cygwin build doesn't USE that new functionality, it didn't matter. [*] Not libtool's fault, this time. I got hit by the dreaded perl fork failure: can't remap DLL in child to same address as in parent problem. Ugh. See http://cygwin.com/ml/cygwin/2009-02/msg00488.html. Your resulting code is e.g. in some cases setting LT_AR to: LT_AR='$(SHELL) $(top_builddir)/libtool --quiet --mode=ar' but your libtool script does not support --mode=ar Yep. The patches/commits weren't quite as independent as I thought, and some that I pseudo-cherry-picked depended on others that I didn't. However, I'm not sure it is a wise thing to feed --mode=ar to the wilderness without an ok on the interface from at least one libtool maintainer? Meh. Cygwin doesn't use it, and it's broken so nobody will actually be ABLE to use it, so I might get some complaints on the cygwin list. But I doubt any of those complaints will show up on this list; and if they do, just blame me for pushing untested patches into the wild and tell the OP to check the real pr-msvc branch if they're really interested. Note that I made a mistake when I commited [2]. It was never intended to go into the pr-msvc-support branch without the above ok [4]. Oh. Didn't realize that. And the 07- patch seems to break ordinary crosses. Well now, that /would/ be bad. My version assumed that the toolchain is an ordinary cross toolchain which understands $build paths, except in cases where it knows it doesn't (i.e. $host=mingw, $build=mingw). Your version assumes that the toolchain is not ordinary, but instead one that understands $host paths (at least when $host is mingw or cygwin). That wasn't my intent. I was attempting to add the caching behavior (which, because of autoconf limitations, requires a whole separate case...esac tree from the to_host_path_cmd tree: you can't cache two different variables at once). But I hoped that, while using the different m4 code structure, the behavior stayed the same as yours. However, because I didn't pseudo-cherry-pick the patch which actually USES the new func_to_tool_path function...I didn't actually *break* anything in my build. But I can see that if you accepted my 07- patch, it would break your pre
FYI: latest official cygwin libtool
I've updated cygwin's libtool packages, using git master at 2009-02-16 21:59:34 +0100 from git revision 9e9ba5e0e2c0b3f33ee44081c5bc3f0b8991aebd (Do not pass $INSTALL via TESTS_ENVIRONMENT.), plus a sequence of patches. I'm posting these mostly for Peter's benefit, as I included some (but not all) of his pr-msvc patches -- but had to revise some of them (esp. add-func_to_tool_path) a bit. Peter, you might want to look at 07-pr-add-func_to_tool_path.patch and 08-pr-use-LT_AR-... Also, I found that 08-pr doesn't work standalone; it requires 09-pr-allow-ms-lib-archiver.patch or you get build errors. 01-fix-dlpreopen-with-disable-static.patch 02-refactor-cwrapper-cross-compile-and-add-cygwin.patch 03-document-and-test-cwrapper-macro.patch 04-pr-dumpbin-link-support.patch 05-pr-lib-prefix-for-archive-name-ltdl.patch 06-pr-preload-heed-libname_spec.patch 07-pr-add-func_to_tool_path.patch 08-pr-use-LT_AR-internally-and-convert-filenames-to-host-format.patch 09-pr-allow-ms-lib-archiver.patch Note that 01-, 02-, and 03- have already appeared on this list in the exact form included. The 0x-pr patches...probably not so much, because of ripple effects from the first three, but I'll leave that to Peter to sort out. g. While my build was cygwin native (that is, I didn't exercise much of the pr-msvc code), it passed all regressions on both cygwin-1.5 and cygwin-1.7 -- so the pr-patches do no harm. I'm going to ask (on the cygwin list) for some test reports by folks who routinely use unix-cygwin cross environments, so maybe we'll get a little in the wild feedback about 02-refactor-cwrapper-cross-compile-and-add-cygwin.patch. -- Chuck 2008-08-02 Peter Rosin ... Allow Microsoft lib to be used as the archiver. * libltdl/m4/libtool.m4: Add $AR_SEP between $AR_FLAGS and the archive file name in all $AR commands. (_LT_CMD_OLD_ARCHIVE): Use _LT_PROG_AR to find archiver, not AC_CHECK_TOOL. * libltdl/config/ltmain.m4sh (func_extract_an_archive): Add support for archivers that only supports extracting one member at a time and otherwise adjust to the above libtool.m4 changes. Also, add $AR_SEP to the $AR invocations. * Makefile.am: Pass AR, AR_FLAGS and AR_SEP through to the testsuite. * tests/archive-in-archive.at: Extract archive name from the .la file instead of hardcoding the name, and allow different archivers. 2009-01-26 Peter Rosin ... Use LT_AR internally and convert archive file to host format * libltdl/m4/libtool.m4 (_LT_PROG_AR): Export LT_AR and LT_ARFLAGS to the libtool script. (_LT_CMD_OLD_ARCHIVE): Make sure they are used. * libltdl/config/ltmain.m4sh (func_mode_ar): Convert the filename of the archive to host format (MSYS fails to convert paths that are prefixed the -out: in arguments). Makes stresstest.at go a bit further on MSYS/MSVC. 2009-01-31 Peter Rosin ... Add func_to_tool_path. * libltdl/config/ltmain.m4sh (func_to_tool_path): New function. * libltdl/m4/libtool.m4 (_LT_PATH_CONVERSION_FUNCTIONS): Add libtool variable $to_tool_path_cmd, and AC_SUBST it. * Makefile.am: Ensure to_tool_path_cmd is included in TEST_ENVIRONMENT so that it is passed to (old testsuite) tests. * tests/testsuite.at: Ensure to_tool_path_cmd is passed as a variable setting on the configure line for (new testsuite) tests. 2008-11-24 Peter Rosin ... Make preloading heed libname_spec. * libltdl/ltdl.c (libprefix): New static variable describing the prefix of static archives. (try_dlopen): Use libprefix. * libltdl/m4/ltdl.m4 (_LTDL_SETUP): Export prefix of static archives to config.h. 2009-01-26 Peter Rosin ... Add lib prefix to archive name if needed in symbol list. * libltdl/m4/libtool.m4 (_LT_CMD_GLOBAL_SYMBOLS): When lib prefix is required, add it - if needed - to the module name as well to match what is done to the symbol that is looked up. 2009-01-26 Peter Rosin ... Don't settle for any dumpbin/link program as name lister. * libltdl/m4/libtool.m4 (LT_PATH_NM): When locating dumpbin or link -dump, check if they appear to really be capable of name listing, in order to eliminate e.g. link from coreutils. This makes the name lister decision fall back on nm as the default if no acceptable candidate is found. * THANKS: Update Reports by Rudolf Leitgeb and Peter Kjellerstedt. 2009-02-17 Charles Wilson ... Document and test LT_DEBUGWRAPPER cwrapper macro * tests/cwrapper.test: Add new test for -DLT_DEBUGWRAPPER. * doc/libtool.texi [Linking executables]: Mention wrapper executables, in addition to wrapper scripts. Add menu referencing subsection 'Wrapper executables for programs'. [Wrapper
Re: [PATCH] [cygwin|mingw] fix dlpreopen with --disable-static take 4
Charles Wilson wrote: The attached, re-re-re-re-revised patch addresses these two issues, but is otherwise the same as take 4. Ping. Most recent version is the take 5 attachment, in this message from two weeks ago: http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg00232.html ChangeLog repeated (with slight revisions) for convenience: * libltdl/config/general.m4sh: Update copyright year. (func_tr_sh): New function. * libltdl/config/ltmain.m4sh (func_generate_dlsyms) [cygwin|mingw]: Obtain DLL name corresponding to import library by using value stored in unique variable libfile_$(transliterated implib name). If that fails, use $sharedlib_from_linklib_cmd to extract DLL name from import library directly. Also, properly extract dlsyms from the import library. (func_mode_link) [cygwin|mingw]: Prefer to dlpreopen DLLs over static libs when both are available. When dlpreopening DLLs, use linklib (that is, import lib) as dlpreopen file, rather than DLL. Store name of associated la file in unique variable libfile_$(transliterated implib name) for later use. (func_win32_libid): Accomodate pei-i386 import libs as well as pe-i386. (func_cygming_dll_for_implib): New function. (func_cygming_dll_for_implib_fallback): New function. (func_cygming_dll_for_implib_fallback_core): New function. (func_cygming_gnu_implib_p): New function. (func_cygming_ms_implib_p): New function. * libltdl/m4/libtool.m4 (_LT_CMD_GLOBAL_SYMBOLS): Adjust sed expressions for lt_cv_sys_global_symbol_to_c_name_address and lt_cv_sys_global_symbol_to_c_name_address_lib_prefix as trailing space after module name is optional. (_LT_LINKER_SHLIBS) [cygwin|mingw][C++]: Set exclude_expsyms correctly for $host. Simplify regular expression in export_symbols_cmds. (_LT_LINKER_SHLIBS) [cygwin|mingw|pw32][C]: Set exclude_expsyms correctly for $host. Enable export_symbols_cmds to identify DATA exports by _nm_ prefix. (_LT_CHECK_SHAREDLIB_FROM_LINKLIB): New macro sets sharedlib_from_linklib_cmd variable. (_LT_DECL_DLLTOOL): New macro ensures DLLTOOL is always set. -- Chuck
Re: [PATCH] [cygwin]: Add cross-compile support to cwrapper
Charles Wilson wrote:
Charles Wilson wrote:
How does that sound, as an intermediate plan?
Implemented as attached, which should be applied on top of the -take3 patch.
Ping?
The attached represents the combination of -take3
http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg00233.html
ChangeLog for that piece is here:
http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg00163.html
And the followup *addendum* patch, with an associated pseudo-changelog:
http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg00238.html
These two *could* be reviewed separately, if that is preferable. Or,
just look at the attached combo patch.
ChangeLog (for combo patch)
libltdl/m4/libtool.m4 (_LT_PATH_CONVERSION_FUNCTIONS): New
function sets libtool variable $to_host_path_cmd, and employs
cache. AC_SUBSTs $to_host_path_cmd, as well.
(_LT_SETUP): Require it.
tests/testsuite.at: Ensure to_host_path_cmd is passed as a
variable setting on the configure line for (new testsuite) tests.
Makefile.am: Ensure to_host_path_cmd is included in
TEST_ENVIRONMENT so that it is passed to (old testsuite) tests.
libltdl/config/ltmain.m4sh (func_cygpath): New function.
(func_init_to_host_pathlist_cmd): New function.
(func_to_host_path): Refactored to... (now uses eval
$to_host_path_cmd).
(func_wine_to_win32_path): Here. New function.
(func_msys_to_win32): Here. New function.
(func_path_convert_check): Here. New function.
(func_noop_path_convert): Here. New function.
(func_msys_to_mingw_path_convert): Here. New function.
(func_cygwin_to_mingw_path_convert): Here. New function.
(func_nix_to_mingw_path_convert): Here. New function.
(func_msys_to_cygwin_path_convert): New function.
(func_nix_to_cygwin_path_convert): New function.
(func_to_host_pathlist): Refactored to... (now uses eval
$to_host_pathlist_cmd and func_init_to_host_pathlist_cmd).
(func_pathlist_convert_check): Here. New function.
(func_pathlist_front_back_pathsep): Here. New function.
(func_wine_to_win32_pathlist): Here. New function.
(func_noop_pathlist_convert): Here. New function.
(func_msys_to_mingw_pathlist_convert): Here. New function.
(func_cygwin_to_mingw_pathlist_convert): Here. New function.
(func_nix_to_mingw_pathlist_convert): Here. New function.
(func_msys_to_cygwin_pathlist_convert): New function.
(func_nix_to_cygwin_pathlist_convert): New function.
diff --git a/Makefile.am b/Makefile.am
index 574147d..9cd1628 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -507,7 +507,8 @@ TESTS_ENVIRONMENT = MAKE=$(MAKE) CC=$(CC)
CFLAGS=$(CFLAGS) \
CXX=$(CXX) CXXFLAGS=$(CXXFLAGS) CXXCPP=$(CXXCPP) \
F77=$(F77) FFLAGS=$(FFLAGS) \
FC=$(FC) FCFLAGS=$(FCFLAGS) \
- GCJ=$(GCJ) GCJFLAGS=$(GCJFLAGS)
+ GCJ=$(GCJ) GCJFLAGS=$(GCJFLAGS) \
+ lt_cv_to_host_path_cmd=$(to_host_path_cmd)
BUILDCHECK_ENVIRONMENT = _lt_pkgdatadir=$(abs_top_srcdir) \
LIBTOOLIZE=$(abs_top_builddir)/libtoolize \
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 49e07c3..d362d73 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -2533,166 +2533,595 @@ fi\
}
+
+# PATH CONVERSION HELPER FUNCTIONS #
+
+
+# func_wine_to_win32_path ARG
+# Helper function used by path conversion functions
+# when $build is *nix, and $host is mingw, cygwin,
+# or some other win32 environment. Relies on a
+# correctly configured wine environment available,
+# with the winepath program in $build's $PATH.
+#
+# ARG is the $build path to be converted to win32 format.
+# result is available in $func_wine_to_win32_path_result
+# result is empty on error (or when arg is empty)
+func_wine_to_win32_path ()
+{
+ $opt_debug
+ lt_sed_naive_backslashify='s|*|\\|g;s|/|\\|g;s|\\||g'
+ func_wine_to_win32_path_result=$1
+ if test -n $1; then
+# Unfortunately, winepath does not exit with a non-zero
+# error code, so we are forced to check the contents of
+# stdout. On the other hand, if the command is not
+# found, the shell will set an exit code of 127 and print
+# *an error message* to stdout. So we must check for both
+# error code of zero AND non-empty stdout, which explains
+# the odd construction:
+func_to_host_path_tmp1=`winepath -w $1 2/dev/null`
+if test $? -eq 0 test -n ${func_wine_to_win32_path_tmp}; then
+ func_to_host_path_result=`$ECHO $func_wine_to_win32_path_tmp |
+$SED -e $lt_sed_naive_backslashify`
+else
+ func_wine_to_win32_path_result=
+fi
+ fi
+}
+# end: func_wine_to_win32_path
+
+
+# func_wine_to_win32_pathlist ARG
+# Helper function used by path conversion functions
+# when $build is *nix, and $host is mingw, cygwin,
+# or some other win32 environment. Relies on a
+# correctly configured wine environment available,
+# with the winepath program in $build's $PATH.
+# Assumes ARG has no leading or trailing path separator
+# characters.
+#
+# ARG is pathlist
Re: [PATCH] [cygwin]: Add cross-compile support to cwrapper
Charles Wilson wrote: In fact, maybe I should add $opt_debug to the new func_to_host_path[list] functions... Addressed in the attached revision. cygwin-native testsuite behavior is as expected.q still true. mingw-native (e.g. msys-mingw) testsuite behavior is as expected. still true. cygwin-mingw testsuite behavior didn't really work, but it does not appear to be as a result of this patch. [*] I think we've more-or-less reached a consensus that cygwin-mingw cross should be treated, by default, as a cygwin to mingw cross (fancy that!) -- in that the compiler should be considered a normal cross-compiler running under cygwin with the ability to understand cygwin paths, symlinks, etc, which happens to generate mingw code. But also, that many people DO use cygwin to drive a native mingw compile process (not MSYS), when building gcc/binutils or other libraries and applications. http://cygwin.com/ml/cygwin/2009-01/msg00808.html (LONG thread). The most prominent example, is that several prominent folks use cygwin to bootstrap native mingw gcc toolchains, by lying: (1) configure --build=mingw32 --host=mingw32 --target=mingw32, which currently works. However, Danny reports that (2) configure --build=cygwin --host=mingw32 --target=mingw32 ALSO currently works. This tells us two things: From scenario (2)... Because the compilers built during this process will all be native, they don't understand the cygwin paths nor symlinks. However, because (2) works anyway, this means that gcc, at least, is structured in such a way that the bootstrap process does not use symlinks nor absolute paths, when building for mingw $host and $target -- even though $build in this case supports it. This is not surprising; how else could --build=linux --host=mingw32 --target=mingw32 work? Of course, since $build != $host, in this case a full triple bootstrap is not performed -- and the testsuite is not run by default (unknown if Danny tries to manually run the testsuite in this configuration). From scenario (1)... Given that current gcc includes a fairly recent libtool with an early version of the func_to_host_path stuff, then IF gcc actually /used/ that libtool to build executables requiring wrapper exes, THEN those executables would be broken -- because even the old func_to_host_path stuff would (a) think that $build=mingw (e.g. msys) because that's what you told it (b) know that $host=mingw (c) use the `( cmd //c echo $1 ) ...` construction to convert the paths. (d) This will fail when the ACTUAL $build is cygwin. However, because Danny says (1) works, currently, this implies that gcc, at least, never uses libtool to build executables -- utilities, or test programs. Therefore, the (1) scenario of (triple) bootstrapping mingw gcc under cygwin (by claiming $build=mingw) should continue to work, even with this patch. That, to me, is a great relief. Now, this doesn't address any possible (probable?) issues with lying to configure about $build for OTHER packages. The attached update attempts to provide end-users with the capability -- although esoteric -- to address them. Basically, I made the to_host_path[list]_cmd variables cached, so that you COULD do this: $ export lt_cv_to_host_path_cmd=func_cygwin_to_mingw_path_convert $ export lt_cv_to_host_pathlist_cmd=func_cygwin_to_mingw_pathlist_convert $ configure --build=mingw32 --host-mingw32 (--target=ming32, if building a tool chain package like binutils or gcc; but apparently this lt_cv* workaround is not necessary for building gcc, yay!) and libtool will NOT use the func_msys_to_mingw_path_convert functions as it normally would for this build/host/target, but instead will use the correct cygwin_to_mingw ones. Coupled with some of Peter's patches to use the (generic encapsulation functions) func_to_host_path[list](), this will address many, if not all, of the issues that may arise (and probably already DO arise, with ToT libtool, for any package OTHER than gcc!) with this scenario. I'd like for somebody to verify that I haven't broken unix-mingw I think Roumen Petrov has verified this; but I can't find the message in the archives. Also, if somebody could verify that the new unix-cygwin support works (ditto lt-demo.c), that'd be great. Nobody has chimed in here, but I'll use a 'test release' over on cygwin-apps to get wider testing. But I'd really rather not wait on that to get the rest of these changes in...can this patch be accepted without explicitly testing the one new facility also included in it? [*] I had to configure as follows: $ export PATH=/c/MinGW/bin:$PATH $ ../libtool/configure --build=i686-pc-cygwin --host=mingw32 NM=/c/MinGW/bin/nm.exe [snip various problems that occur in this configuration] I believe most of these issues are addressed by Peter's patches, which use the (generic encapsulation functions) func_to_host_path[list](). And, perhaps, by --disable-dependency-tracking (since cygwin-make does not grok the dependency
Re: [PATCH] Document and test LT_DEBUGWRAPPER cwrapper macro
Charles Wilson wrote: * tests/cwrapper.test: Add new test for -DLT_DEBUGWRAPPER. * doc/libtool.texi [Linking executables]: Mention wrapper executables, in addition to wrapper scripts. Add menu referencing subsection 'Wrapper executables for programs'. [Wrapper executables for programs]: New subsection. Documents cwrapper rationale, command line options, and LT_DEBUGWRAPPER macro. --- OK to push? For once, it's a nice, simple, small patch g. Ping? FWIW, I plan to expand on the [Wrapper executables for programs] documentation after (assuming) the cross-compile stuff goes in. Some of that info will be taken from here: http://cygwin.com/ml/cygwin/2009-01/msg00851.html The interesting bits start with But I worry that things, although there is one misconception; at the time I thought that current gcc used old libtool (2007-03-18). It doesn't -- it uses 2009-09-26). However, the description of why we use a wrapper exe, and why we eliminated the wrapper script entirely, and why *WE* have to worry about converting paths manually from one format to another are all good. -- Chuck
Re: Status of the MSYS/MSVC port
Peter Rosin wrote: I have: $ gcc -v Reading specs from C:/MinGW/bin/../lib/gcc/mingw32/3.4.2/specs Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry --disable-shared --enable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x --enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter --enable-hash-synchronization --enable-libstdcxx-debug Thread model: win32 gcc version 3.4.2 (mingw-special) gcc -std=c89 -E on lt-usea.c has exactly one occurence of stat.h: # 1 C:/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../include/sys/stat.h 1 3 No declaration from it though. That file is like this: That's...quite different than mine. I'm running a slightly patched version of mingw's gcc: $ gcc -v Reading specs from C:/MinGW/bin/../lib/gcc/mingw32/3.4.5/specs Configured with: ../gcc-3.4.5-20060117-3csw/configure --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --enable-languages=c,c++,f77,objc,java --disable-win32-registry --disable-shared --enable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x --enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter --enable-hash-synchronization --enable-libstdcxx-debug Thread model: win32 gcc version 3.4.5 (mingw special) But the real kicker is sys/stat.h: /* * stat.h * This file has no copyright assigned and is placed in the Public Domain. * This file is a part of the mingw-runtime package. * No warranty is given; refer to the file DISCLAIMER within the package. * * Symbolic constants for opening and creating files, also stat, fstat and * chmod functions. * */ #ifndef _STAT_H_ #define _STAT_H_ /* All the headers include this file. */ #include _mingw.h #define __need_size_t #define __need_wchar_t #ifndef RC_INVOKED #include stddef.h #endif /* Not RC_INVOKED */ #include sys/types.h /* * Constants for the stat st_mode member. */ ... #endif /* Not _STAT_H_ */ What version of mingw-runtime are you using? (I'm not sure which version I have; its from a bundle I put together about a year ago; I can get to the docu for that bundler later today. It's probably mingw-runtime-3.14). -- Chuck
Re: Status of the MSYS/MSVC port
Peter Rosin wrote: Den 2009-01-29 11:49 skrev Charles Wilson: What version of mingw-runtime are you using? (I'm not sure which version I have; its from a bundle I put together about a year ago; I can get to the docu for that bundler later today. It's probably mingw-runtime-3.14). Something prior to [1] obviously. 3.1 or 3.2 perhaps, ca 2003 it seems? Maybe we should just ignore this (ancient) problem... Yes. Doctor, it hurts when I use -std=c89 and my grandfather's mingw-runtime. Okay, then either DON'T use -std=c89 (and live with cwrapper.test failing, because it /will/ use that flag), OR upgrade your mingw-runtime. Problem solved. -- Chuck
Re: Status of the MSYS/MSVC port
Bob Friesenhahn wrote: My own MinGW install dates from the 2002/2003 time frame. :-) At the time MinGW/MSYS was a simple install. Nowadays it seems to be all jumbled up so I have not tried to cross the hurdle of an update. Yes, the MinGW download site is a disaster, thanks to SF improvements. However, TDM has done a lot of the grunt work, and written a custom installer program. It can install his custom MinGW distribution, OR it can also install the official MinGW. I haven't tried it, but it's worth a look (and beats the unmaintained official installer hands down... http://www.tdragon.net/recentgcc/ -- Chuck
Re: Status of the MSYS/MSVC port
Roumen Petrov wrote: I think that we has to be careful about structure _stat and version of msvcrt (=8.0) - it depend from definition of time_t 32/64 bit and the size is deferent depending from an another macro. May be wrapper has to include MSVC headers. This is all moot. We (libtool's cwrapper) have no business defining struct stat. With modern mingw-runtime (or MSVC headers), we will get the right one when we #include sys/stat.h, regardless of any -std=c89 or -std=c99 flags. So no worries. -- Chuck
Re: Pings
Akim Demaille wrote: Le 29 janv. 09 à 19:22, Ralf Wildenhues a écrit : For this one I'd prefer if Charles and/or Peter took care of it, they have a bunch of changes in this area and some discussion going on. Actually, I'd prefer to just be able to say go! once y'all have agreed on a common set of changes. :-) Maybe there are other means to address these warnings. At some other place of our project, it seems that #defining _CRT_SECURE_NO_DEPRECATE, _CRT_NONSTDC_NO_DEPRECATE, _AFX_SECURE_NO_WARNINGS, and _ATL_SECURE_NO_WARNINGS might suffice. Well, we should do our best to make the libtool cwrapper as invisible as possible. So, if a client's code is _CRT_SECURE_NO_DEPRECATE clean, such that they don't need to define that macro, we shouldn't require them to change their entire build settings CFLAGS just to make our little wrapper compile silently. However, there is no WAY we're going to use MS's improved functions like StringCchLength() or StringCbCat(). So, *we* ought to #define those shaddup, MS, I'm not using your 'safe' but proprietary replacements for standard libc functions macros. However, the only ones that matter for the cwrapper is _CRT_SECURE_NO_DEPRECATE (and perhaps _CRT_NONSTDC_NO_DEPRECATE [*]). [*] except that we are already addressing that via the typical port-to-MSVC method of '#define foo _foo' for all posix functions we use. Whatever the choice, this (msvc) is a real nuisance. You can say that again. And again. And several more times. -- Chuck
Re: Pings
Ralf Wildenhues wrote: * Akim Demaille wrote on Wed, Jan 28, 2009 at 04:43:56PM CET: - nuke warnings in the wrappers The patch at the end of http://lists.gnu.org/archive/html/libtool/2008-12/msg00069.html For this one I'd prefer if Charles and/or Peter took care of it, they have a bunch of changes in this area and some discussion going on. Actually, I'd prefer to just be able to say go! once y'all have agreed on a common set of changes. :-) My set of changes were already pushed (0aef3579..6631e515) 2009-01-24 Charles Wilson ... [cygwin|mingw] cwrapper cleanups. * libltdl/config/ltmain.m4sh (func_emit_cwrapperexe_src) [file scope]: re-organized includes and portability macros. Avoid oldnames on MINGW32 and MSVC for setmode/stat/chmod/getcwd/putenv. Declare _putenv on MINGW32 when -ansi. Use namespaced macro LT_DEBUGWRAPPER. This patch ALSO takes care of all but the _CRT_SECURE_NO_DEPRECATE part of Akim's. See earlier reply in this thread for why we don't need to worry about any other magic MSVC macros. So, I think the only remaining cleanup-warnings patch for the cwrapper is this: diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh index 1c745f4..308a89a 100644 --- a/libltdl/config/ltmain.m4sh +++ b/libltdl/config/ltmain.m4sh @@ -3110,6 +3110,9 @@ func_emit_cwrapperexe_src () */ EOF cat EOF +#ifdef _MSC_VER +# define _CRT_SECURE_NO_DEPRECATE 1 +#endif #include stdio.h #include stdlib.h #ifdef _MSC_VER OK to push? -- Chuck
Re: Status of the MSYS/MSVC port
Ralf Wildenhues wrote: * Peter Rosin wrote on Thu, Jan 29, 2009 at 06:53:48PM CET: But maybe, just maybe, you don't have a desperate need to do -std=c89 -Werror :-) Guys, if all you're working around is -Werror, then stop right now. Just eliminate -Werror from $LTCC $LTCFLAGS and be done with it. The cwrapper machinery, if it needs anything, then become simpler and less work to maintain, not more. Err...you're missing the point. We're trying to eliminate warnings under std=c89 and std=c99 (and, for that matter, under normal conditions). The way to detect whether we have successfully done so is to use std=c89 + -Werror, and detect the failure. stripping out -Werror...kinda makes eliminating warnings in cwrapper a little difficult, Now, I'm okay with just letting cwrapper.test fail if MSVC, or if your mingw-runtime is extremely old. All that means is that your *normal* compilation experience (without /WX, or -Werror) will be a little noisier than you might like (or might even fail, if you insist on using -std=c89 with a mingw-runtime that doesn't fully support c89 compliance). So, we don't have to make cwrapper -Werror clean right away, all at once, under all possible configurations. For instance: of the problems reported by Peter yesterday: http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg00195.html stat: missing decl - update your mingw-runtime; problem goes away P_WAIT: missing def - ditto _setmode: missing decl - ditto _spawnv: missing decl - ditto S_IXUSR: missing def - ditto _chmod: missing decl - ditto _getcwd: missing decl - ditto In fact, it looks to me like ALL of the problems Peter reported were caused by using an 2003-era mingw-runtime package (and these were actual errors, not -Werror warnings turned into errors). Well, ok then: libtool's cwrapper might not work with -std=c89 and a very very old mingw-runtime. Client should either (a) stop telling us -std=c89, or (b) update mingw-runtime. Either way, it's not *our* problem. And, as Roumen Petrov pointed out, the strtod failure was a bug in mingw-runtime, now fixed. So, again, no need for us to do anything about it. More in my followup in Akim's Ping? thread. -- Chuck
Re: Status of the MSYS/MSVC port
Peter Rosin wrote:
Maybe, here are the errors:
So, I guess these declarations should do it (untested):
int _setmode (int, int);
int _spawnv (int, const char *, const char * const *);
#ifndef _P_WAIT /* just in case */
# define _P_WAIT0
#endif
_P_WAIT is guarded in MSVC's process.h by #ifndef _POSIX_ (as opposed to
__STRICT_ANSI__). In MinGW's process.h, it is not guarded at all (but
P_WAIT is guarded by _NO_OLDNAMES).
#ifndef _STAT_DEFINED
struct _stat
{
_dev_tst_dev;/* Equivalent to drive number 0=A 1=B ... */
_ino_tst_ino;/* Always zero ? */
_mode_tst_mode;/* See above constants */
shortst_nlink;/* Number of links. */
shortst_uid;/* User: Maybe significant on NT ? */
shortst_gid;/* Group: Ditto */
_dev_tst_rdev;/* Seems useless (not even filled in) */
_off_tst_size;/* File size in bytes */
time_tst_atime;/* Accessed date (always 00:00 hrs local
* on FAT) */
time_tst_mtime;/* Modified time */
time_tst_ctime;/* Creation time */
};
#endif /* _STAT_DEFINED */
Something is not right here. I took a look at the pre-preocessed output
from mingw-gcc -std=c89 -E lt-foo.c, and both 'struct stat' and 'struct
_stat' were declared. Further, looking at the MinGW sys/stat.h, I can't
see where any of the compile flags we are using -- even the restrictive
ones -- would exclude those declarations.
Are you using the MSVC include files here? I thought the test case was:
On MSYS/MinGW, stresstest.at now passes when Run tests with low
max_cmd_len, that fails on git master. On the other hand, cwrapper for
uninstalled executables fails at cwrapper.at:78 (both with and without
low max_cmd_len).
MSYS/MinGW, *not* msvc?
Now, if there are MSVC problems, we'll have to fix those, too. But I
want to be clear on exactly what we're discussing...
int _stat (const char *, struct _stat *);
#ifndef S_IXUSR /* just in case */
# defineS_IXUSR_S_IXUSR
#endif
int _chmod (const char *, int);
char * _getcwd (char *, int);
But IMHO, the struct _stat declaration is horrible to have in the
code. Shouldn't we just #undef __STRICT_ANSI__ before we include
anything or something? It's not as if that define helps...
Well, it's not just __STRICT_ANSI__, it's also _POSIX_ sometimes. Maybe
you're right, and we should #undef __STRICT_ANSI__ and #def _POSIX_
before including headers. However, adding a few more function
declarations is not so bad...so I could go either way, so long as we
figure out why you're not getting the struct _stat declaration.
--
Chuck
Re: Status of the MSYS/MSVC port
Roumen Petrov wrote: Peter Rosin wrote: [SNIP] This was all inside #ifdef __MINGW32__, which assumes msvcrt.dll, i.e. compatible with MSVC 6, so we're safe. I think. Famous last words... It seems to me that I misunderstood report failure and the case. It start for ms compiler why #ifdef __MINGW32__ is now involved ? Peter included three different topics in his original post that began this thread. #1 was Status of the MSYS/MSVC port. #2 was a single sentcence: make check-local on Cygwin/gcc is clean with this flavor of libtool. #3 was On MSYS/MinGW, stresstest.at now passes when Run tests with low max_cmd_len, that fails on git master. On the other hand, cwrapper for uninstalled executables fails at cwrapper.at:78 We are currently on a subthread concerning #3 (although there is some confusion about /that/, too -- which is why Peter is inspecting his pre-processed source code right now...) -- Chuck
Re: [PATCH] [cygwin]: Add cross-compile support to cwrapper
Peter Rosin wrote:
First off, your patch works like a charm on MSYS/MSVC, and I generally
like it.
But a couple of questions are open, when did native MinGW ar enter the
picture when $build = cygwin and why is there a problem with leakage
of paths from the other environment? I thought the tools when $build
is Cygwin are ordinary cross tools (albeit with a strange name so far)?
I was deliberately testing the case where you use the MinGW native
toolchain from the cygwin environment. I had the impression that was
pretty common, because MSYS is, well, limited. Old. Slow to be updated.
Based off an ancient fork of cygwin. Not many ported utilities. Heck,
I'm not even sure it works on Vista with UAC (maybe it does). So, I
figured a lot of folks probably try to drive the official MinGW gcc
using the cygwin bash/tools rather than the MSYS bash/tools. But maybe
they all lie, like Danny does below...
[NB: see thread RFD: cygwin + *native* MinGW compiler
http://cygwin.com/ml/cygwin/2009-01/msg00808.html ]
In fact, Danny Smith [*] stated:
http://gcc.gnu.org/ml/gcc-patches/2009-01/msg01162.html
[I use most often...]
-build=i686-pc-mingw32 --host=i686-pc-mingw32 --target=i686-pc-mingw32
[with] cygwin bash and tools
[*] ex-MinGW maintainer /of/ gcc, now currently one of the gcc
maintainers /for/ MinGW. (Trust me, the two roles sound similar but are
quite different in practice.) Point is, I don't want to break Danny's
use case!
Now, Danny's actually lying to configure, when he claims that $build ==
mingw32, when it is actually cygwin. And, without any other
considerations, his use case may break my patch (or vice versa). You'd
end up calling func_msys_to_mingw, which relies on the msys magic path
conversion logic:
( cmd //c echo $1 )
MSYS (but not cygwin) notices that cmd is a native win32 program, and
that there is a path-like argument $1. MSYS (but not cygwin) will then
automatically convert $1 to DOS format, before spawning the cmd process
-- which echos the converted path to stdout, where we can grab it. MSYS
(but not cygwin) also turns '//c' into '/c' (the extra slash means
don't use the MSYS mount table to convert this path) -- this is how
you pass win32-style switches to native programs. IIRC, there's some
complicated logic to determine whether a given argument that begins with
two slashes is a switch like /EHsc or a unix-format SMB path like
//server/share/path/to/file.
On cygwin, //c stays //c, and $1 stays in unix format, and 'cmd' gets
very confused by the '//c' non-switch. Bang, you're dead (well,
libtool prints a warning and uses the unix-format path, so...you're a
zombie, and you'll die later).
Maybe if $to_host_path_cmd and $to_host_pathlist_cmd were cached
variables, then folks who (a) know what they are doing, and (b) want to
lie, can do
cygwin$ export lt_cv_to_host_path_cmd=func_cygwin_to_mingw_path_convert
cygwin$ export
lt_cv_to_host_pathlist_cmd=func_cygwin_to_mingw_pathlist_convert
cygwin$ path/to/configure \
--build=i686-pc-mingw32 \
--host=i686-pc-mingw32 \
--target=i686-pc-mingw32
???
=
Now, you're certainly right in one respect: if we can assume that
--build=cygwin --host=mingw means my compiler is a generic
cygwin-hosted mingw cross compiler and NOT I'm using the native mingw
compiler from a weird (cygwin) environment -- then things are a lot
easier. Heck, that probably works already. And I'd test it...if I had an
accessible cross compiler of that sort...
But at present, the cygwin distro does not supply such a beast. It
will, very soon: once the official cygwin gcc-4.[34] packages are rolled
out, they will no longer support -mno-cygwin, so we'll be obliged to
provide a true cygwin-host mingw-target cross compiler just to self-host
and build some of our own tools, like setup.exe.
But...I'm a little confused -- to verify: A normal cross compiler
would itself have been configured as --build=cygwin --host=cygwin
--target=mingw (and if gcc used a libtool with my patch, it'd hit
func_noop_path_convert because $build==$host, which is what we want and
expect). Then, if I wanted to USE that cross-compiler to build pkg X,
I'd configure pkg X as --build=cygwin --host=mingw, so if pkg X used
libtool we'd hit func_cygwin_to_mingw_path_convert etc (which again, is
what we want and expect). Right? Good...
However, all that aside, is func_noop_path_convert a good idea?
Wouldn't it be better to just leave to_host_path_cmd empty in that
case and test for that in func_to_host_path? Or is an unconditional
eval as cheap as an if test -n $foo, in the common case when the
eval isn't needed?
func_to_host_path ()
{
if test -n $to_host_path_cmd; then
eval '$to_host_path_cmd $1'
else
func_to_host_path_result=$1
fi
}
I'm not sure. I was going for clarity of code, and figured we could
determine if any speedups were needed or possible later. To me, it's
much clearer if a $cmd variable is assigned to a func_noop() target, as
opposed to leaving the $cmd
Re: Status of the MSYS/MSVC port
Peter Rosin wrote: On MSYS/MinGW, stresstest.at now passes when Run tests with low max_cmd_len, that fails on git master. On the other hand, cwrapper for uninstalled executables fails at cwrapper.at:78 (both with and without low max_cmd_len). It's the second time through the loop that fails, when restrictive_flags='-std=c89 -Wall -Werror' (an attempt to execute the missing usea.exe). The root cause is that when linking, the compile of the wrapper fails with various implicitly declared (or undeclared) identifiers - usea.exe goes MIA. But that test behaves the exact same way on a pure libtool from git master, so move on, nothing to see here... Odd. I thought one of my recent patches (git diff 0aef3579..6631e515) fixed those. Do we need to add more stuff /* declarations of non-ANSI functions */ #if defined(__MINGW32__) # ifdef __STRICT_ANSI__ HERE? -- Chuck
Re: Add lib prefix to library name in the ltdl preloaded symbol lookup
Peter Rosin wrote:
This is from need-lib-prefix.at: main.exeS.c when the test
is run on the tip of the pr-msvc-support branch.
lt__PROGRAM__LTX_preloaded_symbols[] =
{ { @PROGRAM@, (void *) 0 },
{foo1.lib, (void *) 0},
{libfoo1_LTX_i, (void *) foo1_LTX_i},
{libfoo1_LTX_f, (void *) foo1_LTX_f},
The below patch makes that into
{libfoo1.lib, (void *) 0},
{libfoo1_LTX_i, (void *) foo1_LTX_i},
{libfoo1_LTX_f, (void *) foo1_LTX_f},
which works much better.
The need-lib-prefix.at test still works on Cygwin after this test.
Did you test this in conjunction with the [cygwin|mingw] fix dlpreopen
with --disable-static take 4 changes, or do I need to do that? Also,
what if the library is not libfooN.lib, but is instead cygfoo-N.dll
(or foo-N.dll) -- which is another way of asking the same question, I
guess?
--
Chuck
[PATCH] Add -Wall to cwrapper tests.
* tests/cwrapper.at: Add -Wall existing tests. Add additional round of tests with -Wall alone. --- Preapproved. As pushed... tests/cwrapper.at |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/tests/cwrapper.at b/tests/cwrapper.at index 30e591e..ce4572e 100644 --- a/tests/cwrapper.at +++ b/tests/cwrapper.at @@ -55,7 +55,7 @@ int main (void) orig_CFLAGS=$CFLAGS orig_LIBTOOL=$LIBTOOL -for restrictive_flags in '-std=c89 -Werror' '-std=c99 -Werror'; do +for restrictive_flags in '-Wall -Werror' '-std=c89 -Wall -Werror' '-std=c99 -Wall -Werror'; do CFLAGS=$orig_CFLAGS $restrictive_flags sed s/LTCFLAGS=.*/' $restrictive_flags'/ $orig_LIBTOOL ./libtool LIBTOOL=./libtool -- 1.6.0.4
[PATCH] Document and test LT_DEBUGWRAPPER cwrapper macro
* tests/cwrapper.test: Add new test for -DLT_DEBUGWRAPPER.
* doc/libtool.texi [Linking executables]: Mention wrapper
executables, in addition to wrapper scripts. Add menu referencing
subsection 'Wrapper executables for programs'.
[Wrapper executables for programs]: New subsection. Documents
cwrapper rationale, command line options, and LT_DEBUGWRAPPER
macro.
---
OK to push?
doc/libtool.texi | 96 +++-
tests/cwrapper.at | 31 +
2 files changed, 125 insertions(+), 2 deletions(-)
diff --git a/doc/libtool.texi b/doc/libtool.texi
index d304f28..cfae448 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -790,8 +790,9 @@ Note that libtool added the necessary run-time path flag,
as well as
@cindex wrapper scripts for programs
@cindex program wrapper scripts
Notice that the executable, @code{hell}, was actually created in the
-...@file{@value{objdir}} subdirectory. Then, a wrapper script was created
-in the current directory.
+...@file{@value{objdir}} subdirectory. Then, a wrapper script (or, on
+certain platforms, a wrapper executable @pxref{Wrapper executables}) was
+created in the current directory.
Since libtool created a wrapper script, you should use libtool to
install it and debug it too. However, since the program does not depend
@@ -845,6 +846,97 @@ price of being dynamic is eight kilobytes, and the payoff
is about four
kilobytes. So, having a shared @file{libhello} won't be an advantage
until we link it against at least a few more programs.
+...@menu
+* Wrapper executables:: Wrapper executables for certain platforms.
+...@end menu
+
+...@node Wrapper executables
+...@subsection Wrapper executables for programs
+...@cindex wrapper executables for programs
+...@cindex program wrapper executables
+
+Some platforms, notably those hosted on win32 such as cygwin
+and mingw, use a wrapper executable rather than a wrapper script. It
+performs the same function, but is necessary so that @code{make}
+rules for target executables (whose names end in @code{$(EXEEXT)})
+are satisfied. Recall that the actual target executable is created
+in @value{objdir} as @co...@value{objdir}/program_name.exe} on
+these platforms. If a wrapper script were used, then the build
+directory would contain @code{program_name}, @emph{not}
@code{program_name.exe}.
+Thus, @code{make} would never believe that the target executable had
+been created, leading to continual and useless relinking. (We could
+name the wrapper script @code{program_name.exe} on these platforms, but it
+is not a good idea to lie to win32 in this way).
+
+Therefore, these platforms use a wrapper executable to set various
+environment values so that the target executable may locate its
+shared libraries. The wrapper executable then launches the target
+executable using a (possibly $host-dependent) function, such as
+exec() or _spawn().
+
+Note that the wrapper executable, like the target executable, is a
+$host program, not a $build program. Therefore, the path to the
+target executable must be expressed in the native format of the
+$host, not that of $build. Similarly, the environment variable
+values --- and even the name of the specific environment variables
+to adjust --- are $host-specific and should be in $host, not $build,
+format. For this reason, libtool contains a number of path and
+pathlist conversion functions for various $host/$build combinations,
+where $host is one of those platforms where a wrapper executable is
+needed.
+
+Obviously, the wrapper executable itself is quite complex (more so
+than the wrapper script). If something goes wrong, it is useful to
+debug its operation. This can be enabled by recompiling the wrapper
+executable itself as follows:
+
+...@example
+burger$ @kbd{$CC $CFLAGS -DLT_DEBUGWRAPPER -o program_name.exe
@value{objdir}/lt-program_name.c}
+burger$
+...@end example
+
+When executing the new wrapper, diagnostic information will be printed
+to @code{stderr} before the target executable is launched.
+
+Finally, the wrapper executable supports a number of command line
+options. All of these options are in the @code{--lt-} namespace, and
+if present they and their arguments will be removed from the argument
+list passed on to the target executable. Therefore, the target
+executable may not employ command line options in the @code{--lt-}
+namespace. (In fact, the wrapper executable will detect any command
+line options in the @code{--lt-} namespace and abort with an error
+message if the option is recognized). If this presents a problem,
+please contact the libtool team at @email{bug-libtool@@gnu.org}.
+
+These command line options include:
+
+...@table @option
+...@item --lt-dump-script
+Causes the wrapper executable to print a copy of the wrapper @emph{script}
+to @code{stdout}, and exit.
+
+...@item --lt-env-set VAR=VAL
+Takes one argument of the form VAR=VAL. The wrapper executable will set
+the specified environment
Re: [PATCH] Add tests for cwrapper with -std=c89 and -std=c99
Ralf Wildenhues wrote: Please go ahead and push with these changes. Pushed. -- Chuck
[PATCH] Add tests for cwrapper with -std=c89 and -std=c99
* tests/cwrapper.at: New file.
* Makefile.am: Add tests/cwrapper.at.
---
Ok to push?
Makefile.am |1 +
tests/cwrapper.at | 81 +
2 files changed, 82 insertions(+), 0 deletions(-)
create mode 100644 tests/cwrapper.at
diff --git a/Makefile.am b/Makefile.am
index 790..7a61846 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -467,6 +467,7 @@ TESTSUITE_AT= tests/testsuite.at \
tests/indirect_deps.at \
tests/archive-in-archive.at \
tests/execute-mode.at \
+ tests/cwrapper.at \
tests/infer-tag.at \
tests/localization.at \
tests/install.at \
diff --git a/tests/cwrapper.at b/tests/cwrapper.at
new file mode 100644
index 000..2cae611
--- /dev/null
+++ b/tests/cwrapper.at
@@ -0,0 +1,81 @@
+# cwrapper.at -- test compliance with c89 standard -*- Autotest -*-
+
+# Copyright (C) 2009 Free Software Foundation, Inc.
+# Written by Charles Wilson, 2009
+#
+# This file is part of GNU Libtool.
+#
+# GNU Libtool is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# GNU Libtool is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GNU Libtool; see the file COPYING. If not, a copy
+# can be downloaded from http://www.gnu.org/licenses/gpl.html,
+# or obtained by writing to the Free Software Foundation, Inc.,
+# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+
+
+AT_SETUP([wrapper for uninstalled dynamically linked executables - C])
+AT_KEYWORDS([libtool])
+
+# make sure existing libtool is configured for shared libraries
+AT_CHECK([$LIBTOOL --features | grep 'disable shared libraries' exit 77],
+[1], [ignore])
+
+AT_DATA([trivial.c],
+[[
+int main (void)
+{
+ return 0;
+}
+]])
+AT_DATA([liba.c],
+[[int liba_func1 (int arg)
+{
+ return arg + 1;
+}
+]])
+AT_DATA([usea.c],
+[[extern int liba_func1 (int arg);
+int main (void)
+{
+ int a = 2;
+ int b = liba_func1 (a);
+ if (b == 3) return 0;
+ return 1;
+}
+]])
+
+orig_CFLAGS=$CFLAGS
+orig_LIBTOOL=$LIBTOOL
+for restrictive_flags in '-std=c89 -Werror' '-std=c99 -Werror'; do
+ CFLAGS=$orig_CFLAGS $restrictive_flags
+ sed s/LTCFAGS=.*/' $restrictive_flags'/ $orig_LIBTOOL ./libtool
+ LIBTOOL=./libtool
+
+ # make sure $restrictive_flags do not cause a failure
+ # themselves (e.g. because a non-gcc compiler doesn't them)
+ $LIBTOOL --mode=compile $CC $CPPFLAGS $CFLAGS -c trivial.c || continue
+
+ AT_CHECK([$LIBTOOL --mode=compile $CC $CPPFLAGS $CFLAGS -c liba.c],
+ [], [ignore], [ignore])
+ AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -version-info=0.0.0
-no-undefined -o liba.la -rpath /foo liba.lo],
+ [], [ignore], [ignore])
+ AT_CHECK([test -f liba.la])
+
+ AT_CHECK([$CC $CPPFLAGS $CFLAGS -c usea.c],
+ [], [ignore], [ignore])
+ AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o usea$EXEEXT
usea.$OBJEXT liba.la],
+ [], [ignore], [ignore])
+ LT_AT_EXEC_CHECK([./usea], [0], [ignore], [ignore], [])
+done
+
+AT_CLEANUP
+
--
1.6.0.4
Re: [PATCH] [cygwin|mingw] Fix compile warnings when -std=c89.
Charles Wilson wrote: The bits removed from this commit are attached as cygwin-cwrapper-cleanups.patch. Will start a new thread with these cleanups. -- Chuck
Re: testsuite performance
Ralf Wildenhues wrote: * Charles Wilson wrote on Wed, Jan 21, 2009 at 08:47:42PM CET: [...] EVERY separate patchset requires an independent full testsuite run. Until recently, that was 5 hours of sitting in front of my computer waiting for popups, while that computer was completely useless for anything else (100% cpu). That is horrible. May I ask what kind of CPU you have, and which Cygwin version? Core2Duo T5450 (1.66GHz) Vista 32bit Home Cygwin-1.5.25 or 1.7.38 (parallel installs; speed more or less the same) Vista @ 1.66G x 2 cores (my current laptop) seems to be about the same speed as XP @ 433MHz x 1 core (my previous laptop) -- in general, /not/ cygwin-specific. Sad, isn't it? What I try to do now is run long-running stuff on the old laptop since it's still humming away in the corner...but I don't have cygwin-1.7 installed on that one. Can you work on a Linux system with Wine, for at least those changes for which the difference shouldn't matter that much? Can you work on a GCC cfarm system for those tests where Cygwin isn't a premium, and ask the people running the mingw-w64 system for an account to test there? Sure, I can always run tests on a linux system; that would ensure that any changes I make don't break linux; this tells me nothing about *cygwin*. Unfortunately, wine won't really help, as it'd still go thru the cygwin layer, THEN the wine (not-an-) emulator layer, before the splendiferously fast linux system gets a crack at doing anything. There's really no way around testing on cygwin other than testing on cygwin. Ditto for mingw: ya gotta test under MSYS (which is cygwin-really-old by another name). Even mingw-w64: you still need an MSYS shell and utilities to run all the test cases, compare the results, etc. The problem is that test suites, in general, are THE worst performance case for cygwin: a bunch of tiny file accesses and TONS of tiny fork-n-execs (this is why cygwin/mingw get a disproportionate speed boost whenever you succeed in reducing the number of forks in libtool). But process spawning behavior is one of the biggest differences between win32 and posix, and one of the most difficult (and thus, relatively slow and inefficient) for cygwin/msys to paper over. It's been a thorn in our sides for over a decade. However, you think libtool is bad: it took me almost a week to run the gcc test suite. I've only ever done that twice. Dave Korn (cygwin-gcc maintainer) oughta take up a collection for a dedicated machine... -- Chuck
Re: [PATCH] Add tests for cwrapper with -std=c89 and -std=c99
Charles Wilson wrote: + sed s/LTCFAGS=.*/' $restrictive_flags'/ $orig_LIBTOOL ./libtool I've already fixed this typo s/LTCFAGS/LTCFLAGS/ -- Chuck
[PATCH] [cygwin|mingw] cwrapper cleanups.
libltdl/config/ltmain.m4sh (func_emit_cwrapperexe_src) [file scope]: re-organized includes and portability macros. Avoid oldnames on MINGW32 and MSVC for setmode/stat/chmod/getcwd/putenv. Declare _putenv on MINGW32 when -ansi. Use namespaced macro LT_DEBUGWRAPPER. --- This patch contains the parts excluded from http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg4.html as described here: http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg00105.html (with some additional modifications). For discussion of the motivation of this patch, see http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg00101.html and look for Part (2) is a bit unobvious when merely looking about one-third down. It's interesting that on mingw, when -std=c89, there is no declaration of putenv (or _putenv) in the system headers. However, with -Werror the compilation of the wrapper succeeds even without this patch -- but there is an error: if (putenv (str) != EXIT_SUCCESS) You have to turn on -Wall (with -std=c89) to get mingw gcc to complain: In function `lt_setenv': warning: implicit declaration of function `putenv' However, in -std=c99 mode, this warning is printed /without/ -Wall. So, the cwrapper.at tests (which exercise both '-std=c89 -Werror' and '-std=c99 -Werror', will fail on mingw without this patch or something like it. libltdl/config/ltmain.m4sh | 60 +-- 1 files changed, 40 insertions(+), 20 deletions(-) diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh index 3f1a30c..d525893 100644 --- a/libltdl/config/ltmain.m4sh +++ b/libltdl/config/ltmain.m4sh @@ -2716,18 +2716,11 @@ EOF # include direct.h # include process.h # include io.h -# define setmode _setmode #else # include unistd.h # include stdint.h # ifdef __CYGWIN__ # include io.h -# define HAVE_SETENV -# ifdef __STRICT_ANSI__ -char *realpath (const char *, char *); -int putenv (char *); -int setenv (const char *, const char *, int); -# endif # endif #endif #include malloc.h @@ -2741,6 +2734,44 @@ int setenv (const char *, const char *, int); #include fcntl.h #include sys/stat.h +/* declarations of non-ANSI functions */ +#if defined(__MINGW32__) +# ifdef __STRICT_ANSI__ +int _putenv (const char *); +# endif +#elif defined(__CYGWIN__) +# ifdef __STRICT_ANSI__ +char *realpath (const char *, char *); +int putenv (char *); +int setenv (const char *, const char *, int); +# endif +/* #elif defined (other platforms) ... */ +#endif + +/* portability defines, excluding path handling macros */ +#if defined(_MSC_VER) +# define setmode _setmode +# define stat_stat +# define chmod _chmod +# define getcwd _getcwd +# define putenv _putenv +# define S_IXUSR _S_IEXEC +# ifndef _INTPTR_T_DEFINED +# define _INTPTR_T_DEFINED +# define intptr_t int +# endif +#elif defined(__MINGW32__) !defined(__MINGW32CE__) +# define setmode _setmode +# define stat_stat +# define chmod _chmod +# define getcwd _getcwd +# define putenv _putenv +#elif defined(__CYGWIN__) +# define HAVE_SETENV +# define FOPEN_WB wb +/* #elif defined (other platforms) ... */ +#endif + #if defined(PATH_MAX) # define LT_PATHMAX PATH_MAX #elif defined(MAXPATHLEN) @@ -2756,19 +2787,12 @@ int setenv (const char *, const char *, int); # define S_IXGRP 0 #endif -#ifdef _MSC_VER -# define S_IXUSR _S_IEXEC -# define stat _stat -# ifndef _INTPTR_T_DEFINED -# define intptr_t int -# endif -#endif - #ifndef DIR_SEPARATOR # define DIR_SEPARATOR '/' # define PATH_SEPARATOR ':' #endif +/* path handling portability macros */ #if defined (_WIN32) || defined (__MSDOS__) || defined (__DJGPP__) || \ defined (__OS2__) # define HAVE_DOS_BASED_FILE_SYSTEM @@ -2794,10 +2818,6 @@ int setenv (const char *, const char *, int); # define IS_PATH_SEPARATOR(ch) ((ch) == PATH_SEPARATOR_2) #endif /* PATH_SEPARATOR_2 */ -#ifdef __CYGWIN__ -# define FOPEN_WB wb -#endif - #ifndef FOPEN_WB # define FOPEN_WB w #endif @@ -2811,7 +2831,7 @@ int setenv (const char *, const char *, int); } while (0) #undef LTWRAPPER_DEBUGPRINTF -#if defined DEBUGWRAPPER +#if defined LT_DEBUGWRAPPER # define LTWRAPPER_DEBUGPRINTF(args) ltwrapper_debugprintf args static void ltwrapper_debugprintf (const char *fmt, ...) -- 1.6.0.4
Re: [PATCH] Minor cygwin cleanup
Ralf Wildenhues wrote: * Charles Wilson wrote on Tue, Jan 20, 2009 at 11:31:43PM CET: libltdl/config/ltmain.m4sh (func_generate_dlsyms): Correct case pattern for cygwin. --- Ok to push? Yes, thanks! Pushed. -- Chuck
[PATCH] [cygwin|mingw] fix dlpreopen with --disable-static take 4
* libltdl/config/general.m4sh: Update copyright year.
(func_tr_sh): New function.
* libltdl/config/ltmain.m4sh (func_generate_dlsyms) [cygwin|mingw]:
Obtain DLL name corresponding to import library by using value
stored in unique variable libfile_$(transliterated implib name).
If that fails, use $sharedlib_from_linklib_cmd to extract DLL
name from import library directly. Also, properly extract dlsyms
from the import library.
(func_mode_link) [cygwin|mingw]: Prefer to dlpreopen DLLs
over static libs when both are available. When dlpreopening
DLLs, use linklib (that is, import lib) as dlpreopen file,
rather than DLL. Store name of associated la file in
unique variable libfile_$(transliterated implib name)
for later use.
(func_win32_libid): Accomodate pei-i386 import libs
as well as pe-i386.
(func_cygming_dll_for_implib): New function.
(func_cygming_dll_for_implib_fallback): New function.
(func_cygming_dll_for_implib_core): New function.
(func_cygming_implib_p): New function.
(func_cygming_ms_implib_p): New function.
* libltdl/m4/libtool.m4 (_LT_CMD_GLOBAL_SYMBOLS): Adjust sed
expressions for lt_cv_sys_global_symbol_to_c_name_address and
lt_cv_sys_global_symbol_to_c_name_address_lib_prefix
as trailing space after module name is optional.
(_LT_LINKER_SHLIBS) [cygwin|mingw][C++]:
Set exclude_expsyms correctly for $host. Simplify regular
expression in export_symbols_cmds.
(_LT_LINKER_SHLIBS) [cygwin|mingw|pw32][C]: Set exclude_expsyms
correctly for $host. Enable export_symbols_cmds to identify
DATA exports by _nm_ prefix.
(_LT_CHECK_SHAREDLIB_FROM_LINKLIB): New macro sets
sharedlib_from_linklib_cmd variable.
(_LT_DECL_DLLTOOL): New macro ensures DLLTOOL is always set.
---
This updated patch represents the promised combination of take 2
http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg2.html
and take 3
http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg00056.html
for easier reviewing, along with a minor change to func_tr_sh similar
to that suggested by Ralf W, and rebased to current master.
Test suite on cygwin/native in progress. Assumming test suite passes, OK?
Comments, Review, Discussion?
libltdl/config/general.m4sh | 19 -
libltdl/config/ltmain.m4sh | 226 +++
libltdl/m4/libtool.m4 | 62 +++-
3 files changed, 282 insertions(+), 25 deletions(-)
diff --git a/libltdl/config/general.m4sh b/libltdl/config/general.m4sh
index 4bc304c..e839070 100644
--- a/libltdl/config/general.m4sh
+++ b/libltdl/config/general.m4sh
@@ -1,6 +1,6 @@
m4_if([general.m4sh -- general shell script boiler plate -*- Autoconf -*-
- Copyright (C) 2004, 2005, 2007, 2008 Free Software Foundation, Inc.
+ Copyright (C) 2004, 2005, 2007, 2008, 2009 Free Software Foundation, Inc.
Written by Gary V. Vaughan, 2004
This file is part of GNU Cvs-utils.
@@ -412,5 +412,22 @@ func_show_eval_locale ()
fi
fi
}
+
+# func_tr_sh
+# Turn $1 into a string suitable for a shell variable name.
+# Result is stored in $func_tr_sh_result. All characters
+# not in the set a-zA-Z0-9_ are replaced with '_'. Further,
+# if $1 begins with a digit, a '_' is prepended as well.
+func_tr_sh ()
+{
+ case $1 in
+ [0-9]* | *[!a-zA-Z0-9_]*)
+func_tr_sh_result=`$ECHO $1 | $SED 's/^\([0-9]\)/_\1/;
s/[^a-zA-Z0-9_]/_/g'`
+;;
+ * )
+func_tr_sh_result=$1
+;;
+ esac
+}
]])
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 760f647..984abd2 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -2000,10 +2000,49 @@ extern \C\ {
func_verbose extracting global C symbols from \`$dlprefile'
func_basename $dlprefile
name=$func_basename_result
- $opt_dry_run || {
- eval '$ECHO : $name $nlist'
- eval $NM $dlprefile 2/dev/null | $global_symbol_pipe '$nlist'
- }
+ case $host in
+ *cygwin* | *mingw* | *cegcc* )
+ # if an import library, we need to obtain dlname
+ if func_win32_import_lib_p $dlprefile; then
+ func_tr_sh $dlprefile
+ eval curr_lafile=\$libfile_$func_tr_sh_result
+ dlprefile_dlbasename=
+ if test -n $curr_lafile func_lalib_p $curr_lafile; then
+ # Use subshell, to avoid clobbering current variable values
+ dlprefile_dlname=`source $curr_lafile echo $dlname`
+ if test -n $dlprefile_dlname ; then
+ func_basename $dlprefile_dlname
+ dlprefile_dlbasename=$func_basename_result
+ else
+ # no lafile. user explicitly requested -dlpreopen import
library.
+ eval '$sharedlib_from_linklib $dlprefile'
+ dlprefile_dlbasename=$sharedlib_from_linklib_result
+ fi
+ fi
+ $opt_dry_run || {
+ if test -n $dlprefile_dlbasename ; then
Re: [PATCH] [cygwin|mingw] Fix compile warnings when -std=c89.
Peter Rosin wrote: Den 2009-01-16 15:15 skrev Charles Wilson: Charles Wilson wrote: Charles Wilson wrote: * libltdl/config/ltmain.m4sh: Update copyright date. (func_emit_wrapper_part1): move contents to... (func_emit_wrapper_part2): move contents to... (func_emit_wrapper): here. (func_emit_cwrapperexe_src) [file scope]: re-organized includes and portability macros. Avoid oldnames on MINGW32 and MSVC for setmode/stat/chmod/getcwd/putenv. Declare _putenv on MINGW32 when -ansi. Use namespaced macro LT_DEBUGWRAPPER. Remove variables script_text_part1 and script_text_part2. (func_emit_cwrapperexe_src) [lt_dump_script]: New function. (func_emit_cwrapperexe_src) [main]: Call it. Ping? Ping x 2? I tried this patch on the pr-msvc-support branch and it seems to work just fine there as well (tested with MSVC 2005). Thanks, Peter; your validation on msvc is useful and encouraging. Now I'm just waiting for a go/no-go from one of the four libtool maintainers: Gary Vaughan, Peter O'Gorman, Ralf Wildenhues, or Bob Friesenhahn. Status: This patch was successfully tested by Roumen Petrov (on master, unix-mingw cross) http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg00012.html and by Peter Rosin (on pr-msvc-support branch, msys/msvc2005 native) http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg00060.html -- and me, msys/mingw native http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg5.html -- Chuck
Re: [PATCH] [cygwin|mingw] fix dlpreopen with --disable-static take 4
Charles Wilson wrote: Test suite on cygwin/native in progress. Assumming test suite passes, OK? Comments, Review, Discussion? All tests pass (cygwin/native): Old suite: === All 113 tests passed (11 tests were not run) === New suite: 76 tests behaved as expected. 5 tests were skipped. -- Chuck
Re: [PATCH] [cygwin|mingw] fix dlpreopen with --disable-static take 4
Charles Wilson wrote: Reviewing my own submission... (func_cygming_dll_for_implib_core): New function. This function is actually called func_cygming_dll_for_implib_fallback_core Need to correct log history. (func_cygming_implib_p): New function. Confusing. There is already a func_win32_implib_p which is less specific (returns true when [effectively] func_cygming_implib_p || func_cygming_ms_implib_p || (any other kind of implib) This one should be called func_cygming_gnu_implib_p as a parallel with the _cygming_ms_ one. -- Chuck
Re: [PATCH] [cygwin|mingw] Fix compile warnings when -std=c89.
Ralf Wildenhues wrote: * Charles Wilson wrote on Wed, Jan 21, 2009 at 08:47:42PM CET: Part of my tendency to include minor -- easy to review -- changes with larger ones is due to (a) see it, fix it, otherwise it'll be forgotten and (b) EVERY separate patchset requires an independent full testsuite run. Ah, ok. I can feel the pain. Let's relieve that a wee bit, without compromising quality too much: (a) can be addressed with git. Really, git's is flexible enough to allow for doing many many small commits, even ugly ones, and cleaning up afterwards. AIUI git is available for Cygwin and MinGW. Yep. I'm using it on cygwin. For mingw stuff I usually make dist on cygwin, and send the tarball across to mingw. (b) There is no need for full testsuite runs for every patch. If two patches are clearly independent, then one run with both of them should suffice. If you have a (not too huge) patch series, where things belong together, and the end point passes the testsuite, then while that is not ideal, it is still a lot better than nothing; in that case, please note this, and we can still ask for results of intermediate states if necessary. Well that'd be easier. Which however makes testsuite additions all the more important: that way, at least, when we run the suite before a release, we can find potential regressions. Think of testsuite additions as a way to shift some of the testing grunt work from yourself over to other users. This only matters if an full and successful testsuite run is not required after each patch (sequence?), or if all you're worried about is when patchA (submitted for unix, or cygwin) might break mingw but the original submitter only tested on his platform. Which is an important case, of course. But if you're fixing a cygwin bug, you need to test on cygwin (full testsuite? see below...) Just to be sure: you are aware of limiting the testsuite runs to just those bits that you are adding? old suite: make check TESTSUITEFLAGS=-V TESTS=tests/foo.test tests/bar.test \ VERBOSE=yes new suite: make check-local TESTSUITEFLAGS='-v -d -x 27-33' Sure, but how do you then *know* that your change didn't break something else? At some point you still have to run the full testsuite before committing to master, at least on the platform for which you're fixing a bug. These shortcuts can speed up development while coding the fix, but not the final submission/review process for the change. -- Chuck
Re: [PATCH] [cygwin|mingw] Fix compile warnings when -std=c89.
Ralf Wildenhues wrote: Part (1) is easy to review: it is obvious that regressions are very unlikely to be system-dependent. One does get the impression that it might just be more efficient to let libtool save the cwrapper text somewhere and the program just cat that. But still, this part is ok, please apply. This part pushed... Why is this patch not accompanied by a testsuite addition using -std=c89 -Werror on a program that creates a C wrapper? ...but without an additional test. Ralf, how should such a test be structured? Do we need (like Darwin) a separate category of windows-ish tests, that are skipped elsewhere, or what? The bits removed from this commit are attached as cygwin-cwrapper-cleanups.patch. I did not run a full test suite with just the pushed bits; however, those bits plus the cygwin-cwrapper-cleanups did pass, and the pushed bits alone passed a bootstrap/configure/make cycle and some (old) testsuite spot checks. Also, the generated cwrapper code compiled when -std=c89 without error (cygwin). As pushed (0010--cygwin-mingw-Fix-compile-warnings-when-std-c89.patch-pushed): [cygwin|mingw] Fix compile warnings when -std=c89. * libltdl/config/ltmain.m4sh (func_emit_wrapper_part1): move contents to... (func_emit_wrapper_part2): move contents to... (func_emit_wrapper): here. (func_emit_cwrapperexe_src) [file scope]: Remove variables script_text_part1 and script_text_part2. (func_emit_cwrapperexe_src) [lt_dump_script]: New function. (func_emit_cwrapperexe_src) [main]: Call it. -- Chuck diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh index 760f647..8728a7c 100644 --- a/libltdl/config/ltmain.m4sh +++ b/libltdl/config/ltmain.m4sh @@ -2746,18 +2716,11 @@ EOF # include direct.h # include process.h # include io.h -# define setmode _setmode #else # include unistd.h # include stdint.h # ifdef __CYGWIN__ # include io.h -# define HAVE_SETENV -# ifdef __STRICT_ANSI__ -char *realpath (const char *, char *); -int putenv (char *); -int setenv (const char *, const char *, int); -# endif # endif #endif #include malloc.h @@ -2771,6 +2734,33 @@ int setenv (const char *, const char *, int); #include fcntl.h #include sys/stat.h +/* declarations of non-ANSI functions */ +#if defined(__MINGW32__) +# ifdef __STRICT_ANSI__ +int _putenv (const char *); +# endif +#elif defined(__CYGWIN__) +# ifdef __STRICT_ANSI__ +char *realpath (const char *, char *); +int putenv (char *); +int setenv (const char *, const char *, int); +# endif +#endif + +/* portability #defines */ +#if defined(_MSC_VER) || defined(__MINGW32__) +# ifndef __MINGW32CE__ +# define setmode _setmode +# define stat_stat +# define chmod _chmod +# define getcwd _getcwd +# define putenv _putenv +# endif +#endif +#ifdef __CYGWIN__ +# define HAVE_SETENV +#endif + #if defined(PATH_MAX) # define LT_PATHMAX PATH_MAX #elif defined(MAXPATHLEN) @@ -2788,7 +2778,6 @@ int setenv (const char *, const char *, int); #ifdef _MSC_VER # define S_IXUSR _S_IEXEC -# define stat _stat # ifndef _INTPTR_T_DEFINED # define intptr_t int # endif @@ -2841,7 +2830,7 @@ int setenv (const char *, const char *, int); } while (0) #undef LTWRAPPER_DEBUGPRINTF -#if defined DEBUGWRAPPER +#if defined LT_DEBUGWRAPPER # define LTWRAPPER_DEBUGPRINTF(args) ltwrapper_debugprintf args static void ltwrapper_debugprintf (const char *fmt, ...) diff --git a/ChangeLog b/ChangeLog index b702907..8d83a7b 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,17 @@ 2009-01-21 Charles Wilson libt...@cwilson.fastmail.fm + [cygwin|mingw] Fix compile warnings when -std=c89. + * libltdl/config/ltmain.m4sh (func_emit_wrapper_part1): + move contents to... + (func_emit_wrapper_part2): move contents to... + (func_emit_wrapper): here. + (func_emit_cwrapperexe_src) [file scope]: Remove + variables script_text_part1 and script_text_part2. + (func_emit_cwrapperexe_src) [lt_dump_script]: New function. + (func_emit_cwrapperexe_src) [main]: Call it. + +2009-01-21 Charles Wilson libt...@cwilson.fastmail.fm + Minor cygwin cleanup * libltdl/config/ltmain.m4sh (func_generate_dlsyms): Correct case pattern for cygwin. diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh index 760f647..3f1a30c 100644 --- a/libltdl/config/ltmain.m4sh +++ b/libltdl/config/ltmain.m4sh @@ -2308,15 +2308,23 @@ func_extract_archives () } - -# func_emit_wrapper_part1 [arg=no] +# func_emit_wrapper [arg=no] # -# Emit the first part of a libtool wrapper script on stdout. -# For more information, see the description associated with -# func_emit_wrapper(), below. -func_emit_wrapper_part1 () +# Emit a libtool wrapper script on stdout. +# Don't directly open a file because we may want to +# incorporate the script contents within a cygwin/mingw +# wrapper executable. Must ONLY be called from within +# func_mode_link because it depends
Re: Run tests with low max_cmd_len on MSYS/MSVC
Ralf Wildenhues wrote: We may need to think about speeding up func_to_host_path, e.g., by not forking for arguments that don't need conversion, or by converting several paths with a constant amount of forks. But that can be done separately. FWIW, as part of re-writing this: [PATCH] [cygwin]: Add cross-compile support to cwrapper http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg6.html I plan to split up the various case $host/case $build clauses in the func_to_host_path functions into separate functions. Then, using a configure test determine which function should be called via a libtool variable $build_to_host_path_cmd and $build_to_host_pathlist_cmd. The default value will be a function that simply assigns build_to_host_path_result=$1 Then, we can target specific functions for speedups as needed. Ok plan? -- Chuck
Re: spaces
Ralf Wildenhues wrote: OK so it seems there are more voices for spaces. Can we agree to make the switch only after 2.2.8 though, I would like to avoid unnecessary churn ATM. Works for me. -- Chuck
Re: [PATCH] [cygwin|mingw] Fix compile warnings when -std=c89.
Ralf Wildenhues wrote:
I don't see a need to skip the test elsewhere. Here's what I'd do:
transform $LIBTOOL to have CFLAGS and LTCFLAGS also contain -std=c89
-Werror. (The test would be even cleaner with a re-configured libtool,
but let's not go overboard here.)
Being a total novice with autotest, I couldn't figure out how to do the
former, so I did the latter. Attached is my first attempt. It probably
should be named something other than 'c89 test' because that name
implies building all of libtool (including libltdl) with -std=c89. But I
couldn't think of anything else to call it.
If you'd like to knock it into better shape, I wouldn't mind...
--
Chuck
diff --git a/Makefile.am b/Makefile.am
index 790..726b898 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -467,6 +467,7 @@ TESTSUITE_AT= tests/testsuite.at \
tests/indirect_deps.at \
tests/archive-in-archive.at \
tests/execute-mode.at \
+ tests/c89.at \
tests/infer-tag.at \
tests/localization.at \
tests/install.at \
--- a/tests/c89.at 2006-11-30 19:00:00.0 -0500
+++ b/tests/c89.at 2009-01-21 21:32:01.79210 -0500
@@ -0,0 +1,85 @@
+# c89.at -- test compliance with c89 standard -*- Autotest -*-
+
+# Copyright (C) 2009 Free Software Foundation, Inc.
+# Written by Charles Wilson, 2009
+#
+# This file is part of GNU Libtool.
+#
+# GNU Libtool is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# GNU Libtool is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GNU Libtool; see the file COPYING. If not, a copy
+# can be downloaded from http://www.gnu.org/licenses/gpl.html,
+# or obtained by writing to the Free Software Foundation, Inc.,
+# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+
+
+AT_SETUP([c89 test])
+AT_KEYWORDS([libtool])
+
+# make sure existing libtool is configured for shared libraries
+AT_CHECK([$LIBTOOL --features | grep 'disable shared libraries' (exit 77)],
+[1], [ignore])
+
+# make sure CFLAGS -std=c89 -Werror do not cause a failure
+# themselves (e.g. because a non-gcc compiler doesn't support
+# those flags).
+AT_DATA([trivial.c],
+[[
+int main (void)
+{
+ return 0;
+}
+]])
+AT_CHECK([$LIBTOOL --mode=compile $CC $CPPFLAGS $CFLAGS -std=c89 -Werror -c
trivial.c || exit 77],[0],[ignore],[ignore])
+
+AT_DATA([configure.ac],
+[[AC_INIT([app-uses-sharedlib-demo], ]AT_PACKAGE_VERSION[,
]AT_PACKAGE_BUGREPORT[)
+AC_CONFIG_AUX_DIR([config])
+AC_CONFIG_MACRO_DIR([m4])
+AM_INIT_AUTOMAKE([foreign])
+LT_INIT([win32-dll disable-static])
+AC_CONFIG_FILES([Makefile])
+AC_OUTPUT
+]])
+AT_DATA([Makefile.am],
+[[ACLOCAL_AMFLAGS = -I m4
+AUTOMAKE_OPTIONS = 1.7
+lib_LTLIBRARIES = liba.la
+liba_la_LDFLAGS = -version-info 0:0:0 -no-undefined
+liba_la_SOURCES = liba.c
+bin_PROGRAMS = usea
+usea_SOURCES = usea.c
+usea_LDADD = liba.la
+]])
+AT_DATA([liba.c],
+[[int liba_func1 (int arg)
+{
+ return arg + 1;
+}
+]])
+AT_DATA([usea.c],
+[[extern int liba_func1(int arg);
+int main (void)
+{
+ int a = 2;
+ int b = liba_func1 (a);
+ if (b == 3) return 0;
+ return 1;
+}
+]])
+
+LT_AT_BOOTSTRAP([--copy --force], [-I m4 --force], [ignore],
+ [--add-missing --copy --force-missing], [--force], [CFLAGS='-std=c89
-Werror'], [])
+AT_CHECK([test -f liba.la])
+LT_AT_EXEC_CHECK([./usea], [0], [ignore], [ignore], [])
+
+AT_CLEANUP
Re: spaces
Bob Friesenhahn wrote: For many years I have had my editor configured to always use spaces. This ensures WYSIWYG for everyone involved. Agree 100%. I try to manually match whatever sp/tab convention is in place -- using vi if I have to -- but much prefer all spaces. -- Chuck
Re: [PATCH] [cygwin|mingw] fix dlpreopen with --disable-static take 2
Ralf Wildenhues wrote:
+# func_tr_sh
+# turn $1 into a string suitable for a shell variable name
+# result is stored in $func_tr_sh_result
+func_tr_sh ()
+{
+ func_tr_sh_result=`echo $1 | $SED -e 's/[^A-Za-z0-9_]/_/g'`
+ # ensure result begins with non-digit
+ case $func_tr_sh_result in
+[A-Za-z_][A-Za-z0-9_] ) ;;
+* ) func_tr_sh_result=_$func_tr_sh_result ;;
+ esac
+}
]])
Let's not waste processes when we don't have to, with something like
this untested bit:
func_tr_sh ()
{
case $1 in
[!a-zA-Z_]* | *[!a-zA-Z_0-9]*)
func_tr_sh_result=`$ECHO $1 | $SED 's/^[^a-zA-Z]/_/;
s/[^a-zA-Z0-9]/_/g'`
;;
*)
func_tr_sh_result=$1
;;
esac
}
Your version will confuse '1dumblibraryname.a' and '2dumblibraryname.a'
by turning both into '_dumblibraryname_a'. How about this:
# func_tr_sh
# turn $1 into a string suitable for a shell variable name
# result is stored in $func_tr_sh_result. All characters
# not in the set a-zA-z0-9_ are replaced with '_'. Further,
# if $1 begins with a digit, a '_' is prepended as well.
func_tr_sh ()
{
case $1 in
[0-9]* | *[!a-zA-Z_0-9]*)
func_tr_sh_result=`$ECHO $1 | $SED 's/^\([0-9]\)/_\1/;
s/[^A-Za-z0-9]/_/g'`
;;
* )
func_tr_sh_result=$1
;;
esac
}
Which makes it clear exactly what we're trying to do:
1) replace all bad chars with _
2) prepend _ if $1 begins with a digit
There is still a slight inefficiency in the above: IF $1 has all valid
characters, but happens to begin with a digit, then we fork a sed simply
to prepend the '_'. I doubt this will occur much. or ever -- and if it
does, the penalty is an extra fork, not wrong behavior.
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -1988,7 +1988,7 @@ extern \C\ {
eval '$GREP -f $output_objdir/$outputname.exp $nlist
$nlistT'
eval '$MV $nlistT $nlist'
case $host in
-*cygwin | *mingw* | *cegcc* )
+*cygwin* | *mingw* | *cegcc* )
eval echo EXPORTS ' $output_objdir/$outputname.def'
eval 'cat $nlist $output_objdir/$outputname.def'
;;
Is this fixing a bug? If yes, then it should be a separate patch,
documented in the ChangeLog entry, done likely in all other such
instances of missing '*' (I haven't found any), and would be obviously
correct and ok to push. Please, please don't mix heavy patches with
such cleanups. It only leads to cleanups being delayed.
It is not a bug fix, exactly. I just noticed the lack of symmetry, AND
that '*cygwin' never appears anywhere else, and figured it was a typo.
The actual cygwin $host patterns we see AFAIK all match *cygwin -- but
by convention we (libtool) allow extensions on triples for variant
$hosts. This violated that convention, but wasn't /exactly/ a bug.
I can prepare a separate patch and push, if you prefer.
In your take 3 of this patch series, you have this hunk:
| @@ -2217,7 +2217,7 @@ func_win32_libid ()
| ;;
|*ar\ archive*) # could be an import, or static
| if eval $OBJDUMP -f $1 | $SED -e '10q' 2/dev/null |
| - $EGREP 'file format (pe-i386(.*architecture:
i386)?|pe-arm-wince|pe-x86-64)' /dev/null; then
| + $EGREP 'file format (pei?-i386(.*architecture:
i386)?|pe-arm-wince|pe-x86-64)' /dev/null; then
|win32_nmres=`eval $NM -f posix -A $1 |
| $SED -n -e '
| 1,100{
Now, my memory is really bad about win32 semantics, but wasn't it
exactly pei-i386 libraries that we wanted to not match here?
Originally (before the introduction of [func_]win32_libid()), we had
pei*-i386:
cygwin* | mingw* | pw32*)
lt_cv_deplibs_check_method='file_magic file format
pei*-i386(.*architecture: i386)?'
When win32_libid() was first introduced, we moved the pei*-i386
incantation as-is into win32_libid():
grep -E 'file format pei*-i386(.*architecture: i386)?' /dev/null ; then
in 6da15e03aa1127eb42652a1f7e15ee42633dbfdf Thu Oct 31 00:52:39 2002
This was changed to
grep -E 'file format pe-i386(.*architecture: i386)?' /dev/null ; then
in 709bbb17317c67d28cf7ec8f0baaef16c4137ad0 Mon Feb 17 18:55:45 2003
Supposedly, this was part of a rewrite to improve speed. Looking at
the mailing list history from that era:
http://lists.gnu.org/archive/html/libtool-patches/2003-02/msg00048.html
No explanation was given for that particular change (my fault).
Looking at the original version of win32_libid() -- after 6da15e03 but
before 709bbb17 -- it originally did this:
if eval $OBJDUMP -f $1 2/dev/null | \
grep -E 'file format pei+-i386(.*architecture: i386)?' /dev/null ;
then
win32_libid_type=x86 DLL
else
if eval $OBJDUMP -f $1 2/dev/null | \
grep -E 'file format pei*-i386(.*architecture: i386)?' /dev/null
then
win32_libid_type=x86
if eval file $1 2/dev/null | \
grep -E 'ar archive' /dev/null; then
win32_libid_type=$win32_libid_type archive
if eval
[PATCH] Minor cygwin cleanup
libltdl/config/ltmain.m4sh (func_generate_dlsyms): Correct
case pattern for cygwin.
---
Ok to push?
libltdl/config/ltmain.m4sh |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 6be529a..760f647 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -1987,7 +1987,7 @@ extern \C\ {
eval '$GREP -f $output_objdir/$outputname.exp $nlist
$nlistT'
eval '$MV $nlistT $nlist'
case $host in
- *cygwin | *mingw* | *cegcc* )
+ *cygwin* | *mingw* | *cegcc* )
eval echo EXPORTS ' $output_objdir/$outputname.def'
eval 'cat $nlist $output_objdir/$outputname.def'
;;
--
1.6.0.4
Re: [PATCH] [cygwin|mingw] fix dlpreopen with --disable-static take 3
Charles Wilson wrote: Full test suite on cygwin in progress. Assuming it passes, ok for squash and push? Results: old test suite: === All 113 tests passed (11 tests were not run) === New test suite: ERROR: 76 tests were run, 4 failed (3 expected failures). 5 tests were skipped. The unexpected failure was 36: execute mode FAILED (execute-mode.at:193) but it is unrelated; it's a problem in cygwin-1.7's dos-style path detection...That's not a path! --- /dev/null 2006-11-30 19:00:00.0 -0500 +++ /usr/src/packages/libtool/git/build-cygwin-dlpreopen-fix-take2/tests/testsui te.dir/at-groups/36/stderr 2009-01-15 23:50:30.98180 -0500 @@ -0,0 +1,6 @@ +cygwin warning: + MS-DOS style path detected: d\e + Preferred POSIX equivalent is: d/e + CYGWIN environment variable option nodosfilewarning turns off this warning. + Consult the user's guide for more details about POSIX paths: +http://cygwin.com/cygwin-ug-net/using.html#using-pathnames stdout: abc d\e f\g xyz 36. execute-mode.at:25: 36. execute mode (execute-mode.at:25): FAILED (execute-m ode.at:193) OK? -- Chuck
Re: [PATCH] [cygwin|mingw] Fix compile warnings when -std=c89.
Charles Wilson wrote: Charles Wilson wrote: * libltdl/config/ltmain.m4sh: Update copyright date. (func_emit_wrapper_part1): move contents to... (func_emit_wrapper_part2): move contents to... (func_emit_wrapper): here. (func_emit_cwrapperexe_src) [file scope]: re-organized includes and portability macros. Avoid oldnames on MINGW32 and MSVC for setmode/stat/chmod/getcwd/putenv. Declare _putenv on MINGW32 when -ansi. Use namespaced macro LT_DEBUGWRAPPER. Remove variables script_text_part1 and script_text_part2. (func_emit_cwrapperexe_src) [lt_dump_script]: New function. (func_emit_cwrapperexe_src) [main]: Call it. Ping? Ping x 2? -- Chuck
[PATCH] [cygwin|mingw] fix dlpreopen with --disable-static take 3
* libltdl/m4/libtool.m4 (_LT_CHECK_SHAREDLIB_FROM_LINKLIB):
New macro sets sharedlib_from_linklib_cmd variable.
(_LT_DECL_DLLTOOL): New macro ensures DLLTOOL is always set.
* libltdl/config/ltmain.m4sh (func_generate_dlsyms): Use
$sharedlib_from_linklib_cmd instead of directly invoking
func_win32_dllname_for_implib when
libfile_$(transliterated implib name) does not exist.
(func_win32_libid): Accomodate pei-i386 import libs
as well as pe-i386.
(func_dlltool_identify): Removed.
(func_win32_dllname_for_implib): Removed. Replaced by...
(func_cygming_dll_for_implib): this,
(func_cygming_dll_for_implib_fallback): this,
(func_cygming_dll_for_implib_core): ...and this.
(func_cygming_implib_p): New function.
(func_cygming_ms_implib_p): New function.
---
This is a follow-on to:
http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg2.html
If the end result of these two patches is acceptable, I'll squash it
before merging to master. But, here's the rationale for the changes
here:
1) Try to make it easier for Peter to add MSVC-specific versions
of this functionality, by invoking the IMPLIB-to-DLL function
via a libtool variable (*)
2) Set that variable during configure
3) While we're at it, even on cygwin/mingw, decide whether to
use dlltool --identify or the nm/objdump-based shell script
fallback also at configure time
4) Since Danny Smith reports that even on mingw, ld can link
against MS-style import libraries, then ensure that both
versions of the IMPLIB-to-DLL function can perform properly
whether the implib is binutils- or ms- style.
a) dlltool (two patches, both already accepted):
http://sourceware.org/ml/binutils/2009-01/msg00120.html
http://sourceware.org/ml/binutils/2009-01/msg00179.html
b) improved sed-fu in func_cygming_dll_for_implib_core
with wrapper func_cygming_dll_for_implib_fallback.
Wrapper determines `style' of the implib, and invokes
the *_core() function with the appropriate arguments.
(*) Peter could implement two functions for msvc, as well: one
that directly invokes the new dllname application, and the other
which uses different, msvc-specific sed-fu on the output of
$NM (which in this case is actually `dumpbin --symbols'?). Then
in _LT_CHECK_SHAREDLIB_FROM_LINKLIB the determination could be
make as to which one to use, when $host is mingw and $CC is msvc.
Of course, if dllname does not become an official part of msys,
then Peter's additions to _LT_CHECK_SHAREDLIB_FROM_LINKLIB
would just set $sharedlib_from_linklib_cmd to the function
containing the msvc-sed-fu.
Limitation: although I have beat this sed-fu to death *outside*
of libtool, and am pretty confident it works well, there is no
actual test of that code in the testsuite. This is because well-
behaved libtool clients -- and our tests are actually well-behaved
in this regard -- will only -dlpreopen *libtool*-built libraries.
In that case, Ralf's suggested libfile_$(transliterated implib name)
is used, because we have the .la file available which allows that
shortcut. The only time we need `dlltool --identify' is when
dlpreopening a non-libtool implib, where we have no .la file.
And the sed-fu is a fallback to THAT fallback.
Also: is there someplace that libtool variables like
$sharedlib_from_linklib_cmd should be documented?
I did run configure and the demo-shared/demo-make/demo-exec tests
with (a) old --identify-less dlltool and (b) new --identify
dlltool. In each case, configure picked the correct function
for $sharedlib_from_linklib_cmd, and those tests passed.
Full test suite on cygwin in progress. Assuming it passes,
ok for squash and push?
Next step: make an actual package out of impgen2/dllname,
upload to mingw/sourceforge, and see if I can't convince Cesar
and Keith that it should be included in the 'base' MSYS for
release 1.0.11.
--
Chuck
libltdl/config/ltmain.m4sh | 200 +---
libltdl/m4/libtool.m4 | 50 +++
2 files changed, 165 insertions(+), 85 deletions(-)
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 503457c..d701436 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -2016,8 +2016,8 @@ extern \C\ {
dlprefile_dlbasename=$func_basename_result
else
# no lafile. user explicitly requested -dlpreopen import
library.
- func_win32_dllname_for_implib $dlprefile
- dlprefile_dlbasename=$func_win32_dllname_for_implib_result
+ eval '$sharedlib_from_linklib $dlprefile'
+ dlprefile_dlbasename=$sharedlib_from_linklib_result
fi
fi
$opt_dry_run || {
@@ -2217,7 +2217,7 @@ func_win32_libid ()
;;
*ar\ archive*) # could be an import, or static
if eval $OBJDUMP -f $1 | $SED -e '10q' 2/dev/null |
- $EGREP 'file format
Re: [PATCH] [cygwin|mingw] fix dlpreopen with --disable-static take 2
Peter Rosin wrote: Den 2009-01-06 02:06 skrev Charles Wilson: Maybe under that name. But a libbfd-ified version of impgen (as a replacement for the IMO totally broken -- but part of mingw-utils-0.3 -- reimp program), that happens to also supply an --identify foo --identify-ms functionality? Not so far-fetched. Right, but it still seems as if this new fixed impgen tool is closer to MinGW than to MSYS proper. However, as you say, better ask on a better list... After playing with this idea for a while, it made more sense actually to separate the impgen2 functionality from the dllname stuff. It's not yet ready for prime time (and I'm trying to keep it in sync with on-going changes to dlltool in binutils HEAD), but I'll send my latest version of these new tools to you offlist. They compile with both cygwin-gcc (using libiberty and libbfd from 20080624), and with mingw-gcc-3.4.5 (not sure what binutils version I have; one of the more recent releases from mingw/sourceforge I'm sure). Also, it will not fail for Vfw32.Lib, it will instead list the three dlls it imports (AVICAP32.dll, AVIFIL32.dll, MSVFW32.dll). Well, we probably want it to fail. So, for the sake of argument, I agree that it should fail. But then I think it should fail in libtool, not in the tool that digs out the dll name(s) from the import library. But that's a minor point... Well, see this and the following thread: http://sourceware.org/ml/binutils/2008-11/msg00078.html I'm only saying that from the binutils p.o.v. it makes at least some sence to report all imported dlls. At least optionally, but again, this was just a minor point... A new patch to binutils' dlltool was accepted that makes the following changes to --identify: 1) automatically determines -- and operates with -- MS-style or binutils-style implibs 2) by default, lists all imported DLLs 3) new --identify-strict flag causes multiple imported DLLs to be reported as an error http://sourceware.org/ml/binutils/2009-01/msg00152.html -- Chuck
Re: [PATCH] [cygwin|mingw] Fix compile warnings when -std=c89.
Charles Wilson wrote: * libltdl/config/ltmain.m4sh: Update copyright date. (func_emit_wrapper_part1): move contents to... (func_emit_wrapper_part2): move contents to... (func_emit_wrapper): here. (func_emit_cwrapperexe_src) [file scope]: re-organized includes and portability macros. Avoid oldnames on MINGW32 and MSVC for setmode/stat/chmod/getcwd/putenv. Declare _putenv on MINGW32 when -ansi. Use namespaced macro LT_DEBUGWRAPPER. Remove variables script_text_part1 and script_text_part2. (func_emit_cwrapperexe_src) [lt_dump_script]: New function. (func_emit_cwrapperexe_src) [main]: Call it. Ping?
Re: [PATCH] [cygwin|mingw] fix dlpreopen with --disable-static take 2
Peter Rosin wrote:
Den 2009-01-05 06:24 skrev Charles Wilson:
Interesting! Meanwhile, I have done some experiments on my own, as I
don't like the dependence on anything that comes with MinGW when
dealing with libtool and MSVC.
I kind of suspected that. What about the attached? This version needs
to link against libbfd and its dependencies -- so has to be compiled
using mingw gcc. But if this executable was included as part of msys?
(Speaking of dependencies, I don't think the current MinGW code
in libtool requires 'file' to be present, and I don't think it is
part of a minimal MSYS install. It's not in my install anyway.)
Only because its been over two years since msys 1.11 will be ready
RSN. It is intended that the file package be included in the minimal
1.11 install.
I have found that for MSVC import libraries the simplest thing is
to list the archive members to get to the dll name. I have tried
with:
lib -nologo -list $implib | grep -v '\.obj$' | sort -u
or, in gnu speak:
ar t $implib | grep -v '\.obj$' | sort -u
I noticed that, but wasn't sure if self-compiled (using MSVC) import
libraries were the same.
This works for all troublesome implibs that you have listed above
(at least those that I have easy access to, but I have at least one
from each class of problems) and a few others. Except for MAPI.lib,
but my MS provided dumpbin.exe (VS 2005) says
MAPI.lib : warning LNK4048: Invalid format file; ignored
for that one so I too think it is a pathological case.
Ack.
Also, it will not fail for Vfw32.Lib, it will instead list the three
dlls it imports (AVICAP32.dll, AVIFIL32.dll, MSVFW32.dll).
Well, we probably want it to fail. dlpreopen is supposed to work like
dlopen -- and you'd need to dlopen each of the three DLLs separately.
But if you -dlpreopen Vfw32.Lib, you'd need to determine which symbols
IN Vfw32.Lib came from which DLL, and generate three different groups in
you LT_LTX_*[] structure, to register those symbols with their effective
dlopen source:
{ AVICAP32.dll, 0 }
{ symbols }
{ AVIFIL32.dll, 0 }
{ symbols }
{ MSVFW32.dll, 0 }
{ symbols }
I don't think this is going to work well.
Using MS tools (instead of file or objdump -f) to identify if a .lib
is an import lib or a static lib seems to be trickier. One thing
that appears to work is to look for an __IMPORT_DESCRIPTOR_* symbol,
but that can obviously be thwarted by a devious (or ignorant) user...
That's ok. Rule #486: don't deliberately try to undermine your tools,
and then expect them to work.
BTW, those symbols also identifies the imported dll (but that breaks
when that which is imported isn't named foo.dll). E.g.
dumpbin -symbols $lib | grep '| __IMPORT_DESCRIPTOR_'
(output for Vfw32.Lib
001 SECT2 notype External |
__IMPORT_DESCRIPTOR_MSVFW32
001 SECT2 notype External |
__IMPORT_DESCRIPTOR_AVIFIL32
001 SECT2 notype External |
__IMPORT_DESCRIPTOR_AVICAP32
)
or, in gnu speak:
nm $lib | grep 'I __IMPORT_DESCRIPTOR_'
(output for Vfw32.Lib
I __IMPORT_DESCRIPTOR_MSVFW32
I __IMPORT_DESCRIPTOR_AVIFIL32
I __IMPORT_DESCRIPTOR_AVICAP32
)
Yeah, I wanted to avoid assuming that non-libtool shared libraries
always in in *.dll, because many packages (especially ones that do
dlopen/dlpreopen) still name their modules foo.so even on
cygwin/mingw. Take ImageMagick, for instance.
But...I also dislike for fixes to existing bugs, in existing platforms,
to be held up by not-yet-in-master support for other compilers. So, can
we get back to discussing the original patch, under the predicates of
cygwin and mingw (not msvc) $hosts?
Hey, I'm not opposed to the patch, I didn't intend to make that impression
either, sorry if I did. I'm just trying to determine what needs to be
done in the MSVC branch to keep up. Just poking and asking questions,
so thank you very much for your valuable input!
Oh, ok. Thanks.
--
Chuck
/* dllname.c -- tool to extract the name of the DLL associated with
an import library.
Copyright 2008 Charles S. Wilson
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 3 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 51 Franklin Street - Fifth Floor, Boston, MA
02110-1301, USA. */
#include stdio.h
#include stdarg.h
#include bfd.h
#include ansidecl.h
#include unistd.h
Re: [PATCH] [cygwin|mingw] Fix compile warnings when -std=c89.
Roumen Petrov wrote: Charles Wilson wrote: [SNIP] This patch attempts to correct the issues raised in this thread: msys/mingw warnings about string length and putenv absence with gcc -Wall -ansi http://lists.gnu.org/archive/html/bug-libtool/2008-12/msg00038.html [SNIP] Patch fail for trunk(origin): 10 out of 11 hunks FAILED -- saving rejects to file libltdl/config/ltmain.m4sh.rej I'm confused. I just did a 'git pull' on master, and my master was up-to-date. Then I did a 'git rebase master' on my branch, and it said 'Current branch cygwin-c89-fix is up to date.' So then I tried to apply the patch to my master (dry-run): patch -p1 --dry-run ../0010--cygwin-mingw-Fix-compile-warnings-when-std-c89.patch patching file libltdl/config/ltmain.m4sh and it worked fine. Maybe the patch got mangled in the mail. I'll send it privately to you as an attachment. -- Chuck
Re: [PATCH] [cygwin|mingw] fix dlpreopen with --disable-static take 2
Charles Wilson wrote:
Peter Rosin wrote:
I'm primarily trying to determine what impact this has on my
MSVC branch...
Ran some experiments on the libraries shipped with the Windows SDK. The
attached script worked ok on most of them. After eliminating the static
libraries and the import libraries to '*.dll' and '*.DLL' (241
successes in all), I'm left with the following 13 odd ducks:
These are correct, but are a reminder that import libraries exist for
objects other than those named foo.dll. So that's 5 more successes:
KSProxy.Lib :x86 archive import FOR ksproxy.ax
bthprops.lib :x86 archive import FOR bthprops.cpl
irprops.lib :x86 archive import FOR irprops.cpl
NetSh.Lib :x86 archive import FOR NETSH.EXE
WinSpool.Lib :x86 archive import FOR WINSPOOL.DRV
These are the true failures:
For the following 6 libraries, it is the LAST archive member with a
.idata$6 section, not the first one, that specifies the DLL.
GdiPlus.lib :x86 archive import FOR u.GdiplusStartup
MSTask.Lib :x86 archive import FOR .._setnetscheduleaccountinformat...@12
WS2_32.Lib :x86 archive import FOR ..inet_pton
ksuser.lib :x86 archive import FOR ..KsCreateTopologyNode
shell32.lib :x86 archive import FOR =.WOWShellExecute
windowscodecs.lib :x86 archive import FOR q.WICSetEncoderFormat_Proxy
This one imports symbols from multiple DLLs. One of them happens to be
in the last archive member, but...
Vfw32.Lib :x86 archive import FOR -.StretchDIB
I have no idea what this one is. objdump can't grok it:
MAPI.Lib :MAPI.Lib: Microsoft Visual C library
$ objdump -f MAPI.Lib
objdump: MAPI.Lib: File format not recognized
So that's 246 PASS, 8 FAIL.
But I wonder if these 8 failures are just pathological cases, and the
code embodied in the attached script is good enough -- assuming an
msvc-configured libtool is allowed to use file, objdump, nm, etc.
Doctor, func_dll_from_imp fails for library shell32.lib, so I can't
dlpreopen it...Ok, don't do that then.
NOTE:
I had to change the grep expression:
*ar\ archive*) # could be an import, or static
if objdump -f $1 | sed -e '10q' 2/dev/null |
grep -E 'file format pei?-i386(.*architecture: i386)?' /dev/null
; then
from ...pe-i386(... to ...pei?-i386(... so that some of the import
libraries were recognized as such. I'm not sure what the distinction
between pe-i386 and pei-i386 is, or what the implications of this
particular change would be.
FWIW, I think this sed script is safer than the other one, even at the
cost of an extra fork. Keeping the contents of each archive member on a
separate line, rather than merging them all together, just seems better.
--
Chuck
#!/bin/sh
DLLNAME_SECTION=.idata\$6
# mostly the same as libtool's function of the same name,
# except that it stores the result in an explicitly-accessible
# *_result variable. Still echos, tho. Also, the grep -E
# expression is slightly different: pe-i386 - pei?-i386
func_win32_libid ()
{
func_win32_libid_result=unknown
win32_fileres=`file -L $1 2/dev/null`
case $win32_fileres in
*ar\ archive\ import\ library*) # definitely import
func_win32_libid_result=x86 archive import
;;
*ar\ archive*) # could be an import, or static
if objdump -f $1 | sed -e '10q' 2/dev/null |
grep -E 'file format pei?-i386(.*architecture: i386)?' /dev/null ; then
win32_nmres=`eval nm -f posix -A $1 2/dev/null |
sed -n -e '
1,100{
/ I /{
s,.*,import,
p
q
}
}'`
case $win32_nmres in
import*) func_win32_libid_result=x86 archive import ;;
*) func_win32_libid_result=x86 archive static;;
esac
fi
;;
*DLL*)
func_win32_libid_result=x86 DLL
;;
*executable*) # but shell scripts are executable too...
case $win32_fileres in
*MS\ Windows\ PE\ Intel*)
func_win32_libid_result=x86 DLL
;;
esac
;;
esac
echo $func_win32_libid_result
}
# same as libtool's, from master
func_win32_import_lib_p ()
{
case `func_win32_libid $1 2/dev/null | sed -e 10q` in
*import*) : ;;
*) false ;;
esac
}
# Odd. For some reason I can't capture this directly in
# backticks. So, use a level of indirection:
func_dll_for_imp_core ()
{
objdump -s --section $DLLNAME_SECTION $1 2/dev/null |
sed '/^Contents of section '$DLLNAME_SECTION':/{
# Place marker at beginning of archive member dllname section
s/.*/MARK/
p
d
}
# These lines can sometimes be longer than 43 characters, but
# are always uninteresting
/:[ \t]*file format pe[i]\{,1\}-i386$/d
/^In archive [^:]*:/d
# Ensure marker is printed
/^MARK/p
# Remove all lines with less than 43 characters
/^.\{43\}/!d
# From remoaining lines, remove first 43 characters
s/^.\{43\}//' |
sed -n '
# Join marker and all lines until next marker into a single line
Re: [PATCH] [cygwin|mingw] fix dlpreopen with --disable-static take 2
Charles Wilson wrote:
Charles Wilson wrote:
Peter Rosin wrote:
I'm primarily trying to determine what impact this has on my
MSVC branch...
Ran some experiments on the libraries shipped with the Windows SDK. The
attached script worked ok on most of them. After eliminating the static
libraries and the import libraries to '*.dll' and '*.DLL' (241
successes in all), I'm left with the following 13 odd ducks:
These are correct, but are a reminder that import libraries exist for
objects other than those named foo.dll. So that's 5 more successes:
KSProxy.Lib :x86 archive import FOR ksproxy.ax
bthprops.lib :x86 archive import FOR bthprops.cpl
irprops.lib :x86 archive import FOR irprops.cpl
NetSh.Lib :x86 archive import FOR NETSH.EXE
WinSpool.Lib :x86 archive import FOR WINSPOOL.DRV
These are the true failures:
For the following 6 libraries, it is the LAST archive member with a
.idata$6 section, not the first one, that specifies the DLL.
GdiPlus.lib :x86 archive import FOR u.GdiplusStartup
MSTask.Lib :x86 archive import FOR .._setnetscheduleaccountinformat...@12
WS2_32.Lib :x86 archive import FOR ..inet_pton
ksuser.lib :x86 archive import FOR ..KsCreateTopologyNode
shell32.lib :x86 archive import FOR =.WOWShellExecute
windowscodecs.lib :x86 archive import FOR q.WICSetEncoderFormat_Proxy
This one imports symbols from multiple DLLs. One of them happens to be
in the last archive member, but...
Vfw32.Lib :x86 archive import FOR -.StretchDIB
I have no idea what this one is. objdump can't grok it:
MAPI.Lib :MAPI.Lib: Microsoft Visual C library
$ objdump -f MAPI.Lib
objdump: MAPI.Lib: File format not recognized
So that's 246 PASS, 8 FAIL.
So, I've prepared a patch for dlltool which adds an '--identify-ms'
flag, which modifies the behavior of the '--identify implib' option.
It searches for .idata$6 instead of .idata$7, AND attempts to
disambiguate between the one that specifies the DLL name and all the
other ones that list the symbols by inspecting the flags.
In almost all cases, the one that specifies the DLL name has the flag
value 0x0123
SEC_ALLOC | SEC_LOAD | SEC_DATA | SEC_HAS_CONTENTS
The other ones have flag values 0x00204103
SEC_ALLOC | SEC_LOAD | SEC_HAS_CONTENTS | SEC_IN_MEMORY | SEC_KEEP
This version of dlltool was able to operate on all of the import
libraries in the Windows SDK, except for:
MAPI.Lib: MAPI.Lib: Microsoft Visual C library
=== again, because bfd has no idea how to parse this one
Vfw32.Lib: Import library `Vfw32.Lib' specifies two or more dlls:
`MSVFW32.dll' and `AVIFIL32.dll'
And the following:
WebPost.Lib: x86 archive import FOR WEBPOST.DLL
ddao35.lib: x86 archive import FOR ddao35.dll
ddao35d.lib: x86 archive import FOR ddao35d.dll
ddao35u.lib: x86 archive import FOR ddao35u.dll
ddao35ud.lib: x86 archive import FOR ddao35ud.dll
More on these, later.
Note that this dlltool /succeeded/ on
GdiPlus.lib
MSTask.Lib
WS2_32.Lib
ksuser.lib
shell32.lib
windowscodecs.lib
where the script in my previous post failed. Dlltool can handle the case
where the one that specifies the DLL name is not first.
The five new failures (where the script succeeded) are interesting. In
each case, the rule above (the one has flag value 0x0123, and
the others do not) was incorrect:
$ ~/dlltool.exe --identify WebPost.Lib --identify-ms
flags: 0x0123 datasize: 000c data: 'WEBPOST.DLL'
5745 4250 4f53 542e 444c 4c00 WEBPOST.DLL.
flags: 0x0123 datasize: 0010 data: ''
0400 5770 4269 6e64 546f 5369 7465 4100 ..WpBindToSiteA.
/home/cwilson/dlltool: Import library `WebPost.Lib' specifies two or
more dlls: `WEBPOST.DLL' and `'
The error message is a little confusing: `WEBPOST.DLL' and `'? The
empty name is because the data contains the unprintable character \004
followed by '\0'. Recall for symbols, the first two bytes are a
little-endian count. So this is symbol 0x0004. I *guess* I could check
that both offset 0 and offset 1 contain printable characters. But that's
still just a heuristic, because a really big DLL might have
01my_symbol
where the first two bytes are 0x30 0x31 ('01') representing symbol
number 0x3130 or 12352.
But this wierd case occurs only when the import library appears to NOT
follow the pattern most of them do. In fact, in these five import
libraries, ALL of the .idata$6 sections have flag 0x0123, not just
the one we want.
But, what are they? Do we care?
The ddao35 libraries are the Microsoft JET 3.5 DAO C++ libraries, for
DOS-Win16 (!). Microsoft shipped the Jet 4.0 libraries with WinME and
W2k, and recommends against using ones older than that. Do we care that
you won't be able to dlpreopen (or dlltool --identify) these ancient
import libraries?)
Webpost.Lib (-- webpost.dll) seems to be part of the Web Publishing
Wizard API. I can't find
Re: [PATCH] [cygwin|mingw] Fix compile warnings when -std=c89.
Charles Wilson wrote: Spot checked some regression tests on cygwin (all passed). Running full regression suite on mingw. OK to push, pending testsuite results? No regressions on msys/mingw from the last time I ran the testsuite on that platform (2.2.5a). IOW: Old testsuite results: 5 of 106 tests failed (18 tests were not run) Please report to bug-libt...@gnu.org FAIL: tests/mdemo-dryrun.test FAIL: tests/demo-exec.test (after demo-shared [*]) FAIL: tests/f77demo-static.test FAIL: tests/f77demo-conf.test FAIL: tests/f77demo-shared.test [*] probably fixed by my other patch New testsuite results: ERROR: 77 tests were run, 6 failed (3 expected failures). 4 tests were skipped. 65: compiling softlinked libltdl FAILED (recursive.at:71) 66: compiling copied libltdl FAILED (recursive.at:91) 67: installable libltdlFAILED (recursive.at:113) 80: Run tests with low max_cmd_len (ctrl-C'ed, so not incl. in tally) OK to push? -- Chuck
[PATCH] [cygwin]: Add cross-compile support to cwrapper
libltdl/config/ltmain.m4sh: (func_cygpath): New function.
(func_wine_to_win32_path): New function. Refactored from...
(func_msys_to_win32): New function supports converting both
paths and pathlists. Refactored from...
(func_to_host_path): ...here.
[msys-mingw]: Use refactored func_msys_to_win32.
[*nix-mingw]: Use refactored func_wine_to_win32_path.
[cygwin-mingw]: Simplify.
[cygwin-cygwin]: New. Explicit no-op.
[msys-cygwin]: New. Use func_msys_to_win32 + func_cygpath.
[*nix-cygwin]: New. Use func_wine_to_win32_path + func_cygpath.
(func_wine_to_win32_pathlist): New function. Refactored from...
(func_to_host_pathlist): ...here.
[msys-mingw]: Use refactored func_msys_to_win32.
[*nix-mingw]: Use refactored func_wine_to_win32_pathlist.
[cygwin-mingw]: Simplify.
[cygwin-cygwin]: New. Explicit no-op.
[msys-cygwin]: New. Use func_msys_to_win32 + func_cygpath.
[*nix-cygwin]: New. Use func_wine_to_win32_pathlist + func_cygpath.
---
Just as unix - mingw cross builds need special support when
creating the cwrapper source code in order for the cwrapper
to work properly under the wine environment, so too do unix -
cygwin cross builds. However, this led to a lot of duplicated
code, so I refactored a bit.
Now, native cygwin and native mingw both still work ok. What I
can't test is whether I've broken the existing unix - mingw
support. Nor can I actually test the new unix - cygwin
support. I *think* it all should work, but I'd like for
somebody to verify that for me. Please?
NOTE: At present, to use the unix - cygwin support, you *MUST*
have the LT_CYGPATH environment variable exported, containing
the *unix* (that is, $build) path to the cygpath.exe you want
to use. In the final patch, I'll prepare some documentation
to that effect, but right now the implementation is probably
in flux pending feedback.
Here's the comment block in ltmain.m4sh describing this:
# [*] The full *nix path to the cygpath program must be
# specified in the LT_CYGPATH environment variable. This
# is because (a) cygpath shouldn't be in $PATH, because it
# usually lives in cygwin's bin/ directory -- along with
# *cygwin* versions of sed, id, cp. If the unix build
# environment had those programs in its $PATH, many bad
# things could happen. (b) especially in cygwin-1.7, multiple
# installations (with separate mount tables in
# CYGROOT-N/etc/fstab) can coexist on the same Win32
# instance. The cygpath.exe for cygwin installation #N in
# CYGROOT-N/bin automatically deduces the appropriate
# ../etc/fstab file. Therefore, it matters which cygpath.exe
# is used. LT_CYGPATH may be replaced or supplemented by an
# LT_INIT-activated configure option in the future.
In re: LT_INIT, I was thinking maybe LT_INIT([win32-dll cygcross])
where the developers of client packages could enable a configure
option, so that end users could do:
configure \
--host=cygwin \
--cygpath=/opt/cygwin-1.7-unstable/bin/cygpath.exe \
other args
Then, func_cygpath would default to using the specified
cygpath, unless LT_CYGPATH overrides. But I haven't worked
out all the details...eventually I need to set up my own
cygwin-under-wine installation. g Anyway, if cygcross did
not appear as an LT_INIT option, then --cygpath wouldn't
be available (but setting LT_CYGPATH would always work).
Comments? Reviews? *Test Results*?
Oh: one other thing. I know using 'win32' is frowned
upon by the FSF/RMS. But I somehow need to distinguish
between cygwin paths, msys paths, and actual win32
paths. I have several functions now named
func_*_to_win32*(). Got any suggestions? mingw is
actually ambiguous, as it could also refer to unix-style
msys paths. mingw_native might be okay, but it's rather
wordy.
==
Chuck
libltdl/config/ltmain.m4sh | 259 +++-
1 files changed, 209 insertions(+), 50 deletions(-)
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 20ca07b..7677846 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -2557,6 +2557,73 @@ func_emit_wrapper ()
func_emit_wrapper_part2 ${1-no}
}
+# func_wine_to_win32_path arg
+# helper function used by func_to_host_path
+# when $build is neither mingw/msys nor cygwin, and
+# arg must be converted to win32 ($host is mingw or
+# cygwin).
+#
+# result is available in $func_wine_to_win32_path_result
+# result is empty on error (or when arg is empty)
+func_wine_to_win32_path ()
+{
+ lt_sed_naive_backslashify='s|*|\\|g;s|/|\\|g;s|\\||g'
+ func_wine_to_win32_path_result=$1
+ if test -n $1; then
+# Unfortunately, winepath does not exit with a non-zero
+# error code, so we are forced to check the contents of
+# stdout. On the other hand, if the command is not
+# found, the shell will set an exit code of 127 and print
+# *an error message* to stdout. So we must check for both
+# error code of zero AND non-empty stdout, which explains
+# the odd construction:
+
Re: [PATCH] [cygwin|mingw] fix dlpreopen with --disable-static take 2
Peter Rosin wrote: I'm primarily trying to determine what impact this has on my MSVC branch... Den 2009-01-03 02:39 skrev Charles Wilson: *snip* +*cygwin* | *mingw* | *cegcc* ) We should strive to have fewer of these in ltmain.m4sh, not more. Yep. But the problem is, there are really two BIG categories of platforms: those that support ELF-semantics for shared libraries, and those that support PE-DLL semantics. The differences between, say, HP and Linux are in this regard much less significant than the differences between win32 (cygwin, mingw, msvc, even wince) and any *nixoid. And vice verse: cygwin and msvc are much more similar *with regards to the construction of shared libraries* than they are different (even though the implib/static lib formats are non-interchangeable). I'm not sure it would be an improvement, exactly, but we could have a libtool variable $LT_HOST_SUPPORTS_PE_DLL (or a function that takes $host), and replace many of these case $host in *cygwin* | *mingw* | *cegcc* ) ... ;; everything else ) ... ;; esac occurences with 'if host_supports_pe_dll ; then ... ; else ... ; fi' Still ugly, but it means you only have to fix the case $host pattern in one place. + func_warn Using fallback code to determine dllname for $1; consider updating binutils to version 2.20 (2.19.50.20081115), or newer. I fail to find that version of binutils in Cygwin setup, so I guess the fallback code will get exercised. Not exactly. Background: the --identify option is supported only in CVS. There has not yet been an official binutils release containing that code. Furthermore, cygwin's official binutils, while based on a CVS snapshot, is from 20080624. So, no, if you want it you have to compile it yourself. Same for the mingw-provided binutils. But, func_win32_dllname_for_implib is only ever called if we were unable to find the .la file for the implib. Normally, you'd do something like: -dlpreopen foo.la and then, the libfile_$(transliterated implib name) stuff is used, not func_win32_dllname_for_implib. You only use that function if somebody did: -dlpreopen /path/to/foo.dll.a (maybe because they had no .la file, or it was not installed by the system packaging, or whatever). BTW, I'm assuming that func_win32_import_lib_p() works for msvc, because you've got the correct $file_magic_command for your toolchain (whatever correct means)... The comments say that gcc adds the dll name in .idata$7, and the fallback code makes use of this fact. How stable is that? For gcc dll's, very. Hasn't changed in over a decade. pe-ppc (as opposed to pe-i386) uses .idata$6; a dlltool compiled for that toolchain correctly inspects .idata$6. That's why this manual parsing stuff is just a fallback; it'd be better to use a binary tool. But, for msvc, I haven't even thought about trying to parse dumpbin output. Can we (libtool?) provide binary utility programs to go along with msvc to solve some of these issues? Furthermore, can we even assume that binutils progs like objdump and dlltool are available? Or file, for that matter? What happens if you generate an import library late (if you only have the dll) with something that is not gcc? First, I'm assuming that you're not talking about mixing between toolchains (e.g. if $CC is gcc, then the libs were generated by gcc/ld. if $CC is cl, then the libs were generated by cl.exe.) So, you're talking about completely non-gcc-based toolchains AND you're dealing with an import library for which you have no .la file. In that case you're stuck using func_win32_dllname_for_implib. Now, dlltool --identify (if you even HAVE dlltool) doesn't work with MSVC lib files (I just checked). I could see different functions defined for each toolchain, and then a libtool variable $pedll_dllname_for_implib_cmd that points to the correct implementation for your toolchain. (mingw and cygwin and probably cegcc would point to my implementation, whatever it is renamed to). But remember, this is all a corner case: dlpreopen of a shared library, when you don't have an .la file. Otherwise, it ought to just work(tm). What if you have an import library created by e.g. MSVC? Looking at a few import libs in the Platform SDK suggests that MSVC uses .idata$6 instead. Sortof. I see a LOT of .idata$6 entries. Most of them contain symbol names at offset 2, and offset 0,1 contain a little-endian count. But the one that has the DLL name starts at offset 0. How are you supposed to tell that 'MS' is actually the first two characters of a DLL name, and not an indication that symbol 'VCR80.dll' is entry number 0x534d in the symbol list? Unless the first member of the archive is ALWAYS the one that will specify the DLL, and you look in the .idata$LAST of that member. I think it would be better NOT to try to generalize this, and instead go the $LT_pedll_dllname_for_implib_cmd route above. If your msvc port can use objdump, then the following works
[PATCH] [cygwin|mingw] fix dlpreopen with --disable-static take 2
* libltdl/config/general.m4sh: Adjust copyright date.
(func_tr_sh): New function.
* libltdl/config/ltmain.m4sh: Adjust copyright date.
(func_dlltool_identify): New function.
(func_win32_dllname_for_implib): New function.
(func_generate_dlsyms) [cygwin|mingw]: Obtain DLL name
corresponding to import library by using value stored in
unique variable libfile_$(transliterated implib name).
If that fails, use func_win32_dllname_for_implib to extract
DLL name from import library directly. Also, properly extract
dlsyms from the import library.
(func_mode_link) [cygwin|mingw]: Prefer to dlpreopen DLLs
over static libs when both are available. When dlpreopening
DLLs, Use linklib (that is, import lib) as dlpreopen file,
rather than DLL. Store name of associated la file in
unique variable libfile_$(transliterated implib name)
for later use.
* libltdl/m4/libtool.m4: Adjust copyright date.
(_LT_COPYING): Adjust copyright date.
(_LT_CMD_GLOBAL_SYMBOLS): adjust sed expressions for
lt_cv_sys_global_symbol_to_c_name_address and
lt_cv_sys_global_symbol_to_c_name_address_lib_prefix
as trailing space after module name is optional.
(_LT_LINKER_SHLIBS) [cygwin|mingw][C++]:
Set exclude_expsyms correctly for $host. Simplify regular
expression in export_symbols_cmds.
(_LT_LINKER_SHLIBS) [cygwin|mingw|pw32][C]: Set exclude_expsyms
correctly for $host. Enable export_symbols_cmds to identify
DATA exports by _nm_ prefix.
---
This is a revised version of patch(es) posted here
http://lists.gnu.org/archive/html/libtool-patches/2008-11/msg00019.html
and here:
http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg1.html
In response to a bug reported here:
http://lists.gnu.org/archive/html/bug-libtool/2008-05/msg00054.html
Please see those threads for a discussion of the need for this
patch and the approach taken here. One change reflected in the
patch below, but not discussed in the preceeding threads, is
that for systems-supporting-PE-DLLs (e.g. cygwin, mingw, cegcc),
the linker will automatically link against the import library
instead of the static library if both are present in the search
path. However, earlier versions of this patch -- and indeed,
un-patched libtool -- would, in the both-are-present case,
extract symbols from the static library always, even tho the
final dlpreopen link was against the import library.
This situation led to an erroneous symbol list:
lt__PROGRAM__LTX_preloaded_symbols[] =
{ { @PROGRAM@, (void *) 0 },
{libhello.a, (void *) 0}, HERE
{nothing, (void *) nothing},
{hello, (void *) hello},
{foo, (void *) foo},
{0, (void *) 0}
};
when the correct symbol list should be:
lt__PROGRAM__LTX_preloaded_symbols[] =
{ { @PROGRAM@, (void *) 0 },
{cyghello-2.dll, (void *) 0}, HERE
{nothing, (void *) nothing},
{hello, (void *) hello},
{foo, (void *) foo},
{0, (void *) 0}
};
The patch below therefore modifies func_generate_dlsyms to
prefer the DLL/import library over the static library when
both are present -- but only for PE-DLL platforms. Other
platforms still prefer to dlpreopen static libraries when
both are present.
bootstrapped on cygwin, tested the
demo-{conf|shared|static} + demo-make + demo-exec
test cases with success. Full test suite in progress.
=
libltdl/config/general.m4sh | 15 +++-
libltdl/config/ltmain.m4sh | 198 ++-
libltdl/m4/libtool.m4 | 16 ++--
3 files changed, 201 insertions(+), 28 deletions(-)
diff --git a/libltdl/config/general.m4sh b/libltdl/config/general.m4sh
index 4bc304c..c4de91a 100644
--- a/libltdl/config/general.m4sh
+++ b/libltdl/config/general.m4sh
@@ -1,6 +1,6 @@
m4_if([general.m4sh -- general shell script boiler plate -*- Autoconf -*-
- Copyright (C) 2004, 2005, 2007, 2008 Free Software Foundation, Inc.
+ Copyright (C) 2004, 2005, 2007, 2008, 2009 Free Software Foundation, Inc.
Written by Gary V. Vaughan, 2004
This file is part of GNU Cvs-utils.
@@ -412,5 +412,18 @@ func_show_eval_locale ()
fi
fi
}
+
+# func_tr_sh
+# turn $1 into a string suitable for a shell variable name
+# result is stored in $func_tr_sh_result
+func_tr_sh ()
+{
+ func_tr_sh_result=`echo $1 | $SED -e 's/[^A-Za-z0-9_]/_/g'`
+ # ensure result begins with non-digit
+ case $func_tr_sh_result in
+[A-Za-z_][A-Za-z0-9_] ) ;;
+* ) func_tr_sh_result=_$func_tr_sh_result ;;
+ esac
+}
]])
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 20ca07b..503457c 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -5,7 +5,7 @@ m4_divert_push([SCRIPT])# @configure_input@
# Written by Gordon Matzigkeit g...@gnu.ai.mit.edu, 1996
# Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2003, 2004, 2005,
-# 2006, 2007, 2008 Free Software Foundation, Inc.
+# 2006, 2007, 2008, 2009 Free Software Foundation, Inc.
# This is free software; see the source for copying conditions. There is NO
# warranty; not even for MERCHANTABILITY or FITNESS
Re: [PATCH] [cygwin|mingw] fix dlpreopen with --disable-static take 2
Charles Wilson wrote:
bootstrapped on cygwin, tested the
demo-{conf|shared|static} + demo-make + demo-exec
test cases with success. Full test suite in progress.
And...4.5 hours later, test suite results on cygwin (1.7.0-37, but that
shouldn't matter. The good news is, cygwin-1.7 now handles missing DLL
errors without a GUI popup dialog. Un-attended testsuite execution on
Vista has been restored!)
old:
===
All 113 tests passed
(11 tests were not run)
===
SKIP: tests/cdemo-undef.test
SKIP: tests/tagdemo-undef.test
SKIP: tests/fcdemo-* == 9 tests
new:
76 tests behaved as expected.
5 tests were skipped.
23: Java convenience archives skipped (convenience.at:230)
27: shlibpath_overrides_runpath skipped (shlibpath.at:54)
41: GCJ inferred tag skipped (infer-tag.at:84)
52: ltdl API skipped (ltdl-api.at:31)
81: darwin fat compileskipped (darwin.at:42)
OK to push? Comments? Revisions?
--
Chuck
[PATCH] [cygwin|mingw] Fix compile warnings when -std=c89.
* libltdl/config/ltmain.m4sh: Update copyright date.
(func_emit_wrapper_part1): move contents to...
(func_emit_wrapper_part2): move contents to...
(func_emit_wrapper): here.
(func_emit_cwrapperexe_src) [file scope]: re-organized
includes and portability macros. Avoid oldnames on MINGW32
and MSVC for setmode/stat/chmod/getcwd/putenv. Declare
_putenv on MINGW32 when -ansi. Use namespaced macro
LT_DEBUGWRAPPER. Remove variables script_text_part1 and
script_text_part2.
(func_emit_cwrapperexe_src) [lt_dump_script]: New function.
(func_emit_cwrapperexe_src) [main]: Call it.
---
This patch attempts to correct the issues raised in this thread:
msys/mingw warnings about string length and putenv absence with gcc -Wall
-ansi
http://lists.gnu.org/archive/html/bug-libtool/2008-12/msg00038.html
There was an earlier, similar patch related to errors that occurred
when -std=c99. One of those errors, related to a limitation on const
char* arrays to less than 4096 bytes, led to splitting the existing
function 'func_emit_wrapper' into two different pieces, each less
than 4096 characters. However, the string limitation in c89 is 509
characters, which would lead to too many such subfunctions. Futher,
it would be very difficult to chose breakpoints to ensure this char
length limit, when some chunks would include long variable values
such as LD_LIBRARY_PATH or PATH.
To achieve this more stringent limitation, the best we can (easily)
do is to emit each line of the script as a single const char*. Thus,
we require -- but do not check -- that each line in the wrapper
script has less than 509 characters. However, we do not want 127
'func_emit_wrapper_partN' functions. So, in this patch I reverted
the split and moved all of the script contents back into
func_emit_wrapper. However, when building the cwrapper source
code, each line of the script is turned into a separate C string:
fputs (one line\n, stdout);
I probably should have done it this way to start with, but was
trying to avoid 127 different function calls. Oh well.
Also took the opportunity here to move the DEBUGWRAPPER macro
into the LT_* namespace, and to reorganize the #includes and
the portability #defines into separate sections.
Spot checked some regression tests on cygwin (all passed).
Running full regression suite on mingw. OK to push, pending
testsuite results?
=
libltdl/config/ltmain.m4sh | 132
1 files changed, 59 insertions(+), 73 deletions(-)
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 20ca07b..ebedf69 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -5,7 +5,7 @@ m4_divert_push([SCRIPT])# @configure_input@
# Written by Gordon Matzigkeit g...@gnu.ai.mit.edu, 1996
# Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2003, 2004, 2005,
-# 2006, 2007, 2008 Free Software Foundation, Inc.
+# 2006, 2007, 2008, 2009 Free Software Foundation, Inc.
# This is free software; see the source for copying conditions. There is NO
# warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
@@ -2309,15 +2309,23 @@ func_extract_archives ()
}
-
-# func_emit_wrapper_part1 [arg=no]
+# func_emit_wrapper [arg=no]
+#
+# Emit a libtool wrapper script on stdout.
+# Don't directly open a file because we may want to
+# incorporate the script contents within a cygwin/mingw
+# wrapper executable. Must ONLY be called from within
+# func_mode_link because it depends on a number of variables
+# set therein.
#
-# Emit the first part of a libtool wrapper script on stdout.
-# For more information, see the description associated with
-# func_emit_wrapper(), below.
-func_emit_wrapper_part1 ()
+# ARG is the value that the WRAPPER_SCRIPT_BELONGS_IN_OBJDIR
+# variable will take. If 'yes', then the emitted script
+# will assume that the directory in which it is stored is
+# the $objdir directory. This is a cygwin/mingw-specific
+# behavior.
+func_emit_wrapper ()
{
- func_emit_wrapper_part1_arg1=${1-no}
+ func_emit_wrapper_arg1=${1-no}
$ECHO \
#! $SHELL
@@ -2398,24 +2406,10 @@ _LTECHO_EOF'
file=\`\$ECHO \\$file\ | $SED 's%^.*/%%'\`
file=\`ls -ld \\$thisdir/\$file\ | $SED -n 's/.*- //p'\`
done
-
-}
-# end: func_emit_wrapper_part1
-
-# func_emit_wrapper_part2 [arg=no]
-#
-# Emit the second part of a libtool wrapper script on stdout.
-# For more information, see the description associated with
-# func_emit_wrapper(), below.
-func_emit_wrapper_part2 ()
-{
-func_emit_wrapper_part2_arg1=${1-no}
-
- $ECHO \
# Usually 'no', except on cygwin/mingw when embedded into
# the cwrapper.
- WRAPPER_SCRIPT_BELONGS_IN_OBJDIR=$func_emit_wrapper_part2_arg1
+ WRAPPER_SCRIPT_BELONGS_IN_OBJDIR=$func_emit_wrapper_arg1
if test \\$WRAPPER_SCRIPT_BELONGS_IN_OBJDIR\ = \yes\; then
# special case for '.'
if test \\$thisdir\ = \.\; then
@@ -2532,30 +2526,6 @@ func_emit_wrapper_part2 ()
fi\
}
-# end:
Re: [PATCH] [cygwin|mingw] fix dlpreopen with --disable-static
Brian Dessent wrote:
Ralf Wildenhues wrote:
Did GCC change since then, or is this system-dependent?
Interesting. I'd be curious to see if powerpc-ibm-aix5.3.0.0-c++filt
recognises the FI/FD encoding, and if so then it would be reasonable to
conclude that this is in fact system-dependent or otherwise an internal
implementation detail. Nevertheless it seems to me like the regexp
ought accept but not require the leading F since the testcase of a
simple ctor results in a symbol _GLOBAL__I_.* on Linux as well.
My revised patch is still in-progress, but I've changed the libtool.m4
[cygwin|mingw] part to look like this;
--
Chuck
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 35d7d5c..d45013d 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -4089,6 +4089,7 @@ m4_require([_LT_TAG_COMPILER])dnl
AC_MSG_CHECKING([whether the $compiler linker ($LD) supports shared libraries])
m4_if([$1], [CXX], [
_LT_TAGVAR(export_symbols_cmds, $1)='$NM $libobjs $convenience |
$global_symbol_pipe | $SED '\''s/.* //'\'' | sort | uniq $export_symbols'
+ _LT_TAGVAR(exclude_expsyms, $1)=['_GLOBAL_OFFSET_TABLE_|_GLOBAL__F[ID]_.*']
case $host_os in
aix[[4-9]]*)
# If we're using GNU nm, then we don't want the -C option.
@@ -4103,13 +4104,13 @@ m4_if([$1], [CXX], [
_LT_TAGVAR(export_symbols_cmds, $1)=$ltdll_cmds
;;
cygwin* | mingw* | cegcc*)
-_LT_TAGVAR(export_symbols_cmds, $1)='$NM $libobjs $convenience |
$global_symbol_pipe | $SED -e '\''/^[[BCDGRS]][[ ]]/s/.*[[ ]]\([[^ ]]*\)/\1
DATA/;/^.*[[ ]]__nm__/s/^.*[[ ]]__nm__\([[^ ]]*\)[[ ]][[^ ]]*/\1 DATA/;/^I[[
]]/d;/^[[AITW]][[ ]]/s/.* //'\'' | sort | uniq $export_symbols'
+_LT_TAGVAR(export_symbols_cmds, $1)='$NM $libobjs $convenience |
$global_symbol_pipe | $SED -e '\''/^[[BCDGRS]][[ ]]/s/.*[[ ]]\([[^ ]]*\)/\1
DATA/;s/^.*[[ ]]__nm__\([[^ ]]*\)[[ ]][[^ ]]*/\1 DATA/;/^I[[ ]]/d;/^[[AITW]][[
]]/s/.* //'\'' | sort | uniq $export_symbols'
+_LT_TAGVAR(exclude_expsyms,
$1)=['[_]+GLOBAL_OFFSET_TABLE_|[_]+GLOBAL__[FID]_.*|[_]+head_[A-Za-z0-9_]+_dll|[A-Za-z0-9_]+_dll_iname']
;;
*)
_LT_TAGVAR(export_symbols_cmds, $1)='$NM $libobjs $convenience |
$global_symbol_pipe | $SED '\''s/.* //'\'' | sort | uniq $export_symbols'
;;
esac
- _LT_TAGVAR(exclude_expsyms, $1)=['_GLOBAL_OFFSET_TABLE_|_GLOBAL__F[ID]_.*']
], [
runpath_var=
_LT_TAGVAR(allow_undefined_flag, $1)=
@@ -4248,7 +4249,8 @@ _LT_EOF
_LT_TAGVAR(allow_undefined_flag, $1)=unsupported
_LT_TAGVAR(always_export_symbols, $1)=no
_LT_TAGVAR(enable_shared_with_static_runtimes, $1)=yes
- _LT_TAGVAR(export_symbols_cmds, $1)='$NM $libobjs $convenience |
$global_symbol_pipe | $SED -e '\''/^[[BCDGRS]][[ ]]/s/.*[[ ]]\([[^ ]]*\)/\1
DATA/'\'' | $SED -e '\''/^[[AITW]][[ ]]/s/.*[[ ]]//'\'' | sort | uniq
$export_symbols'
+ _LT_TAGVAR(export_symbols_cmds, $1)='$NM $libobjs $convenience |
$global_symbol_pipe | $SED -e '\''/^[[BCDGRS]][[ ]]/s/.*[[ ]]\([[^ ]]*\)/\1
DATA/;s/^.*[[ ]]__nm__\([[^ ]]*\)[[ ]][[^ ]]*/\1 DATA/;/^I[[ ]]/d;/^[[AITW]][[
]]/s/.* //'\'' | sort | uniq $export_symbols'
+ _LT_TAGVAR(exclude_expsyms,
$1)=['[_]+GLOBAL_OFFSET_TABLE_|[_]+GLOBAL__[FID]_.*|[_]+head_[A-Za-z0-9_]+_dll|[A-Za-z0-9_]+_dll_iname']
if $LD --help 21 | $GREP 'auto-import' /dev/null; then
_LT_TAGVAR(archive_cmds, $1)='$CC -shared $libobjs $deplibs
$compiler_flags -o $output_objdir/$soname ${wl}--enable-auto-image-base
-Xlinker --out-implib -Xlinker $lib'
Re: [PATCH] Fix --verbose option and add new --no-silent option
Charles Wilson wrote: Ralf Wildenhues wrote: Hi Charles, * Charles Wilson wrote on Sat, Nov 15, 2008 at 10:40:26AM CET: * libltdl/config/ltmain.m4sh (usage): Document new --no-silent/--no-quiet options. Spacing changes. (func_enable_tag): Handle --no-silent/--no-quiet options. Modified --verbose to actually activate opt_verbose. New behavior: --silent disables both normal output and func_verbose output. --verbose enables both normal output and func_verbose output. --no-silent enables normal output, but does not affect func_verbose output. Okay to push? This requires a NEWS entry, and libtool.texi update. Ideally it should also have a quick functionality test. Attached, all but functionality test. Any ideas how a functionality test should be structured, in order to exercise the three effective verbosity modes? normal verbose (default) ON OFF --silent OFF OFF --verbose ON ON (there really isn't any way to have verbose output without normal output). Might also want to verify that: --silent --no-silent (in that order) restores default behavior. -- Chuck
[PATCH] Fix --verbose option; add new --no-{silent|quiet|verbose} options.
* libltdl/config/ltmain.m4sh (usage): Document
new options --no-silent/--no-quiet and --no-verbose.
(func_enable_tag): Handle new options.
Modified --verbose to actually activate opt_verbose.
New behavior: --silent disables both normal output and
func_verbose output. --verbose enables both normal
output and func_verbose output. --no-silent enables
normal output, but does not affect func_verbose output.
--no-verbose disables func_verbose output, but does not
affect normal output.
* NEWS: announce new options --no-silent/--no-quiet, and
--no-verbose.
* doc/libtool.texi: document new options --no-silent/--no-quiet
and --no-verbose.
---
As pushed (ChangeLog portion of patch below edited for archives).
--
Chuck
ChangeLog | 19 +++
NEWS |9 +
doc/libtool.texi | 39 ++-
libltdl/config/ltmain.m4sh | 16 +++-
4 files changed, 81 insertions(+), 2 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index b1582fd..cd1b1fa 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,22 @@
+2008-11-21 Charles Wilson ...
+
+ Fix --verbose option; add new --no-{silent|quiet|verbose} options.
+
+ * libltdl/config/ltmain.m4sh (usage): Document
+ new options --no-silent/--no-quiet and --no-verbose.
+ (func_enable_tag): Handle new options.
+ Modified --verbose to actually activate opt_verbose.
+ New behavior: --silent disables both normal output and
+ func_verbose output. --verbose enables both normal
+ output and func_verbose output. --no-silent enables
+ normal output, but does not affect func_verbose output.
+ --no-verbose disables func_verbose output, but does not
+ affect normal output.
+ * NEWS: announce new options --no-silent/--no-quiet, and
+ --no-verbose.
+ * doc/libtool.texi: document new options --no-silent/--no-quiet
+ and --no-verbose.
+
2008-11-20 Ralf Wildenhues ...
Fix match patterns for cegcc*.
diff --git a/NEWS b/NEWS
index a38bfb3..c00e404 100644
--- a/NEWS
+++ b/NEWS
@@ -6,6 +6,12 @@ New in 2.2.8 2008-??-??: git version 2.2.7a, Libtool team:
- Libtool ships and installs man pages for libtool and libtoolize now.
- New libtool command line flag --help-all.
+ - New libtool command line flag --no-silent (with alternate spelling
+--no-quiet). This flag (re)enables the default informational messages,
+but has no effect on so-called verbose output messages.
+ - New libtool command line flag --no-verbose, which disables only
+the extra verbose output messages and has no effect on the
+default informational messages.
* Bug fixes:
@@ -13,6 +19,9 @@ New in 2.2.8 2008-??-??: git version 2.2.7a, Libtool team:
with Autoconf 2.59 (`possibly undefined macro: LT_LIBEXT').
- Fix 2.2.4 regression that caused arguments with special characters
to be mangled by the compile wrapper for uninstalled programs on MinGW.
+ - libtool command line flag --verbose now also enables explicit
+verbose output, in addition to its previous behavior of (re)enabling
+only the default informational output. See New Features, --no-silent.
* Miscellaneous changes:
diff --git a/doc/libtool.texi b/doc/libtool.texi
index f03adfb..fe9547e 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -1207,7 +1207,44 @@ Do not print out any progress or informational messages.
@item -v
@itemx --verbose
-Print out progress and informational messages (enabled by default).
+Print out progress and informational messages (enabled by default),
+as well as additional messages not ordinary seen by default.
+
[EMAIL PROTECTED] --no-quiet
[EMAIL PROTECTED] --no-silent
+Print out the progress and informational messages that are seen
+by default. This option has no effect on whether the additional
+messages seen in @option{--verbose} mode are shown.
+
[EMAIL PROTECTED] --no-verbose
+Do not print out any additional informational messages beyond
+those ordinarily seen by default. This option has no effect
+on whether the ordinary progress and informational messages
+enabled by @option{--no-quiet} are shown.
+
+Thus, there are now three different message levels (not counting
[EMAIL PROTECTED]), depending on whether the normal messages and/or
+the additional verbose messages are displayed. Note that there is
+no mechanism to diplay verbose messages, without also displaying
+normal messages.
+
[EMAIL PROTECTED] @strong
[EMAIL PROTECTED] default
+Normal messages are displayed, verbose messages are not displayed.
+In addition to being the default mode, it can be forcibly achieved
+by using both option @option{--no-verbose} and either option
[EMAIL PROTECTED] or option @option{--no-quiet}.
+
[EMAIL PROTECTED] silent
+Neither normal messages nor verbose messages are displayed. This
+mode can be achieved using either option @option{--silent} or
+option @option{--quiet}.
+
[EMAIL PROTECTED
Re: [PATCH] Fix --verbose option and add new --no-silent option
Ralf Wildenhues wrote:
If you agree, then go ahead and commit with needed changes.
Pushed: see new thread: [PATCH] Fix --verbose option; add new
--no-{silent|quiet|verbose} options.
--
Chuck
[PATCH] Fix --verbose option and add new --no-silent option
* libltdl/config/ltmain.m4sh (usage): Document new --no-silent/--no-quiet options. Spacing changes. (func_enable_tag): Handle --no-silent/--no-quiet options. Modified --verbose to actually activate opt_verbose. New behavior: --silent disables both normal output and func_verbose output. --verbose enables both normal output and func_verbose output. --no-silent enables normal output, but does not affect func_verbose output. --- The first of several smaller patches broken out of my original [PATCH] [cygwin|mingw] fix dlpreopen with --disable-static one: http://lists.gnu.org/archive/html/libtool-patches/2008-11/msg00019.html Test suite results (cygwin): Fails old test demo-exec after demo-shared (this is the failure my larger patch in the referenced message fixed). In the new testsuite, fails 25, 74 (which is not a regression on cygwin). Okay to push? libltdl/config/ltmain.m4sh | 30 +++--- 1 files changed, 19 insertions(+), 11 deletions(-) diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh index db0ea67..3b8f05b 100644 --- a/libltdl/config/ltmain.m4sh +++ b/libltdl/config/ltmain.m4sh @@ -33,17 +33,18 @@ m4_divert_push([SCRIPT])# @configure_input@ # # Provide generalized library-building support services. # -# --config show all configuration variables -# --debug enable verbose shell tracing -# -n, --dry-rundisplay commands without modifying any files -# --features display basic configuration information and exit -# --mode=MODE use operation mode MODE -# --preserve-dup-deps don't remove duplicate dependency libraries -# --quiet, --silentdon't print informational messages -# --tag=TAGuse configuration variables from tag TAG -# -v, --verboseprint informational messages (default) -# --versionprint version information -# -h, --help, --help-all print short, long, or detailed help message +# --config show all configuration variables +# --debug enable verbose shell tracing +# -n, --dry-rundisplay commands without modifying any files +# --features display basic configuration information, exit +# --mode=MODE use operation mode MODE +# --preserve-dup-deps don't remove duplicate dependency libraries +# --quiet, --silentdon't print informational messages +# --no-quiet, --no-silent print informational messages (default) +# --tag=TAGuse configuration variables from tag TAG +# -v, --verboseprint more informational messages than default +# --versionprint version information +# -h, --help, --help-all print short, long, or detailed help message # # MODE must be one of the following: # @@ -319,10 +320,17 @@ func_enable_tag () --quiet|--silent)preserve_args=$preserve_args $opt opt_silent=: + opt_verbose=false + ;; + + --no-quiet|--no-silent) + preserve_args=$preserve_args $opt + opt_silent=false ;; --verbose| -v) preserve_args=$preserve_args $opt opt_silent=false + opt_verbose=: ;; --tag) test $# -eq 0 func_missing_arg $opt break -- 1.6.0.2
[PATCH] Add func_win32_import_lib_p
* libltdl/config/ltmain.m4sh (func_win32_import_lib_p):
New function.
---
The second of several smaller patches broken out of, or arising from
discussion involving, my original
[PATCH] [cygwin|mingw] fix dlpreopen with --disable-static one:
http://lists.gnu.org/archive/html/libtool-patches/2008-11/msg00019.html
This one was pre-approved. I bootstrapped and rebuilt, and manually
exercised the function -- which verified no syntax errors, at least.
However, I did not run the entire test suite; I couldn't see the
need as ALL the patch does is add the new function. It is not actually
called by anything yet.
Pushed.
libltdl/config/ltmain.m4sh | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index db0ea67..91c1f47 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -3720,6 +3720,17 @@ EOF
}
# end: func_emit_cwrapperexe_src
+# func_win32_import_lib_p ARG
+# True if ARG is an import lib, as indicated by $file_magic_cmd
+func_win32_import_lib_p ()
+{
+$opt_debug
+case `eval $file_magic_cmd \\$1\ 2/dev/null | $SED -e 10q` in
+*import*) : ;;
+*) false ;;
+esac
+}
+
# func_mode_link arg...
func_mode_link ()
{
--
1.6.0.2
Re: [PATCH] [cygwin|mingw] fix dlpreopen with --disable-static
Charles Wilson wrote: Of course, first I need to revise the dlltool patch and get it accepted; there have been some comments on the binutils list. Done. Yay! http://sourceware.org/ml/binutils/2008-11/msg00180.html Well, that, and it fixes a test that currently fails. Which one, and can you post output for failure as well as success with the patch, please? demo-exec after demo-shared, in the old test suite. I'll post the output(s) tonight or tomorrow. Attached. The fixed output is from the original, unmodified patch that started this thread. -- Chuck dlpreopen-failure.log.bz2 Description: Binary data dlpreopen-fixed.log.bz2 Description: Binary data
Re: [PATCH] [cygwin|mingw] fix dlpreopen with --disable-static
Ralf Wildenhues wrote:
The point is, we perhaps STARTED with the .la file, but the whole point
of the dlpreopen $pass is to replace each .la file in $dlprefiles with
the name of the object from which the symbols should be extracted, to
build the symbol table. So, pick one: either the DLL, or the import
library (there is no static lib, the failure mode in question occurs
when --disable-static).
If you pick DLL -- then it's real hard to get the symbols (objdump
ugliness, plus figuring out which ones are DATA).
If you pick implib -- then it's real hard to get the correct DLL name
(but not nearly as hard as extracting the correct symbols from the dll).
But the name of the .la file is no longer available.
But that's a problem that can be solved.
# turn $1 into a string suitable for a shell variable name
func_tr_sh ()
{
... # typically forks, except maybe with bash ${var/subst/repl}
}
# when treating $dlprefile, save the corresponding .la file name:
func_tr_sh $dlprefile
eval libfile_$tr_sh_result=\$corresponding_dotla_file
# later, when searching for the .la file, test libfile$tr_sh_result
# for contents
What do you think?
That would work. But it only gets rid of the grotty find the name of
the DLL given the implib problem -- which is not a small thing, of course.
But that presupposes that my change to the dlpreopen $pass, where on
cygwin|mingw we replace the la file in the $dlprefiles list with the
implib, stands. Did I convince you we needed this bit:
- elif test -n $dlname; then
- newdlprefiles=$newdlprefiles $dir/$dlname
+ # Except on mingw|cygwin, where we must use the import library,
+ # so lt_dlopen is handled in another way
else
- newdlprefiles=$newdlprefiles $dir/$linklib
+ case $host in
+ *cygwin* | *mingw* )
+ newdlprefiles=$newdlprefiles $dir/$linklib
+;;
+ * )
+ if test -n $dlname; then
+ newdlprefiles=$newdlprefiles $dir/$dlname
+ else
+ newdlprefiles=$newdlprefiles $dir/$linklib
+ fi
+;;
+ esac
If so, then I guess the other code section would look like
func_verbose extracting global C symbols from \`$dlprefile'
func_basename $dlprefile
name=$func_basename_result
-$opt_dry_run || {
- eval '$ECHO : $name $nlist'
- eval $NM $dlprefile 2/dev/null | $global_symbol_pipe '$nlist'
-}
+case $host in
+ *cygwin | *mingw* )
+# if an import library, we need to obtain dlname
+if func_win32_import_lib_p $dlprefile; then
+ func_tr_sh $dlprefile
+ eval curr_lafile=\$libfile_$tr_sh_result
+ $opt_dry_run || {
+if test -n $curr_lafile func_lalib_p $curr_lafile; then
+ # geez. does this need to happen in a subshell, to
+ # avoid clobbering our current variable values?
+ source $curr_lafile
+ if test -n $dlname ; then
+func_basename $dlname
+dlbasename=$func_basename_result
+eval '$ECHO : $dlbasename $nlist'
+ else
+func_warning Could not compute DLL name from $name
+eval '$ECHO : $name $nlist'
+ fi
+else
+ func_warning Could not determing .la name from $name
+ eval '$ECHO : $name $nlist'
+fi
+eval $NM $dlprefile 2/dev/null | $global_symbol_pipe |
+ $SED -e '/I __imp/d' -e 's/I __nm_/D /;s/_nm__//'
'$nlist'
+ }
+else # not an import lib
+ $opt_dry_run || {
+ eval '$ECHO : $name $nlist'
+ eval $NM $dlprefile 2/dev/null | $global_symbol_pipe
'$nlist'
+ }
+fi
+;;
+ *)
etc.
Is that the idea?
--
Chuck
