Re: [PATCH] [mingw|cygwin] Modify cwrapper to invoke target directly.
Charles Wilson wrote:
2008-05-05 Charles Wilson ...
* libltdl/config/ltmain.m4sh (func_to_native_path):
new function. If $host is mingw, and $build is mingw
or cygwin, convert path to mingw native format.
(func_to_native_pathlist): new function. Ditto, for
:-separated pathlists.
(func_emit_cwrapperexe_src) [__CYGWIN__ __STRICT_ANSI__]:
ensure putenv and setenv are declared. Define HAVE_SETENV.
(func_emit_cwrapperexe_src) [main]: add new constants to
hold desired PATH settings; initialize and convert to native
mingw format using functions above. Add new command-line
options --lt-env-set, --lt-env-prepend, and --lt-env-append.
No longer emit wrapper script as integral part of launching
child. Remove support for (now) unnecessary $TARGETSHELL.
Exec actual target executable directly.
(func_emit_cwrapperexe_src) [lt_setenv]: new function.
(func_emit_cwrapperexe_src) [lt_extend_str]: new function.
(func_emit_cwrapperexe_src) [lt_split_name_value]: new function.
(func_emit_cwrapperexe_src) [lt_opt_process_env_set]: new function.
(func_emit_cwrapperexe_src) [lt_opt_process_env_prepend]: new function.
(func_emit_cwrapperexe_src) [lt_opt_process_env_append]: new function.
(func_emit_cwrapperexe_src) [lt_update_exe_path]: new function.
(func_emit_cwrapperexe_src) [lt_update_lib_path]: new function.
The attached patch (to be applied over the previous one) addresses the
comments received so far. I can post the merged patch if desired -- and
of course, I'll squash into a single patch before I push.
Cygwin: passes 115 (9 skip) on old test suite
only two unexpected failures on new test suite -- but 25 and 72 are
actually expected on cygwin.
Mingw (msys): no regressions over previous results:
old test suite: fails demo-exec after demo-shared (helldl)
fails the fortran tests, but that's a peculiarity of my system
new test suite: fails 25 and 72 (expected), and 58-60 (a problem with
the autotool wrappers on my system)
OK for push?
--
Chuck
libltdl/config/ltmain.m4sh | 267 +---
1 files changed, 177 insertions(+), 90 deletions(-)
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 82f920e..6469beb 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -2472,19 +2472,23 @@ fi\
}
# end: func_emit_wrapper
-# func_to_native_path
+# func_to_host_path ARG
#
-# intended for use on native mingw (where libtool itself
-# is running under the msys shell). Paths need to be converted
-# to native format when used with native tools. Ordinarily, the
-# (msys) shell automatically converts such things for non-msys
-# applications it launches, but that isn't available from inside
-# the cwrapper. Similar accommodations are necessary for $host
-# mingw and $build cygwin. Calling this function does no harm
-# on other $build or for other $host.
-func_to_native_path ()
+# Convert paths to build format when used with build tools.
+# Intended for use with native mingw (where libtool itself
+# is running under the msys shell). Ordinarily, the (msys) shell
+# automatically converts such things for non-msys applications
+# it launches, but that isn't available from inside the cwrapper.
+# Similar accommodations are necessary for $host mingw and $build
+# cygwin. Calling this function does no harm on other $build or
+# for other $host.
+#
+# ARG is the path (on $build) that should be converted to
+# the proper representation for $host. The result is stored
+# in $func_to_host_path_result.
+func_to_host_path ()
{
- func_to_native_path_result=$1
+ func_to_host_path_result=$1
if test -n $1 ; then
case $host in
*mingw* )
@@ -2493,76 +2497,88 @@ func_to_native_path ()
*mingw* ) # actually, msys
# awkward: cmd appends spaces to result
lt_sed_strip_trailing_spaces=s/[ ]*\$//
-func_to_native_path_tmp1=`( cmd //c echo $1 | $SED -e
$lt_sed_strip_trailing_spaces ) 2/dev/null || echo `
-func_to_native_path_result=`echo $func_to_native_path_tmp1 |
$SED -e $lt_sed_naive_backslashify`
+func_to_host_path_tmp1=`( cmd //c echo $1 |\
+ $SED -e $lt_sed_strip_trailing_spaces ) 2/dev/null || echo `
+func_to_host_path_result=`echo $func_to_host_path_tmp1 |\
+ $SED -e $lt_sed_naive_backslashify`
;;
*cygwin* )
-func_to_native_path_tmp1=`cygpath -w $1`
-func_to_native_path_result=`echo $func_to_native_path_tmp1 |
$SED -e $lt_sed_naive_backslashify`
+func_to_host_path_tmp1=`cygpath -w $1`
+func_to_host_path_result=`echo $func_to_host_path_tmp1 |\
+ $SED -e $lt_sed_naive_backslashify`
;;
esac
-if test -z $func_to_native_path_result ; then
-
multiarch procedure
Hi, I've been using libtool quite happily for some time but have just started looking at packaging libraries for x86_64 systems. I'm trying to find out what the recommended method is for installation of x86_64 64bit libraries. Most of the systems I'm targeting are Fedora which expect 64bit libraries in /usr/local/lib64 etc. and use /usr/local/lib only for 32bit. The compilers I have installed on the x86_64 test machine all build 64bit libraries by default (which is what I want) but $(libdir) defaults to /usr/local/lib Is the only method to manually set --libdir at configure time (I have libtool integrated with automake/autoconf)? I was a little reluctant to have to tell everyone building the libraries that they may (or may not) have to use this switch since I really was hoping to keep the configure stage as automatic as possible. I've done some googling on the subject (with little or nothing concrete to show for it) and it appears that Fedora libtool was patched for multiarch support - although I'm currently uncertain whether this is still true. I had a run through the libtool info at work and I'm sure I found a tantalising reference to multiarch (with a comment along the lines of unless you know what this is you don't need it) but I certainly can't find anything on my home system (libtool 2.2.4) Any suggestions for a 'correct' approach will be gratefully received! (Please CC me in any replies as I am not subscribed to libtool on this email account) Steve -- ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: multiarch procedure
On Fri, 9 May 2008, Steve Edwards wrote: I've been using libtool quite happily for some time but have just started looking at packaging libraries for x86_64 systems. I'm trying to find out what the recommended method is for installation of x86_64 64bit libraries. Different systems use different approaches. Is the only method to manually set --libdir at configure time (I have libtool integrated with automake/autoconf)? I was a little The only way to be sure that things will work is to use --prefix and install into a different directory tree. If you advise to use --libdir, then you still have the interface header files to worry about. Interface header files often have different definitions for 32 and 64 bits. I had a run through the libtool info at work and I'm sure I found a tantalising reference to multiarch (with a comment along the lines of unless you know what this is you don't need it) but I certainly can't find anything on my home system (libtool 2.2.4) Libtool 2.2.X includes support for automatically using 64-bit libraries on various popular systems (e.g. Solaris, Linux). Otherwise 64-bit builds would fail on systems which default to a 32 bit ABI. It does not include multiarch/multilib support necessary to build 32 and 64 bit libraries and install into that footprint. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: multiarch procedure
On Fri, May 9, 2008 at 9:20 AM, Bob Friesenhahn [EMAIL PROTECTED] wrote: On Fri, 9 May 2008, Steve Edwards wrote: I've been using libtool quite happily for some time but have just started looking at packaging libraries for x86_64 systems. I'm trying to find out what the recommended method is for installation of x86_64 64bit libraries. Different systems use different approaches. Is the only method to manually set --libdir at configure time (I have libtool integrated with automake/autoconf)? I was a little The only way to be sure that things will work is to use --prefix and install into a different directory tree. If you advise to use --libdir, then you still have the interface header files to worry about. Interface header files often have different definitions for 32 and 64 bits. I agree with this. I started out using the default redhat method of lib64 and lib. After a while, and adding more platforms, compilers, versions, etc. I found it useful to almost always use different prefixes. That being said, I still have a mechanism in my configure to use lib64, etc. I use the code below to add a configure option to set a libdir suffix. Thus, I can set it to create lib64, lib/x86_64, etc. Then, all my other checks for packages try using $acl_libdirstem to link. If that fails and it is not simply lib, I try that for a mix of packages some of which use lib64, some of which use separate prefixes. You could also set a default, say based on the existance of /usr/lib64 for redhat systems. AC_DEFUN([CHECK_LIBDIR_SUFFIX], [ AC_ARG_WITH(libdir-suffix, AS_HELP_STRING([--with-libdir-suffix=suffix],[Suffix to apply to library directories]),,with_libdir_suffix=) ]) acl_libdirstem=lib$with_libdir_suffix libdir=$libdir$with_libdir_suffix Hope that helps some. I had a run through the libtool info at work and I'm sure I found a tantalising reference to multiarch (with a comment along the lines of unless you know what this is you don't need it) but I certainly can't find anything on my home system (libtool 2.2.4) Libtool 2.2.X includes support for automatically using 64-bit libraries on various popular systems (e.g. Solaris, Linux). Otherwise 64-bit builds would fail on systems which default to a 32 bit ABI. It does not include multiarch/multilib support necessary to build 32 and 64 bit libraries and install into that footprint. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool ___ http://lists.gnu.org/mailman/listinfo/libtool
libtool(2.2.4) detect native java compiler in cross-compilation environment
Hello libtool Team, In my environment exist GNU C and Java compilers along with mingw C cross-compiler. When I build libtool the path to mingw C-compiler (gcc) precede path to native C-compiler. In configure output I see : checking for i386-mingw32msvc-strip... i386-mingw32msvc-strip checking for i386-mingw32msvc-gcc... i386-mingw32msvc-gcc checking for i386-mingw32msvc-gcj... no checking for gcj... gcj - OOPS ! checking if gcj supports -fno-rtti -fno-exceptions... (cached) no checking for gcj option to produce PIC... checking if gcj static flag -static works... no checking if gcj supports -c -o file.o... yes checking if gcj supports -c -o file.o... (cached) yes checking whether the gcj linker (/opt/mingw/i386-mingw32msvc/bin/ld) . Is above detection correct ? If is detected a prefix for a program why configure try to find a program without prefix ? The check for Fortran compiler look similar but I don't have installed native Fortran-compiler so libtool configure don't detect any. Roumen ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool(2.2.4) detect native java compiler in cross-compilation environment
On Fri, 9 May 2008, Roumen Petrov wrote: checking for i386-mingw32msvc-gcj... no checking for gcj... gcj - OOPS ! Is above detection correct ? If is detected a prefix for a program why configure try to find a program without prefix ? It looks to me like it did not detect a prefix for the program in the above example, so, as a last-ditch effort, it tried without a prefix. If it picks up the wrong tools, does libtool's configure end up using them or does it eventually reject them? Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool(2.2.4) detect native java compiler in cross-compilation environment
Bob Friesenhahn wrote: On Fri, 9 May 2008, Roumen Petrov wrote: checking for i386-mingw32msvc-gcj... no checking for gcj... gcj - OOPS ! Is above detection correct ? If is detected a prefix for a program why configure try to find a program without prefix ? It looks to me like it did not detect a prefix for the program in the above example, so, as a last-ditch effort, it tried without a prefix. If it picks up the wrong tools, does libtool's configure end up using them or does it eventually reject them? Dunno. May be it try to use. As example file builddirtests/testsuite.dir/35/run contain (after make check-local) contain: = ... CPP='i386-mingw32msvc-gcc -E' ... STRIP='i386-mingw32msvc-strip' ... GCJ='gcj' GCJFLAGS='-g -O2' ... = Also in the file srcdir/tests/convenience.at I found: = 262: # There are just too many broken gcj installations out there, either missing 263: # libgcj.spec or unable to find it. Skip this test for them. 264: if test $i -eq 1; then 265:AT_CHECK([$GCJ $GCJFLAGS -c foo1.java || exit 77], [], [ignore], [ignore]) 266:AT_CHECK([$GCJ $GCJFLAGS --main=foo1 -o foo1 foo1.java A1.java || exit 77],[],[ignore],[ignore]) 267:AT_CHECK([./foo1$EXEEXT || exit 77],[],[ignore],[ignore]) = and the command make check-local report: 23: Java convenience archives skipped (convenience.at:267) Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Roumen ___ http://lists.gnu.org/mailman/listinfo/libtool
