Re: [PATCH] [cygwin|mingw] fix dlpreopen with --disable-static (take 8?)
Hello Charles,
* Charles Wilson wrote on Mon, Jun 28, 2010 at 12:05:40AM CEST:
On 6/27/2010 4:43 PM, Ralf Wildenhues wrote:
* Charles Wilson wrote on Sun, Jun 27, 2010 at 02:51:21PM CEST:
So...can I get a verdict? Is -dlpreopen not-an-la-file supposed to work?
I think Pierre's report was about using -dlpreopen file.la at link time,
but then not wanting to need the .la file at run time. I think that is
desirable. At link edit time, having a .la file is a reasonable thing I
think.
So...I *don't* need to worry about -dlpreopen not-an-.la? The issue is
that I can't figure out how *current* libtool EVER gets here:
(current master ltmain.m4sh:1984:func_generate_dlsyms)
for dlprefile in $dlprefiles; do
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'
}
done
in that situation, with anything IN $dlprefiles -- because in
ltmain.m4sh, we have:
5764 if test $linkmode = prog; then
5765 dlfiles=$newdlfiles
5766 fi
5767 if test $linkmode = prog || test $linkmode = lib; then
5768 dlprefiles=$newdlprefiles
5769 fi
and at this point, both newdlfiles and newdlfiles are empty, when the
argument to libtool's -dlpreopen option is not a libtool .la library.
So...we APPEAR to have a bunch of dead code.
I wasn't aware of that. Sorry about the sloppy review.
It obviously isn't
SUPPOSED to be dead -- or it wouldn't be there.
Well, I wouldn't put my money on that reasoning.
So, I can either keep
(that is, commit) all of my new stuff in this patch, some of which will
also be dead code, in anticipation of somebody tracking down WHY it and
these existing snippets are (currently) dead, and brings them back to life.
Or I can NOT commit any new (dead) code and commit only those bits that
are presently live, and wait until after the existing dead code is
resurrected, and THEN add those particular bits that I'd've held back.
Which?
I'd say the part that is easier for you, so I guess that would be
committing all the code, including presumably-dead. And maybe in a
future patch adding a testsuite test that exercises the code.
I tried to use Gary's _LT_PROG_XSI_REPLACE function, but using a sed
script to create a sed script and all the quoting nightmares just made
my head hurt. So, I have _LT_PROG_FUNCTION_REPLACE that uses the old
'copy half the script, emit the new function content, copy the rest of
the script' algorithm.
I don't see this method as the new method of choice. We already have a
mechanism for years to transport values to the libtool script with
_LT_DECLs and _LT_TAGDECLs, and at least for small code snippets,
Yeah, that's the problem. You complained that these functions added a
lot of parse time to all the other platforms that would never use them,
presumably because they were BIG functions and there were several of
them. Presumably, the parse-time cost of small functions is low, unless
there are a TON.
I think you can measure parse time in script length plus number of
here-documents (for old shells).
But please, in the future, don't complain so strongly ([your patch]
makes me cringe) about architectural issues if you don't actually want
to see them fixed: system-specific code in ltmain...rather than in
libtool.m4 where it belongs.
I feel (more) discouraged now (than usual), having wasted so much time
addressing a criticism of a patch that wasn't meant to be taken seriously.
I would like to apologize for this comment making you do this extra
work. Again, that review of mine was more sloppy than it should have
been.
In fact, I have often wondered if the reason many of my patches -- and
Peter's -- tend to languish so long is because of these aesthetic
objections
Of course code maintenance aspects and long-term slowdown of the code
are a part of code quality.
Anyway, this patch AND that upcoming cross-compile patch both add
several large system-specific new functions to ltmain.sh. Since you
objected to them now, I figured I'd hear it again THEN, so...I took this
opportunity to TRY and create the appropriate infrastructure to handle
LARGE system-specific functions from m4. (Few if any of these functions
are suitable candidates for single-line $foo_cmd _LT_DECL-style
treatment, or even just few-line $foo_cmd)
I won't bother to do that in the future.
Again, sorry for making you do extra work.
because at least currently, the second entry in the
LTX_preloaded_symbols array is cygfoo-N.dll in those circumstances,
not libfoo.a.
Well yeah, this confusion and interface non-well-definedness is bad, no?
Sure it is. But some of these considerations are hard to accommodate on
win32 if the .la file is not available at runtime, AND the caller
doesn't
Re: [PATCH] [cygwin|mingw] fix dlpreopen with --disable-static (take 8?)
Hi Chuck,
Thanks for persevering with the Windows support in Libtool.
Regarding our patch review process, I honestly find the tough reviews
valuable in keeping up the quality of my patches, not least because it
makes me more careful not to leave loose ends in my submissions.
Nevertheless, please do remember that it is a *review*, and if you find
yourself disagreeing with something (excepting an outright veto of course),
Ralf and I are both acutely aware that you are the one doing the work on
these patches and the last thing we want to do is retard the progress of
Libtool on Windows, so please don't be afraid to say on balance, I'd
rather see this patch move Libtool forward in some small way without
addressing issue X right now. Often, we'll concede in exchange for a
TODO item! :)
On 28 Jun 2010, at 13:10, Ralf Wildenhues wrote:
* Charles Wilson wrote on Mon, Jun 28, 2010 at 12:05:40AM CEST:
On 6/27/2010 4:43 PM, Ralf Wildenhues wrote:
* Charles Wilson wrote on Sun, Jun 27, 2010 at 02:51:21PM CEST:
I tried to use Gary's _LT_PROG_XSI_REPLACE function, but using a sed
script to create a sed script and all the quoting nightmares just made
my head hurt. So, I have _LT_PROG_FUNCTION_REPLACE that uses the old
'copy half the script, emit the new function content, copy the rest of
the script' algorithm.
I don't see this method as the new method of choice. We already have a
mechanism for years to transport values to the libtool script with
_LT_DECLs and _LT_TAGDECLs, and at least for small code snippets,
Yeah, that's the problem.
I wrote _LT_DECL and _LT_TAGDECL to propagate shell variable declarations to
the libtool script, and I fear it will behave badly if we try to use that
mechanism for shoehorning anything else through, especially because it works
by doing a *lot* of booking-keeping at m4 time.
_LT_PROG_XSI_REPLACE is designed for swapping out fallback implementations
of full functions (suitably decorated) for more efficient implementations
based on the build-time environment. I think that is exactly what you're
trying to do, but it seems to me like you might be able to work more
effectively in reverse: by putting the full Windows required implementations
into ltmain.m4sh, and using _LT_PROG_XSI_REPLACE to replace them with
stubs when configure is not building on (or for!!) a Windows machine?
(At that point, we should come up with a better name, and changing the
decorator strings to match. The XSI is already a misnomer now that I'm
using it for `+=' and ${foo:n:m} constructions.)
Cheers,
--
Gary V. Vaughan (g...@gnu.org)
Re: MSVC: Add MSVC support.
Hi Ralf,
Thanks for the review!
Den 2010-06-24 06:51 skrev Ralf Wildenhues:
How about this:
* Changes in supported systems or compilers:
- Initial support for the Microsoft C/C++ Compiler with help from
(proposed changes to) the compile script in Automake.
And then fiddle the NEWS entry to specify the needed Automake version
when one is known?
How about for unreleased Automake 1.12, that should be safe.
This is what I'm intending to push when the 72 hours have passed for
the updated patch I'm about to send in the other thread, i.e.
MSVC: For MSVC, embed the manifest as a resource in the executable.
I'm only posting this here, since that patch depends on this one
and I don't want to push that patch until this patch is pushable.
I.e. this is just FYI.
Cheers,
Peter
commit 570e58da9c2fce4a93b097dc33f9578b5871837e
Author: Peter Rosin peda@lysator.liu.se
Date: Thu Jun 24 07:28:16 2010 +0200
Add MSVC support.
* libltdl/m4/libtool.m4 (_LT_SYS_DYNAMIC_LINKER)
(_LT_LINKER_SHLIBS, _LT_LANG_CXX_CONFIG) [mingw, cygwin]: Add
support for the Microsoft C/C++ Compiler (cl) relying on help
from the compile script in Automake.
* NEWS: Add note of the above.
diff --git a/ChangeLog b/ChangeLog
index e939f43..12e9168 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,12 @@
+2010-06-24 Peter Rosin peda@lysator.liu.se
+
+ Add MSVC support.
+ * libltdl/m4/libtool.m4 (_LT_SYS_DYNAMIC_LINKER)
+ (_LT_LINKER_SHLIBS, _LT_LANG_CXX_CONFIG) [mingw, cygwin]: Add
+ support for the Microsoft C/C++ Compiler (cl) relying on help
+ from the compile script in Automake.
+ * NEWS: Add note of the above.
+
2010-06-28 Gary V. Vaughan gary@gnu.org
Add func_append_quoted and do inline func_append substitutions.
diff --git a/NEWS b/NEWS
index 33531dc..5735b01 100644
--- a/NEWS
+++ b/NEWS
@@ -7,6 +7,10 @@ New in 2.2.12 2010-08-??: git version 2.2.11a, Libtool team:
- On non-cygwin Windows systems, we now lookup potential library
file names without regard to file name case.
+* Changes in supported systems or compilers:
+ - Initial support for the Microsoft C/C++ Compiler, with help from
+the compile script in unreleased Automake 1.12.
+
New in 2.2.10 2010-06-10: git version 2.2.9a, Libtool team:
* New features:
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 01a9c41..18eedb3 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -2198,8 +2198,9 @@ cygwin* | mingw* | pw32* | cegcc*)
need_version=no
need_lib_prefix=no
- case $GCC,$host_os in
- yes,cygwin* | yes,mingw* | yes,pw32* | yes,cegcc*)
+ case $GCC,$cc_basename in
+ yes,*)
+# gcc
library_names_spec='$libname.dll.a'
# DLL is installed to $(libdir)/../bin by postinstall_cmds
postinstall_cmds='base_file=`basename \${file}`~
@@ -2232,13 +2233,42 @@ m4_if([$1], [],[
library_names_spec='`echo ${libname} | sed -e 's/^lib/pw/'``echo ${release} | $SED -e 's/[[.]]/-/g'`${versuffix}${shared_ext}'
;;
esac
+dynamic_linker='Win32 ld.exe'
+;;
+
+ *,cl*)
+# Native MSVC
+libname_spec='$name'
+soname_spec='${libname}`echo ${release} | $SED -e 's/[[.]]/-/g'`${versuffix}${shared_ext}'
+library_names_spec='${libname}`echo ${release} | $SED -e 's/[[.]]/-/g'`${versuffix}.lib'
+sys_lib_search_path_spec=$LIB
+if $ECHO $sys_lib_search_path_spec | [$GREP ';[c-zC-Z]:/' /dev/null]; then
+ # It is most probably a Windows format PATH.
+ sys_lib_search_path_spec=`$ECHO $sys_lib_search_path_spec | $SED -e 's/;/ /g'`
+else
+ sys_lib_search_path_spec=`$ECHO $sys_lib_search_path_spec | $SED -e s/$PATH_SEPARATOR/ /g`
+fi
+# FIXME: find the short name or the path components, as spaces are
+# common. (e.g. Program Files - PROGRA~1)
+# DLL is installed to $(libdir)/../bin by postinstall_cmds
+postinstall_cmds='base_file=`basename \${file}`~
+ dlpath=`$SHELL 21 -c '\''. $dir/'\''\${base_file}'\''i; echo \$dlname'\''`~
+ dldir=$destdir/`dirname \$dlpath`~
+ test -d \$dldir || mkdir -p \$dldir~
+ $install_prog $dir/$dlname \$dldir/$dlname'
+postuninstall_cmds='dldll=`$SHELL 21 -c '\''. $file; echo \$dlname'\''`~
+ dlpath=$dir/\$dldll~
+ $RM \$dlpath'
+shlibpath_overrides_runpath=yes
+dynamic_linker='Win32 link.exe'
;;
*)
+# Assume MSVC wrapper
library_names_spec='${libname}`echo ${release} | $SED -e 's/[[.]]/-/g'`${versuffix}${shared_ext} $libname.lib'
+dynamic_linker='Win32 ld.exe'
;;
esac
- dynamic_linker='Win32 ld.exe'
# FIXME: first we should search . and the directory the executable is in
shlibpath_var=PATH
;;
@@ -4248,13 +4278,18 @@ m4_if([$1], [CXX], [
;;
pw32*)
_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/;/^.*[[
Re: MSVC: For MSVC, embed the manifest as a resource in the executable.
Hi Ralf,
Thanks for the review!
Den 2010-06-26 22:42 skrev Ralf Wildenhues:
* Peter Rosin wrote on Fri, Jun 25, 2010 at 12:20:53AM CEST:
Den 2010-06-24 20:17 skrev Ralf Wildenhues:
I guess. Wait. Will mt be needed for programs also in packages using
only static libraries on w32, that maybe won't (or don't want to) use
the win32-dll option? Then it needs to be outside of this option,
preferably in a new macro in libtool.m4, AC_REQUIREd by the macro(s)
that use(s) mt.
Yes, it might well be. It will be needed as soon as libtool is involved
with linking a program (and when it is using cl for that, of course).
Putting the check for mt outside the win32-dll option is right then.
Will it also be needed by packages using Automake but not Libtool? IOW,
does your cl always create manifest files? If not: when does it?
Yes, I suppose it does.
or should I add a macro somewhere (where?) that is more like LT_PATH_NM?
I.e. walks the PATH and discards mt:s that do not appear to be the
intended mt.
Let's try the easy way first, but after the AC_CHECK_TOOL, ensure -? is
accepted. I don't want magnetic tape action anywhere due to libtool.
Here's a first shot.
I know that I haven't addressed the exeext comment
in your other reply, but I don't know what you want me to do. Please
advise further...
Step 0 would be using
case ... in
*.exe | *.EXE ) ...
because nobody mixes case. Step 1 (optional) would be having a variable
in ltmain which contains exeext-normalized value (i.e., either always
with, or always without the extension), so you don't have to put the
case in the tag code. Step 2: IIUC then this particular .EXE can only
come from some makefile(.am) author using upper-case .EXE *in* the file.
Slap that author. ;-)
I don't really grok step 1, so I stopped at step 0. But I wish I could get
to the LART step though :-)
Do I need a NEWS entry for the new MT environment variable?
Yes that could help I guess.
Ok, added.
Is the name
MT in too much contention? I can easily imagine that this is not going
to be the first MT variable in the world...
codesearch.google.com exists to answer such questions for the open and
free software world. Use the regex search interface.
Ok, looked and...
But what should it be instead?
$MANIFEST or $MANIFEST_TOOL? What is Microsoft's verbose name for the
tool? I don't have a big problem with MT though.
...I changed it to $MANIFEST_TOOL.
This is what mt (from Visual Studio 2005) says at the top:
Microsoft (R) Manifest Tool version 5.2.3790.2075
Copyright (c) Microsoft Corporation 2005.
All rights reserved.
Other than that, I think you too have a couple unneeded eval in the
change. I don't remember if I already approved of the patch but in case
not, you may commit after fixing issues, posting updated version, and
waiting 72h then, unless you have further questions you want answered.
I simply plagiarized those evals from the name lister macro above. Oh
well, I fixed that.
I have run the testsuite over the last couple of days on the following
systems, but without this last round of trivial changes (but I have
verified that the trivial changes didn't trivially break anything, i.e.
it looks good on one system). The regression testing was done against
3d2d3ef8 Ensure getopts.m4sh is compatible with Autoconf-2.61 and newer.
MSYS/MinGW
MSYS/MSVC
Cygwin/gcc
Debian Linux cross to mingw32 (with Wine)
Debian Linux/gcc
No regressions and this is the (slightly edited for readability) summary
from the MSVC run (lots of expected failures since I don't have Automake
installed in this environment, I use Cygwin for that part):
abs_srcdir=`CDPATH=${ZSH_VERSION+.}: cd .. pwd`; cd tests; \
CONFIG_SHELL=/bin/sh /bin/sh $abs_srcdir/tests/testsuite \
MAKE=make CC=/path/to/compile cl CFLAGS=-MD -Zi -EHsc \
CPP=/path/to/compile cl -E CPPFLAGS= LD=link LDFLAGS= \
LIBS= LN_S=ln -s NM=dumpbin -symbols RANLIB=: MT=mt \
STRIP=: lt_INSTALL=/bin/install -c OBJEXT=obj EXEEXT=.exe \
SHELL=/bin/sh CONFIG_SHELL=/bin/sh CXX=/path/to/compile cl \
CXXFLAGS=-MD -Zi -EHsc CXXCPP=/path/to/compile cl -E F77=no \
FFLAGS= FC=no FCFLAGS= GCJ=no GCJFLAGS=-g -O2 \
_lt_pkgdatadir=/path/to/libtool/msvc/.. \
LIBTOOLIZE=/path/to/libtool/libtoolize \
LIBTOOL=/path/to/libtool/libtool \
tst_aclocaldir=/path/to/libtool/msvc/../libltdl/m4
## --- ##
## GNU Libtool 2.2.11a test suite. ##
## --- ##
Libtoolize operation.
1: libtoolize macro installation ok
2: libtoolize macro directory mismatch error ok
3: libtoolize macro serial update ok
4: libtoolize config files serial update ok
5: diagnose missing LT_CONFIG_LTDL_DIR ok
6: copy ltdl.m4 with shared macro directoryok
7: correctly parse LTDL_INIT from configure.ac ok
8: diagnose missing
Re: [PATCH] Add an XSI replacement for func_split_short_opt.
No, ${parameter:offset} and ${parameter:offset:length} are bash specific
not XSI mandated.
But we don't need bash-specific hacks.
${parameter#??} serves as a great XSI alternative to ${parameter:2},
and with a (lot) more thought, ${1:1:1} can be written without forks
and without bash-isms as:
tmp=${1#?}
patt=
i=2
while test $i -lt ${#1}; do
patt=?$patt
i=$((i+1))
done
result=${tmp%$patt}
Obviously, you'd want to pick better variable names due to namespace
considerations...
--
View this message in context:
http://old.nabble.com/-PATCH--Add-an-XSI-replacement-for-func_split_short_opt.-tp29005049p29008555.html
Sent from the Gnu - Libtool - Patches mailing list archive at Nabble.com.
Re: [PATCH] Add an XSI replacement for func_split_short_opt.
Hi Eric,
thanks for the suggestion. I had considered the idea for a second, but
failed to see the nontrivial half.
* Eric Blake wrote on Mon, Jun 28, 2010 at 02:49:40PM CEST:
tmp=${1#?}
patt=
i=2
while test $i -lt ${#1}; do
patt=?$patt
If the parameter may be expected to be very long (which I don't think it
will be) then
func_append patt '?'
would be useful here, and even if not, appending rather than prepending
here helps with current bash.
i=$((i+1))
done
result=${tmp%$patt}
Cheers,
Ralf
Re: [PATCH] Add an XSI replacement for func_split_short_opt.
On 06/28/2010 04:19 PM, Ralf Wildenhues wrote:
Hi Eric,
thanks for the suggestion. I had considered the idea for a second, but
failed to see the nontrivial half.
* Eric Blake wrote on Mon, Jun 28, 2010 at 02:49:40PM CEST:
tmp=${1#?}
patt=
i=2
while test $i -lt ${#1}; do
patt=?$patt
If the parameter may be expected to be very long (which I don't think it
will be) then
func_append patt '?'
would be useful here, and even if not, appending rather than prepending
here helps with current bash.
i=$((i+1))
done
result=${tmp%$patt}
After thinking a bit more, this alternative should do the same job in
fewer lines of code and fewer temporary variables:
result=${1#?}
while test ${#result} -gt 1; do
result=${result%?}
done
Also, you have to be a bit careful:
$ tmp=a
$ echo ${tmp:2}
$ echo ${tmp#??}
a
that is, before trying to split off the first two bytes using XSI, you
must ensure that ${#1} has at least two bytes to be split in the first
place.
--
Eric Blake ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 3/4] Uniform const'ness of symlist variable lt_preloaded_symbols.
Hello Vincent, * Ralf Wildenhues wrote on Sat, Jun 19, 2010 at 12:08:29PM CEST: I would like to commit the patch quoted below, on the way of support for LTO with GCC. For that, I need to know from somebody who is willing to help out with the Windows CE port of Libtool whether the #defines used in the patch are sufficient and correct. This is http://thread.gmane.org/gmane.comp.gnu.libtool.general/10794/focus=9769. Libtool has no wince maintainer. If we cannot even get simple questions answered about WinCE, then we cannot ensure to keep Libtool working on this system. Questions answered are a necessary, but not necessarily sufficient condition for keeping a port working. Regular regression testing is usually necessary as well, even if there are none to few changes specific to some port. For systems Charles, the Peters, Bob, Gary, and I have access to, regular testing is pretty much a given, which sums up to something like 3 dozen different setups at least (users do more testing, but I have less of an overview off-hand). Right now I have one simple question: can I assume that the preprocessor symbol _WIN32_WCE is defined for wince code, and usually not defined for non-wince code? This question is the only impediment for this particular patch. Of course, a regression test of Libtool with this patch on wince would be much better even. Thank you, Ralf
