Re: [PATCH] getopt.m4sh generated libtool option parser, and XSI improvements.
I forgot to commit the following chunk before extracting the patch from git: diff --git a/libltdl/config/getopt.m4sh b/libltdl/config/getopt.m4sh index 1487755..76f9d35 100644 --- a/libltdl/config/getopt.m4sh +++ b/libltdl/config/getopt.m4sh @@ -49,6 +49,13 @@ m4_pattern_forbid([^_?m4go_]) ## 1. Backwards compatibility. ## ## --- ## +# We prefer m4sugar.m4 from Autoconf-2.64, but have fallbacks in this +# section that work back as far as Autoconf-2.61. This file is used +# at bootstrap time to generate the shell processing loop for ltmain.sh +# and libtoolize.in, so it's okay for the requirement to be tighter +# than the configure time Autoconf prerequisite version. +m4_version_prereq([2.61]) + # m4_chomp(STRING) # # m4_chomp was not introduced until Autoconf-2.64. Currently we Assuming this is rolled in too, okay to push? On 23 Jun 2010, at 03:23, Gary V. Vaughan wrote: * libltdl/m4/libtool.m4 (_LT_PROG_XSI_SHELLFNS): Moved portable shell versions of various utility functions from here... * libltdl/config/getopt.m4sh (func_split_long_opt): ...to here... * libltdl/config/general.m4sh (func_dirname, func_basename) (func_dirname_and_basename, func_strip_name): ...here... * libltdl/config/ltmain.m4sh (func_append, func_arith, func_len) (func_lo2o, func_xform): ...and here. * libltdl/config/libtool.m4 (_LT_PROG_XSI_REPLACE): New macro that expands into a sed command for replacing the contents of a suitably decorated shell function with an alternate XSI implementation. (_LT_PROG_XSI_SHELLFNS): Use it to replace the portable shell versions of the functions above with equivalent XSI implementations that avoid unnecessary forks if the host shell supports that. * libltdl/config/ltmain.m4sh: Replace hand written shell code with a call to M4SH_GETOPTS. Rename some option variables in the client code to match the generated option parser settings. * libltdl/config/general.m4sh (func_echo, func_error) (func_warning): Use $opt_mode instead of obsoleted $mode in message leader. Signed-off-by: Gary V. Vaughan g...@gnu.org Cheers, -- Gary V. Vaughan (g...@gnu.org)
Re: MSVC: MSVC needs a hint to force it to compile either as C or C++.
Hi Gary, Den 2010-06-22 14:53 skrev Gary V. Vaughan: In this case, Peter, would you point me at the followup patches that need this preliminary prep work? I had a poke around in your git branch but couldn't (quickly) figure out where this is going... and without that it's hard to do a sane review. I've said it elsewhere, but here are more details in case you missed it: In _LT_LINKER_SHLIBS([TAGNAME]) _LT_TAGVAR(compile_tag, $1)=-TC and in _LT_LANG_CXX_CONFIG([TAG]) _LT_TAGVAR(compile_tag, $1)=-TP As found in commit 9c848f1e8acdf435d019aa80f3f0b0aeb45613f7 Add MSVC support. Cheers, Peter
Re: MSVC: MSVC needs a hint to force it to compile either as C or C++.
On 23 Jun 2010, at 13:56, Peter Rosin wrote: Hi Gary, Hi Peter, Den 2010-06-22 14:53 skrev Gary V. Vaughan: In this case, Peter, would you point me at the followup patches that need this preliminary prep work? I had a poke around in your git branch but couldn't (quickly) figure out where this is going... and without that it's hard to do a sane review. I've said it elsewhere, It seems our posts crossed, but I saw the other response too, thanks. but here are more details in case you missed it: In _LT_LINKER_SHLIBS([TAGNAME]) _LT_TAGVAR(compile_tag, $1)=-TC and in _LT_LANG_CXX_CONFIG([TAG]) _LT_TAGVAR(compile_tag, $1)=-TP As found in commit 9c848f1e8acdf435d019aa80f3f0b0aeb45613f7 Add MSVC support. Actually, this is kind of backwards for how I would have done things... normally I try to build the infrastructure in the earlier patches, and then slot in the enhancements that build on it later. But no matter really, as long as you're happy to point forward to subsequent patches that rely on seemingly non-functional additions from earlier patches as we work through the merge. If you'd rather follow Ralf's suggestions from earlier in this thread, and move the hinting process into Automake, then I'll be delighted. Otherwise, pending the outcome of that discussion, if you're still happy that your earlier branch was already going in the right direction, feel free to commit this to master. I haven't made any testsuite reruns for this part of the review, since this patch is so innocuous I'll wait until I'm reviewing something more contentious first... I am assuming, of course, that you have made a successful testsuite run with this patch merged to guard against syntax errors or the like (successful testsuite run on Linux or Mac is perfectly fine at this point). Cheers, -- Gary V. Vaughan (g...@gnu.org)
Re: MSVC: MSVC needs a hint to force it to compile either as C or C++.
Hi Ralf, Den 2010-06-22 22:16 skrev Ralf Wildenhues: * Peter Rosin wrote on Tue, Jun 22, 2010 at 03:07:30PM CEST: So, it's not a bit deal for me to have this one dangling. But that said, it is nice to fire and forget... This one is not fire and forget. I can live with fire, but not with forget, because the right place to fix this issue is not within Libtool. The issue is similar to what Fortran solves with AC_FC_SRCEXT in Autoconf, whose result automake uses to to put right before the source file name. Here, the same could be done for -Tc or -Tp, respectively. One difference is that the flag is not specific to the file name extension, just to the language. What am I missing? Ah yes, someone would need to call such a macro; probably the cleanest way would be call it from AC_PROG_CC. One cheaper way could be to hard-code known extensions into 'compile' now, but that means this script is getting more uglier. For those that didn't know, we have these cl options to play with: /Tpsource file compile file as .cpp /Tcsource file compile file as .c /TP compile all files as .cpp /TC compile all files as .c (but using - instead of / to not go insane immediately) cl will interpret any files with unknown extensions as object files. It does know about .c and .cpp, but falls over on .cc .c++ .cxx etc. It will treat .C files as plain old C since it doesn't care about filename case. My patches went with -TP/-TC. IIUC AC_FC_SRCEXT outputs FCFLAGS_ext which can be used as this: foo.o: foo.f90 $(FC) -c $(FCFLAGS) $(FCFLAGS_f90) '$(srcdir)/foo.f90' which is a closer match for -Tp/-Tc but I don't know if the missing space is going to be an issue for other potential future users of the macro. I.e. can you portably store a trailing space in a makefile variable so that the following is a usable construct for something that needs e.g. say CXXFLAGS_cc=-cpp ? $(CXX) -c $(CXXFLAGS) $(CXXFLAGS_cc)'$(srcdir)/foo.cc' Another issue that doesn't translate directly from the Fortran case is that one extension we /may/ want to cover is .c++, and I don't expect that CXXFLAGS_c++ is very good as a variable name. To me, it seems way easier to do it in compile. Can it take the clutter? (which would be something like this added to the proposed compile script) *.C | *.cc | *.cpp) func_file_conv $1 set x $@ -Tp$file shift ;; *.c) func_file_conv $1 set x $@ -Tc$file shift ;; And yes, I should apologize for not seeing this four years ago ... You might have, I just don't remember it (I did search and couldn't find anything, but that's hardly water tight evidence...). I do have vague memories of a discussion about which of -TP/-TC and -Tp/-Tc to use though so don't feel too bad. But that might have been before I proposed the patch? Anyway, that doesn't matter. I'm not adding these references about what happened when in these messages to make everyone apologize and generally feel bad. I add them to simplify review and to save others from digging in history that I have already been through. Cheers, Peter
libtool does not recognize /usr/lib64 as default location for libraries
Hello, we have run into a problem where package developed on Debian and packaged for Fedora had rpath included in binaries. This is bad and forbidden by rpm rules (rpmlint will mark it as an error). After long discussion with upstream and Fedora packagers mailing list we have found a reason for this bug: libtool does not consider /usr/lib64 as default location for libraries. On Fedora for x86_64 it's however default location for libraries. We would kindly ask you to incorporate patch to add /usr/lib64 as default location for libraries to the official source code. http://cvs.fedoraproject.org/viewvc/rpms/libtool/devel/libtool-2.2.6a- rpath.patch?content-type=text%2Fplainview=co This will enable packages developed on other than Fedora systems (with included libtool script) to be compiled properly on Fedora. Thanks a lot! Jirka Please check this mailing thread: http://lists.fedoraproject.org/pipermail/packaging/2010-June/007182.html Most important e-mail is this one: = From: Mamoru Tasaka mtas...@ioa.s.u-tokyo.ac.jp Date: Tue, 22 Jun 2010 14:36:01 +0900 To: Discussion of RPM packaging standards and practices for Fedora packag...@lists.fedoraproject.org Well, actually the upstream libtool (Fedora uses 2.2.6a) does not take care of /usr/lib64 for rpath (and this seems the same for the latest 2.2.8). What I usually say is that: -- - Usually the reason that unneeded rpath /usr/lib64 is added to the rebuilt binary is that the upstream developer uses libtool which does not take special care of /usr/lib64 for sys_lib_dlsearch_path_spec, while Fedora's libtool take care of this by adding a patch. See the below patch: http://cvs.fedoraproject.org/viewvc/rpms/libtool/devel/libtool-2.2.6a- rpath.patch?content-type=text%2Fplainview=co So actually for most cases, the case that rpath /usr/lib64 is added (only for 64 bits arch) can be avoided by sed -i.libdir_syssearch -e \ '/sys_lib_dlsearch_path_spec/s|/usr/lib |/usr/lib /usr/lib64 /lib /lib64 |' \ configure i.e. just add the needed paths to sys_lib_dlsearch_path_spec in configure (note that libtool in the build directory is generated by configure) before calling %configure. - You can alternatively do autoreconf -fi, however calling autotools is not recommended unless unavoidable. -- So it is highly possible that if the upstream does not use Fedora (i.e. does not use patched libtool) rpath /usr/lib64 appears on Fedora. And I just confirmed that this method works for this package (hwloc). Regards, Mamoru =
Re: MSVC: MSVC needs a hint to force it to compile either as C or C++.
Den 2010-06-23 07:39 skrev Gary V. Vaughan: What happened 4 years ago? (pr-msvc-support branched on 2008-08-02) I started working in this problem space ca 2003-2004, and proposed a very rough patch 2005. Ralf help immensely and it all got into a much better shape. 2006 was the first time my patches showed up in a form that resembles what's in the pr-msvc-support branch. Ralf created the branch in 2008 with the intention that the work should not bit-rot completely. But having the branch in the official repo has made me reluctant to rebase, refactor and otherwise change things even though it is not correct or tasty enough, so the branch has not really worked from my point of view. Cheers, Peter
Re: MSVC: MSVC needs a hint to force it to compile either as C or C++.
Den 2010-06-22 22:16 skrev Ralf Wildenhues: This one is not fire and forget. I can live with fire, but not with forget, because the right place to fix this issue is not within Libtool. So, let's skip this for libtool and assume that it is fixed elsewhere, at least for now. It's not vital and the libtool testsuite uses .cpp anyway so it should not light up the whole thing with FAILED making other problems hard to spot. Cheers, Peter
Re: MSVC: MSVC needs a hint to force it to compile either as C or C++.
On 6/23/2010 3:57 AM, Peter Rosin wrote: For those that didn't know, we have these cl options to play with: /Tpsource file compile file as .cpp /Tcsource file compile file as .c /TP compile all files as .cpp /TC compile all files as .c (but using - instead of / to not go insane immediately) Yes, cl accepts switches with either '/' or '-' introductory characters. For our purposes, it's almost required to use '-' rather than the Microsoft standard '/', because for native use, our shell is an msys shell, and MSYS does interesting things when exec() or spawn() functions are called... In this case, one interesting thing is that MSYS has a heuristic that any command line arguments that start with '/' are presumed to be (posix) paths, and if the to-be-exec'ed program is a native one, then the argument will be converted to a DOS path. E.g. /Tpbob.cpp == C:/pwd/Tpbob.cpp /TcC:/path/to/fred.cpp == C:/TcC:/path/to/fred.cpp /TP == C:/TP /TC == C:/TC This is clearly bad...and can be avoided by always using '-' (or by 'doubling' the leading slash, which turns off MSYS's path conversion logic: msys path.cc: // // Multiple forward slashes are treated special, // Remove one and return for the form of //foo or ///bar // but just return for the form of //server/share. // but (a) this would break for //TcC:/a/path because the fact that there are additional '/' other than the leading sequence means that the first, doubled pair would not be translated into a single leading slash, and (b) that's just more than we want to deal with, here, since '-' will do what we want.) My patches went with -TP/-TC. OTOH, //TP and //TC would work just as well, with an MSYS shell. But I think your choice (both using '-' and using the capital variants of these switches) is a good one, because... To me, it seems way easier to do it in compile. Can it take the clutter? (which would be something like this added to the proposed compile script) *.C | *.cc | *.cpp) func_file_conv $1 set x $@ -Tp$file shift ;; *.c) func_file_conv $1 set x $@ -Tc$file shift ;; There is one problem with the above. -Tcrel/path/to/file will work OK, and -Tcfile-in-curdir will work. Also -TcC:/dos/path/to. But -Tc/abs/posix/path/to/file won't, because...well, another MSYS heuristic. MSYS knows about some of gcc's path introductory switches, like -I and -L, and will convert -I/posix/path/to/inc -L/posix/path/to/lib to -IC:/msys/1.0/posix/path/to/inc -LC:/msys/1.0/posix/path/to/lib if the gcc in question is a native application (like MinGW gcc is) [Technically, this works for any single letter option. But MSYS *doesn't* know about cl's path introductory switches like -Tc or -Tp that have more than a single letter. msys path.cc: // // Check for single letter option with a // path argument attached, eg -I/include */ // So, for the path translation heuristics to work, MSYS *needs* a space between -Tc and /the/path, so that /the/path can be detected as an absolute posix path by itself. Unfortunately, I *think* cl requires that there be NO space between -Tc and C:/the/path. Ditto -Fo, etc. Unless you've already manually converted the path in question from posix to win32 form, the -Fo, -Tc, -Tp, and similar options won't work. The preceding is all just background, because I think Peter's patch *does* do a manual path conversion for any paths that appear together with these options. It costs an extra fork for each one, but...short of teaching the MSYS DLL about cl's huge list of multi-char options, I think Peter's approach is the only rational choice. -- Chuck
Re: libtool does not recognize /usr/lib64 as default location for libraries
On 2010-06-23, Jirka Hladky jhla...@redhat.com wrote: we have run into a problem where package developed on Debian and packaged for Fedora had rpath included in binaries. This is bad and forbidden by rpm rules (rpmlint will mark it as an error). After long discussion with upstream and Fedora packagers mailing list we have found a reason for this bug: libtool does not consider /usr/lib64 as default location for libraries. On Fedora for x86_64 it's however default location for libraries. We would kindly ask you to incorporate patch to add /usr/lib64 as default location for libraries to the official source code. http://cvs.fedoraproject.org/viewvc/rpms/libtool/devel/libtool-2.2.6a- rpath.patch?content-type=text%2Fplainview=co This will enable packages developed on other than Fedora systems (with included libtool script) to be compiled properly on Fedora. The underlying issue here is that libtool parses ld.so.conf itself, but ldconfig searches some directories in addition to those listed in the config file, so libtool has a list of those default directories which it adds to those it finds in the config file. But the default list varies - on Fedora the list includes /usr/lib64 (presumably only for 64 bit archs though). Fixing this by adding /usr/lib64 unconditionally is technically wrong since not all distros search /usr/lib64 - e.g. Debian and Ubuntu use /lib and /usr/lib on both 32 and 64 bit archs - and 32 bit archs presumably don't for any distro. A user specifying --prefix=/usr/lib64 on a machine where that would need an rpath wouldn't get one (probably not a huge issue in practice), but more of a concern is that there may also be other default directories. For example, on x86-64 Ubuntu karmic libtool 2.2.6 misses the following directories which ldconfig searches by default: /lib32 /usr/lib32 /lib32/i486 /lib32/i686 /lib32/i586 /usr/lib32/sse2 /lib32/i686/cmov Overall it seems to me to be more reliable and cleaner to ask ldconfig what directories it thinks it is looking in rather than parsing its config files and guessing at what others it might search by default. I posted just such a patch exactly 3 years ago today (coincidentally) - here's the thread: http://thread.gmane.org/gmane.comp.gnu.libtool.general/8339/focus=8345 Back then Ralf said Olly's solution should not be forgotten, though, but it seems it has been. I've been using this code in Xapian to override libtool's version for a couple of years now, with no reported problems. The only downside is that it can be quite slow to get the list from ldconfig (I haven't investigated why or if this could be improved - it's interesting that it always seems quick if run a second time which suggests either a cache issue, or that there's a cached value being updated), but the speed of the current approach seems greatly outweighed by the wrong answers it gives. As I said in the original thread, if the patch is wanted I'm happy to update it for current libtool and write a ChangeLog entry. Cheers, Olly
Re: libtool does not recognize /usr/lib64 as default location for libraries
On 06/23/2010 09:12 AM, Olly Betts wrote: I posted just such a patch exactly 3 years ago today (coincidentally) - here's the thread: http://thread.gmane.org/gmane.comp.gnu.libtool.general/8339/focus=8345 Back then Ralf said Olly's solution should not be forgotten, though, but it seems it has been. I've been using this code in Xapian to override libtool's version for a couple of years now, with no reported problems. The only downside is that it can be quite slow to get the list from ldconfig (I haven't investigated why or if this could be improved - it's interesting that it always seems quick if run a second time which suggests either a cache issue, or that there's a cached value being updated), but the speed of the current approach seems greatly outweighed by the wrong answers it gives. As I said in the original thread, if the patch is wanted I'm happy to update it for current libtool and write a ChangeLog entry. Please do, you're obviously correct, the right answer slowly is always better than the wrong one quickly. Peter
MSVC: Add MSVC support.
Hi!
This is basically
Add MSVC support.
9c848f1e8acdf435d019aa80f3f0b0aeb45613f7
but with some things removed, which makes it depend on
the proposed changes to the compile script in automake.
This patch should be a NOP unless you are using the
Microsoft C/C++ Compiler (aka MSVC, aka cl) and are
on a windows $host.
Since it changes the indentation of some other code
I'm attaching a diff -b (msvc-b.diff) as well as the
exported change from git (msvc.patch).
There are many failures in the testsuite with MSVC
with this patch, at least for MSVC 2005 which is the
compiler I'm using by default, due to problems with
manifests. See below. So I'm not publishing any
testsuite results this time, they are too just
disappointing. Please hold.
For this patch I'm looking for an ok to commit, but
I'm going to hold the actual commit until I have done
a couple of more things:
* I have a similar ok for one more patch (.manifest
related, 9f550cb81d4dfe4fc8962f23a7eccb1152e5c4a5)
* I have run the testsuite on Cygwin, MinGW/gcc and
MinGW/msvc and verified that there are no regressions.
* maybe (if you think I should) wait for the proposed
compile script to be commited to automake.
Cheers,
Peter
commit bc206b38ba3a10d106e84acd1a4eb4ba31bfe101
Author: Peter Rosin peda@lysator.liu.se
Date: Wed Jun 23 10:52:58 2010 +0200
Add MSVC support.
* libltdl/m4/libtool.m4: Add support for Microsoft Visual C.
* NEWS: Add note of the above.
diff --git a/ChangeLog b/ChangeLog
index 18e346d..1e2404e 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2010-06-23 Peter Rosin peda@lysator.liu.se
+
+ Add MSVC support.
+ * libltdl/m4/libtool.m4: Add support for Microsoft Visual C.
+ * NEWS: Add note of the above.
+
2010-06-21 Gary V. Vaughan gary@gnu.org
Ensure getopts.m4sh is compatible with Autoconf-2.61 and newer.
diff --git a/NEWS b/NEWS
index 33531dc..b25f096 100644
--- a/NEWS
+++ b/NEWS
@@ -7,6 +7,9 @@ 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 w/o cccl.
+
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 b93dd0c..f11a2d2 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -2201,8 +2201,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,* | yes,* | yes,*)
+# gcc
library_names_spec='$libname.dll.a'
# DLL is installed to $(libdir)/../bin by postinstall_cmds
postinstall_cmds='base_file=`basename \${file}`~
@@ -2235,13 +2236,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
;;
@@ -4251,13 +4281,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
MSVC: For MSVC, embed the manifest as a resource in the executable.
Hi!
This is
For MSVC, embed the manifest as a resource in the executable.
9f550cb81d4dfe4fc8962f23a7eccb1152e5c4a5
and the relevant part of
patch msvc-documentation.patch
06cfce005204bb8ca212aadab38b38c0202ea04e
with @var changed to @code
This patch depends on the just posted Add MSVC support. patch.
This patch was originally proposed here:
http://lists.gnu.org/archive/html/libtool-patches/2008-08/msg00018.html
And okeyed for the pr-msvc-support branch by Ralf here:
http://lists.gnu.org/archive/html/libtool-patches/2008-08/msg00031.html
I'm intend to reply to this message with testsuite results
for the Add MSVC support patch plus this patch for various
systems.
Cheers,
Peter
commit d742f2543f4d04cabe53f9b37822cdd535441d76
Author: Peter Rosin peda@lysator.liu.se
Date: Wed Jun 23 14:14:05 2010 +0200
For MSVC, embed the manifest as a resource in the executable.
* libltdl/m4/libtool.m4 (_LT_LINKER_SHLIBS) postlink_cmds:
New tag variable.
[ cygwin, mingw, cegcc ] cl*: Embed the manifest file as a
resource.
(_LT_LANG_CXX_CONFIG): Likewise.
* libltdl/config/ltmain.m4sh (func_mode_link): After linking
a program, replace @OUTPUT@ in $postlink_cmds and then execute
the commands.
* doc/libtool.texi (libtool script contents): Document
new variable.
Signed-off-by: Ralf Wildenhues Ralf.Wildenhues@gmx.de
diff --git a/ChangeLog b/ChangeLog
index 1e2404e..1ee1b81 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,19 @@
2010-06-23 Peter Rosin peda@lysator.liu.se
+ For MSVC, embed the manifest as a resource in the executable.
+ * libltdl/m4/libtool.m4 (_LT_LINKER_SHLIBS) postlink_cmds:
+ New tag variable.
+ [ cygwin, mingw, cegcc ] cl*: Embed the manifest file as a
+ resource.
+ (_LT_LANG_CXX_CONFIG): Likewise.
+ * libltdl/config/ltmain.m4sh (func_mode_link): After linking
+ a program, replace @OUTPUT@ in $postlink_cmds and then execute
+ the commands.
+ * doc/libtool.texi (libtool script contents): Document
+ new variable.
+
+2010-06-23 Peter Rosin peda@lysator.liu.se
+
Add MSVC support.
* libltdl/m4/libtool.m4: Add support for Microsoft Visual C.
* NEWS: Add note of the above.
diff --git a/doc/libtool.texi b/doc/libtool.texi
index 7ae2c66..82a544e 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -6199,6 +6199,15 @@ Commands run after installing a shared or static library, respectively.
Commands run after uninstalling a shared or static library, respectively.
@end defvar
+@defvar postlink_cmds
+Commands necessary for finishing linking programs. @code{postlink_cmds}
+are executed immediately after the program is linked. Any occurance of
+the string @code{@@OUTPUT@@} in @code{postlink_cmds} is replaced by the
+name of the created executable (i.e. not the wrapper, if a wrapper is
+generated) prior to execution. Normally disabled (i.e.
+@code{postlink_cmds} empty).
+@end defvar
+
@defvar reload_cmds
@defvarx reload_flag
Commands to create a reloadable object.
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index a325e27..9618074 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -7448,6 +7448,11 @@ EOF
exit_status=0
func_show_eval $link_command 'exit_status=$?'
+ if test -n $postlink_cmds; then
+ postlink_cmds=`func_echo_all $postlink_cmds | $SED -e 's%@OUTPUT@%'$output'%g'`
+ func_execute_cmds $postlink_cmds 'exit $?'
+ fi
+
# Delete the generated files.
if test -f $output_objdir/${outputname}S.${objext}; then
func_show_eval '$RM $output_objdir/${outputname}S.${objext}'
@@ -7493,6 +7498,12 @@ EOF
$opt_dry_run || $RM $output
# Link the executable and exit
func_show_eval $link_command 'exit $?'
+
+ if test -n $postlink_cmds; then
+ postlink_cmds=`func_echo_all $postlink_cmds | $SED -e 's%@OUTPUT@%'$output'%g'`
+ func_execute_cmds $postlink_cmds 'exit $?'
+ fi
+
exit $EXIT_SUCCESS
fi
@@ -7526,6 +7537,11 @@ EOF
func_show_eval $link_command 'exit $?'
+ if test -n $postlink_cmds; then
+ postlink_cmds=`func_echo_all $postlink_cmds | $SED -e 's%@OUTPUT@%'$output_objdir/$outputname'%g'`
+ func_execute_cmds $postlink_cmds 'exit $?'
+ fi
+
# Now create the wrapper script.
func_verbose creating $output
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index f11a2d2..a0c723c 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -4858,6 +4858,10 @@ _LT_EOF
_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'
# Don't use ranlib
_LT_TAGVAR(old_postinstall_cmds, $1)='chmod 644 $oldlib'
+ _LT_TAGVAR(postlink_cmds, $1)='if test -e @OUTPUT@.exe.manifest; then
+ mt -manifest @OUTPUT@.exe.manifest -outputresource:@OUTPUT@.exe;
+ $RM @OUTPUT@.exe.manifest;
+ fi'
;;
*)
# Assume MSVC wrapper
@@ -5411,6 +5415,8 @@
Re: MSVC: For MSVC, embed the manifest as a resource in the executable.
Hi! Den 2010-06-23 16:47 skrev Peter Rosin: I'm intend to reply to this message with testsuite results for the Add MSVC support patch plus this patch for various systems. While I didn't see any regressions, I did notice that it didn't go too well with MSVC either. So, I dug around and found a forgotten gem [1], and updated it to apply on top of the previous patch. Result attached. So, I'm asking if this too can be commited, if the testsuite finds no regressions... [1] http://lists.gnu.org/archive/html/libtool-patches/2008-09/msg0.html Cheers, Peter commit a5763df949041e07cb01b7da29dbfdb4d3eb9491 Author: Peter Rosin peda@lysator.liu.se Date: Wed Jun 23 18:05:11 2010 +0200 Handle -o w/ and w/o $EXEEXT during manifest embedding * libltdl/m4/libtool.m4 (_LT_LINKER_SHLIBS) [ cygwin, mingw, cegcc ] cl*: @OUTPUT@ may or may not include a trailing $EXEEXT. If mt fails, make sure libtool exits with an error. (_LT_LANG_CXX_CONFIG): Likewise. * tests/exeext.at: New. Make sure linking with both -o prog and -o prog$EXEEXT works. * Makefile.am: Add previous test to testsuite. diff --git a/ChangeLog b/ChangeLog index 1ee1b81..b9a5c80 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,17 @@ 2010-06-23 Peter Rosin peda@lysator.liu.se + Handle -o w/ and w/o $EXEEXT during manifest embedding + * libltdl/m4/libtool.m4 (_LT_LINKER_SHLIBS) + [ cygwin, mingw, cegcc ] cl*: @OUTPUT@ may or may not + include a trailing $EXEEXT. If mt fails, make sure libtool + exits with an error. + (_LT_LANG_CXX_CONFIG): Likewise. + * tests/exeext.at: New. Make sure linking with both -o prog + and -o prog$EXEEXT works. + * Makefile.am: Add previous test to testsuite. + +2010-06-23 Peter Rosin peda@lysator.liu.se + For MSVC, embed the manifest as a resource in the executable. * libltdl/m4/libtool.m4 (_LT_LINKER_SHLIBS) postlink_cmds: New tag variable. diff --git a/Makefile.am b/Makefile.am index 5822428..de98e4e 100644 --- a/Makefile.am +++ b/Makefile.am @@ -471,6 +471,7 @@ TESTSUITE_AT = tests/testsuite.at \ tests/search-path.at \ tests/indirect_deps.at \ tests/archive-in-archive.at \ + tests/exeext.at \ tests/execute-mode.at \ tests/bindir.at \ tests/cwrapper.at \ diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4 index a0c723c..0a7065a 100644 --- a/libltdl/m4/libtool.m4 +++ b/libltdl/m4/libtool.m4 @@ -4858,9 +4858,14 @@ _LT_EOF _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' # Don't use ranlib _LT_TAGVAR(old_postinstall_cmds, $1)='chmod 644 $oldlib' - _LT_TAGVAR(postlink_cmds, $1)='if test -e @OUTPUT@.exe.manifest; then - mt -manifest @OUTPUT@.exe.manifest -outputresource:@OUTPUT@.exe; - $RM @OUTPUT@.exe.manifest; + _LT_TAGVAR(postlink_cmds, $1)='lt_outputfile=@OUTPUT@~ + case $lt_outputfile in + *.[[eE][xX][eE]]) ;; + *) lt_outputfile=$lt_outputfile.exe ;; + esac~ + if test -e $lt_outputfile.manifest; then + mt -manifest $lt_outputfile.manifest -outputresource:$lt_outputfile || exit 1; + $RM $lt_outputfile.manifest; fi' ;; *) @@ -5840,9 +5845,14 @@ if test $_lt_caught_CXX_error != yes; then _LT_TAGVAR(enable_shared_with_static_runtimes, $1)=yes # Don't use ranlib _LT_TAGVAR(old_postinstall_cmds, $1)='chmod 644 $oldlib' - _LT_TAGVAR(postlink_cmds, $1)='if test -e @OUTPUT@.exe.manifest; then - mt -manifest @OUTPUT@.exe.manifest -outputresource:@OUTPUT@.exe; - $RM @OUTPUT@.exe.manifest; + _LT_TAGVAR(postlink_cmds, $1)='lt_outputfile=@OUTPUT@~ + case $lt_outputfile in + *.[[eE][xX][eE]]) ;; + *) lt_outputfile=$lt_outputfile.exe ;; + esac~ + if test -e $lt_outputfile.manifest; then + mt -manifest $lt_outputfile.manifest -outputresource:$lt_outputfile || exit 1; + $RM $lt_outputfile.manifest; fi' ;; *) diff --git a/tests/exeext.at b/tests/exeext.at new file mode 100644 index 000..ee5d755 --- /dev/null +++ b/tests/exeext.at @@ -0,0 +1,53 @@ +# exeext.at -- ensure that exeext handling works -*- Autotest -*- +# +# Copyright (C) 2010 Free Software Foundation, Inc. +# Written by Peter Rosin +# +# 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
Re: MSVC: MSVC needs a hint to force it to compile either as C or C++.
* Peter Rosin wrote on Wed, Jun 23, 2010 at 09:57:54AM CEST:
For those that didn't know, we have these cl options to play with:
One reference: http://msdn.microsoft.com/en-us/library/19z1t1wy.aspx
My patches went with -TP/-TC. IIUC AC_FC_SRCEXT outputs FCFLAGS_ext which
can be used as this:
foo.o: foo.f90
$(FC) -c $(FCFLAGS) $(FCFLAGS_f90) '$(srcdir)/foo.f90'
which is a closer match for -Tp/-Tc but I don't know if the missing space
is going to be an issue for other potential future users of the macro. I.e.
can you portably store a trailing space in a makefile variable so that the
following is a usable construct for something that needs e.g. say
CXXFLAGS_cc=-cpp ?
$(CXX) -c $(CXXFLAGS) $(CXXFLAGS_cc)'$(srcdir)/foo.cc'
It is possible I think, with something like
empty =
trailing_space = foo $(empty)
But for packages using automake, this is not an issue at all. Look at
automake.in, it controls how per-language compile lines will look like:
$sourceflags{'.' . $suffix} = '$(FCFLAGS_' . $suffix . ') '
Note the trailing space, that gets expanded at automake run time, not at
make run time.
Another issue that doesn't translate directly from the Fortran case is that
one extension we /may/ want to cover is .c++, and I don't expect that
CXXFLAGS_c++ is very good as a variable name.
Flattening of the suffix is trivial in automake, too.
This would all just be an issue for packages using Autoconf but not
Automake, writing compile lines in Makefile.in files themselves.
To me, it seems way easier to do it in compile. Can it take the clutter?
(which would be something like this added to the proposed compile script)
*.C | *.cc | *.cpp)
func_file_conv $1
set x $@ -Tp$file
shift
;;
*.c)
func_file_conv $1
set x $@ -Tc$file
shift
;;
Are you sure there can't be another argument matching these endings?
-Dfoo=bar.cc
Does cl accept any options with separated arguments, i.e., $2 has the
argument to $1? We may have to start parsing these right.
Other than that, I don't see problems with the 'compile' hack approach.
Please keep this change (and associated testsuite additions) separate
from the other patch though, for clarity.
I'm not adding these references about what happened when in these messages
to make everyone apologize and generally feel bad. I add them to simplify
review and to save others from digging in history that I have already been
through.
Yeah, and that's good, too.
Thanks,
Ralf
Re: MSVC: Add MSVC support.
* Peter Rosin wrote on Wed, Jun 23, 2010 at 04:26:22PM CEST:
For this patch I'm looking for an ok to commit, but
I'm going to hold the actual commit until I have done
a couple of more things:
* I have a similar ok for one more patch (.manifest
related, 9f550cb81d4dfe4fc8962f23a7eccb1152e5c4a5)
* I have run the testsuite on Cygwin, MinGW/gcc and
MinGW/msvc and verified that there are no regressions.
You have my OK to commit this patch, provided that you do the above
testing, address the nits below, and wait 72h for other comments.
Thanks.
* maybe (if you think I should) wait for the proposed
compile script to be commited to automake.
Not for me. If you want this available somewhere then I suggest you put
Automake plus your proposed patches up on a github somewhere until the
copyright assignment is done, which might easily take weeks. Please
make it clear in the .git/description that it is not an official tree.
+2010-06-23 Peter Rosin p...@lysator.liu.se
+
+ Add MSVC support.
+ * libltdl/m4/libtool.m4: Add support for Microsoft Visual C.
+ * NEWS: Add note of the above.
Please rewrite this ChangeLog entry to be a good one, mentioning the
macros you change, the systems, compilers affected, in the format
used otherwise in the ChangeLog.
--- a/NEWS
+++ b/NEWS
@@ -7,6 +7,9 @@ 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 w/o cccl.
Please no abbreviations like w/o here, this is text for the user. Also,
the 'compile' script is needed now, no?
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -2201,8 +2201,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,* | yes,* | yes,*)
`X | X | X' is equivalent to `X'.
@@ -2235,13 +2236,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
;;
@@ -4253,8 +4283,13 @@ m4_if([$1], [CXX], [
_LT_TAGVAR(export_symbols_cmds, $1)=$ltdll_cmds
;;
cygwin* | mingw* | cegcc*)
+case $cc_basename in
+cl*) ;;
+*)
_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'
;;
+esac
+;;
*)
_LT_TAGVAR(export_symbols_cmds, $1)='$NM $libobjs $convenience |
$global_symbol_pipe | $SED '\''s/.* //'\'' | sort | uniq $export_symbols'
;;
@@ -4797,6 +4832,35 @@ _LT_EOF
# Microsoft Visual C++.
# hardcode_libdir_flag_spec is actually meaningless, as there is
# no search path for DLLs.
+ case $cc_basename in
+ cl*)
+ # Native MSVC
+ _LT_TAGVAR(hardcode_libdir_flag_spec, $1)=' '
+
Re: MSVC: For MSVC, embed the manifest as a resource in the executable.
Hi Peter, * Peter Rosin wrote on Wed, Jun 23, 2010 at 04:47:45PM CEST: For MSVC, embed the manifest as a resource in the executable. 9f550cb81d4dfe4fc8962f23a7eccb1152e5c4a5 and the relevant part of patch msvc-documentation.patch 06cfce005204bb8ca212aadab38b38c0202ea04e This patch assumes that 'mt' is present, is what you think it is, and doesn't allow an override. On my GNU/Linux, mt is part of cpio and controls magnetic tapes. Is there possibility for similar confusion on w32, or want of choice of a different mt version? This should probably use AC_CHECK_TOOL or so for this, and an _LT_DECL, similar to how objdump, dlltool are handled in ltoptions.m4, but defaulting to ':' not false. Not that I can imagine anyone prefixing it with `$host-'. But it's probably prudent to check that it accepts -? or so (be sure to quote the ?). I'm assuming that we will rework manifest handling later again anyway, but for now it doesn't look like this can make things any worse other than above note. So, with that addressed, please repost and wait 72h before committing. Thanks, Ralf
Re: MSVC: For MSVC, embed the manifest as a resource in the executable.
* Peter Rosin wrote on Wed, Jun 23, 2010 at 06:12:43PM CEST: While I didn't see any regressions, I did notice that it didn't go too well with MSVC either. So, I dug around and found a forgotten gem [1], and updated it to apply on top of the previous patch. Result attached. So, I'm asking if this too can be commited, if the testsuite finds no regressions... [1] http://lists.gnu.org/archive/html/libtool-patches/2008-09/msg0.html Okay if you replace test -e with test -f in this and prior patch, and if the testsuite addition exposes the issue, and the test passes on one unixy system. I'm not happy about the exeext normalization here, that probably belongs alongside the rest of the exeext hanling in ltmain. OTOH, there, no case-insensitive handling is done. Why should it be needed here? Do you expect package authors to write .EXE in their makefiles? Note that you aren't picking up file names from the system here; right? Thanks, Ralf
Re: MSVC: Add MSVC support.
Den 2010-06-23 20:29 skrev Ralf Wildenhues: * Peter Rosin wrote on Wed, Jun 23, 2010 at 04:26:22PM CEST: For this patch I'm looking for an ok to commit, but I'm going to hold the actual commit until I have done a couple of more things: * I have a similar ok for one more patch (.manifest related, 9f550cb81d4dfe4fc8962f23a7eccb1152e5c4a5) * I have run the testsuite on Cygwin, MinGW/gcc and MinGW/msvc and verified that there are no regressions. You have my OK to commit this patch, provided that you do the above testing, address the nits below, and wait 72h for other comments. Thanks. Cool! * maybe (if you think I should) wait for the proposed compile script to be commited to automake. Not for me. If you want this available somewhere then I suggest you put Automake plus your proposed patches up on a github somewhere until the copyright assignment is done, which might easily take weeks. Please make it clear in the .git/description that it is not an official tree. That's not worth it. At least not to me... +2010-06-23 Peter Rosinp...@lysator.liu.se + + Add MSVC support. + * libltdl/m4/libtool.m4: Add support for Microsoft Visual C. + * NEWS: Add note of the above. Please rewrite this ChangeLog entry to be a good one, mentioning the macros you change, the systems, compilers affected, in the format used otherwise in the ChangeLog. Ouch. That was a pretty bad entry indeed. Is this good enough? 2010-06-23 Peter Rosin p...@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. --- a/NEWS +++ b/NEWS @@ -7,6 +7,9 @@ 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 w/o cccl. Please no abbreviations like w/o here, this is text for the user. Also, the 'compile' script is needed now, no? 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? + yes,* | yes,* | yes,*) `X | X | X' is equivalent to `X'. How silly. *fixing* It strikes me as a bit inconsistent that here, the default case will be g++, and above, the default case is non-GCC. I'm not actually sure which is better, in the presence of other compilers users want to see supported, but I think we should be consistent in handling between C and C++. It's just the way it is. In the C case, there is a big divider between GNU and non-GNU. For C++ it all jumbled together. Fixing that is out of scope I presume. The difference is perhaps even more visible by the fact that the cccl port (if it even deserves to be called a port) is not C++ aware AFAICT. Cheers, Peter
Re: Blackfin and version scripts
Mike Frysinger vap...@gentoo.org writes: alternative might be to do something like -export-symbols where libtool has its own method for managing lists of symbols, but extend it to handle versioning information as available with GNU/Solaris linkers. then that would take care of outputting the version script with the symbol prefix which libtool already knows. That might be a cleaner way of implementing the 80% solution. For most packages, I suspect that all you need to do is add the default symbol version string to the existing -export-symbols list as input parameters and then have libtool generate a symbol versioning file giving all symbols that version and listing everything in -export-symbols as global, with a local: *; section. There are nice things that you can do with a more sophisticated approach to versioning the symbols, but most use of symbol versioning is to avoid conflicts when multiple versions of a shared library are loaded at the same time, not to do more sophisticated things like provide multiple versions of a function bound to different symbol versions. -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Blackfin and version scripts
On Wed, 23 Jun 2010 07:29, r...@stanford.edu said:
I can take a pass at starting. All that I need for my packages is to
support the basic version syntax:
version {
global:
symbol;
That would be sufficient for me too as long as a version_2 with only
global symbols is supported as well.
Having a second file with a simple list of symbols instead of a version
script parser is another option. Actually this is required because to
support W32 we need a .def file
EXPORTS
gcry_check_version @1
gcry_control @2
which allows to assign id numbers to symbols. In theory we could add
this via comment lines to a versions script but that would make a parser
even more complicated. In some projects I create the .def file from a
.def.in file to handle differences between W32 and W32CE. In any case
the .def file is easy to parse and could be used as input to
--export-symbols.
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
___
http://lists.gnu.org/mailman/listinfo/libtool
