[PATCH 07/10] libtool: fix DLL creation/installation/uninstallation on OS/2
OS/2 limits a length of a DLL base name up to 8 characters. If a name of
a shared library is longer than 8 characters, OS/2 cannot load it. And
fix install/uninstall process using link which is not supported OS/2.
* build-aux/ltmain.in: Do not strip an import lib.
* m4/libtool.m4: Set variables to fix DLL creation, installation
and uninstallation.
---
build-aux/ltmain.in |7 +++
m4/libtool.m4 | 48
2 files changed, 51 insertions(+), 4 deletions(-)
diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index 5829cf2..86b42dd 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -2400,6 +2400,13 @@ func_mode_install ()
;;
esac
;;
+ os2*)
+ case $realname in
+ *_dll.a)
+ tstripme=
+ ;;
+ esac
+ ;;
esac
if test -n $tstripme test -n $striplib; then
func_show_eval $striplib $destdir/$realname 'exit $?'
diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 0713c29..e360efd 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -2810,9 +2810,27 @@ os2*)
libname_spec='$name'
shrext_cmds=.dll
need_lib_prefix=no
- library_names_spec='$libname$shared_ext $libname.a'
+ # OS/2 limits a length of a DLL basename up to 8 characters.
+ # So there is need to use a short name instead of a original name
+ # longer than 8 characters. And replace '.' with '_'.
+ soname_spec='`eval $ECHO $libname | cut -b -8 | tr . _`${shared_ext}'
+ library_names_spec='${libname}_dll.$libext'
dynamic_linker='OS/2 ld.exe'
- shlibpath_var=LIBPATH
+ shlibpath_var=BEGINLIBPATH
+ sys_lib_search_path_spec=/lib /usr/lib /usr/local/lib
+ sys_lib_dlsearch_path_spec=$sys_lib_search_path_spec
+ 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~
+chmod a+x \$dldir/$dlname~
+if test -n '\''$stripme'\'' test -n '\''$striplib'\''; then
+ eval '\''$striplib \$dldir/$dlname'\'' || exit \$?;
+fi'
+ postuninstall_cmds='dldll=`$SHELL 21 -c '\''. $file; $ECHO \$dlname'\''`~
+dlpath=$dir/\$dldll~
+ $RM \$dlpath'
;;
osf3* | osf4* | osf5*)
@@ -4960,6 +4978,16 @@ _LT_EOF
_LT_TAGVAR(link_all_deplibs, $1)=yes
;;
+os2*)
+ _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir'
+ _LT_TAGVAR(hardcode_minus_L, $1)=yes
+ _LT_TAGVAR(allow_undefined_flag, $1)=unsupported
+ shrext_cmds=.dll
+ _LT_TAGVAR(archive_cmds, $1)='$ECHO LIBRARY ${soname%$shared_ext}
INITINSTANCE TERMINSTANCE $output_objdir/$libname.def~$ECHO DESCRIPTION
\$libname\ $output_objdir/$libname.def~$ECHO DATA
$output_objdir/$libname.def~$ECHO MULTIPLE NONSHARED
$output_objdir/$libname.def~$ECHO EXPORTS $output_objdir/$libname.def~emxexp
$libobjs | $SED /_DLL_InitTerm/d $output_objdir/$libname.def~$CC -Zdll
-Zcrtdll -o $output_objdir/$soname $libobjs $deplibs $compiler_flags
$output_objdir/$libname.def~emximp -o $lib $output_objdir/$libname.def'
+ _LT_TAGVAR(old_archive_From_new_cmds, $1)='emximp -o
$output_objdir/${libname}_dll.a $output_objdir/$libname.def'
+ _LT_TAGVAR(enable_shared_with_static_runtimes, $1)=yes
+ ;;
+
interix[[3-9]]*)
_LT_TAGVAR(hardcode_direct, $1)=no
_LT_TAGVAR(hardcode_shlibpath_var, $1)=no
@@ -5578,8 +5606,10 @@ _LT_EOF
_LT_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir'
_LT_TAGVAR(hardcode_minus_L, $1)=yes
_LT_TAGVAR(allow_undefined_flag, $1)=unsupported
- _LT_TAGVAR(archive_cmds, $1)='$ECHO LIBRARY $libname INITINSTANCE
$output_objdir/$libname.def~$ECHO DESCRIPTION \$libname\
$output_objdir/$libname.def~echo DATA $output_objdir/$libname.def~echo
SINGLE NONSHARED $output_objdir/$libname.def~echo EXPORTS
$output_objdir/$libname.def~emxexp $libobjs $output_objdir/$libname.def~$CC
-Zdll -Zcrtdll -o $lib $libobjs $deplibs $compiler_flags
$output_objdir/$libname.def'
- _LT_TAGVAR(old_archive_from_new_cmds, $1)='emximp -o
$output_objdir/$libname.a $output_objdir/$libname.def'
+ shrext_cmds=.dll
+ _LT_TAGVAR(archive_cmds, $1)='$ECHO LIBRARY ${soname%$shared_ext}
INITINSTANCE TERMINSTANCE $output_objdir/$libname.def~$ECHO DESCRIPTION
\$libname\ $output_objdir/$libname.def~$ECHO DATA
$output_objdir/$libname.def~$ECHO MULTIPLE NONSHARED
$output_objdir/$libname.def~$ECHO EXPORTS $output_objdir/$libname.def~emxexp
$libobjs | $SED /_DLL_InitTerm/d $output_objdir/$libname.def~$CC -Zdll
-Zcrtdll -o $output_objdir/$soname $libobjs $deplibs $compiler_flags
$output_objdir/$libname.def~emximp -o $lib $output_objdir/$libname.def'
+ _LT_TAGVAR(old_archive_From_new_cmds, $1)='emximp -o
$output_objdir/${libname}_dll.a $output_objdir/$libname.def'
+
[PATCH 02/10] libtool: set lt_prog_compiler_static to -Bstatic on OS/2
* m4/libtool.m4 (_LT_COMPILER_PIC): Same as the title. --- m4/libtool.m4 | 15 +++ 1 files changed, 15 insertions(+), 0 deletions(-) diff --git a/m4/libtool.m4 b/m4/libtool.m4 index 320d8b3..248d423 100644 --- a/m4/libtool.m4 +++ b/m4/libtool.m4 @@ -4060,6 +4060,11 @@ m4_if([$1], [CXX], [ # (--disable-auto-import) libraries m4_if([$1], [GCJ], [], [_LT_TAGVAR(lt_prog_compiler_pic, $1)='-DDLL_EXPORT']) + case $host_os in + os2*) +_LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic' +;; + esac ;; darwin* | rhapsody*) # PIC is the default on this platform @@ -4379,6 +4384,11 @@ m4_if([$1], [CXX], [ # (--disable-auto-import) libraries m4_if([$1], [GCJ], [], [_LT_TAGVAR(lt_prog_compiler_pic, $1)='-DDLL_EXPORT']) + case $host_os in + os2*) +_LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic' +;; + esac ;; darwin* | rhapsody*) @@ -4476,6 +4486,11 @@ m4_if([$1], [CXX], [ # built for inclusion in a dll (and should export symbols for example). m4_if([$1], [GCJ], [], [_LT_TAGVAR(lt_prog_compiler_pic, $1)='-DDLL_EXPORT']) + case $host_os in + os2*) +_LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic' +;; + esac ;; hpux9* | hpux10* | hpux11*) -- 1.7.3.2
[PATCH 2/8] libtool: don't eliminate duplications in $postdeps and $predeps on OS/2
* build-aux/ltmain.h (libtool_validate_options): Add *os2* to the list. --- build-aux/ltmain.in |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in index 0dea055..cf72c66 100644 --- a/build-aux/ltmain.in +++ b/build-aux/ltmain.in @@ -499,7 +499,7 @@ libtool_validate_options () case $host in # Solaris2 added to fix http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16452 # see also: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59788 - *cygwin* | *mingw* | *pw32* | *cegcc* | *solaris2*) + *cygwin* | *mingw* | *pw32* | *cegcc* | *solaris2* | *os2*) # don't eliminate duplications in $postdeps and $predeps opt_duplicate_compiler_generated_deps=: ;; -- 1.7.3.2
[PATCH 1/8] libtool: add -os2dllname option
OS/2 limits a length of a DLL base name up to 8 characters. If a name of
a shared library is longer than 8 characters, OS/2 cannot load it. So the
option to specify a OS/2 DLL name shorter than 8 characters is needed.
As well as, OS/2 does not allow OS/2 DLL name to contain '.'.
* NEWS: Add news for -os2dllname.
* build-aux/ltmain.in (func_mode_help): Add a description for -os2dllname.
(fund_mode_link): Add -os2dllname.
* doc/libtool.texi: Add -os2dllname item.
* m4/libtool.m4: Introduce os2dllname_cmds for -os2dllname.
---
NEWS|2 ++
build-aux/ltmain.in | 11 +++
doc/libtool.texi|4
m4/libtool.m4 | 38 ++
4 files changed, 51 insertions(+), 4 deletions(-)
diff --git a/NEWS b/NEWS
index 1ca6d65..b2479db 100644
--- a/NEWS
+++ b/NEWS
@@ -34,6 +34,8 @@ NEWS - list of user-visible changes between releases of GNU
Libtool
make check-local TESTSUITEFLAGS='-k !expensive'
+ - Added -os2dllname option to specify a OS/2 DLL name (OS/2 only)
+
** Bug fixes:
- Fix a long-standing latent bug in autom4te include path for autotests
diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index 65b5a2d..0dea055 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -1819,6 +1819,7 @@ The following components of LINK-COMMAND are treated
specially:
-no-undefined declare that a library does not refer to external symbols
-o OUTPUT-FILEcreate OUTPUT-FILE from the specified objects
-objectlist FILE Use a list of object files found in FILE to specify objects
+ -os2dllname NAME specify a OS/2 DLL name(effect on OS/2 only)
-precious-files-regex REGEX
don't remove output files matching REGEX
-release RELEASE specify package release information
@@ -4856,6 +4857,11 @@ func_mode_link ()
prev=
continue
;;
+ os2dllname)
+ os2dllname_cmds=$ECHO $arg | cut -b -8 | tr . _
+ prev=
+ continue
+ ;;
precious_regex)
precious_files_regex=$arg
prev=
@@ -5165,6 +5171,11 @@ func_mode_link ()
continue
;;
+ -os2dllname)
+ prev=os2dllname
+ continue
+ ;;
+
-o) prev=output ;;
-precious-files-regex)
diff --git a/doc/libtool.texi b/doc/libtool.texi
index 89c5d1a..65d63a3 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -1531,6 +1531,10 @@ Create @var{output-file} from the specified objects and
libraries.
@item -objectlist @var{file}
Use a list of object files found in @var{file} to specify objects.
+@item -os2dllname @var{name}
+If @var{name} is specified, replace a name for a DLL with @var{suffix} (effect
+on OS/2 only)
+
@item -precious-files-regex @var{regex}
Prevents removal of files from the temporary output directory whose
names match this regular expression. You might specify @samp{\.bbg?$}
diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 320d8b3..da29e57 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -2286,6 +2286,7 @@ BEGIN {RS = ; FS = /|\n;} {
else
sys_lib_search_path_spec=/lib /usr/lib /usr/local/lib
fi])
+os2dllname_cmds=
library_names_spec=
libname_spec='lib$name'
soname_spec=
@@ -2810,9 +2811,15 @@ os2*)
libname_spec='$name'
shrext_cmds=.dll
need_lib_prefix=no
- library_names_spec='$libname$shared_ext $libname.a'
+ # OS/2 limits a length of a DLL basename up to 8 characters.
+ # So there is need to use a short name instead of a original name
+ # longer than 8 characters. And replace '.' with '_'.
+ os2dllname_cmds='$ECHO $libname | cut -b -8 | tr . _'
+ library_names_spec='`eval $os2dllname_cmds`${shared_ext}
${libname}_dll.$libext'
dynamic_linker='OS/2 ld.exe'
- shlibpath_var=LIBPATH
+ shlibpath_var=BEGINLIBPATH
+ sys_lib_search_path_spec=/lib /usr/lib /usr/local/lib
+ sys_lib_dlsearch_path_spec=$sys_lib_search_path_spec
;;
osf3* | osf4* | osf5*)
@@ -2958,6 +2965,7 @@ _LT_DECL([], [shlibpath_var], [0],[Shared library path
variable])
_LT_DECL([], [shlibpath_overrides_runpath], [0],
[Is shlibpath searched before the hard-coded library search path?])
_LT_DECL([], [libname_spec], [1], [Format of library name prefix])
+_LT_DECL([], [os2dllname_cmds], [2], [Command to make a OS/2 DLL name])
_LT_DECL([], [library_names_spec], [1],
[[List of archive names. First name is the real one, the rest are links.
The last name is the one that the linker finds with -lNAME]])
@@ -4942,6 +4950,16 @@ _LT_EOF
_LT_TAGVAR(link_all_deplibs, $1)=yes
;;
+os2*)
+ _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir'
+ _LT_TAGVAR(hardcode_minus_L, $1)=yes
+ _LT_TAGVAR(allow_undefined_flag, $1)=unsupported
+ shrext_cmds=.dll
+ _LT_TAGVAR(archive_cmds, $1)='$ECHO LIBRARY `eval $os2dllname_cmds`
INITINSTANCE TERMINSTANCE $output_objdir/$libname.def~$ECHO DESCRIPTION
\$libname\ $output_objdir/$libname.def~$ECHO DATA
$output_objdir
[PATCH 8/8] libtool: create an import libraries instead of links to the real library on OS/2
Link is not supported on OS/2.
* build-aux/ltmain.in (fund_mode_install): Create an import library.
(fund_mode_link): Likewise.
---
build-aux/ltmain.in | 23 ---
1 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index 62c3564..6af7dac 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -2413,8 +2413,17 @@ func_mode_install ()
# so we also need to try rm ln -s.
for linkname
do
- test $linkname != $realname \
-func_show_eval (cd $destdir { $LN_S -f $realname
$linkname || { $RM $linkname $LN_S $realname $linkname; }; })
+ if test $linkname != $realname; then
+ case $host_os in
+ os2*)
+ # Create import libraries instead of links on OS/2
+ func_show_eval (emximp -o $destdir/$linkname
$dir/${linkname%%_dll.$libext}.def)
+ ;;
+ *)
+ func_show_eval (cd $destdir { $LN_S -f $realname
$linkname || { $RM $linkname $LN_S $realname $linkname; }; })
+ ;;
+ esac
+ fi
done
fi
@@ -8067,7 +8076,15 @@ EOF
# Create links to the real library.
for linkname in $linknames; do
if test $realname != $linkname; then
- func_show_eval '(cd $output_objdir $RM $linkname $LN_S
$realname $linkname)' 'exit $?'
+ case $host_os in
+ os2*)
+ # Create import libraries instead of links on OS/2
+ func_show_eval '(emximp -o $output_objdir/$linkname
$output_objdir/$libname.def)' 'exit $?'
+ ;;
+ *)
+ func_show_eval '(cd $output_objdir $RM $linkname $LN_S
$realname $linkname)' 'exit $?'
+ ;;
+ esac
fi
done
--
1.7.3.2
[PATCH 3/8] libtool: set lt_prog_compiler_static to -Bstatic on OS/2
* m4/libtool.m4 (_LT_COMPILER_PIC): Same as the title. --- m4/libtool.m4 | 15 +++ 1 files changed, 15 insertions(+), 0 deletions(-) diff --git a/m4/libtool.m4 b/m4/libtool.m4 index da29e57..f54c882 100644 --- a/m4/libtool.m4 +++ b/m4/libtool.m4 @@ -4068,6 +4068,11 @@ m4_if([$1], [CXX], [ # (--disable-auto-import) libraries m4_if([$1], [GCJ], [], [_LT_TAGVAR(lt_prog_compiler_pic, $1)='-DDLL_EXPORT']) + case $host_os in + os2*) +_LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic' +;; + esac ;; darwin* | rhapsody*) # PIC is the default on this platform @@ -4387,6 +4392,11 @@ m4_if([$1], [CXX], [ # (--disable-auto-import) libraries m4_if([$1], [GCJ], [], [_LT_TAGVAR(lt_prog_compiler_pic, $1)='-DDLL_EXPORT']) + case $host_os in + os2*) +_LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic' +;; + esac ;; darwin* | rhapsody*) @@ -4484,6 +4494,11 @@ m4_if([$1], [CXX], [ # built for inclusion in a dll (and should export symbols for example). m4_if([$1], [GCJ], [], [_LT_TAGVAR(lt_prog_compiler_pic, $1)='-DDLL_EXPORT']) + case $host_os in + os2*) +_LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic' +;; + esac ;; hpux9* | hpux10* | hpux11*) -- 1.7.3.2
[PATCH 5/8] libtool: there is no need to relink DLLs on OS/2
* build-aux/ltmain.in (func_mode_link): Set need_relink to no on OS/2.
---
build-aux/ltmain.in |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index cf72c66..48ae7fa 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -6164,7 +6164,7 @@ func_mode_link ()
if test -n $library_names
{ test no = $use_static_libs || test -z $old_library; }; then
case $host in
- *cygwin* | *mingw* | *cegcc*)
+ *cygwin* | *mingw* | *cegcc* | *os2*)
# No point in relinking DLLs because paths are not encoded
func_append notinst_deplibs $lib
need_relink=no
--
1.7.3.2
libtool version mismatch error persists after running `autoreconf -fvi`
Hi, I'm trying to make my first project with adding a new binary to an old project written in C/C++ on my machine with Ubuntu 14.04. First I need to run ./setup_configure which runs the following script: set cmd1=(rm -rf autom4te.cache) if ( `uname -s` == Darwin ) then set cmd2=(glibtoolize --force) else #set cmd2=(libtoolize --force) set cmd2=(libtoolize -f -v) endif set cmd3=(aclocal) set cmd4=(automake -a -c) set cmd5=(autoreconf --force -Wno-portability) set cmd6=(autoconf -Wno-portability) and afterwards I need to run ./configure. Since I do not want to compile the whole project I cd into the new sub-directory I have added and run make, however, the process does not go smoothly and ends with the following error: /bin/bash ../libtool --tag=CC --mode=link g++ -I../include -L/usr/lib64 -L/usr/X11R6/lib64 -L/opt/mni_library/lib -L/opt/vxl/build/lib-o mri_segment_ms mri_segment_ms.o ../utils/libutils.a ../fsgdf/libfsgdf.a ../rgb/librgb.a ../unix/libunix.a ../dicom/libdicom.a ../hipsstubs/libhipsstubs.a ../log/liblog.a ../xml2/libxml2.a ../jpeg/libjpeg.a ../tiff/libtiff.a ../expat/libexpat.a -lz -lm -lcrypt -ldl -lpthread -lnetcdf -lvolume_io -lminc -lvnl_algo -lvnl -lvcl -lnetlib -lv3p_netlib ../libtool: line 469: CDPATH: command not found libtool: Version mismatch error. This is libtool 2.4.2 Debian-2.4.2-1.7ubuntu1, but the libtool: definition of this LT_INIT comes from an older release. libtool: You should recreate aclocal.m4 with macros from libtool 2.4.2 Debian-2.4.2-1.7ubuntu1 libtool: and run autoconf again. make: *** [mri_segment_ms] Error 63 I have found lots of QAs regarding a similar problem over internet, most of which suggest the user to run autoreconf -ivf. There is also a comprehensive answer in Stackoverflow (http://stackoverflow.com/questions/3096989/libtool-version-mismatch-error). I have performed all the suggested steps, unfortunately the problem persists. I was wondering whether anyone could give me a hint. Thanks Arman ___ https://lists.gnu.org/mailman/listinfo/libtool
libtool: lib: command not found
Hello, I'm having some trouble cross building libraries from a Linux machine (Debian/unstable) using mingw-w64, seem libtool is looking for a lib command to generate a .lib library, but the command is missing and I can't find it in any package (on stackoverflow I've seen for the same problem on Windows is just a matter of adding the path VC/bin to the env to let the command be found, but I suspect on Linux the lib command doesn't exist at all and something else is wrong). Here's a libzzip output example but I've the same problem with another lib (I suspect any). libtool: link: warning: undefined symbols not allowed in i686-w64-mingw32 shared libraries ../libtool: line 1095: lib: command not found Makefile:566: recipe for target 'libzzip.la' failed Any suggestion? Thanks in advance ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool: lib: command not found
Hi! On 2014-09-05 13:28, raz...@eml.cc wrote: I'm having some trouble cross building libraries from a Linux machine (Debian/unstable) using mingw-w64, seem libtool is looking for a lib command to generate a .lib library, but the command is missing and I can't find it in any package (on stackoverflow I've seen for the same problem on Windows is just a matter of adding the path VC/bin to the env to let the command be found, but I suspect on Linux the lib command doesn't exist at all and something else is wrong). Here's a libzzip output example but I've the same problem with another lib (I suspect any). libtool: link: warning: undefined symbols not allowed in i686-w64-mingw32 shared libraries ../libtool: line 1095: lib: command not found Makefile:566: recipe for target 'libzzip.la' failed You seem to have configured libzzip in such a way that it thinks it is should be built with Microsoft tools. That may not be your fault, but can we see the config.log file please? The undefined symbols warning suggests that the project has not been ported to Windows, or at least not the autotools build system. Cheers, Peter ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool: lib: command not found
Hi Peter, thank you attacched the zzip config.log. But the problem seem to be with any lib I try to cross build with mingw and libtool, I wasn't sure the mail was sent to the mailing list (usually I see immediatly the sent mail in mutt but not in this case) so I've done a sort of cross posting *sorry* with a more generic case: http://stackoverflow.com/questions/25687097/mingw-w64-libtool-lib-command-not-found (attacched also this test config.log and the sources I'm using) On Fri, Sep 05, 2014 at 04:21:33PM +0200, Peter Rosin wrote: Hi! On 2014-09-05 13:28, raz...@eml.cc wrote: I'm having some trouble cross building libraries from a Linux machine (Debian/unstable) using mingw-w64, seem libtool is looking for a lib command to generate a .lib library, but the command is missing and I can't find it in any package (on stackoverflow I've seen for the same problem on Windows is just a matter of adding the path VC/bin to the env to let the command be found, but I suspect on Linux the lib command doesn't exist at all and something else is wrong). Here's a libzzip output example but I've the same problem with another lib (I suspect any). libtool: link: warning: undefined symbols not allowed in i686-w64-mingw32 shared libraries ../libtool: line 1095: lib: command not found Makefile:566: recipe for target 'libzzip.la' failed You seem to have configured libzzip in such a way that it thinks it is should be built with Microsoft tools. That may not be your fault, but can we see the config.log file please? The undefined symbols warning suggests that the project has not been ported to Windows, or at least not the autotools build system. Cheers, Peter ___ https://lists.gnu.org/mailman/listinfo/libtool zzip-config.log.gz Description: application/gzip test-config.log.gz Description: application/gzip test2.tgz Description: application/gtar-compressed ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool: lib: command not found
On Fri, Sep 05, 2014 at 05:05:52PM +0200, Peter Rosin wrote: On 2014-09-05 16:52, raz...@eml.cc wrote: Hi Peter, thank you attacched the zzip config.log. Bleh, sorry, but could you also provide the output from ./libtool --config from your build directory? Attacched dpkg -L *libtool*: libtool 2.4.2-1.10 libtool-bin 2.4.2-1.10 test-libtool-config.gz Description: application/gzip ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool: lib: command not found
On 2014-09-05 17:19, raz...@eml.cc wrote: On Fri, Sep 05, 2014 at 05:05:52PM +0200, Peter Rosin wrote: On 2014-09-05 16:52, raz...@eml.cc wrote: Hi Peter, thank you attacched the zzip config.log. Bleh, sorry, but could you also provide the output from ./libtool --config from your build directory? Attacched dpkg -L *libtool*: libtool 2.4.2-1.10 libtool-bin 2.4.2-1.10 Ok, this is strange. You have this in your libtool --config: # Commands used to build an old-style archive. old_archive_cmds=lib -OUT:\$oldlib\$oldobjs\$old_deplibs Looking in the libtool.m4 file, the only way for lib -OUT... to be chosen is if test yes = $lt_use_gnu_ld_interface doesn't match. Your libtool --config also has: # Whether we are building with GNU ld or not. with_gnu_ld=no which seems strange on Debian. Looking in your config.log, I find configure:4994: checking for ld used by i686-w64-mingw32-gcc configure:5061: result: i686-w64-mingw32-g++-win32 configure:5068: checking if the linker (i686-w64-mingw32-g++-win32) is GNU ld configure:5083: result: no which is the cause of the above strangeness. What is the output from: i686-w64-mingw32-g++-win32 -v Libtool assumes that GNU ld produces something that matches: *GNU* | *'with BFD'* Cheers, Peter ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool: lib: command not found
Thank you! Peter your comments pointed me in the right direction, CXX and LD in the env seem to be not needed --host is enough, LT_INIT need [win32-dll] and libexample_la_LDFLAGS need -no-undefined. Got static and shared dll built. Cheers Alex Ok, this is strange. You have this in your libtool --config: # Commands used to build an old-style archive. old_archive_cmds=lib -OUT:\$oldlib\$oldobjs\$old_deplibs Looking in the libtool.m4 file, the only way for lib -OUT... to be chosen is if test yes = $lt_use_gnu_ld_interface doesn't match. Your libtool --config also has: # Whether we are building with GNU ld or not. with_gnu_ld=no which seems strange on Debian. Looking in your config.log, I find configure:4994: checking for ld used by i686-w64-mingw32-gcc configure:5061: result: i686-w64-mingw32-g++-win32 configure:5068: checking if the linker (i686-w64-mingw32-g++-win32) is GNU ld configure:5083: result: no which is the cause of the above strangeness. What is the output from: i686-w64-mingw32-g++-win32 -v Using built-in specs. COLLECT_GCC=i686-w64-mingw32-g++-win32 COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-w64-mingw32/4.9-win32/lto-wrapper Target: i686-w64-mingw32 Configured with: ../../src/configure --build=i586-linux-gnu --prefix=/usr --includedir='/usr/include' --mandir='/usr/share/man' --infodir='/usr/share/info' --sysconfdir=/etc --localstatedir=/var --libexecdir='/usr/lib/gcc-mingw-w64' --disable-maintainer-mode --disable-dependency-tracking --prefix=/usr --enable-shared --enable-static --disable-multilib --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --libdir=/usr/lib --enable-libstdcxx-time=yes --with-tune=generic --enable-version-specific-runtime-libs --enable-fully-dynamic-string --enable-libgomp --enable-languages=c,c++,fortran,objc,obj-c++ --enable-lto --with-plugin-ld --enable-threads=win32 --program-suffix=-win32 --program-prefix=i686-w64-mingw32- --target=i686-w64-mingw32 --with-as=/usr/bin/i686-w64-mingw32-as --with-ld=/usr/bin/i686-w64-mingw32-ld Thread model: win32 gcc version 4.9.1 (GCC) Libtool assumes that GNU ld produces something that matches: *GNU* | *'with BFD'* Cheers, Peter ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Trying to get libtool not to add -rpath, since libs are only in a staging directory
Friendly ping?
+cc the libtool maintainers according to http://www.gnu.org/software/libtool/
If this is indeed a bug, I'd be willing to invest some time in trying
to fix it, but I'd need some pointers on what would be the proper way
to fix it...
I really think libtool should be creating a wrapper script and not a
binary with an rpath pointing to the stage directory, am I wrong?
Cheers,
Filipe
On Tue, Aug 19, 2014 at 4:33 PM, Filipe Brandenburger
filbran...@google.com wrote:
Hi,
I'm trying to link binaries to libraries that are not installed on the
system, but just unpacked to a staging directory.
Consider this (real) example:
1) Build expat with --libdir=/usr/lib/${platform}
2) Install expat with make install DESTDIR=${stagedir}
3) Configure dbus with -L${stagedir}/usr/lib/${platform} where it
will find expat now, and -rpath /usr/lib/${platform} where it will
find expat at real runtime when both are installed.
4) Build expat
The problem is that ${stagedir} is leaking and the resulting
dbus-daemon gets both /usr/lib/${platform} and
${stagedir}/usr/lib/${platform} added to it...
I tried working around it by passing --with-sysroot=${stagedir} to the
dbus configure, but unfortunately that didn't work...
Do you have a suggestion of something I could do to accomplish what
I'm trying to accomplish?
Is this a libtool bug?
Any suggestions of workarounds?
(I also filed a bug at
http://savannah.gnu.org/support/index.php?108637 in case this is
actually a libtool bug.)
Thanks in advance!
Filipe
___
https://lists.gnu.org/mailman/listinfo/libtool
[sr #108637] libtool adds -rpath to staging directory
Follow-up Comment #1, sr #108637 (project libtool): Small correction, step #4 should read Build dbus. If someone could confirm this is indeed a bug and whether there's a good workaround for it that would be great. Thinking about it, my impression is that bintest should actually be a wrapper shell script with the actual binary under .libs/bintest and make install should possibly relink it without the rpath to the staging directory... I'd be happy to contribute code, but I'd need some pointers on where the issue is and what would be an acceptable way to fix this. Thanks! Filipe ___ Reply to this item at: http://savannah.gnu.org/support/?108637 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Trying to get libtool not to add -rpath, since libs are only in a staging directory
Hi Filipe, Filipe Brandenburger wrote: Hi, I'm trying to link binaries to libraries that are not installed on the system, but just unpacked to a staging directory. [SNIP] Is this a libtool bug? Any suggestions of workarounds? (I also filed a bug at http://savannah.gnu.org/support/index.php?108637 in case this is actually a libtool bug.) Libtool exclude directories from RPATH if path is listed in sys_lib_dlsearch_path_spec - list of space separated directories. Variable sys_lib_dlsearch_path_spec is generated from a libtool macro. On linux with FSF libtool version value start with /lib /usr/lib and existing directories from /etc/ld.so.conf . After configuration user could check current value with command: $ ./libtool --config | grep sys_lib_dlsearch_path_spec ( I assume that package build process generate libtool script in build directory ) You could use lt_cv_sys_lib_dlsearch_path_spec to override it at configure time. .../configure \ ... lt_cv_sys_lib_dlsearch_path_spec=ORIGINAL VALUE STAGING_PATH ... Regards Roumen Petrov ___ https://lists.gnu.org/mailman/listinfo/libtool
[sr #108637] libtool adds -rpath to staging directory
URL:
http://savannah.gnu.org/support/?108637
Summary: libtool adds -rpath to staging directory
Project: GNU Libtool
Submitted by: None
Submitted on: Tue 19 Aug 2014 11:30:33 PM UTC
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
Status: None
Privacy: Public
Assigned to: None
Originator Email: filbran...@google.com
Open/Closed: Open
Discussion Lock: Any
Operating System: GNU/Linux
___
Details:
Hi,
I'm trying to link binaries to libraries that are not installed on the system,
but just unpacked to a staging directory.
Consider this (real) example:
1) Build expat with --libdir=/usr/lib/${platform}
2) Install expat with make install DESTDIR=${stagedir}
3) Configure dbus with -L${stagedir}/usr/lib/${platform} where it will find
expat now, and -rpath /usr/lib/${platform} where it will find expat at real
runtime when both are installed.
4) Build expat
The problem is that ${stagedir} is leaking and the resulting dbus-daemon gets
both /usr/lib/${platform} *and* ${stagedir}/usr/lib/${platform} added to
it...
I tried working around it by passing --with-sysroot=${stagedir} to the dbus
configure, but unfortunately that didn't work...
I wrote a small reproducer that seems to illustrate the issue, I tried it with
latest libtool from git (commit ac180507c123469d0fe9b25437d459af24b3f789) and
I still have the same problem.
$ libtool_rpath/reproduce.sh
...
=== RPATH of bintest:
0x000f (RPATH) Library rpath:
[/path/to/libtool_rpath/destdir/usr/lib/platform:/usr/lib/platform]
Do you have a suggestion of something I could do to accomplish what I'm trying
to accomplish?
Is this a libtool bug?
Any suggestions of workarounds?
Thanks!
Filipe
___
File Attachments:
---
Date: Tue 19 Aug 2014 11:30:33 PM UTC Name: libtool_rpath.tgz Size: 912B
By: None
Script to reproduce this bug.
http://savannah.gnu.org/support/download.php?file_id=31921
___
Reply to this item at:
http://savannah.gnu.org/support/?108637
___
Message sent via/by Savannah
http://savannah.gnu.org/
___
https://lists.gnu.org/mailman/listinfo/libtool
Trying to get libtool not to add -rpath, since libs are only in a staging directory
Hi,
I'm trying to link binaries to libraries that are not installed on the
system, but just unpacked to a staging directory.
Consider this (real) example:
1) Build expat with --libdir=/usr/lib/${platform}
2) Install expat with make install DESTDIR=${stagedir}
3) Configure dbus with -L${stagedir}/usr/lib/${platform} where it
will find expat now, and -rpath /usr/lib/${platform} where it will
find expat at real runtime when both are installed.
4) Build expat
The problem is that ${stagedir} is leaking and the resulting
dbus-daemon gets both /usr/lib/${platform} and
${stagedir}/usr/lib/${platform} added to it...
I tried working around it by passing --with-sysroot=${stagedir} to the
dbus configure, but unfortunately that didn't work...
Do you have a suggestion of something I could do to accomplish what
I'm trying to accomplish?
Is this a libtool bug?
Any suggestions of workarounds?
(I also filed a bug at
http://savannah.gnu.org/support/index.php?108637 in case this is
actually a libtool bug.)
Thanks in advance!
Filipe
___
https://lists.gnu.org/mailman/listinfo/libtool
LibTool and Windows Server
Hello, One of our clients has LibTool installed on a server running Windows Server 2003. We are planning to upgrade their server to Windows Server 2012. Is LibTools compatible with Windows Server 2012? Thank you, Bryan Fulton [cid:cio_logo1fed64] Bryan Fulton JR Systems Administrator | bful...@cioservicesllc.com 606 North and South Rd | Suite 201 | Saint Louis, MO | 63130 314.414.8400 | www.cioservicesllc.com For support requests, please email answ...@cioservicesllc.commailto:answ...@cioservicesllc.com or call 314.414.8400. ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Libtool and ASAN
Le 17 mai 2014 à 03:36, Peter Rosin p...@lysator.liu.se a écrit : Hi! Hi Peter, Thanks for the answer! My other libraries, which are not modules, are linked properly though. For instance (the only relevant part is that -fsanitize is not stripped from the command passed to the linker): This part I don't understand, is there perhaps a -fsanitize in one of the dependent .la files? Yes, probably. I've not looked into the details to know what has happened though. Thanks for reading (the English parts of this message :)! This last part is an FAQ: http://www.gnu.org/software/libtool/manual/libtool.html#FAQ Bummer, that's even the only FAQ :) I would suggest adding common dropped options in there, such as -f, so that a search would find it. Thanks again. ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Libtool and ASAN
Hi! On 2014-04-28 17:45, Akim Demaille wrote: I'm trying to use -fsanitize=address on OS X using MacPorts' Clang++ 3.5. The project consists of C++ libraries, on top of which is built a Python module (with a thin C++ layer which needs to be compiled). Libtool (2.4.2 - the name of a fine belgian band of electronic music btw) is used in all layers. To enable ASAN, I add '-fsanitize=address' to my CXXFLAGS. It works well except for the C++ part of the Python module: *snip* What matters here is that -fsanitize=address is dropped, it is not passed to the linker. And I really need it: *snap* I have to use -Wc to force Libtool to pass it to the compiler used to link (I must not use -Wl, because then it is passed to the linker invoked by the compiler, and the linker rejects -fsanitize). *snep* My other libraries, which are not modules, are linked properly though. For instance (the only relevant part is that -fsanitize is not stripped from the command passed to the linker): This part I don't understand, is there perhaps a -fsanitize in one of the dependent .la files? *snyp* So what should I do? Am I doing something wrong? I'd like to avoid having to teach my package to configure itself with ASAN and the others, it should remain only a question of passing appropriate CXXFLAGS and other LDFLAGS to configure. Why does libtool strip these -f? I could not find any instruction about this in the documentation. Thanks for reading (the English parts of this message :)! This last part is an FAQ: http://www.gnu.org/software/libtool/manual/libtool.html#FAQ Cheers, Peter ___ https://lists.gnu.org/mailman/listinfo/libtool
[SCM] GNU Libtool branch, master, updated. v2.4.2.444-31-g13aa364
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project GNU Libtool. The branch, master has been updated via 13aa364c0c66f9f6b41f98772d0735039ac974a1 (commit) from da30ce4dc9554c80f1931600af2b8bbab486476e (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit 13aa364c0c66f9f6b41f98772d0735039ac974a1 Author: Peter Rosin p...@lysator.liu.se Date: Tue May 6 10:11:34 2014 +0200 libtool: fix nm test for MSYS/MinGW The check for the -B option of nm does not work as intended on MSYS/MinGW. MSYS converts /dev/null to the DOW/Windows equivanent special file NUL, but the MinGW nm treats this file as any empty file. This means that you might end up with some fallback nm instead of the desired nm. This is not normally a problem, but if one nm is built without lto support, it starts to matter. Fixes sr #108558, reported by LRN. * m4/libtool.m4 (LT_PATH_NM) [MSYS]: Use a non-existant file instead of /dev/null when checking if nm supports -B. Signed-off-by: Peter Rosin p...@lysator.liu.se --- Summary of changes: m4/libtool.m4 |9 +++-- 1 files changed, 7 insertions(+), 2 deletions(-) diff --git a/m4/libtool.m4 b/m4/libtool.m4 index 0454030..320d8b3 100644 --- a/m4/libtool.m4 +++ b/m4/libtool.m4 @@ -3509,8 +3509,13 @@ else # Adding the 'sed 1q' prevents false positives on HP-UX, which says: # nm: unknown option B ignored # Tru64's nm complains that /dev/null is an invalid object file - case `$tmp_nm -B /dev/null 21 | sed '1q'` in - */dev/null* | *'Invalid file or object type'*) + # MSYS converts /dev/null to NUL, MinGW nm treats NUL as empty + case $build_os in + mingw*) lt_bad_file=conftest.nm/nofile ;; + *) lt_bad_file=/dev/null ;; + esac + case `$tmp_nm -B $lt_bad_file 21 | sed '1q'` in + *$lt_bad_file* | *'Invalid file or object type'*) lt_cv_path_NM=$tmp_nm -B break 2 ;; hooks/post-receive -- GNU Libtool
[sr #108558] libtool nm test does not really work for W32 versions of nm
Update of sr #108558 (project libtool): Status:None = Done ___ Follow-up Comment #10: Patch pushed. Cheers, Peter ___ Reply to this item at: http://savannah.gnu.org/support/?108558 ___ Meddelandet skickades via/av Savannah http://savannah.gnu.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
[SCM] GNU Libtool branch, master, updated. v2.4.2.444-30-gda30ce4
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.
The branch, master has been updated
via da30ce4dc9554c80f1931600af2b8bbab486476e (commit)
from 5911665520a53415bafd8bb6da9989b5fe25df80 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
commit da30ce4dc9554c80f1931600af2b8bbab486476e
Author: Peter Rosin p...@lysator.liu.se
Date: Tue May 6 00:03:19 2014 +0200
libtool: speed up ltwrapper_script detection in execute mode
Execute mode is slow and might even DOS the computer in extreme
cases when a parameter is a big binary file without newlines.
Work around this with different truncation if a suitable dd
utility is found.
Fixes bug#13472 and bug#16662.
Reported by Pavel Raiskup and Nick Bowler.
* m4/libtool.m4 (_LT_PATH_DD): New macro, for finding a dd utility
that works for the below purpose.
(_LT_CMD_TRUNCATE): New macro, for finding out how to truncate binary
pipes (fallback to the old sed truncation if no suitable dd is found
in _LT_PATH_DD).
(_LT_SETUP): Require _LT_CMD_TRUNCATE.
(LT_INIT): Require Autoconf 2.62, as needed by _LT_PATH_DD.
* build_aux/ltmain.in (func_lalib_p): Factor out the actual generated
by libtool test into...
(func_generated_by_libtool_p): ...this new function...
(func_ltwrapper_script_p): ...so that it can be reused here, when
truncating the pipe according to _LT_CMD_TRUNCATE.
* THANKS: Update.
Signed-off-by: Peter Rosin p...@lysator.liu.se
---
Summary of changes:
THANKS |2 ++
build-aux/ltmain.in | 14 +++---
m4/libtool.m4 | 40 +++-
3 files changed, 52 insertions(+), 4 deletions(-)
diff --git a/THANKS b/THANKS
index e895aee..85c5150 100644
--- a/THANKS
+++ b/THANKS
@@ -150,6 +150,7 @@
Mike Gorchak m...@malva.ua
Mike Frysinger vap...@gentoo.org
Mike Miller mtmil...@ieee.org
+ Nick Bowler nbow...@draconx.ca
Nix n...@esperi.org.uk
Olaf Lenzol...@fias.uni-frankfurt.de
Olly Betts o...@muscat.co.uk
@@ -161,6 +162,7 @@
Paul Eggert egg...@twinsun.com
Paul Laight plai...@quantxautomation.co.uk
Paul Seidler se...@lavabit.com
+ Pavel Raiskupprais...@redhat.com
PaweÅ Daniluk pa...@bioexploratorium.pl
Peter Eisentraut pete...@gmx.net
Peter Fritzsche peter.fritzs...@gmx.de
diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index 3a0fb0c..6af4087 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -570,6 +570,14 @@ $1
_LTECHO_EOF'
}
+# func_generated_by_libtool
+# True iff stdin has been generated by Libtool. This function is only
+# a basic sanity check; it will hardly flush out determined imposters.
+func_generated_by_libtool_p ()
+{
+ $GREP ^# Generated by .*$PACKAGE /dev/null 21
+}
+
# func_lalib_p file
# True iff FILE is a libtool '.la' library or '.lo' object file.
# This function is only a basic sanity check; it will hardly flush out
@@ -577,8 +585,7 @@ _LTECHO_EOF'
func_lalib_p ()
{
test -f $1
- $SED -e 4q $1 2/dev/null \
-| $GREP ^# Generated by .*$PACKAGE /dev/null 21
+ $SED -e 4q $1 2/dev/null | func_generated_by_libtool_p
}
# func_lalib_unsafe_p file
@@ -610,7 +617,8 @@ func_lalib_unsafe_p ()
# determined imposters.
func_ltwrapper_script_p ()
{
-func_lalib_p $1
+test -f $1
+ $lt_truncate_bin $1 2/dev/null | func_generated_by_libtool_p
}
# func_ltwrapper_executable_p file
diff --git a/m4/libtool.m4 b/m4/libtool.m4
index ce58f31..0454030 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -59,7 +59,7 @@ esac
# LT_INIT([OPTIONS])
# --
AC_DEFUN([LT_INIT],
-[AC_PREREQ([2.58])dnl We use AC_INCLUDES_DEFAULT
+[AC_PREREQ([2.62])dnl We use AC_PATH_PROGS_FEATURE_CHECK
AC_REQUIRE([AC_CONFIG_AUX_DIR_DEFAULT])dnl
AC_BEFORE([$0], [LT_LANG])dnl
AC_BEFORE([$0], [LT_OUTPUT])dnl
@@ -169,6 +169,7 @@ m4_require([_LT_CHECK_SHAREDLIB_FROM_LINKLIB])dnl
m4_require([_LT_CMD_OLD_ARCHIVE])dnl
m4_require([_LT_CMD_GLOBAL_SYMBOLS])dnl
m4_require([_LT_WITH_SYSROOT])dnl
+m4_require([_LT_CMD_TRUNCATE])dnl
_LT_CONFIG_LIBTOOL_INIT([
# See if we are running on zsh, and set the options that allow our
@@ -3216,6 +3217,43 @@ _LT_TAGDECL([], [reload_cmds], [2])dnl
])# _LT_CMD_RELOAD
+# _LT_PATH_DD
+# ---
+# find a working dd
+m4_defun([_LT_PATH_DD
Re: [sr #108558] libtool nm test does not really work for W32 versions of nm
On 2014-05-06 15:30, Peter Rosin wrote: Follow-up Comment #8, sr #108558 (project libtool): I have attached a patch that does the safe-safe-safe version. Does it work for you? *snip* http://savannah.gnu.org/support/?108558 To not force everyone to follow the link, here's the patch in question. Cheers, Peter From 13aa364c0c66f9f6b41f98772d0735039ac974a1 Mon Sep 17 00:00:00 2001 From: Peter Rosin p...@lysator.liu.se Date: Tue, 6 May 2014 10:11:34 +0200 Subject: [PATCH] libtool: fix nm test for MSYS/MinGW The check for the -B option of nm does not work as intended on MSYS/MinGW. MSYS converts /dev/null to the DOW/Windows equivanent special file NUL, but the MinGW nm treats this file as any empty file. This means that you might end up with some fallback nm instead of the desired nm. This is not normally a problem, but if one nm is built without lto support, it starts to matter. Fixes sr #108558, reported by LRN. * m4/libtool.m4 (LT_PATH_NM) [MSYS]: Use a non-existant file instead of /dev/null when checking if nm supports -B. Signed-off-by: Peter Rosin p...@lysator.liu.se --- m4/libtool.m4 |9 +++-- 1 files changed, 7 insertions(+), 2 deletions(-) diff --git a/m4/libtool.m4 b/m4/libtool.m4 index 0454030..320d8b3 100644 --- a/m4/libtool.m4 +++ b/m4/libtool.m4 @@ -3509,8 +3509,13 @@ else # Adding the 'sed 1q' prevents false positives on HP-UX, which says: # nm: unknown option B ignored # Tru64's nm complains that /dev/null is an invalid object file - case `$tmp_nm -B /dev/null 21 | sed '1q'` in - */dev/null* | *'Invalid file or object type'*) + # MSYS converts /dev/null to NUL, MinGW nm treats NUL as empty + case $build_os in + mingw*) lt_bad_file=conftest.nm/nofile ;; + *) lt_bad_file=/dev/null ;; + esac + case `$tmp_nm -B $lt_bad_file 21 | sed '1q'` in + *$lt_bad_file* | *'Invalid file or object type'*) lt_cv_path_NM=$tmp_nm -B break 2 ;; -- 1.7.9
[sr #108558] libtool nm test does not really work for W32 versions of nm
Follow-up Comment #8, sr #108558 (project libtool): I have attached a patch that does the safe-safe-safe version. Does it work for you? Cheers, Peter (file #31318) ___ Additional Item Attachment: File name: 0001-libtool-fix-nm-test-for-MSYS-MinGW.patch Size:1 KB ___ Reply to this item at: http://savannah.gnu.org/support/?108558 ___ Meddelandet skickades via/av Savannah http://savannah.gnu.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
[sr #108558] libtool nm test does not really work for W32 versions of nm
Follow-up Comment #9, sr #108558 (project libtool): I have attached a patch that does the safe-safe-safe version. Does it work for you? Yes, it seems that it does. ___ Reply to this item at: http://savannah.gnu.org/support/?108558 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: [sr #108558] libtool nm test does not really work for W32 versions of nm
On 2014-05-06 15:30, Peter Rosin wrote: Follow-up Comment #8, sr #108558 (project libtool): I have attached a patch that does the safe-safe-safe version. Does it work for you? *snip* http://savannah.gnu.org/support/?108558 To not force everyone to follow the link, here's the patch in question. Cheers, Peter From 13aa364c0c66f9f6b41f98772d0735039ac974a1 Mon Sep 17 00:00:00 2001 From: Peter Rosin p...@lysator.liu.se Date: Tue, 6 May 2014 10:11:34 +0200 Subject: [PATCH] libtool: fix nm test for MSYS/MinGW The check for the -B option of nm does not work as intended on MSYS/MinGW. MSYS converts /dev/null to the DOW/Windows equivanent special file NUL, but the MinGW nm treats this file as any empty file. This means that you might end up with some fallback nm instead of the desired nm. This is not normally a problem, but if one nm is built without lto support, it starts to matter. Fixes sr #108558, reported by LRN. * m4/libtool.m4 (LT_PATH_NM) [MSYS]: Use a non-existant file instead of /dev/null when checking if nm supports -B. Signed-off-by: Peter Rosin p...@lysator.liu.se --- m4/libtool.m4 |9 +++-- 1 files changed, 7 insertions(+), 2 deletions(-) diff --git a/m4/libtool.m4 b/m4/libtool.m4 index 0454030..320d8b3 100644 --- a/m4/libtool.m4 +++ b/m4/libtool.m4 @@ -3509,8 +3509,13 @@ else # Adding the 'sed 1q' prevents false positives on HP-UX, which says: # nm: unknown option B ignored # Tru64's nm complains that /dev/null is an invalid object file - case `$tmp_nm -B /dev/null 21 | sed '1q'` in - */dev/null* | *'Invalid file or object type'*) + # MSYS converts /dev/null to NUL, MinGW nm treats NUL as empty + case $build_os in + mingw*) lt_bad_file=conftest.nm/nofile ;; + *) lt_bad_file=/dev/null ;; + esac + case `$tmp_nm -B $lt_bad_file 21 | sed '1q'` in + *$lt_bad_file* | *'Invalid file or object type'*) lt_cv_path_NM=$tmp_nm -B break 2 ;; -- 1.7.9 ___ https://lists.gnu.org/mailman/listinfo/libtool
[SCM] GNU Libtool branch, master, updated. v2.4.2.444-29-g5911665
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project GNU Libtool. The branch, master has been updated via 5911665520a53415bafd8bb6da9989b5fe25df80 (commit) from 053df7eb31d21c6d6dbe54c44f42009efec9d0c9 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit 5911665520a53415bafd8bb6da9989b5fe25df80 Author: Peter Rosin p...@lysator.liu.se Date: Fri May 2 14:51:02 2014 +0200 libtool: prevent lto from stripping the magic cookie from the cwrapper Whole program optimization may remove unused symbols unless told they are really needed. Fixes sr #108559 reported by LRN. * build-aux/ltmain.in (func_emit_cwrapperexe_src:MAGIC_EXE): Try to ensure that the magic cookie is preserved. Signed-off-by: Peter Rosin p...@lysator.liu.se --- Summary of changes: build-aux/ltmain.in |7 ++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in index f8e0f5f..3a0fb0c 100644 --- a/build-aux/ltmain.in +++ b/build-aux/ltmain.in @@ -3738,7 +3738,12 @@ void lt_dump_script (FILE *f); EOF cat EOF -volatile const char * MAGIC_EXE = $magic_exe; +#if __GNUC__ 4 || (__GNUC__ == 4 __GNUC_MINOR__ 5) +# define externally_visible volatile +#else +# define externally_visible __attribute__((externally_visible)) volatile +#endif +externally_visible const char * MAGIC_EXE = $magic_exe; const char * LIB_PATH_VARNAME = $shlibpath_var; EOF hooks/post-receive -- GNU Libtool
[sr #108558] libtool nm test does not really work for W32 versions of nm
Follow-up Comment #1, sr #108558 (project libtool): Thanks for the report. Just a quick note, Cygwin is not affected. This happens on MSYS/MinGW only. On Cygwin, the Windows (or should I say DOS?) NUL device is never involved. cygwin$ /bin/nm -B /dev/null /bin/nm: Warning: '/dev/null' is not an ordinary file cygwin$ /bin/i686-pc-mingw32-nm -B /dev/null /bin/i686-pc-mingw32-nm: Warning: '/dev/null' is not an ordinary file If you have native MinGW tools and run libtool from Cygwin (i.e. if you are using a 'fake' or 'lying' cross setup, as described in the libtool manual), the test check succeeds like this: cygwin$ /cygdrive/c/MinGW/mingw/bin/nm -B /dev/null C:\mingw\bin\nm.exe: '/dev/null': No such file But you are quite correct that the test falls over on MSYS: msys$ /mingw/bin/nm -B /dev/null msys$ echo $? 1 It would be easier to work around this if the native MinGW nm reported some kind of error message involving 'NUL', so that the case pattern could be extended. Granted, that would not fix the bug for old tool chains, but the bug has existed for a very long time and you can always work around it with an explicit NM=... The alternative is for libtool use some other non-existant or otherwise special file on MSYS, when it is trying to work out if nm supports -B. I don't know what that file would be though, and it always feels a little bit icky to special case things. Cheers, Peter ___ Reply to this item at: http://savannah.gnu.org/support/?108558 ___ Meddelandet skickades via/av Savannah http://savannah.gnu.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
[sr #108558] libtool nm test does not really work for W32 versions of nm
Follow-up Comment #2, sr #108558 (project libtool): I was not aware of the extent to which Cygwin is mangling commandlines of pure-W32 programs it runs (since i don't really use Cygwin; i do know it does some kind of conversion; apparently, only in one direction). Evidently, it does not replace /dev/null with nul. In which case - yes, this only affects MSYS. It would be easier to work around this if the native MinGW nm reported some kind of error message involving 'NUL', so that the case pattern could be extended. I can come up with a fix for binutils. However, upstreaming it would be difficult, i expect. In fact i did make a patch: right now my hack makes it open the file, feed the fd to isatty(), and if it turns to not to be a real file, it checks whether its name is nul and replaces that with /dev/null, so the script gets the output it expects. As you may imagine, this is never going to be accepted upstream. The isatty() part might be acceptable (though i expect someone to point out that opening files may be a performance hit), and in that case libtool can just check for 'nul'. Granted, that would not fix the bug for old tool chains, but the bug has existed for a very long time and you can always work around it with an explicit NM=... Yes. Not only NM=..., but you can also let it fall back to *-pc-msys-nm, which totally worked, and may even continue to work for most users (which have matching MSYS and MinGW toolchains). The alternative is for libtool use some other non-existant or otherwise special file on MSYS, when it is trying to work out if nm supports -B. I don't know what that file would be though, and it always feels a little bit icky to special case things. Well, in MSYS2 you can simply do: nm -B /dev/thisfilebetternotexistotherwiseyoullbeintrouble and get satisfactory results (file name and 'No such file' in the output). Can't say anything about MSYS1, haven't used it for some time. ___ Reply to this item at: http://savannah.gnu.org/support/?108558 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
[sr #108558] libtool nm test does not really work for W32 versions of nm
Follow-up Comment #3, sr #108558 (project libtool): Well, in MSYS2 you can simply do: nm -B /dev/thisfilebetternotexistotherwiseyoullbeintrouble and get satisfactory results (file name and 'No such file' in the output). Can't say anything about MSYS1, haven't used it for some time. That would also work on MSYS1. However, I had an idea. Anyone against using $tmp_nm -B ///dev/null everywhere? ///foo and /foo should be equivalent according to Posix. We should still check for /dev/null in the output, methinks... Cheers, Peter ___ Reply to this item at: http://savannah.gnu.org/support/?108558 ___ Meddelandet skickades via/av Savannah http://savannah.gnu.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
[sr #108559] libtool binary wrappers fall prey to aggressive optimizations
Follow-up Comment #1, sr #108559 (project libtool): Isn't this a more direct approach, not affected by new and even more aggressive optimizations? -volatile const char * MAGIC_EXE = $magic_exe; +#if __GNUC__ 4 || (__GNUC__ == 4 __GNUC_MINOR__ 5) +# define externally_visible volatile +#else +# define externally_visible __attribute__((externally_visible)) volatile +#endif +externally_visible const char * MAGIC_EXE = $magic_exe; Does the above work for you? Cheers, Peter ___ Reply to this item at: http://savannah.gnu.org/support/?108559 ___ Meddelandet skickades via/av Savannah http://savannah.gnu.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
[sr #108558] libtool nm test does not really work for W32 versions of nm
Follow-up Comment #4, sr #108558 (project libtool): Well, in MSYS2 you can simply do: nm -B /dev/thisfilebetternotexistotherwiseyoullbeintrouble and get satisfactory results (file name and 'No such file' in the output). Can't say anything about MSYS1, haven't used it for some time. That would also work on MSYS1. However, I had an idea. Anyone against using $tmp_nm -B ///dev/null everywhere? ///foo and /foo should be equivalent according to Posix. We should still check for /dev/null in the output, methinks... Neat! I like that. ___ Reply to this item at: http://savannah.gnu.org/support/?108558 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
[sr #108559] libtool binary wrappers fall prey to aggressive optimizations
Follow-up Comment #2, sr #108559 (project libtool): Yeah, that worked ___ Reply to this item at: http://savannah.gnu.org/support/?108559 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
[sr #108559] libtool binary wrappers fall prey to aggressive optimizations
Update of sr #108559 (project libtool): Status:None = Done ___ Follow-up Comment #3: I have now pushed this change, thanks for testing! Cheers, Peter ___ Reply to this item at: http://savannah.gnu.org/support/?108559 ___ Meddelandet skickades via/av Savannah http://savannah.gnu.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
[sr #108558] libtool nm test does not really work for W32 versions of nm
Follow-up Comment #5, sr #108558 (project libtool): Hmm, on second thought, that depends on MSYS (and MSYS2) still thinking that an argument starting with more than two slashes is a UNC path (or a switch). That might change if someone points out that ///foo and /foo should be equivalent and that Posix only considers //foo special and that command line switches starting with /// are really uncommon... Relying on corner cases in the MSYS argument conversion heuristics does not seem to be a very good idea... But maybe it's the best option anyway? Maybe use dev/null, to handle a future MSYS stripping one leading slash as it currently does for command line switches? Then again, accidentally (or otherwise) creating an empty C:\dev\null file does not seem totally unlikely, so maybe using dev/null isn't so bright after all... Crap. Cheers, Peter ___ Reply to this item at: http://savannah.gnu.org/support/?108558 ___ Meddelandet skickades via/av Savannah http://savannah.gnu.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
[sr #108558] libtool nm test does not really work for W32 versions of nm
Follow-up Comment #6, sr #108558 (project libtool): Crap. How about just opening a file that is known to not to exist? Alternatively, give nm a real file that is at least 1 byte long (binutils nm checks for filesize being 1 and fails quietly; having 1 byte makes it say filename (which is what we want) and File truncated). ___ Reply to this item at: http://savannah.gnu.org/support/?108558 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
[sr #108558] libtool nm test does not really work for W32 versions of nm
Follow-up Comment #7, sr #108558 (project libtool): Ok, something like this seems safer: mkdir conftest.dir case `$tmp_nm -B conftest.dir/nofile` in *conftest.dir/nofile*) blablabla esac rm -rf conftest.dir But I don't know how non-GNU nm behaves, so the safe-safe-safe version only does the above on MSYS... Crap again. Cheers, Peter ___ Reply to this item at: http://savannah.gnu.org/support/?108558 ___ Meddelandet skickades via/av Savannah http://savannah.gnu.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
[sr #107959] Libtool generates invalid .def files
Update of sr #107959 (project libtool): Status:None = Done ___ Follow-up Comment #1: Fixed a while ago by commit a5a4944fbb2bbd20adb12b. Cheers, Peter ___ Reply to this item at: http://savannah.gnu.org/support/?107959 ___ Meddelandet skickades via/av Savannah http://savannah.gnu.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
[sr #108558] libtool nm test does not really work for W32 versions of nm
URL:
http://savannah.gnu.org/support/?108558
Summary: libtool nm test does not really work for W32
versions of nm
Project: GNU Libtool
Submitted by: lrn
Submitted on: Fri 02 May 2014 05:10:04 AM GMT
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
Status: None
Privacy: Public
Assigned to: None
Originator Email:
Open/Closed: Open
Discussion Lock: Any
Operating System: Microsoft Windows
___
Details:
libtool.m4 contains the following code:
# Check to see if the nm accepts a BSD-compat flag.
# Adding the 'sed 1q' prevents false positives on HP-UX, which says:
# nm: unknown option B ignored
# Tru64's nm complains that /dev/null is an invalid object file
case `$tmp_nm -B /dev/null 21 | sed '1q'` in
*/dev/null* | *'Invalid file or object type'*)
lt_cv_path_NM=$tmp_nm -B
break 2
;;
*)
case `$tmp_nm -p /dev/null 21 | sed '1q'` in
*/dev/null*)
lt_cv_path_NM=$tmp_nm -p
break 2
;;
*)
lt_cv_path_NM=${lt_cv_path_NM=$tmp_nm} # keep the first match, but
continue # so that we can try to find one that supports BSD flags
;;
esac
;;
esac
This does not work if `nm' in question is built for W32, because `/dev/null'
gets mangled into `nul', and `nul' does not behave the same way (it can be
stat()'ed successfully and looks like a zero-size file to stat()).
Even if binutils are patched to do a more thorough check (for example, stricmp
(file_name, nul) or isatty(open (file_name, ...))), the file name
reported in the error message is `nul', not `/dev/null', so the case statement
here won't match.
AFAIU, this bug is as old as this code (which, i guess, makes it quite old),
but it was masked by the fact that /usr/bin/nm (MSYS/Cygwin nm) does pass this
test, and it's sufficiently compatible (for the purpose of parsing object
files) for this not to matter.
Things start to blow up when MinGW nm and MSYS/Cygwin nm are not completely
compatible (for example, when MinGW binutils and gcc are built with LTO
support, and MSYS/Cygwin binutilsgcc are not).
___
Reply to this item at:
http://savannah.gnu.org/support/?108558
___
Message sent via/by Savannah
http://savannah.gnu.org/
___
https://lists.gnu.org/mailman/listinfo/libtool
[sr #108559] libtool binary wrappers fall prey to aggressive optimizations
URL: http://savannah.gnu.org/support/?108559 Summary: libtool binary wrappers fall prey to aggressive optimizations Project: GNU Libtool Submitted by: lrn Submitted on: Fri 02 May 2014 05:16:44 AM GMT Category: None Priority: 5 - Normal Severity: 3 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Operating System: None ___ Details: When building binary wrappers (say, for W32), libtool puts a MAGIC constant string into them. Later on libtool greps the program for this string to see whether this is a wrapper or a real program. However, MAGIC string is not used in the program in any way, and gcc may remove it. This does happen when building with -flto. My proposal would be to make use of the string somehow to fool gcc into leaving it alone. For example, this call: lt_fatal (__FILE__, __LINE__, unrecognized %s option: '%s', ltwrapper_option_prefix, argv[i]); can be changed like this: lt_fatal (__FILE__, __LINE__, unrecognized %s option: '%s'\0%s, ltwrapper_option_prefix, argv[i], MAGIC_EXE); ___ Reply to this item at: http://savannah.gnu.org/support/?108559 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Libtool and ASAN
Hi friends, I'm trying to use -fsanitize=address on OS X using MacPorts' Clang++ 3.5. The project consists of C++ libraries, on top of which is built a Python module (with a thin C++ layer which needs to be compiled). Libtool (2.4.2 - the name of a fine belgian band of electronic music btw) is used in all layers. To enable ASAN, I add '-fsanitize=address' to my CXXFLAGS. It works well except for the C++ part of the Python module: akim@erebus ~/src/lrde/vaucanson2 $ make -C _build/35d python/vcsn_cxx.la V=1 /bin/sh ./libtool --tag=CXX --mode=link ccache clang++-mp-3.5 -Wall -Wextra -Wcast-align -Wcast-qual -Wdocumentation -Wformat -Wmissing-declarations -Wno-parentheses -Woverloaded-virtual -Wpointer-arith -Wwrite-strings -Qunused-arguments -ggdb -fsanitize=address -std=c++11 -avoid-version -module -L/opt/local/lib -Wl,-rpath,/opt/local/lib -L/opt/local/lib -o python/vcsn_cxx.la -rpath /opt/gostai/lib/python2.7/site-packages python/python_vcsn_cxx_la-vcsn_cxx.lo -lboost_python-mt lib/liblal_char_b.la lib/liblal_char_br.la lib/liblal_char_q.la lib/liblal_char_r.la lib/liblal_char_z.la lib/liblal_char_zr.la lib/liblal_char_zrr.la lib/liblan_char_b.la lib/liblan_char_r.la lib/liblan_char_z.la lib/liblan_char_zr.la lib/liblao_br.la lib/liblao_z.la lib/liblaw_char_b.la lib/liblaw_char_br.la lib/liblaw_char_r.la lib/liblaw_char_z.la lib/liblaw_char_zr.la lib/liblaw_char_zrr.la lib/libvcsn.la libtool: link: rm -fr python/.libs/vcsn_cxx.la python/.libs/vcsn_cxx.lai python/.libs/vcsn_cxx.so libtool: link: ccache clang++-mp-3.5 -Wl,-undefined -Wl,dynamic_lookup -o python/.libs/vcsn_cxx.so -bundle python/.libs/python_vcsn_cxx_la-vcsn_cxx.o -L/opt/local/lib -lboost_python-mt lib/.libs/liblal_char_b.dylib lib/.libs/liblal_char_br.dylib lib/.libs/liblal_char_q.dylib lib/.libs/liblal_char_r.dylib lib/.libs/liblal_char_z.dylib lib/.libs/liblal_char_zr.dylib lib/.libs/liblal_char_zrr.dylib lib/.libs/liblan_char_b.dylib lib/.libs/liblan_char_r.dylib lib/.libs/liblan_char_z.dylib lib/.libs/liblan_char_zr.dylib lib/.libs/liblao_br.dylib lib/.libs/liblao_z.dylib lib/.libs/liblaw_char_b.dylib lib/.libs/liblaw_char_br.dylib lib/.libs/liblaw_char_r.dylib lib/.libs/liblaw_char_z.dylib lib/.libs/liblaw_char_zr.dylib lib/.libs/liblaw_char_zrr.dylib lib/.libs/libvcsn.dylib -lboost_filesystem-mt -lboost_system-mt -lltdl -Wl,-rpath -Wl,/opt/local/lib libtool: link: ( cd python/.libs rm -f vcsn_cxx.la ln -s ../vcsn_cxx.la vcsn_cxx.la ) What matters here is that -fsanitize=address is dropped, it is not passed to the linker. And I really need it: akim@erebus ~/src/lrde/vaucanson2 $ ./_build/35d/tests/bin/vcsn -e python -c 'import vcsn' Traceback (most recent call last): File string, line 1, in module File /Users/akim/src/lrde/vaucanson2/python/vcsn/__init__.py, line 4, in module from vcsn_cxx import * ImportError: dlopen(/Users/akim/src/lrde/vaucanson2/_build/35d/python/.libs/vcsn_cxx.so, 2): Symbol not found: ___asan_option_detect_stack_use_after_return Referenced from: /Users/akim/src/lrde/vaucanson2/_build/35d/lib/.libs/liblal_char_b.0.dylib Expected in: flat namespace in /Users/akim/src/lrde/vaucanson2/_build/35d/lib/.libs/liblal_char_b.0.dylib I have to use -Wc to force Libtool to pass it to the compiler used to link (I must not use -Wl, because then it is passed to the linker invoked by the compiler, and the linker rejects -fsanitize). akim@erebus ~/src/lrde/vaucanson2/_build/35d $ /bin/sh ./libtool --tag=CXX --mode=link ccache clang++-mp-3.5 -Wall -Wextra -Wcast-align -Wcast-qual -Wdocumentation -Wformat -Wmissing-declarations -Wno-parentheses -Woverloaded-virtual -Wpointer-arith -Wwrite-strings -Qunused-arguments -ggdb -Wc,-fsanitize=address -std=c++11 -avoid-version -module -L/opt/local/lib -Wl,-rpath,/opt/local/lib -L/opt/local/lib -o python/vcsn_cxx.la -rpath /opt/gostai/lib/python2.7/site-packages python/python_vcsn_cxx_la-vcsn_cxx.lo -lboost_python-mt lib/liblal_char_b.la lib/liblal_char_br.la lib/liblal_char_q.la lib/liblal_char_r.la lib/liblal_char_z.la lib/liblal_char_zr.la lib/liblal_char_zrr.la lib/liblan_char_b.la lib/liblan_char_r.la lib/liblan_char_z.la lib/liblan_char_zr.la lib/liblao_br.la lib/liblao_z.la lib/liblaw_char_b.la lib/liblaw_char_br.la lib/liblaw_char_r.la lib/liblaw_char_z.la lib/liblaw_char_zr.la lib/liblaw_char_zrr.la lib/libvcsn.la libtool: link: rm -fr python/.libs/vcsn_cxx.so.ld_QwmwqO libtool: link: ccache clang++-mp-3.5 -Wl,-undefined -Wl,dynamic_lookup -o python/.libs/vcsn_cxx.so -bundle python/.libs/python_vcsn_cxx_la-vcsn_cxx.o -L/opt/local/lib -lboost_python-mt lib/.libs/liblal_char_b.dylib lib/.libs/liblal_char_br.dylib lib/.libs/liblal_char_q.dylib lib/.libs/liblal_char_r.dylib lib/.libs/liblal_char_z.dylib lib/.libs/liblal_char_zr.dylib lib/.libs/liblal_char_zrr.dylib lib/.libs/liblan_char_b.dylib lib/.libs/liblan_char_r.dylib
Re: Libtool 2.4.3 release
Hi Richard, Thanks for bringing these to my attention. A very brief look at the names of your patches makes me curious to know more... I've added taking a proper look at them to my TODO, but I don't want to hold up the release for them. If you have time, I'm keeping a mirror of the Libtool repo in my github account to make submitting pull-requests as easy as possible. If you can find the time to polish the ones you want in the release and submit them via github within a month or so, there's still time to make the release :-) Cheers, -- Gary V. Vaughan (gary AT gnu DOT org) On Mar 21, 2014, at 5:46 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Thu, 2014-03-20 at 18:07 +1300, Gary V. Vaughan wrote: On Mar 20, 2014, at 5:37 AM, Arnout Vandecappelle arnout.vandecappe...@essensium.com wrote: [Please keep me in CC, I'm not on the list] Dear libtool maintainers, Is there a possibility for a new libtool release in the foreseeable future? Yes, absolutely. In fact there are only 2 things ahead of it on my TODO list: 1. Figure out why a4ffcdb5e is a regression for test 57 2. fix test 120 race condition Unfortunately, Libtool is a complex beast, and we are woefully undermanned here. While everything rests on my shoulders, it will be at least another month before I can start work (I'm in the process of emigrating and all that entails). Patches for those 2 items, or any other as yet unknown issues with git master (or http://vaughan.pe/libtool/libtool-2.4.2.458.tar.gz if a bootstrapped tarball is easier to work with) are extremely welcome, and could lead to an immediate release... FWIW I'm another build system maintainer who sees email here. We currently have 12 patches against libtool: http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/recipes-devtools/libtool/libtool Some of these are inappropriate for upstream, one or two may have been merged into libtool, some others may highlight issues, particularly around the sysroot support. Unfortunately whilst I have the best intentions (and am still on the list), I haven't found the time to look into the issues as yet and figure out if we could get some into a form that they'd be accepted upstream. Cheers, Richard ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Libtool 2.4.3 release
On 20/03/14 06:07, Gary V. Vaughan wrote: On Mar 20, 2014, at 5:37 AM, Arnout Vandecappelle arnout.vandecappe...@essensium.com mailto:arnout.vandecappe...@essensium.com wrote: [Please keep me in CC, I'm not on the list] Dear libtool maintainers, Is there a possibility for a new libtool release in the foreseeable future? Hi Arnout, Yes, absolutely. In fact there are only 2 things ahead of it on my TODO list: 1. Figure out why a4ffcdb5e is a regression for test 57 2. fix test 120 race condition Unfortunately, Libtool is a complex beast, and we are woefully undermanned here. Complex beast indeed... Which is another reason why we prefer not to carry patches. While everything rests on my shoulders, it will be at least another month before I can start work (I'm in the process of emigrating and all that entails). Patches for those 2 items, or any other as yet unknown issues with git master (or http://vaughan.pe/libtool/libtool-2.4.2.458.tar.gz if a bootstrapped tarball is easier to work with) are extremely welcome, and could lead to an immediate release... Unfortunately, none of the buildroot maintainers seem up to the challenge of attacking ltmain... We've had issues that are probably best solved within libtool but where we resort to other workarounds to keep things simple. Most recent test logs here: http://vaughan.pe/libtool/libtool-2.4.2.458.logs/ In buildroot, we build all autotools (including libtool) as part of the cross-compilation process. We recently had to add a libtool patch for MIPS n64 support, which is annoying because it means we have to re-run automake etc. to update the autools-generated scripts in libtool. Did you patch just config.guess/config.sub and pass that back upstream? That is a prerequisite for arriving in the next release. Otherwise if you patched Libtool files, are your changes in upstream already? Yes, it's an upstream patch that we back-ported. However, our normal autotools support doesn't work because that creates a circular dependency. So we have to add a few hacks in the libtool build steps to make things work. A release of libtool would help a lot because then we don't need to carry patches and we don't need to generate configure etc. Thank you, Regards, Arnout -- Arnout Vandecappelle arnout dot vandecappelle at essensium dot com Cheers, -- Gary V. Vaughan (gary AT gnu DOT org) -- Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect+32-16-286500 Essensium/Mindhttp://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Libtool 2.4.3 release
On Thu, 2014-03-20 at 18:07 +1300, Gary V. Vaughan wrote: On Mar 20, 2014, at 5:37 AM, Arnout Vandecappelle arnout.vandecappe...@essensium.com wrote: [Please keep me in CC, I'm not on the list] Dear libtool maintainers, Is there a possibility for a new libtool release in the foreseeable future? Yes, absolutely. In fact there are only 2 things ahead of it on my TODO list: 1. Figure out why a4ffcdb5e is a regression for test 57 2. fix test 120 race condition Unfortunately, Libtool is a complex beast, and we are woefully undermanned here. While everything rests on my shoulders, it will be at least another month before I can start work (I'm in the process of emigrating and all that entails). Patches for those 2 items, or any other as yet unknown issues with git master (or http://vaughan.pe/libtool/libtool-2.4.2.458.tar.gz if a bootstrapped tarball is easier to work with) are extremely welcome, and could lead to an immediate release... FWIW I'm another build system maintainer who sees email here. We currently have 12 patches against libtool: http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/recipes-devtools/libtool/libtool Some of these are inappropriate for upstream, one or two may have been merged into libtool, some others may highlight issues, particularly around the sysroot support. Unfortunately whilst I have the best intentions (and am still on the list), I haven't found the time to look into the issues as yet and figure out if we could get some into a form that they'd be accepted upstream. Cheers, Richard ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Libtool 2.4.3 release
On Mar 20, 2014, at 5:37 AM, Arnout Vandecappelle arnout.vandecappe...@essensium.com wrote: [Please keep me in CC, I'm not on the list] Dear libtool maintainers, Is there a possibility for a new libtool release in the foreseeable future? Hi Arnout, Yes, absolutely. In fact there are only 2 things ahead of it on my TODO list: 1. Figure out why a4ffcdb5e is a regression for test 57 2. fix test 120 race condition Unfortunately, Libtool is a complex beast, and we are woefully undermanned here. While everything rests on my shoulders, it will be at least another month before I can start work (I'm in the process of emigrating and all that entails). Patches for those 2 items, or any other as yet unknown issues with git master (or http://vaughan.pe/libtool/libtool-2.4.2.458.tar.gz if a bootstrapped tarball is easier to work with) are extremely welcome, and could lead to an immediate release... Most recent test logs here: http://vaughan.pe/libtool/libtool-2.4.2.458.logs/ In buildroot, we build all autotools (including libtool) as part of the cross-compilation process. We recently had to add a libtool patch for MIPS n64 support, which is annoying because it means we have to re-run automake etc. to update the autools-generated scripts in libtool. Did you patch just config.guess/config.sub and pass that back upstream? That is a prerequisite for arriving in the next release. Otherwise if you patched Libtool files, are your changes in upstream already? However, our normal autotools support doesn't work because that creates a circular dependency. So we have to add a few hacks in the libtool build steps to make things work. A release of libtool would help a lot because then we don't need to carry patches and we don't need to generate configure etc. Thank you, Regards, Arnout -- Arnout Vandecappelle arnout dot vandecappelle at essensium dot com Cheers, -- Gary V. Vaughan (gary AT gnu DOT org)___ https://lists.gnu.org/mailman/listinfo/libtool
linking libtool archives across toolchains
I have a question about how to work with libtool in a multi-toolchain environment. Background: We have a piece of software (MVAPICH2) we're trying to build that uses libtool to create shared libraries for some C++ code. For ABI compatibility reasons we need to compile this C++ code with the Cray C++ compiler. This code depends on another installed library that was built with GCC, and when libtool goes to create the shared library, it pulls in some information from this library's installed .la file, which contains, among other things, a definition for inherited_linker_flags containing the -pthread option. Unfortunately, the Cray compilers do not support the -pthread option, so the linking fails. Obviously, this is just a single example, and it can be hacked around by removing the -pthread option in the libtool script before linking, but I wanted to ask any advice on how to work with libtool when libraries are being built with two or more compiler toolchains. Has this scenario been dealt with before? Is it not a good idea in general? -- Eric Bavier, Scientific Libraries, Cray Inc. ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: linking libtool archives across toolchains
On Fri, 14 Feb 2014, Eric Bavier wrote: Obviously, this is just a single example, and it can be hacked around by removing the -pthread option in the libtool script before linking, but I wanted to ask any advice on how to work with libtool when libraries are being built with two or more compiler toolchains. Has this scenario been dealt with before? Is it not a good idea in general? Libtool was always developed with the expectation that it is used with the toolchain it was configured with, and the libraries it uses were built using the same toolchain. The pthreads option is an obvious example but there are more subtle issues which crop up, not all due to libtool itself. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
[SCM] GNU Libtool branch, master, updated. v2.4.2.444-28-g053df7e
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project GNU Libtool. The branch, master has been updated via 053df7eb31d21c6d6dbe54c44f42009efec9d0c9 (commit) via 0d666fc13b8e5a110e7600866d6fa55dade4d4a0 (commit) from c18b2d494e03ed15407c65b1de4b2231d733fb75 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit 053df7eb31d21c6d6dbe54c44f42009efec9d0c9 Author: Peter Rosin p...@lysator.liu.se Date: Wed Feb 12 10:03:56 2014 +0100 tests: sprinkle -no-undefined when linking libraries * tests/duplicate_conv.at, tests/f77demo.at, tests/fcdemo.at: Here. Signed-off-by: Peter Rosin p...@lysator.liu.se commit 0d666fc13b8e5a110e7600866d6fa55dade4d4a0 Author: Peter Rosin p...@lysator.liu.se Date: Wed Feb 12 10:01:13 2014 +0100 libtool: actually strip -Wl when relinking with $LD Fixes the regression from commit v2.4.2.444 which is causing a testsuite failure in duplicate_conv.at (seen on Cygwin). * build-aux/ltmain.in (func_mode_link): $reload_cmds typically starts with $LD$reload_flag ... when $LD is used to relink. Make the case expression match that when checking if $LD is in fact used to relink. Signed-off-by: Peter Rosin p...@lysator.liu.se --- Summary of changes: build-aux/ltmain.in |2 +- tests/duplicate_conv.at |6 +++--- tests/f77demo.at|4 tests/fcdemo.at |4 4 files changed, 12 insertions(+), 4 deletions(-) diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in index 3b4e6ec..f8e0f5f 100644 --- a/build-aux/ltmain.in +++ b/build-aux/ltmain.in @@ -8094,7 +8094,7 @@ EOF # whole_archive_flag_spec and hope we can get by with turning comma # into space. case $reload_cmds in -*\$LD\ *) wl= ;; +*\$LD[\ \$]*) wl= ;; esac if test -n $convenience; then if test -n $whole_archive_flag_spec; then diff --git a/tests/duplicate_conv.at b/tests/duplicate_conv.at index cf1ba6a..3e39b20 100644 --- a/tests/duplicate_conv.at +++ b/tests/duplicate_conv.at @@ -50,7 +50,7 @@ $LIBTOOL --mode=link --tag=CC $CC $CFLAGS $LDFLAGS -o a/liba.la a/a.lo $LIBTOOL --mode=link --tag=CC $CC $CFLAGS $LDFLAGS -o b/liba.la b/a.lo b/b.lo # Fold into convenience archive. -AT_CHECK([$LIBTOOL --mode=link --tag=CC $CC $CFLAGS $LDFLAGS -o libcee.la c.lo a/liba.la b/liba.la], +AT_CHECK([$LIBTOOL --mode=link --tag=CC $CC $CFLAGS $LDFLAGS -no-undefined -o libcee.la c.lo a/liba.la b/liba.la], [0], [ignore], [ignore]) AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o main$EXEEXT main.$OBJEXT ./libcee.la], [0], [ignore], [ignore]) @@ -62,7 +62,7 @@ $LIBTOOL --mode=clean rm -f libcee.la #OTOH, we'd like to test the other situation, too. # Fold into static library. -AT_CHECK([$LIBTOOL --mode=link --tag=CC $CC $CFLAGS $LDFLAGS -rpath /foo -static -o libcee.la c.lo a/liba.la b/liba.la], +AT_CHECK([$LIBTOOL --mode=link --tag=CC $CC $CFLAGS $LDFLAGS -no-undefined -rpath /foo -static -o libcee.la c.lo a/liba.la b/liba.la], [0], [ignore], [ignore]) AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o main$EXEEXT main.$OBJEXT ./libcee.la], [0], [ignore], [ignore]) @@ -70,7 +70,7 @@ LT_AT_EXEC_CHECK([./main],[0],[ignore],[ignore]) $LIBTOOL --mode=clean rm -f libcee.la # Fold into library. -AT_CHECK([$LIBTOOL --mode=link --tag=CC $CC $CFLAGS $LDFLAGS -rpath /foo -o libcee.la c.lo a/liba.la b/liba.la], +AT_CHECK([$LIBTOOL --mode=link --tag=CC $CC $CFLAGS $LDFLAGS -no-undefined -rpath /foo -o libcee.la c.lo a/liba.la b/liba.la], [0], [ignore], [ignore]) AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o main$EXEEXT main.$OBJEXT ./libcee.la], [0], [ignore], [ignore]) diff --git a/tests/f77demo.at b/tests/f77demo.at index da8e324..da7e18b 100644 --- a/tests/f77demo.at +++ b/tests/f77demo.at @@ -64,12 +64,16 @@ lib_LTLIBRARIES = libfoo.la libmix.la libfoo2.la libfoo3.la libfoo_la_SOURCES = foof.f libfoo_la_LIBADD = libfoo2.la +libfoo_la_LDFLAGS = -no-undefined libfoo2_la_SOURCES = foof2.f +libfoo2_la_LDFLAGS = -no-undefined libfoo3_la_SOURCES = foof3.f +libfoo3_la_LDFLAGS = -no-undefined libmix_la_SOURCES = foof.f foof2.f fooc.c +libmix_la_LDFLAGS = -no-undefined noinst_HEADERS = foo.h diff --git a/tests/fcdemo.at b/tests/fcdemo.at index 8cfa214..34953ac 100644 --- a/tests/fcdemo.at +++ b/tests/fcdemo.at @@ -68,12 +68,16 @@ lib_LTLIBRARIES = libfoo.la libmix.la libfoo2.la libfoo3.la libfoo_la_SOURCES = foof.f90 libfoo_la_LIBADD = libfoo2.la +libfoo_la_LDFLAGS = -no-undefined libfoo2_la_SOURCES
[SCM] GNU Libtool branch, master, updated. v2.4.2.444-26-gc18b2d4
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project GNU Libtool. The branch, master has been updated via c18b2d494e03ed15407c65b1de4b2231d733fb75 (commit) from fa83d293d95e2e3bdfbfe739fc12e5c3a6307b64 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit c18b2d494e03ed15407c65b1de4b2231d733fb75 Author: Peter Rosin p...@lysator.liu.se Date: Mon Feb 10 14:51:07 2014 +0100 bootstrap: fix description of func_sort_ver to match recent sort change gl/build-aux/funclib.sh: Update comment to match reality. bootstrap: Regenerate. Signed-off-by: Peter Rosin p...@lysator.liu.se --- Summary of changes: bootstrap |2 +- gl/build-aux/funclib.sh |4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/bootstrap b/bootstrap index feb20a1..eecab2c 100755 --- a/bootstrap +++ b/bootstrap @@ -1499,7 +1499,7 @@ func_warning () # --- # 'sort -V' is not generally available. # Note this deviates from the version comparison in automake -# in that it treats 1.5 1.5.0, and treats 1.4.4a 1.4-p3a +# in that it treats 1.5 1.5.0, and treats 1.4-p12a 1.4-p3a # but this should suffice as we won't be specifying old # version formats or redundant trailing .0 in bootstrap.conf. # If we did want full compatibility then we should probably diff --git a/gl/build-aux/funclib.sh b/gl/build-aux/funclib.sh index 9cb02ff..fe53505 100644 --- a/gl/build-aux/funclib.sh +++ b/gl/build-aux/funclib.sh @@ -1,5 +1,5 @@ # Set a version string for this script. -scriptversion=2014-01-03.01; # UTC +scriptversion=2014-02-10.13; # UTC # General shell script boiler plate, and helper functions. # Written by Gary V. Vaughan, 2004 @@ -1268,7 +1268,7 @@ func_warning () # --- # 'sort -V' is not generally available. # Note this deviates from the version comparison in automake -# in that it treats 1.5 1.5.0, and treats 1.4.4a 1.4-p3a +# in that it treats 1.5 1.5.0, and treats 1.4-p12a 1.4-p3a # but this should suffice as we won't be specifying old # version formats or redundant trailing .0 in bootstrap.conf. # If we did want full compatibility then we should probably hooks/post-receive -- GNU Libtool
[SCM] GNU Libtool branch, master, updated. v2.4.2.444-25-gfa83d29
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.
The branch, master has been updated
via fa83d293d95e2e3bdfbfe739fc12e5c3a6307b64 (commit)
from 4d57e0905a2c5ba0e537c8b3ccc116cdc0240c5d (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
commit fa83d293d95e2e3bdfbfe739fc12e5c3a6307b64
Author: Gary V. Vaughan g...@gnu.org
Date: Thu Feb 6 12:05:04 2014 +1300
doc: remove redundant in order to phrase where possible.
* doc/libtool.texi: Remove many occurrences of the redundant
phrase in order to, where ever to is as clear or clearer.
* THANKS: Add attribution.
Reported by Dave Yost
Signed-off-by: Gary V. Vaughan g...@gnu.org
---
Summary of changes:
THANKS |1 +
doc/libtool.texi | 55 ++---
2 files changed, 28 insertions(+), 28 deletions(-)
diff --git a/THANKS b/THANKS
index de0cfde..e895aee 100644
--- a/THANKS
+++ b/THANKS
@@ -94,6 +94,7 @@
Daniel Reed n...@ml.org
Daniel Richard G.sk...@iskunk.org
Dave Korndave.korn.cyg...@googlemail.com
+ Dave Yostd...@yost.com
DJ Delorie d...@delorie.com
Donn Washburnn5...@comcast.net
Edouard G. Parmelan edouard.parme...@france.ncr.com
diff --git a/doc/libtool.texi b/doc/libtool.texi
index 05fec92..89c5d1a 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -241,7 +241,7 @@ each host type is available via a generic interface, but
nasty quirks
are hidden from the programmer.
GNU Libtool's consistent interface is reassuring@dots{} users don't need
-to read obscure documentation in order to have their favorite source
+to read obscure documentation to have their favorite source
package build shared libraries. They just run your package
@code{configure} script (or equivalent), and libtool does all the dirty
work.
@@ -694,7 +694,7 @@ make it easier to clean up the build directory, and to help
ensure that
other programs fail horribly if you accidentally forget to use libtool
when you should.
-Again, you may want to have a look at the @file{.la} file in order
+Again, you may want to have a look at the @file{.la} file
to see what Libtool stores in it. In particular, you will see that
Libtool uses this file to remember the destination directory for the
library (the argument to @option{-rpath}) as well as the dependency
@@ -952,7 +952,7 @@ burger$
@end example
Argh. Now GDB complains because it cannot find the shared library that
-@file{hell} is linked against. So, we must use libtool in order to
+@file{hell} is linked against. So, we must use libtool to
properly set the library path and run the debugger. Fortunately, we can
forget all about the @file{@value{objdir}} directory, and just run it on
the executable wrapper (@pxref{Execute mode}):
@@ -2039,7 +2039,7 @@ automake, The Automake Manual}, for more information.
@cindex configuring libtool
Libtool requires intimate knowledge of your compiler suite and operating
-system in order to be able to create shared libraries and link against
+system to be able to create shared libraries and link against
them properly. When you install the libtool distribution, a
system-specific libtool script is installed into your binary directory.
@@ -2054,7 +2054,7 @@ system features, then generates the @file{Makefile}s (and
possibly a
@file{config.h} header file), after which you can run @code{make} and
build the package.
-Libtool adds its own tests to your @code{configure} script in order to
+Libtool adds its own tests to your @code{configure} script to
generate a libtool script for the installer's host machine.
@menu
@@ -2747,7 +2747,7 @@ Manipulation Program, for those who haven't taken the
plunge. See
@url{http://www.gimp.org/}.} distribution @file{README}:
@example
-The GIMP uses GNU Libtool in order to build shared libraries on a
+The GIMP uses GNU Libtool to build shared libraries on a
variety of systems. While this is very nice for making usable
binaries, it can be a pain when trying to debug a program. For that
reason, compilation of shared libraries can be turned off by
@@ -2761,7 +2761,7 @@ specifying the @option{--disable-shared} option to
@file{configure}.
@cindex languages, non-C
@cindex C++, using
-Libtool was first implemented in order to add support for writing shared
+Libtool was first implemented to add support for writing shared
libraries in the C language. However, over time, libtool is being
integrated with other languages, so
Re: libtool fails with uninstalled frameworks and the -F flag
Hmm, -F should be passed through unmolested. # Flags to be passed through unchanged, with rationale: # -64, -mips[0-9] enable 64-bit mode for the SGI compiler # -r[0-9][0-9]*specify processor for the SGI compiler # -xarch=*, -xtarget=* enable 64-bit mode for the Sun compiler # +DA*, +DD* enable 64-bit mode for the HP compiler # -q* compiler args for the IBM compiler # -m*, -t[45]*, -txscale* architecture-specific flags for GCC # -F/path path to uninstalled frameworks, gcc on darwin # -p, -pg, --coverage, -fprofile-* profiling flags for GCC # @fileGCC response files # -tp=*Portland pgcc target processor selection # --sysroot=* for sysroot support # -O*, -g*, -flto*, -fwhopr*, -fuse-linker-plugin GCC link-time optimization # -stdlib=*select c++ std lib with clang -64|-mips[0-9]|-r[0-9][0-9]*|-xarch=*|-xtarget=*|+DA*|+DD*|-q*|-m*| \ -t[45]*|-txscale*|-p|-pg|--coverage|-fprofile-*|-F*|@*|-tp=*|--sysroot=*| \ -O*|-g*|-flto*|-fwhopr*|-fuse-linker-plugin|-stdlib=*) What version of GNU libtool are you using? Peter On Jan 31, 2014, at 3:06 PM, Michael C. Grant m...@cvxr.com wrote: Gary, Sorry for the delay. I think I'm going to have to give up on this one. I'm afraid my understanding of libtool internals as well as Darwin -framework idiosyncracies are insufficient to the task. Fortunately, the issue we were having with Octave compilation has been resolved by other means (actually by forcing link-all-dependencies in libtool whenever an uninstalled framework is encountered). Feel free to close this for now. If I get ambitious and figure things out more fully I will take another crack at it. On Jan 13, 2014, at 8:50 PM, Gary V. Vaughan g...@gnu.org wrote: Hi Michael, [moved to libtool-patches list] On Jan 14, 2014, at 11:45 AM, Michael C. Grant m...@cvxr.com wrote: I'm trying to compile GNU Octave and its new Qt GUI on a Mac OSX with Homebrew. Homebrew installs the Qt frameworks in /usr/local/Cellar/qt/4.8.5/lib, so after some fiddling with the configure script I get this: QT_LDFLAGS=-F/usr/local/Cellar/qt/4.8.5/lib QT_LIBS=-framework QtCore -framework QtGui -framework QtNetwork However, the libtool script does not handle the -F argument through properly, so it is stripped out of the linking process. I created the following patch for the generated libtool script, which causes libtool to treat -F exactly like it treats -L. This seems to do the trick. I did notice that scanning through past discussions that this has come up a couple of times, but there is reluctance to provide full support for -F for some reason. Perhaps the relative simplicity of this patch would convince you to reconsider. I'm also discussing this with the Homebrew folks to see if they would consider including in their formula, but they do prefer not to use patches if they can help it. Thanks for the patch. Sorry I didn't reply to your earlier emails - I marked them for further attention, but didn't make the time to actually go back and respond. My main worry is whether that changing libtool's treatment of -F is going to do something unexpected on another platform. That said, apart from your conflating of -L and -F in the case branches with the patch you sent, I'm open to including it in the upcoming release if you don't mind reworking it a little? Please keep the -L and -F branches separate, factoring the branch bodies into a shell function if necessary to prevent cut-n-pasting blocks of code between the two. Bonus points if you could also make -F behave as before on all platforms but *-darwin*. If you have github, I keep a mirror of libtool at http://github.com/gvvaughan/GNU-libtool, so that might be a more convenient way for you to submit a pull request than dropping patch attachments into the mailing list. I have a couple of small fixes of my own that I need to polish and push, and then I'll do another round of platform testing to nail down what else is a show-stopper for a final pre-release. Cheers, -- Gary V. Vaughan (gary AT gnu DOT org)
Re: libtool fails with uninstalled frameworks and the -F flag
Gary, Sorry for the delay. I think I'm going to have to give up on this one. I'm afraid my understanding of libtool internals as well as Darwin -framework idiosyncracies are insufficient to the task. Fortunately, the issue we were having with Octave compilation has been resolved by other means (actually by forcing link-all-dependencies in libtool whenever an uninstalled framework is encountered). Feel free to close this for now. If I get ambitious and figure things out more fully I will take another crack at it. On Jan 13, 2014, at 8:50 PM, Gary V. Vaughan g...@gnu.org wrote: Hi Michael, [moved to libtool-patches list] On Jan 14, 2014, at 11:45 AM, Michael C. Grant m...@cvxr.com wrote: I'm trying to compile GNU Octave and its new Qt GUI on a Mac OSX with Homebrew. Homebrew installs the Qt frameworks in /usr/local/Cellar/qt/4.8.5/lib, so after some fiddling with the configure script I get this: QT_LDFLAGS=-F/usr/local/Cellar/qt/4.8.5/lib QT_LIBS=-framework QtCore -framework QtGui -framework QtNetwork However, the libtool script does not handle the -F argument through properly, so it is stripped out of the linking process. I created the following patch for the generated libtool script, which causes libtool to treat -F exactly like it treats -L. This seems to do the trick. I did notice that scanning through past discussions that this has come up a couple of times, but there is reluctance to provide full support for -F for some reason. Perhaps the relative simplicity of this patch would convince you to reconsider. I'm also discussing this with the Homebrew folks to see if they would consider including in their formula, but they do prefer not to use patches if they can help it. Thanks for the patch. Sorry I didn't reply to your earlier emails - I marked them for further attention, but didn't make the time to actually go back and respond. My main worry is whether that changing libtool's treatment of -F is going to do something unexpected on another platform. That said, apart from your conflating of -L and -F in the case branches with the patch you sent, I'm open to including it in the upcoming release if you don't mind reworking it a little? Please keep the -L and -F branches separate, factoring the branch bodies into a shell function if necessary to prevent cut-n-pasting blocks of code between the two. Bonus points if you could also make -F behave as before on all platforms but *-darwin*. If you have github, I keep a mirror of libtool at http://github.com/gvvaughan/GNU-libtool, so that might be a more convenient way for you to submit a pull request than dropping patch attachments into the mailing list. I have a couple of small fixes of my own that I need to polish and push, and then I'll do another round of platform testing to nail down what else is a show-stopper for a final pre-release. Cheers, -- Gary V. Vaughan (gary AT gnu DOT org)
[SCM] GNU Libtool branch, master, updated. v2.4.2.444-23-g70ff0e0
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.
The branch, master has been updated
via 70ff0e04c9dda19b74c88005abed3c1ca4adc3fc (commit)
from 525cddd2bcea4c565d6dd1d2d55dd1de1a476b67 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
commit 70ff0e04c9dda19b74c88005abed3c1ca4adc3fc
Author: Gary V. Vaughan g...@gnu.org
Date: Mon Jan 27 15:04:53 2014 +1300
bootstrap: use `-d .git` to check whether we are in a git tree.
* gl/build-aux/bootstrap.in (func_require_git): .git is not a
regular file, use -d to check its existence.
* bootstrap: Regenerate.
* THANKS: Add Bruce Korb.
Reported by Bruce Korb
Copyright-paperwork-exempt: Yes
Signed-off-by: Gary V. Vaughan g...@gnu.org
---
Summary of changes:
THANKS|1 +
bootstrap |4 ++--
gl/build-aux/bootstrap.in |4 ++--
3 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/THANKS b/THANKS
index de0cfde..63d3ea2 100644
--- a/THANKS
+++ b/THANKS
@@ -78,6 +78,7 @@
Brad Smith b...@comstyle.com
Brent Leback brent.leb...@st.com
Brian Barrettbrbar...@osl.iu.edu
+ Bruce Korb bruce.k...@gmail.com
Bruno Haible hai...@ilog.fr
Brice De Bruyne bric...@gmail.com
Camilo La Rota camilo.lar...@ens-lyon.fr
diff --git a/bootstrap b/bootstrap
index 2094e73..4e24dbf 100755
--- a/bootstrap
+++ b/bootstrap
@@ -2563,7 +2563,7 @@ test extract-trace = $progname func_main $@
# End:
# Set a version string for *this* script.
-scriptversion=2014-01-04.01; # UTC
+scriptversion=2014-01-27.02; # UTC
## --- ##
@@ -3698,7 +3698,7 @@ func_require_git ()
$opt_skip_git GIT=true
test true = $GIT || {
- if test -f .git; then
+ if test -d .git; then
($GIT --version) /dev/null 21 || GIT=true
fi
}
diff --git a/gl/build-aux/bootstrap.in b/gl/build-aux/bootstrap.in
index 8441bdc..d0276f6 100755
--- a/gl/build-aux/bootstrap.in
+++ b/gl/build-aux/bootstrap.in
@@ -232,7 +232,7 @@ vc_ignore=
. `echo $0 |${SED-sed} 's|[^/]*$||'`extract-trace
# Set a version string for *this* script.
-scriptversion=2014-01-04.01; # UTC
+scriptversion=2014-01-27.02; # UTC
## --- ##
@@ -1367,7 +1367,7 @@ func_require_git ()
$opt_skip_git GIT=true
test true = $GIT || {
- if test -f .git; then
+ if test -d .git; then
($GIT --version) /dev/null 21 || GIT=true
fi
}
hooks/post-receive
--
GNU Libtool
[SCM] GNU Libtool branch, master, updated. v2.4.2.444-22-g525cddd
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.
The branch, master has been updated
via 525cddd2bcea4c565d6dd1d2d55dd1de1a476b67 (commit)
via 64367d3499ec323af2e18326996c8c73924eab50 (commit)
from 2f75576d051fad9a8c0b274c5be1289d57c0b636 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
commit 525cddd2bcea4c565d6dd1d2d55dd1de1a476b67
Author: Rainer Orth r...@cebitec.uni-bielefeld.de
Date: Sat Jan 18 10:07:52 2014 +1300
libtool: opt_duplicate_compiler_generated_deps is harmful on Solaris
Fix for http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16452.
* build-aux/ltmain.in (libtool_validate_options): disable the
opt_duplicate_compiler_generated_deps optimization for Solaris2 so
that gcc-4.9+ compiled C++ code with -Wl,-Bdirect on 64-bit Solaris
x86 can avoid unwinding failures caused by accidental mixing of the
libc and libgcc_s unwinders in a single executable.
Signed-off-by: Gary V. Vaughan g...@gnu.org
commit 64367d3499ec323af2e18326996c8c73924eab50
Author: Gary V. Vaughan g...@gnu.org
Date: Wed Jan 15 20:10:29 2014 +1300
bootstrap: check for git checkout correctly.
* gl/bulid-aux/bootstrap.in (func_require_git): Use .git instead
of .gitignore to recognise a git checkout.
* bootstrap: Regenerate.
Signed-off-by: Gary V. Vaughan g...@gnu.org
---
Summary of changes:
bootstrap |4 ++--
build-aux/ltmain.in |4 +++-
gl/build-aux/bootstrap.in |4 ++--
3 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/bootstrap b/bootstrap
index db31255..2094e73 100755
--- a/bootstrap
+++ b/bootstrap
@@ -3698,8 +3698,8 @@ func_require_git ()
$opt_skip_git GIT=true
test true = $GIT || {
- if test -f .gitignore ($GIT --version) /dev/null 21; then :; else
- GIT=true
+ if test -f .git; then
+($GIT --version) /dev/null 21 || GIT=true
fi
}
diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index f452e54..3b4e6ec 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -497,7 +497,9 @@ libtool_validate_options ()
test : = $debug_cmd || func_append preserve_args --debug
case $host in
- *cygwin* | *mingw* | *pw32* | *cegcc*)
+ # Solaris2 added to fix
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16452
+ # see also: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59788
+ *cygwin* | *mingw* | *pw32* | *cegcc* | *solaris2*)
# don't eliminate duplications in $postdeps and $predeps
opt_duplicate_compiler_generated_deps=:
;;
diff --git a/gl/build-aux/bootstrap.in b/gl/build-aux/bootstrap.in
index 71ff3ae..8441bdc 100755
--- a/gl/build-aux/bootstrap.in
+++ b/gl/build-aux/bootstrap.in
@@ -1367,8 +1367,8 @@ func_require_git ()
$opt_skip_git GIT=true
test true = $GIT || {
- if test -f .gitignore ($GIT --version) /dev/null 21; then :; else
- GIT=true
+ if test -f .git; then
+($GIT --version) /dev/null 21 || GIT=true
fi
}
hooks/post-receive
--
GNU Libtool
Re: libtool fails with uninstalled frameworks and the -F flag
Please keep the -L and -F branches separate, factoring the branch bodies into a shell function if necessary to prevent cut-n-pasting blocks of code between the two. Bonus points if you could also make -F behave as before on all platforms but *-darwin*. I'll do that. If you have github, I keep a mirror of libtool athttp://github.com/gvvaughan/GNU-libtool, so that might be a more convenient way for you to submit a pull request than dropping patch attachments into the mailing list. Ah, perfect. I'll submit a pull request there. I have a couple of small fixes of my own that I need to polish and push, and then I'll do another round of platform testing to nail down what else is a show-stopper for a final pre-release. Cheers, -- Gary V. Vaughan (gary AT gnu DOT org)
Re: libtool fails with uninstalled frameworks and the -F flag
Hi Michael, [moved to libtool-patches list] On Jan 14, 2014, at 11:45 AM, Michael C. Grant m...@cvxr.com wrote: I'm trying to compile GNU Octave and its new Qt GUI on a Mac OSX with Homebrew. Homebrew installs the Qt frameworks in /usr/local/Cellar/qt/4.8.5/lib, so after some fiddling with the configure script I get this: QT_LDFLAGS=-F/usr/local/Cellar/qt/4.8.5/lib QT_LIBS=-framework QtCore -framework QtGui -framework QtNetwork However, the libtool script does not handle the -F argument through properly, so it is stripped out of the linking process. I created the following patch for the generated libtool script, which causes libtool to treat -F exactly like it treats -L. This seems to do the trick. I did notice that scanning through past discussions that this has come up a couple of times, but there is reluctance to provide full support for -F for some reason. Perhaps the relative simplicity of this patch would convince you to reconsider. I'm also discussing this with the Homebrew folks to see if they would consider including in their formula, but they do prefer not to use patches if they can help it. Thanks for the patch. Sorry I didn't reply to your earlier emails - I marked them for further attention, but didn't make the time to actually go back and respond. My main worry is whether that changing libtool's treatment of -F is going to do something unexpected on another platform. That said, apart from your conflating of -L and -F in the case branches with the patch you sent, I'm open to including it in the upcoming release if you don't mind reworking it a little? Please keep the -L and -F branches separate, factoring the branch bodies into a shell function if necessary to prevent cut-n-pasting blocks of code between the two. Bonus points if you could also make -F behave as before on all platforms but *-darwin*. If you have github, I keep a mirror of libtool at http://github.com/gvvaughan/GNU-libtool, so that might be a more convenient way for you to submit a pull request than dropping patch attachments into the mailing list. I have a couple of small fixes of my own that I need to polish and push, and then I'll do another round of platform testing to nail down what else is a show-stopper for a final pre-release. Cheers, -- Gary V. Vaughan (gary AT gnu DOT org) signature.asc Description: Message signed with OpenPGP using GPGMail
libtool fails with uninstalled frameworks and the -F flag
I'm trying to compile GNU Octave and its new Qt GUI on a Mac OSX with Homebrew. Homebrew installs the Qt frameworks in /usr/local/Cellar/qt/4.8.5/lib, so after some fiddling with the configure script I get this: QT_LDFLAGS=-F/usr/local/Cellar/qt/4.8.5/lib QT_LIBS=-framework QtCore -framework QtGui -framework QtNetwork However, the libtool script does not handle the -F argument through properly, so it is stripped out of the linking process. I created the following patch for the generated libtool script, which causes libtool to treat -F exactly like it treats -L. This seems to do the trick. I did notice that scanning through past discussions that this has come up a couple of times, but there is reluctance to provide full support for -F for some reason. Perhaps the relative simplicity of this patch would convince you to reconsider. I'm also discussing this with the Homebrew folks to see if they would consider including in their formula, but they do prefer not to use patches if they can help it. Regards, Michael libtool.diff Description: libtool.diff ___ https://lists.gnu.org/mailman/listinfo/libtool
[SCM] GNU Libtool branch, master, updated. v2.4.2.444-20-g2f75576
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project GNU Libtool. The branch, master has been updated via 2f75576d051fad9a8c0b274c5be1289d57c0b636 (commit) from 754721442a645b599113f53bae5ed76d804de5bd (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit 2f75576d051fad9a8c0b274c5be1289d57c0b636 Author: Todd C. Miller todd.mil...@courtesan.com Date: Sat Jan 11 13:15:32 2014 +1300 libtoolize: don't remove install-sh. If you are not using automake, libtoolize would remove install-sh. It needs the same treatment as config.guess and config.sub. * libtoolize.in (func_require_seen_libtool): Remove install-sh from $all_pkgaux_files, the list of files removed by `libtoolize --force`. * THANKS: Add Todd C. Miller. * NEWS: Update. Copyright-paperwork-exempt: Yes Signed-off-by: Gary V. Vaughan g...@gnu.org --- Summary of changes: NEWS |3 +++ THANKS|1 + libtoolize.in |7 --- 3 files changed, 8 insertions(+), 3 deletions(-) diff --git a/NEWS b/NEWS index c8730c7..1ca6d65 100644 --- a/NEWS +++ b/NEWS @@ -69,6 +69,9 @@ NEWS - list of user-visible changes between releases of GNU Libtool - Recognize more variants (e.g. those starting with a LIBRARY statement) of module-definitions (.def) files when using them instead of a raw list of symbols to export. + - Fix a long-standing bug when using libtoolize without automake; we +no longer remove install-sh with --force, since it's not a file +libtoolize will reinstall without --install.. ** Important incompatible changes: diff --git a/THANKS b/THANKS index b59bed2..de0cfde 100644 --- a/THANKS +++ b/THANKS @@ -194,6 +194,7 @@ Sven Verdoolaege sk...@liacs.nl Terry D. Dontje terry.don...@sun.com Tim Mooney moo...@dogbert.cc.ndsu.nodak.edu + Todd C. Miller todd.mil...@courtesan.com Todd Vierlingt...@pobox.com Tom Tromey tro...@cygnus.com Tor Lillqvistt...@iki.fi diff --git a/libtoolize.in b/libtoolize.in index 1842465..d819470 100644 --- a/libtoolize.in +++ b/libtoolize.in @@ -1894,9 +1894,10 @@ func_require_seen_libtool () # Lists of all files libtoolize has ever installed. These are removed # before installing the latest files when --force was passed to help # ensure a clean upgrade. - # Do not remove config.guess nor config.sub, we don't install them - # without --install, and the project may not be using Automake. - all_pkgaux_files=compile install-sh depcomp missing ltmain.sh snippet/_Noreturn.h snippet/arg-nonnull.h snippet/c++defs.h snippet/warn-on-use.h + # Do not remove config.guess, config.sub or install-sh, we don't + # install them without --install, and the project may not be using + # Automake. + all_pkgaux_files=compile depcomp missing ltmain.sh snippet/_Noreturn.h snippet/arg-nonnull.h snippet/c++defs.h snippet/warn-on-use.h all_pkgmacro_files=argz.m4 libtool.m4 ltdl.m4 ltoptions.m4 ltsugar.m4 ltversion.in ltversion.m4 lt~obsolete.m4 all_pkgltdl_files=COPYING.LIB Makefile Makefile.in Makefile.inc Makefile.am README acinclude.m4 aclocal.m4 argz_.h argz.c config.h.in config-h.in configure configure.ac configure.in libltdl/lt__alloc.h libltdl/lt__dirent.h libltdl/lt__glibc.h libltdl/lt__private.h libltdl/lt__strl.h libltdl/lt_dlloader.h libltdl/lt_error.h libltdl/lt_system.h libltdl/slist.h loaders/dld_link.c loaders/dlopen.c loaders/dyld.c loaders/load_add_on.c loaders/loadlibrary.c loaders/preopen.c loaders/shl_load.c lt__alloc.c lt__dirent.c lt__strl.c lt_dlloader.c lt_error.c ltdl.c ltdl.h ltdl.mk slist.c hooks/post-receive -- GNU Libtool
[SCM] GNU Libtool branch, master, updated. v2.4.2.444-18-g5e5cf7a
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.
The branch, master has been updated
via 5e5cf7a7d67a1af4752bf442a42a5a77dccacd3e (commit)
from 1f14273e954361bde44143458098acd9723e54a2 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
commit 5e5cf7a7d67a1af4752bf442a42a5a77dccacd3e
Author: Gary V. Vaughan g...@gnu.org
Date: Tue Jan 7 14:16:34 2014 +1300
bootstrap: specify particular version in buildreq with =x.y.
* gl/build-aux/bootstrap.in (func_check_versions): If the version
number begins with '=' then it must match the installed version of
the named tool exactly.
* gl/doc/bootstrap.texi (buildreq): Document the '=vernum' feature.
* bootstrap: Regenerate.
Signed-off-by: Gary V. Vaughan g...@gnu.org
---
Summary of changes:
bootstrap | 26 --
gl/build-aux/bootstrap.in | 26 --
gl/doc/bootstrap.texi |5 +
3 files changed, 45 insertions(+), 12 deletions(-)
diff --git a/bootstrap b/bootstrap
index b5b6730..4ca10e4 100755
--- a/bootstrap
+++ b/bootstrap
@@ -4805,9 +4805,6 @@ delimited list of triples; 'program min-version url'.
else
_G_instver=`func_get_version $_G_app`
-test -z $_G_instver \
-|| func_verbose found '$_G_app' version $_G_instver.
-
# Fail if --version didn't work.
if test -z $_G_instver; then
func_error Prerequisite '$_G_app' not found. Please install it, or
@@ -4816,12 +4813,29 @@ delimited list of triples; 'program min-version url'.
# Fail if a newer version than what we have is required.
else
- func_lt_ver $_G_reqver $_G_instver || {
-func_error \
+ func_verbose found '$_G_app' version $_G_instver.
+
+ case $_G_reqver in
+=*)
+ # If $buildreq version starts with '=', version must
+ # match the installed program exactly.
+ test x$_G_reqver = x=$_G_instver || {
+ func_error \
+ '$_G_app' version == $_G_instver is too old
+ 'exactly $_G_app-$_G_reqver is required
+func_check_versions_result=false
+ }
+ ;;
+ *)
+ # Otherwise, anything that is not older is a match.
+ func_lt_ver $_G_reqver $_G_instver || {
+func_error \
'$_G_app' version == $_G_instver is too old
'$_G_app' version = $_G_reqver is required
func_check_versions_result=false
- }
+ }
+ ;;
+ esac
fi
fi
done
diff --git a/gl/build-aux/bootstrap.in b/gl/build-aux/bootstrap.in
index 7fc0c12..71ff3ae 100755
--- a/gl/build-aux/bootstrap.in
+++ b/gl/build-aux/bootstrap.in
@@ -2474,9 +2474,6 @@ delimited list of triples; 'program min-version url'.
else
_G_instver=`func_get_version $_G_app`
-test -z $_G_instver \
-|| func_verbose found '$_G_app' version $_G_instver.
-
# Fail if --version didn't work.
if test -z $_G_instver; then
func_error Prerequisite '$_G_app' not found. Please install it, or
@@ -2485,12 +2482,29 @@ delimited list of triples; 'program min-version url'.
# Fail if a newer version than what we have is required.
else
- func_lt_ver $_G_reqver $_G_instver || {
-func_error \
+ func_verbose found '$_G_app' version $_G_instver.
+
+ case $_G_reqver in
+=*)
+ # If $buildreq version starts with '=', version must
+ # match the installed program exactly.
+ test x$_G_reqver = x=$_G_instver || {
+ func_error \
+ '$_G_app' version == $_G_instver is too old
+ 'exactly $_G_app-$_G_reqver is required
+func_check_versions_result=false
+ }
+ ;;
+ *)
+ # Otherwise, anything that is not older is a match.
+ func_lt_ver $_G_reqver $_G_instver || {
+func_error \
'$_G_app' version == $_G_instver is too old
'$_G_app' version = $_G_reqver is required
func_check_versions_result=false
- }
+ }
+ ;;
+ esac
fi
fi
done
diff --git a/gl/doc/bootstrap.texi b/gl/doc/bootstrap.texi
index a457931..2f7b382 100755
--- a/gl/doc/bootstrap.texi
+++ b/gl/doc/bootstrap.texi
@@ -82,6 +82,11 @@ requirement for Autobuild is added automatically, and
finally if there
are any diff files under @code{local_gl_dir}, then a versionless
requirement
[SCM] GNU Libtool branch, master, updated. v2.4.2.444-19-g7547214
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.
The branch, master has been updated
via 754721442a645b599113f53bae5ed76d804de5bd (commit)
from 5e5cf7a7d67a1af4752bf442a42a5a77dccacd3e (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
commit 754721442a645b599113f53bae5ed76d804de5bd
Author: Gary V. Vaughan g...@gnu.org
Date: Tue Jan 7 16:06:02 2014 +1300
options-parser: --version works with 'DO NOT EDIT' preamble again.
* gl/build-aux/options-parser (func_version): Don't quit on first
leading '##' line, otherwise DO NOT edit warnings prevent version
information from being extracted correctly.
* bootstrap: Regenerate.
Signed-off-by: Gary V. Vaughan g...@gnu.org
---
Summary of changes:
bootstrap |4 ++--
gl/build-aux/options-parser |4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/bootstrap b/bootstrap
index 4ca10e4..db31255 100755
--- a/bootstrap
+++ b/bootstrap
@@ -1536,7 +1536,7 @@ func_lt_ver ()
#! /bin/sh
# Set a version string for this script.
-scriptversion=2014-01-04.01; # UTC
+scriptversion=2014-01-07.03; # UTC
# A portable, pluggable option parser for Bourne shell.
# Written by Gary V. Vaughan, 2010
@@ -2109,7 +2109,7 @@ func_version ()
$debug_cmd
printf '%s\n' $progname $scriptversion
-$SED -n '/^##/q
+$SED -n '
/(C)/!b go
:more
/\./!{
diff --git a/gl/build-aux/options-parser b/gl/build-aux/options-parser
index 25a25eb..41302a8 100644
--- a/gl/build-aux/options-parser
+++ b/gl/build-aux/options-parser
@@ -1,7 +1,7 @@
#! /bin/sh
# Set a version string for this script.
-scriptversion=2014-01-04.01; # UTC
+scriptversion=2014-01-07.03; # UTC
# A portable, pluggable option parser for Bourne shell.
# Written by Gary V. Vaughan, 2010
@@ -574,7 +574,7 @@ func_version ()
$debug_cmd
printf '%s\n' $progname $scriptversion
-$SED -n '/^##/q
+$SED -n '
/(C)/!b go
:more
/\./!{
hooks/post-receive
--
GNU Libtool
[SCM] GNU Libtool branch, master, updated. v2.4.2.444-17-g1f14273
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.
The branch, master has been updated
via 1f14273e954361bde44143458098acd9723e54a2 (commit)
from b40922af00e13b7ab30d3dff6c63a7c9f6aece5d (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
commit 1f14273e954361bde44143458098acd9723e54a2
Author: Gary V. Vaughan g...@gnu.org
Date: Sun Jan 5 17:13:47 2014 +1300
bootstrap: remove conftest.sed file droppings.
* gl/build-aux/funclib.sh: Remove conftest.sed when no longer
needed.
* bootstrap: Regenerate.
Signed-off-by: Gary V. Vaughan g...@gnu.org
---
Summary of changes:
bootstrap |1 +
gl/build-aux/funclib.sh |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/bootstrap b/bootstrap
index 8b1b76c..b5b6730 100755
--- a/bootstrap
+++ b/bootstrap
@@ -426,6 +426,7 @@ test -z $SED {
}
func_path_progs sed gsed func_check_prog_sed $PATH:/usr/xpg4/bin
+ rm -f conftest.sed
SED=$func_path_progs_result
}
diff --git a/gl/build-aux/funclib.sh b/gl/build-aux/funclib.sh
index 981941d..9cb02ff 100644
--- a/gl/build-aux/funclib.sh
+++ b/gl/build-aux/funclib.sh
@@ -195,6 +195,7 @@ test -z $SED {
}
func_path_progs sed gsed func_check_prog_sed $PATH:/usr/xpg4/bin
+ rm -f conftest.sed
SED=$func_path_progs_result
}
hooks/post-receive
--
GNU Libtool
Re: [SCM] GNU Libtool branch, master, updated. v2.4.2.444-2-g581d90b
On 2014-01-03 02:01, Gary V. Vaughan wrote: Joking aside, you're quite right, I'll shuffle the order of bootstrap.in to leave that warning at the top, and remove the write bit from the generated file. Thanks for fixing that! (too) Cheers, Peter
[SCM] GNU Libtool branch, master, updated. v2.4.2.444-16-gb40922a
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.
The branch, master has been updated
via b40922af00e13b7ab30d3dff6c63a7c9f6aece5d (commit)
from b1a09dfa0d7ed7ca32139556d5fc815e73a7b274 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
commit b40922af00e13b7ab30d3dff6c63a7c9f6aece5d
Author: Gary V. Vaughan g...@gnu.org
Date: Sat Jan 4 14:53:06 2014 +1300
bootstrap: replace spurious hyphen in some section comments.
* gl/build-aux/bootstrap.in: replace spurious hypen in same
section header comments with a space.
* gl/build-aux/extract-trace, gl/build-aux/options-parser:
Likewise.
* bootstrap: Regenerate.
Signed-off-by: Gary V. Vaughan g...@gnu.org
---
Summary of changes:
bootstrap | 20 ++--
gl/build-aux/bootstrap.in |6 +++---
gl/build-aux/extract-trace |8
gl/build-aux/options-parser |6 +++---
4 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/bootstrap b/bootstrap
index 86ff9f7..8b1b76c 100755
--- a/bootstrap
+++ b/bootstrap
@@ -1535,7 +1535,7 @@ func_lt_ver ()
#! /bin/sh
# Set a version string for this script.
-scriptversion=2014-01-03.01; # UTC
+scriptversion=2014-01-04.01; # UTC
# A portable, pluggable option parser for Bourne shell.
# Written by Gary V. Vaughan, 2010
@@ -1957,9 +1957,9 @@ func_validate_options ()
-## --##
+## - ##
## Helper functions. ##
-## --##
+## - ##
# This section contains the helper functions used by the rest of the
# hookable option parser framework in ascii-betical order.
@@ -2154,7 +2154,7 @@ test -z $progpath . `echo $0 |${SED-sed}
's|[^/]*$||'`/funclib.sh
test extract-trace = $progname . `echo $0 |${SED-sed}
's|[^/]*$||'`/options-parser
# Set a version string.
-scriptversion=2013-08-22.10; # UTC
+scriptversion=2014-01-04.01; # UTC
# 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
@@ -2186,9 +2186,9 @@ scriptversion=2013-08-22.10; # UTC
-## --##
+## - ##
## Helper functions. ##
-## --##
+## - ##
# This section contains the helper functions used by the rest of
# 'extract-trace'.
@@ -2557,12 +2557,12 @@ test extract-trace = $progname func_main $@
# mode: shell-script
# sh-indentation: 2
# eval: (add-hook 'before-save-hook 'time-stamp)
-# time-stamp-pattern: 10/scriptversion=%:y-%02m-%02d.%02H; # UTC
+# time-stamp-pattern: 20/scriptversion=%:y-%02m-%02d.%02H; # UTC
# time-stamp-time-zone: UTC
# End:
# Set a version string for *this* script.
-scriptversion=2014-01-03.01; # UTC
+scriptversion=2014-01-04.01; # UTC
## --- ##
@@ -4314,9 +4314,9 @@ func_require_vc_ignore_files ()
}
-## --##
+## - ##
## Helper functions. ##
-## --##
+## - ##
# This section contains the helper functions used by the rest of 'bootstrap'.
diff --git a/gl/build-aux/bootstrap.in b/gl/build-aux/bootstrap.in
index 848d344..7fc0c12 100755
--- a/gl/build-aux/bootstrap.in
+++ b/gl/build-aux/bootstrap.in
@@ -232,7 +232,7 @@ vc_ignore=
. `echo $0 |${SED-sed} 's|[^/]*$||'`extract-trace
# Set a version string for *this* script.
-scriptversion=2014-01-03.01; # UTC
+scriptversion=2014-01-04.01; # UTC
## --- ##
@@ -1984,9 +1984,9 @@ func_require_vc_ignore_files ()
}
-## --##
+## - ##
## Helper functions. ##
-## --##
+## - ##
# This section contains the helper functions used by the rest of 'bootstrap'.
diff --git a/gl/build-aux/extract-trace b/gl/build-aux/extract-trace
index e18ed90..41a7b8b 100755
--- a/gl/build-aux/extract-trace
+++ b/gl/build-aux/extract-trace
@@ -12,7 +12,7 @@ test -z $progpath . `echo $0 |${SED-sed}
's|[^/]*$||'`/funclib.sh
test extract-trace = $progname . `echo $0 |${SED-sed}
's|[^/]*$||'`/options-parser
# Set a version string.
-scriptversion=2013-08-22.10; # UTC
+scriptversion=2014-01-04.01; # UTC
# 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
@@ -44,9 +44,9 @@ scriptversion=2013-08-22.10; # UTC
-## --##
+## - ##
## Helper functions. ##
-## --##
+## - ##
# This section contains the helper functions used by the rest of
# 'extract-trace'.
@@ -415,6 +415,6
[SCM] GNU Libtool branch, master, updated. v2.4.2.444-3-g95e1f34
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.
The branch, master has been updated
via 95e1f34f7b1238c2ad3db25c820ded22c93d049f (commit)
from 581d90bacaec6c20d5a5f776bdcdd9512f724192 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
commit 95e1f34f7b1238c2ad3db25c820ded22c93d049f
Author: Gary V. Vaughan g...@gnu.org
Date: Fri Jan 3 13:33:38 2014 +1300
libtoolize: use printf '%s\n' unconditionally.
It's been a year since the as_echo probes were removed in Autoconf,
so we can follow suit and remove our equivalent bs_echo probing
now. Retain $ECHO in case users need to override default printf
calls in museum piece environments.
* gl/build-aux/funclib.sh (ECHO): Default to 'printf %s\n'.
(bs_echo): Remove.
Adjust all bs_echo callers to use $ECHO instead.
* bootstrap: Regenerate.
* NEWS: Update.
Signed-off-by: Gary V. Vaughan g...@gnu.org
---
Summary of changes:
NEWS|9
bootstrap | 101 +--
build-aux/ltmain.in |2 +-
gl/build-aux/bootstrap.in | 12 +++---
gl/build-aux/extract-trace | 10 ++--
gl/build-aux/funclib.sh | 65 +--
gl/build-aux/options-parser | 14 +++---
7 files changed, 70 insertions(+), 143 deletions(-)
diff --git a/NEWS b/NEWS
index ecb48b1..c8730c7 100644
--- a/NEWS
+++ b/NEWS
@@ -99,10 +99,19 @@ NEWS - list of user-visible changes between releases of GNU
Libtool
[m4_define([AC_CONFIG_MACRO_DIRS],
m4_defn([AC_CONFIG_MACRO_DIR]))])
+ - Overhead of probing for a non-backslash crippled echo equivalent
+during initialization of every script has been removed in favor of
+trusting that printf %s\n works out of the box on all non-museum
+host architectures. Manually setting ECHO appropriately in the
+build environment will be necessary on some ancient architectures.
+
** Changes in supported systems or compilers:
- Support for bitrig (*-*-bitrig*).
+ - Solaris 7 and earlier requires ECHO=/usr/ucb/echo in the build
+environment, to build and use libtool.
+
New in 2.4.2 2011-10-17: git version 2.4.1a, Libtool team:
* New features:
diff --git a/bootstrap b/bootstrap
index 18323eb..3c30de8 100755
--- a/bootstrap
+++ b/bootstrap
@@ -163,47 +163,6 @@ func_path_progs ()
}
-# There are still modern systems that have problems with 'echo' mis-
-# handling backslashes, among others, so make sure $bs_echo is set to a
-# command that correctly interprets backslashes.
-# (this code from Autoconf 2.68)
-
-# Printing a long string crashes Solaris 7 /usr/bin/printf.
-bs_echo='\\\'
-bs_echo=$bs_echo$bs_echo$bs_echo$bs_echo$bs_echo
-bs_echo=$bs_echo$bs_echo$bs_echo$bs_echo$bs_echo$bs_echo
-# Prefer a ksh shell builtin over an external printf program on Solaris,
-# but without wasting forks for bash or zsh.
-if test -z $BASH_VERSION$ZSH_VERSION \
- (test X`print -r -- $bs_echo` = X$bs_echo) 2/dev/null; then
- bs_echo='print -r --'
- bs_echo_n='print -rn --'
-elif (test X`printf %s $bs_echo` = X$bs_echo) 2/dev/null; then
- bs_echo='printf %s\n'
- bs_echo_n='printf %s'
-else
- if test X`(/usr/ucb/echo -n -n $bs_echo) 2/dev/null` = X-n $bs_echo;
then
-bs_echo_body='eval /usr/ucb/echo -n $1$nl'
-bs_echo_n='/usr/ucb/echo -n'
- else
-bs_echo_body='eval expr X$1 : X\\(.*\\)'
-bs_echo_n_body='eval
- arg=$1;
- case $arg in #(
- *$nl*)
- expr X$arg : X\\(.*\\)$nl;
- arg=`expr X$arg : .*$nl\\(.*\\)`;;
- esac;
- expr X$arg : X\\(.*\\) | tr -d $nl
-'
-export bs_echo_n_body
-bs_echo_n='sh -c $bs_echo_n_body bs_echo'
- fi
- export bs_echo_body
- bs_echo='sh -c $bs_echo_body bs_echo'
-fi
-
-
# We want to be able to use the functions in this file before configure
# has figured out where the best binaries are kept, which means we have
# to search for them ourselves - except when the results are already set
@@ -224,13 +183,13 @@ test -z $SED {
_G_path_prog=$1
_G_count=0
-$bs_echo_n 0123456789 conftest.in
+printf 0123456789 conftest.in
while :
do
cat conftest.in conftest.in conftest.tmp
mv conftest.tmp conftest.in
cp conftest.in conftest.nl
- $bs_echo '' conftest.nl
+ echo '' conftest.nl
$_G_path_prog -f conftest.sed conftest.nl conftest.out 2/dev/null
|| break
diff conftest.out conftest.nl /dev/null 21 || break
[SCM] GNU Libtool branch, master, updated. v2.4.2.444-14-gda59d47
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.
The branch, master has been updated
via da59d47a448f0a623c7f56632dbe8c3f864a450a (commit)
via 9ef95183f0ae64d1cdbfeb68d3ad6ce37e6e9b97 (commit)
via 5b1d8fd0a05f2aec7f67082c9343a9a592910a2c (commit)
from 9f8717edbcb133d0aa3fa797e56de83432acd941 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
commit da59d47a448f0a623c7f56632dbe8c3f864a450a
Author: Gary V. Vaughan g...@gnu.org
Date: Fri Jan 3 20:07:48 2014 +1300
inline-source: gawk doesn't have boolean constants.
I've been writing a lot of Lua lately, but still a silly mistake:(
* gl/build-aux/inline-source (func_include): Use `magic` variable
to count #! lines found, and only output the DO NOT EDIT warning
after the first one.
Signed-off-by: Gary V. Vaughan g...@gnu.org
commit 9ef95183f0ae64d1cdbfeb68d3ad6ce37e6e9b97
Author: Gary V. Vaughan g...@gnu.org
Date: Fri Jan 3 18:21:40 2014 +1300
edit-readme-alpha: adjust for recent README edits.
* build-aux/edit-readme-alpha: Adjust regexps for recent README
improvements.
* README.md: Fix a SPACE-TAB sanity check failure.
Signed-off-by: Gary V. Vaughan g...@gnu.org
commit 5b1d8fd0a05f2aec7f67082c9343a9a592910a2c
Author: Gary V. Vaughan g...@gnu.org
Date: Fri Jan 3 18:20:40 2014 +1300
bootstrap: fix test-dollar sanity check failure.
* gl/build-aux/bootstrap.in (func_ensure_README): quote argument.
* bootstrap: Regenerate.
Signed-off-by: Gary V. Vaughan g...@gnu.org
---
Summary of changes:
README.md |2 +-
bootstrap |6 +++---
build-aux/edit-readme-alpha | 12 ++--
gl/build-aux/bootstrap.in |6 +++---
gl/build-aux/inline-source |6 +++---
5 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/README.md b/README.md
index 96898b4..5e41f2e 100644
--- a/README.md
+++ b/README.md
@@ -120,7 +120,7 @@ that further limiting of the recursive set of tests is
possible. For
example, to run only the template tests within the `max_cmd_len`, use:
gmake check TESTSUITEFLAGS=-v -x -k max_cmd_len \
- INNER_TESTSUITEFLAGS=',template -v -x'
+INNER_TESTSUITEFLAGS=',template -v -x'
If you wish to report test failures to the libtool list, you need to
send the file `tests/testsuite.log` to the [bug mailing list][].
diff --git a/bootstrap b/bootstrap
index 44cd0cd..e102622 100755
--- a/bootstrap
+++ b/bootstrap
@@ -3029,17 +3029,17 @@ EOT
# Without AM_INIT_AUTOMAKE([foreign]), automake will not run to
# completion with no README file, even though README.md or README.txt
# is often preferable.
-func_ensure_changelog ()
+func_ensure_README ()
{
$debug_cmd
test -f README || {
_G_README=
for _G_readme in README.txt README.md README.rst; do
-test -f $_G_readme break
+test -f $_G_readme break
done
- test -f $_G_readme $LN_S $_G_readme README
+ test -f $_G_readme $LN_S $_G_readme README
func_verbose $LN_S $_G_readme README
}
diff --git a/build-aux/edit-readme-alpha b/build-aux/edit-readme-alpha
index 390994a..166584c 100755
--- a/build-aux/edit-readme-alpha
+++ b/build-aux/edit-readme-alpha
@@ -64,12 +64,12 @@ for file in $@; do
# Make sure the paragraph we are matching has not been edited since
# this script was written.
- matched=`sed -n -e '/^This is GNU Libtool,/,/^interface\.$/p' $file \
+ matched=`sed -n -e '/^\[GNU Libtool\]\[libtool\] is/,/^consistent, portable
interface\.$/p' $file \
|wc -l |sed 's|^ *||'`
# Unless, of course, it was edited by this script already.
test 3 = $matched \
- || matched=`sed -n -e '/^This is an alpha testing release/,/behind a
consistent, portable interface\.$/p' $file \
+ || matched=`sed -n -e '/^This is an alpha testing release/,/a
consistent, portable interface\.$/p' $file \
|wc -l |sed 's|^ *||'`
test 3 = $matched \
@@ -79,10 +79,10 @@ for file in $@; do
trap 'x=$?; rm $file.T; exit $x' 1 2 13 15
# Edit the first paragraph to be suitable for an alpha release.
- sed -e '/^This is GNU Libtool,/,/^interface.$/c\
-This is an alpha testing release of GNU Libtool, a generic library\
-support script. Libtool hides the complexity of using shared libraries\
-behind a consistent, portable interface.' $file $file.T
+ sed -n '/^\[GNU Libtool\]\[libtool\] is/,/^consistent, portable
interface\.$/c\
+This is an alpha testing release of [GNU Libtool][libtool], a generic\
+library support script
Re: [SCM] GNU Libtool branch, master, updated. v2.4.2.444-2-g581d90b
On 2014-01-02 01:32, Gary V. Vaughan wrote: Peter's a7462c5 fix was applied to the generated bootstrap script instead of the funclib.sh source, and had have been overwritten the next time bootstrap was regenerated. Nice catch! As my feeble defense, I claim that there should have been a generated, do not edit comment in the files that are generated with funclib.sh. :-) Cheers, Peter
Re: [SCM] GNU Libtool branch, master, updated. v2.4.2.444-2-g581d90b
Hi Peter, On Jan 3, 2014, at 11:55 AM, Peter Rosin p...@lysator.liu.se wrote: On 2014-01-02 01:32, Gary V. Vaughan wrote: Peter's a7462c5 fix was applied to the generated bootstrap script instead of the funclib.sh source, and had have been overwritten the next time bootstrap was regenerated. Nice catch! As my feeble defense, I claim that there should have been a generated, do not edit comment in the files that are generated with funclib.sh. :-) ┌─┤gary@kamala│~/Dropbox/Projects/libtool--devo--0 ├!68795=grep -i 'do not edit' bootstrap │master│95e1f34│ ## DO NOT EDIT THIS FILE, CUSTOMIZE IT USING A BOOTSTRAP.CONF ## ## DO NOT EDIT THIS FILE! ## :-p Joking aside, you're quite right, I'll shuffle the order of bootstrap.in to leave that warning at the top, and remove the write bit from the generated file. Cheers, -- Gary V. Vaughan (gary AT gnu DOT org) signature.asc Description: Message signed with OpenPGP using GPGMail
[SCM] GNU Libtool branch, master, updated. v2.4.2.444-1-g8886f3b
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project GNU Libtool. The branch, master has been updated via 8886f3b473da66de42c2f7aa43db7e8789018cca (commit) from a4ffcdb5e0f207656bb2584b1c4e1702a6d7fa32 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit 8886f3b473da66de42c2f7aa43db7e8789018cca Author: Gary V. Vaughan g...@gnu.org Date: Thu Jan 2 12:52:50 2014 +1300 maint: change history. * NEWS: Remove alpha release header. * cfg.mk (old_NEWS_hash): Update. Signed-off-by: Gary V. Vaughan g...@gnu.org --- Summary of changes: NEWS |3 --- cfg.mk |2 +- 2 files changed, 1 insertions(+), 4 deletions(-) diff --git a/NEWS b/NEWS index 4fb1e0a..ecb48b1 100644 --- a/NEWS +++ b/NEWS @@ -2,9 +2,6 @@ NEWS - list of user-visible changes between releases of GNU Libtool * Noteworthy changes in release ?.? (-??-??) [?] - -* Noteworthy changes in release 2.4.2.418 (2013-10-27) [alpha] - ** New features: - Moved to gnulib release infrastructure. diff --git a/cfg.mk b/cfg.mk index 6620685..de3aef3 100644 --- a/cfg.mk +++ b/cfg.mk @@ -24,7 +24,7 @@ update-copyright-env := UPDATE_COPYRIGHT_FORCE=1 UPDATE_COPYRIGHT_USE_INTERVALS=1 # Set format of NEWS -old_NEWS_hash := c7c9fc43ba42057e4f8bd593a0c2e086 +old_NEWS_hash := d41d8cd98f00b204e9800998ecf8427e manual_title = Portable Dynamic Shared Object Management hooks/post-receive -- GNU Libtool
[SCM] GNU Libtool branch, master, updated. v2.4.2.444-2-g581d90b
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.
The branch, master has been updated
via 581d90bacaec6c20d5a5f776bdcdd9512f724192 (commit)
from 8886f3b473da66de42c2f7aa43db7e8789018cca (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
commit 581d90bacaec6c20d5a5f776bdcdd9512f724192
Author: Gary V. Vaughan g...@gnu.org
Date: Thu Jan 2 13:04:31 2014 +1300
bootstrap: push Peter's version sort fix back into funclib.sh.
Peter's a7462c5 fix was applied to the generated bootstrap script
instead of the funclib.sh source, and had have been overwritten
the next time bootstrap was regenerated.
* gl/build-aux/funclib.sh (func_sort_ver): Sort numerically on the
non-primary keys as well.
* bootstrap: Regenerate, with the change applied.
Signed-off-by: Gary V. Vaughan g...@gnu.org
---
Summary of changes:
bootstrap |4 ++--
gl/build-aux/funclib.sh |4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/bootstrap b/bootstrap
index 6b4cc6d..18323eb 100755
--- a/bootstrap
+++ b/bootstrap
@@ -1327,8 +1327,8 @@ func_sort_ver ()
{
$debug_cmd
-printf '%s\n%s\n' $1 $2 |
-sort -t. -k 1,1n -k 2,2n -k 3,3n -k 4,4n -k 5,5n -k 6,6n -k 7,7n -k 8,8n
-k 9,9n
+printf '%s\n%s\n' $1 $2 \
+ | sort -t. -k 1,1n -k 2,2n -k 3,3n -k 4,4n -k 5,5n -k 6,6n -k 7,7n -k
8,8n -k 9,9n
}
# func_lt_ver PREV CURR
diff --git a/gl/build-aux/funclib.sh b/gl/build-aux/funclib.sh
index 73b3e26..3bd2ab8 100644
--- a/gl/build-aux/funclib.sh
+++ b/gl/build-aux/funclib.sh
@@ -1317,8 +1317,8 @@ func_sort_ver ()
{
$debug_cmd
-printf '%s\n%s\n' $1 $2 |
-sort -t. -k1n -k1 -k2n -k2 -k3n -k3 -k4n -k4 -k5n -k5 -k6n -k6 -k7n -k7
-k8n -k8 -k9n -k9
+printf '%s\n%s\n' $1 $2 \
+ | sort -t. -k 1,1n -k 2,2n -k 3,3n -k 4,4n -k 5,5n -k 6,6n -k 7,7n -k
8,8n -k 9,9n
}
# func_lt_ver PREV CURR
hooks/post-receive
--
GNU Libtool
[SCM] GNU Libtool branch, master, updated. v2.4.2.418-11-g4494446
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.
The branch, master has been updated
via 4494446e43ccd60c1e91a707584841705d28e338 (commit)
from a7462c5563e124e06f4f61ce2a9cea26cf8be390 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
commit 4494446e43ccd60c1e91a707584841705d28e338
Author: Peter Rosin p...@lysator.liu.se
Date: Sun Dec 8 23:48:07 2013 +0100
maint: fix out-of-tree autoreconf w/o manual rebootstrap
build-aux/ltmain.in: Look for funclib.sh and options-parser in
the same location ltmain.in is found.
Signed-off-by: Peter Rosin p...@lysator.liu.se
---
Summary of changes:
build-aux/ltmain.in |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index fba05c1..0da8ad7 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -61,8 +61,8 @@ package_revision=@package_revision@
# Much of our low-level functionality needs to be sourced from external
# libraries, which are installed to $pkgauxdir.
-. build-aux/funclib.sh
-. build-aux/options-parser
+. `echo $0 |${SED-sed} 's|[^/]*$||'`funclib.sh
+. `echo $0 |${SED-sed} 's|[^/]*$||'`options-parser
# Set a version string.
scriptversion='(GNU @PACKAGE@) @VERSION@'
hooks/post-receive
--
GNU Libtool
libtool rule for (windows) import lib from exe?
Hi, I'm trying to build plugins on windows that reference symbols in the main application. I've been told that the best way to do this is to build an import lib for your exe file, and then link your modules against the import lib to form DLLs. Is this recommended? I'm getting a warning message that implies I can dlopen *.a archives if I pass -dlopen to the linker for the main application. I am planning to use dlfcn-win32 to implement dlopen for the windows executable. On linux everything works, and I'm able to build *.so modules that I can load and call from dlopen. For mingw, everything builds, but libtool builds *.a files instead of *.dll files, with this warning: *** Warning: linker path does not have real file for library -lbali-phy.exe.a. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libbali-phy.exe.a but no candidates were found. (...for file magic test) *** Warning: libtool could not satisfy all declared inter-library *** dependencies of module Range. Therefore, libtool will create *** a static module, that should work as long as the dlopening *** application is linked with the -dlopen flag. I have two questions: (1) If the warning above is right, it looks like I do not need a DLL after all. Therefore I do not need to make an import library, I can just pass '-dlopen' as a linker flag when compiling the main application, and dlopen *.a files. Is this right on windows? (2) Could someone please help me find where the -dlopen flag is documented? Does this dlopen flag take an argument, like '-dlopen file'? If so, what is the file? (3) How can I write a libtool rule to construct the import library? Right now I have this: if HOST_LINUX bali_phy_LDFLAGS = -rdynamic else if HOST_MINGW32 bali_phy_LDFLAGS = -Wl,--export-all-symbols,--output-def,bali-phy.def else bali_phy_LDFLAGS = endif endif libbali-phy.exe.a: bali-phy.exe $(DLLTOOL) -dllname bali-phy.exe --def bali-phy.def --output-lib libbali-phy.exe.a (4) How can I tell libtool that the modules depend on the import lib? Right now I have something like: if HOST_MINGW32 IMPORTLIB = -lbali-phy.exe.a else IMPORTLIB = endif mod_la_SOURCES = computation/builtins/mod.C mod_la_LDFLAGS = -module -shared -avoid-version -export-dynamic -no-undefined -enable-runtime-pseudo-reloc mod_la_LIBADD = $(IMPORTLIB) However, this produces the results above, where the modules are built as static *.a files instead of DLLs. Thanks so much for your help! -BenRI ___ https://lists.gnu.org/mailman/listinfo/libtool
[SCM] GNU Libtool branch, master, updated. v2.4.2.418-10-ga7462c5
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project GNU Libtool. The branch, master has been updated via a7462c5563e124e06f4f61ce2a9cea26cf8be390 (commit) from 397f71725630cd6d97fe69104f170861f441507a (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit a7462c5563e124e06f4f61ce2a9cea26cf8be390 Author: Peter Rosin p...@lysator.liu.se Date: Tue Nov 19 11:54:27 2013 +0100 bootstrap: fix version sort Reported by Ozkan Sezer who suffered from makeinfo 4.13 being detected as lesser than the required makeinfo 4.8. * bootstrap (func_sort_ver): Sort numerically on the non-primary keys as well. --- Summary of changes: bootstrap |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/bootstrap b/bootstrap index 1b16d95..852efd5 100755 --- a/bootstrap +++ b/bootstrap @@ -1323,7 +1323,7 @@ func_sort_ver () $debug_cmd printf '%s\n%s\n' $1 $2 | -sort -t. -k1n -k1 -k2n -k2 -k3n -k3 -k4n -k4 -k5n -k5 -k6n -k6 -k7n -k7 -k8n -k8 -k9n -k9 +sort -t. -k 1,1n -k 2,2n -k 3,3n -k 4,4n -k 5,5n -k 6,6n -k 7,7n -k 8,8n -k 9,9n } # func_lt_ver PREV CURR hooks/post-receive -- GNU Libtool
[PATCH] libtool: update cached $GCC value when updating $GXX
Hi! I noticed this while looking at the -nostdlib stuff. Will push in a couple of days unless there are valid objections. Cheers, Peter From 7efe9b28d977fccded55843c8bee3458835d0435 Mon Sep 17 00:00:00 2001 From: Peter Rosin p...@lysator.liu.se Date: Mon, 11 Nov 2013 10:00:28 +0100 Subject: [PATCH] libtool: update cached $GCC value when updating $GXX In the meat of the _LT_LANG_CXX_CONFIG macro, and in invoked macros, $GCC is used to indicate if g++ is used. $GCC is used instead of $GXX if an invoced macro is written in a tag agnositic way, like _LT_SYS_DYNAMIC_LINKER is. Note that GCC is restored to its original value at the end of the macro. * m4/libtool.m4 (_LT_LANG_CXX_CONFIG): If updating the GXX variable, for consistency also update the GCC variable. Signed-off-by: Peter Rosin p...@lysator.liu.se --- m4/libtool.m4 |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/m4/libtool.m4 b/m4/libtool.m4 index e34e021..523503f 100644 --- a/m4/libtool.m4 +++ b/m4/libtool.m4 @@ -6083,6 +6083,7 @@ if test yes != $_lt_caught_CXX_error; then else GXX=no + GCC=$GXX with_gnu_ld=no wlarc= fi -- 1.7.9
Re: [PATCH] libtool: update cached $GCC value when updating $GXX
On 2013-11-11 10:37, Peter Rosin wrote: Will push in a couple of days unless there are valid objections. Forget it. I am a moron. It would be more valid to simply remove the GXX=no assignment, but I can't classify that as a bug. Sorry for wasting your bandwidth. Cheers, Peter
Re: Using libtool via autotools causes linking problem on mingw
On 7 November 2013 22:00, Panicz Maciej Godek godek.mac...@gmail.comwrote: Hi, For some time I've been trying to compile my framework for writing multimedia and 3d games in Guile Scheme on Windows/MinGW. The framework uses SDL library, and more details can be found here: https://puszcza.gnu.org.ua/projects/slayer After many issues with compiling Guile Scheme on MinGW, I've finally managed to achieve it, and having build SDL, I proceeded to compile my framework. Although I did use the autotools to create a package, I know only superficially how it is supposed to work. Having ./configured my project, I managed to build the object files, but the final linking (performed by libtool) fails. It is invoked in the following way: ./libtool --tag=CXX --mode=link g++ -D_GNU_SOURCE=1 -Dmain=SDL_main -Ic:/mingw/msys/1.0/include/SDL -Ic:/mingw/msys/1.0/include/guile/2.0 -I/usr/local/include -Ic:/mingw/msys/1.0/include-Wall -Werror -mwindows -Lc:/mingw/msys/1.0/lib -lmingw32 -lSDLmain -lSDL -Lc:/mingw/msys/1.0/lib -lguile-2.0 -lgc -mwindows -Lc:/mingw/msys/1.0/lib -lSDL_image -lmingw32 -lSDLmain -lSDL -g -O2 -mwindows -Lc:/mingw/msys/1.0/lib -lmingw32 -lSDLmain -lSDL -Lc:/mingw/msys/1.0/lib -lguile-2.0 -lgc -mwindows -Lc:/mingw/msys/1.0/lib -lSDL_image -lmingw32 -lSDLmain -lSDL -o slayer.exe file.o font.o image.o input.o slayer.o symbols.o video.o -lSDL_ttf and the following error appears: c:/mingw/msys/1.0/lib/libmingw32.a(main.o): In function `main': e:\p\giaw\src\pkg\mingwrt-4.0.3-1-mingw32-src\bld/../mingwrt-4.0.3-1-mingw32-src/src/libcrt/crt/main.c:91: undefined reference to `WinMain@16' collect2.exe: error: ld returned 1 exit status The -mwindows switch says that your are compiling a Windows GUI application, which implies WinMain() function. If you are not doing that, remove the switch and (maybe) use -mconsole instead. See http://gcc.gnu.org/onlinedocs/gcc/i386-and-x86_002d64-Windows-Options.html for explanations of the switches. However, I do manage to build the executable with the following command: gcc -o slayer.exe file.o font.o image.o input.o slayer.o symbols.o video.o -mwindows -lmingw32 -lSDLmain -lSDL -lSDL_image -lSDL_ttf -lguile-2.0 (there are still some problems caused by libguile in the runtime, but at least the linkign stage succeeds) I know that it might be a complicated issue, and the cause might lie on the side of either MinGW or SDL or pkg-config or autotools or mine, but I thought it might be best to ask you first. The project's files can be browsed here http://hg.gnu.org.ua/hgweb/slayer/file/bb4c97fd8329 Thanks in advance, M. -- VZ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Using libtool via autotools causes linking problem on mingw
On 2013-11-08 11:31, Václav Zeman wrote: On 7 November 2013 22:00, Panicz Maciej Godek godek.mac...@gmail.com mailto:godek.mac...@gmail.com wrote: Hi, For some time I've been trying to compile my framework for writing multimedia and 3d games in Guile Scheme on Windows/MinGW. The framework uses SDL library, and more details can be found here: https://puszcza.gnu.org.ua/projects/slayer After many issues with compiling Guile Scheme on MinGW, I've finally managed to achieve it, and having build SDL, I proceeded to compile my framework. Although I did use the autotools to create a package, I know only superficially how it is supposed to work. Having ./configured my project, I managed to build the object files, but the final linking (performed by libtool) fails. It is invoked in the following way: ./libtool --tag=CXX --mode=link g++ -D_GNU_SOURCE=1 -Dmain=SDL_main -Ic:/mingw/msys/1.0/include/SDL -Ic:/mingw/msys/1.0/include/guile/2.0 -I/usr/local/include -Ic:/mingw/msys/1.0/include-Wall -Werror -mwindows -Lc:/mingw/msys/1.0/lib -lmingw32 -lSDLmain -lSDL -Lc:/mingw/msys/1.0/lib -lguile-2.0 -lgc -mwindows -Lc:/mingw/msys/1.0/lib -lSDL_image -lmingw32 -lSDLmain -lSDL -g -O2 -mwindows -Lc:/mingw/msys/1.0/lib -lmingw32 -lSDLmain -lSDL -Lc:/mingw/msys/1.0/lib -lguile-2.0 -lgc -mwindows -Lc:/mingw/msys/1.0/lib -lSDL_image -lmingw32 -lSDLmain -lSDL-o slayer.exe file.o font.o image.o input.o slayer.o symbols.o video.o -lSDL_ttf and the following error appears: c:/mingw/msys/1.0/lib/libmingw32.a(main.o): In function `main': e:\p\giaw\src\pkg\mingwrt-4.0.3-1-mingw32-src\bld/../mingwrt-4.0.3-1-mingw32-src/src/libcrt/crt/main.c:91: undefined reference to `WinMain@16' collect2.exe: error: ld returned 1 exit status The -mwindows switch says that your are compiling a Windows GUI application, which implies WinMain() function. If you are not doing that, remove the switch and (maybe) use -mconsole instead. See http://gcc.gnu.org/onlinedocs/gcc/i386-and-x86_002d64-Windows-Options.html for explanations of the switches. The SDL library, for some obscure reason, has its own special take on that and prescribes that you should keep using main() even if you are doing a GUI app. I think the SDLmain library contains the real WinMain@16 entry point and that entry point in turn calls the application main function. Or I should perhaps say SDL_main (see that -Dmain=SDL_main define above). Some part of this fragile SDL crap fails. I don't know what. Perhaps the SDL_main library was compiled to expect an ordinary main entry point instead of the GUI WinMain@16 version? Just to be clear, I'm not an SDL user. This is just my understanding of this. The above description might very well be flawed in some way, but SDL initialization is peculiar. Cheers, Peter ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Using libtool via autotools causes linking problem on mingw
2013/11/8 Václav Zeman vhais...@gmail.com The -mwindows switch says that your are compiling a Windows GUI application, which implies WinMain() function. If you are not doing that, remove the switch and (maybe) use -mconsole instead. See http://gcc.gnu.org/onlinedocs/gcc/i386-and-x86_002d64-Windows-Options.html for explanations of the switches. I think the issue can rather be concerned with the use of SDL. As I mentioned above, when I link using gcc -o slayer.exe file.o font.o image.o input.o slayer.o symbols.o video.o -mwindows -lmingw32 -lSDLmain -lSDL -lSDL_image -lSDL_ttf -lguile-2.0 the linkage succeeds. Note that, although the -D option shouldn't have any influence on the linkage, it does replace main with SDL_main during the compilation of object files, and I think it's the SDL_main library that contains the actual entry point. However, the question is not how to get the things built (because I already managed to do so), but how to adjust the build system (i.e. configure.acand/or various Makefile.am files) so that it builds the things properly. In particular, I didn't put the -mwindows there in the first place, so I have no option to remove it or replace it. regards, M. ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Using libtool via autotools causes linking problem on mingw
On 2013-11-08 12:18, Panicz Maciej Godek wrote: 2013/11/8 Peter Rosin p...@lysator.liu.se mailto:p...@lysator.liu.se The SDL library, for some obscure reason, has its own special take on that and prescribes that you should keep using main() even if you are doing a GUI app. I think the SDLmain library contains the real WinMain@16 entry point and that entry point in turn calls the application main function. Or I should perhaps say SDL_main (see that -Dmain=SDL_main define above). Some part of this fragile SDL crap fails. I don't know what. Perhaps the SDL_main library was compiled to expect an ordinary main entry point instead of the GUI WinMain@16 version? Just to be clear, I'm not an SDL user. This is just my understanding of this. The above description might very well be flawed in some way, but SDL initialization is peculiar. I can later try to add some of the options from the libtool invocation generated by autoconf to my invocation of gcc to see which particular option causes the failure and then let you know. I think that your description of the way SDL does things on mingw is sound (and I think that the goal is to ensure portability, as unix programmers have no idea what the WinMain is) Hmmm, I have this hunch that the -nostdlib option that libtool adds to the g++ invocation beats -mwindows, just like it beats -pthread. But I don't know that for a fact... Cheers, Peter ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Using libtool via autotools causes linking problem on mingw
On 2013-11-08 14:15, Peter Rosin wrote: On 2013-11-08 12:18, Panicz Maciej Godek wrote: 2013/11/8 Peter Rosin p...@lysator.liu.se mailto:p...@lysator.liu.se The SDL library, for some obscure reason, has its own special take on that and prescribes that you should keep using main() even if you are doing a GUI app. I think the SDLmain library contains the real WinMain@16 entry point and that entry point in turn calls the application main function. Or I should perhaps say SDL_main (see that -Dmain=SDL_main define above). Some part of this fragile SDL crap fails. I don't know what. Perhaps the SDL_main library was compiled to expect an ordinary main entry point instead of the GUI WinMain@16 version? Just to be clear, I'm not an SDL user. This is just my understanding of this. The above description might very well be flawed in some way, but SDL initialization is peculiar. I can later try to add some of the options from the libtool invocation generated by autoconf to my invocation of gcc to see which particular option causes the failure and then let you know. I think that your description of the way SDL does things on mingw is sound (and I think that the goal is to ensure portability, as unix programmers have no idea what the WinMain is) Hmmm, I have this hunch that the -nostdlib option that libtool adds to the g++ invocation beats -mwindows, just like it beats -pthread. But I don't know that for a fact... No, wait. You're not building a library, so -nostdlib isn't relevant... Sorry for the wasted bandwidth. Cheers, Peter ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Using libtool via autotools causes linking problem on mingw
2013/11/8 Peter Rosin p...@lysator.liu.se On 2013-11-08 12:18, Panicz Maciej Godek wrote: 2013/11/8 Peter Rosin p...@lysator.liu.se mailto:p...@lysator.liu.se The SDL library, for some obscure reason, has its own special take on that and prescribes that you should keep using main() even if you are doing a GUI app. I think the SDLmain library contains the real WinMain@16 entry point and that entry point in turn calls the application main function. Or I should perhaps say SDL_main (see that -Dmain=SDL_main define above). Some part of this fragile SDL crap fails. I don't know what. Perhaps the SDL_main library was compiled to expect an ordinary main entry point instead of the GUI WinMain@16 version? Just to be clear, I'm not an SDL user. This is just my understanding of this. The above description might very well be flawed in some way, but SDL initialization is peculiar. I can later try to add some of the options from the libtool invocation generated by autoconf to my invocation of gcc to see which particular option causes the failure and then let you know. I think that your description of the way SDL does things on mingw is sound (and I think that the goal is to ensure portability, as unix programmers have no idea what the WinMain is) Hmmm, I have this hunch that the -nostdlib option that libtool adds to the g++ invocation beats -mwindows, just like it beats -pthread. But I don't know that for a fact... I just made the following test: I removed the mediation of libtool and called g++ directly, with the same flags, i.e. g++ -D_GNU_SOURCE=1 -Dmain=SDL_main -Ic:/mingw/msys/1.0/include/SDL -Ic:/mingw/msys/1.0/include/guile/2.0 -I/usr/local/include -Ic:/mingw/msys/1.0/include-Wall -Werror -g -O2 -o slayer.exe file.o font.o image.o input.o slayer.o symbols.o video.o -mwindows -Lc:/mingw/msys/1.0/lib -lmingw32 -lSDLmain -lSDL -Lc:/mingw/msys/1.0/lib -lguile-2.0 -lgc -mwindows -Lc:/mingw/msys/1.0/lib -lSDL_image -lmingw32 -lSDLmain -lSDL -lSDL_ttf (the initial part, /bin/sh ../libtool --tag=CXX --mode=link, was removed) and it got linked with no complaints. I then removed both -mwindows flags from the above invocation, and it did work as well. So plainly it looks as if there was some problem with libtool on MinGW. Unfortunately, I'm not a shell scripting master, so I can't say exactly which command libtool uses to link the program and how it is invoked. ___ https://lists.gnu.org/mailman/listinfo/libtool
Using libtool via autotools causes linking problem on mingw
Hi, For some time I've been trying to compile my framework for writing multimedia and 3d games in Guile Scheme on Windows/MinGW. The framework uses SDL library, and more details can be found here: https://puszcza.gnu.org.ua/projects/slayer After many issues with compiling Guile Scheme on MinGW, I've finally managed to achieve it, and having build SDL, I proceeded to compile my framework. Although I did use the autotools to create a package, I know only superficially how it is supposed to work. Having ./configured my project, I managed to build the object files, but the final linking (performed by libtool) fails. It is invoked in the following way: ./libtool --tag=CXX --mode=link g++ -D_GNU_SOURCE=1 -Dmain=SDL_main -Ic:/mingw/msys/1.0/include/SDL -Ic:/mingw/msys/1.0/include/guile/2.0 -I/usr/local/include -Ic:/mingw/msys/1.0/include-Wall -Werror -mwindows -Lc:/mingw/msys/1.0/lib -lmingw32 -lSDLmain -lSDL -Lc:/mingw/msys/1.0/lib -lguile-2.0 -lgc -mwindows -Lc:/mingw/msys/1.0/lib -lSDL_image -lmingw32 -lSDLmain -lSDL -g -O2 -mwindows -Lc:/mingw/msys/1.0/lib -lmingw32 -lSDLmain -lSDL -Lc:/mingw/msys/1.0/lib -lguile-2.0 -lgc -mwindows -Lc:/mingw/msys/1.0/lib -lSDL_image -lmingw32 -lSDLmain -lSDL -o slayer.exe file.o font.o image.o input.o slayer.o symbols.o video.o -lSDL_ttf and the following error appears: c:/mingw/msys/1.0/lib/libmingw32.a(main.o): In function `main': e:\p\giaw\src\pkg\mingwrt-4.0.3-1-mingw32-src\bld/../mingwrt-4.0.3-1-mingw32-src/src/libcrt/crt/main.c:91: undefined reference to `WinMain@16' collect2.exe: error: ld returned 1 exit status However, I do manage to build the executable with the following command: gcc -o slayer.exe file.o font.o image.o input.o slayer.o symbols.o video.o -mwindows -lmingw32 -lSDLmain -lSDL -lSDL_image -lSDL_ttf -lguile-2.0 (there are still some problems caused by libguile in the runtime, but at least the linkign stage succeeds) I know that it might be a complicated issue, and the cause might lie on the side of either MinGW or SDL or pkg-config or autotools or mine, but I thought it might be best to ask you first. The project's files can be browsed here http://hg.gnu.org.ua/hgweb/slayer/file/bb4c97fd8329 Thanks in advance, M. ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Using libtool via autotools causes linking problem on mingw
On 2013-11-07 22:00, Panicz Maciej Godek wrote: Hi, For some time I've been trying to compile my framework for writing multimedia and 3d games in Guile Scheme on Windows/MinGW. The framework uses SDL library, and more details can be found here: https://puszcza.gnu.org.ua/projects/slayer After many issues with compiling Guile Scheme on MinGW, I've finally managed to achieve it, and having build SDL, I proceeded to compile my framework. Although I did use the autotools to create a package, I know only superficially how it is supposed to work. Having ./configured my project, I managed to build the object files, but the final linking (performed by libtool) fails. It is invoked in the following way: ./libtool --tag=CXX --mode=link g++ -D_GNU_SOURCE=1 -Dmain=SDL_main -Ic:/mingw/msys/1.0/include/SDL -Ic:/mingw/msys/1.0/include/guile/2.0 -I/usr/local/include -Ic:/mingw/msys/1.0/include-Wall -Werror -mwindows -Lc:/mingw/msys/1.0/lib -lmingw32 -lSDLmain -lSDL -Lc:/mingw/msys/1.0/lib -lguile-2.0 -lgc -mwindows -Lc:/mingw/msys/1.0/lib -lSDL_image -lmingw32 -lSDLmain -lSDL -g -O2 -mwindows -Lc:/mingw/msys/1.0/lib -lmingw32 -lSDLmain -lSDL -Lc:/mingw/msys/1.0/lib -lguile-2.0 -lgc -mwindows -Lc:/mingw/msys/1.0/lib -lSDL_image -lmingw32 -lSDLmain -lSDL-o slayer.exe file.o font.o image.o input.o slayer.o symbols.o video.o -lSDL_ttf and the following error appears: c:/mingw/msys/1.0/lib/libmingw32.a(main.o): In function `main': e:\p\giaw\src\pkg\mingwrt-4.0.3-1-mingw32-src\bld/../mingwrt-4.0.3-1-mingw32-src/src/libcrt/crt/main.c:91: undefined reference to `WinMain@16' collect2.exe: error: ld returned 1 exit status However, I do manage to build the executable with the following command: gcc -o slayer.exe file.o font.o image.o input.o slayer.o symbols.o video.o -mwindows -lmingw32 -lSDLmain -lSDL -lSDL_image -lSDL_ttf -lguile-2.0 (there are still some problems caused by libguile in the runtime, but at least the linkign stage succeeds) I know that it might be a complicated issue, and the cause might lie on the side of either MinGW or SDL or pkg-config or autotools or mine, but I thought it might be best to ask you first. The project's files can be browsed here http://hg.gnu.org.ua/hgweb/slayer/file/bb4c97fd8329 Hi! This is a classic error. You have to specify libraries *after* the object files and other libraries that need them in order to be portable. In your case the specifics are that you are adding a lot of $(FOO_LIBS) vars to AM_LDFLAGS in src/Makefile.am when you should probably have specified them in slayer_LDADD or something such instead. Hope that helps. Cheers, Peter ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Using libtool via autotools causes linking problem on mingw
Hi, I did apply that change, i.e. replaced AM_LDFLAGS with slayer_LDADD and moved the definition to the end of the src/Makefile.am. The libtool is right now invoked this way: /bin/sh ../libtool --tag=CXX --mode=link g++ -D_GNU_SOURCE=1 -Dmain=SDL_main -Ic:/mingw/msys/1.0/include/SDL -Ic:/mingw/msys/1.0/include/guile/2.0 -I/usr/local/include -Ic:/mingw/msys/1.0/include-Wall -Werror -g -O2 -o slayer.exe file.o font.o image.o input.o slayer.o symbols.o video.o -mwindows -Lc:/mingw/msys/1.0/lib -lmingw32 -lSDLmain -lSDL -Lc:/mingw/msys/1.0/lib -lguile-2.0 -lgc -mwindows -Lc:/mingw/msys/1.0/lib -lSDL_image -lmingw32 -lSDLmain -lSDL -lSDL_ttf (plainly the libraries are given after the .o files) but I still get the same error message. ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Using libtool via autotools causes linking problem on mingw
On 2013-11-07 23:39, Panicz Maciej Godek wrote: Hi, I did apply that change, i.e. replaced AM_LDFLAGS with slayer_LDADD and moved the definition to the end of the src/Makefile.am. The libtool is right now invoked this way: /bin/sh ../libtool --tag=CXX --mode=link g++ -D_GNU_SOURCE=1 -Dmain=SDL_main -Ic:/mingw/msys/1.0/include/SDL -Ic:/mingw/msys/1.0/include/guile/2.0 -I/usr/local/include -Ic:/mingw/msys/1.0/include-Wall -Werror -g -O2 -o slayer.exe file.o font.o image.o input.o slayer.o symbols.o video.o -mwindows -Lc:/mingw/msys/1.0/lib -lmingw32 -lSDLmain -lSDL -Lc:/mingw/msys/1.0/lib -lguile-2.0 -lgc -mwindows -Lc:/mingw/msys/1.0/lib -lSDL_image -lmingw32 -lSDLmain -lSDL -lSDL_ttf (plainly the libraries are given after the .o files) but I still get the same error message. Ok, I'm at a loss then. But I bet it's some kind of argument ordering issue... Maybe you could try moving -mwindows last or something? How to make that happen sanely with pkg-config is another matter. Sigh. Cheers, Peter ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool-2.4.2.418 released [alpha]
Libtoolers! The Libtool Team is pleased to announce the release of libtool 2.4.2.418. This is a preliminary alpha release to begin platform testing in preparation for the next stable release. I built 2.4.2.418 on x86_64-pc-solaris2.11 (OpenIndiana 151a8) with the Oracle Studio 12.3 toolchain. There was one unexpected failure in the new test suite: 21: quote shell meta-characters in filenamesFAILED (libtool.at:120) If I re-run the test-suite with --verbose, test #21 shows: 21. libtool.at:60: testing quote shell meta-characters in filenames ... ./libtool.at:102: $LIBTOOL -n --mode=$mode $preargs $preflag$flag:test $postargs stdout: libtool: compile: cc -c -DVAR=:test foo.c -KPIC -DPIC -o .libs/foo.o libtool: compile: cc -c -DVAR=:test foo.c -o foo.o /dev/null 21 ./libtool.at:106: grep $mode:.*$match_preflag$flag:test stdout stdout: libtool: compile: cc -c -DVAR=:test foo.c -KPIC -DPIC -o .libs/foo.o libtool: compile: cc -c -DVAR=:test foo.c -o foo.o /dev/null 21 ./libtool.at:116: $LIBTOOL -n --mode=$mode $preargs $preflag$flag\\:test\\ $postargs stdout: libtool: compile: cc -c -DVAR=\\:test\\ foo.c -KPIC -DPIC -o .libs/foo.o libtool: compile: cc -c -DVAR=\\:test\\ foo.c -o foo.o /dev/null 21 ./libtool.at:120: grep $mode:.*$match_preflag'\?'$flag:test'\? ' stdout stdout: ./libtool.at:120: exit code was 1, expected 0 21. libtool.at:60: FAILED (libtool.at:120) Let me know what other useful information I can provide. There's a patch after my signature that alters the README to provide the actual name of the log file from the test suite. Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 --- libtool-2.4.2.418.orig/README 2013-10-26 19:02:00.0 -0500 +++ libtool-2.4.2.418/README2013-11-05 16:16:33.243527395 -0600 @@ -113,7 +113,7 @@ to send the verbose output of the FAILing group, along with the information from the end of '$(top_builddir)/libtool --help' to the bug report mailing list, bug-libt...@gnu.org with a subject line that -includes the string '[TEST FAILURE]'. The file test-suite.log contains +includes the string '[TEST FAILURE]'. The file testsuite.log contains the verbose output from all failed tests. In order to enable debug shell tracing, you can set VERBOSE=debug when ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool-2.4.2.418 released [alpha]
Hi Tim, On 6 Nov 2013, at 11:20, Tim Mooney tim.moo...@ndsu.edu wrote: The Libtool Team is pleased to announce the release of libtool 2.4.2.418. This is a preliminary alpha release to begin platform testing in preparation for the next stable release. I built 2.4.2.418 on x86_64-pc-solaris2.11 (OpenIndiana 151a8) with the Oracle Studio 12.3 toolchain. There was one unexpected failure in the new test suite: 21: quote shell meta-characters in filenamesFAILED (libtool.at:120) Yes, I'm seeing this failure on quite a few of my test architectures too, but haven't been able to get to the bottom of it. If you have any insight, I'd be very happy to hear about it. If I re-run the test-suite with --verbose, test #21 shows: 21. libtool.at:60: testing quote shell meta-characters in filenames ... ./libtool.at:102: $LIBTOOL -n --mode=$mode $preargs $preflag$flag:test $postargs stdout: libtool: compile: cc -c -DVAR=:test foo.c -KPIC -DPIC -o .libs/foo.o libtool: compile: cc -c -DVAR=:test foo.c -o foo.o /dev/null 21 ./libtool.at:106: grep $mode:.*$match_preflag$flag:test stdout stdout: libtool: compile: cc -c -DVAR=:test foo.c -KPIC -DPIC -o .libs/foo.o libtool: compile: cc -c -DVAR=:test foo.c -o foo.o /dev/null 21 ./libtool.at:116: $LIBTOOL -n --mode=$mode $preargs $preflag$flag\\:test\\ $postargs stdout: libtool: compile: cc -c -DVAR=\\:test\\ foo.c -KPIC -DPIC -o .libs/foo.o libtool: compile: cc -c -DVAR=\\:test\\ foo.c -o foo.o /dev/null 21 ./libtool.at:120: grep $mode:.*$match_preflag'\?'$flag:test'\? ' stdout stdout: ./libtool.at:120: exit code was 1, expected 0 21. libtool.at:60: FAILED (libtool.at:120) Let me know what other useful information I can provide. A fix? ;-) There's a patch after my signature that alters the README to provide the actual name of the log file from the test suite. Thanks, I'll apply and push that presently. Cheers, -- Gary V. Vaughan (gary AT gnu DOT org) ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool-2.4.2.418 released [alpha]
Hi Gary and Tim, On Wed, 6 Nov 2013, Gary V. Vaughan wrote: | Hi Tim, | | On 6 Nov 2013, at 11:20, Tim Mooney tim.moo...@ndsu.edu wrote: | The Libtool Team is pleased to announce the release of libtool 2.4.2.418. | | This is a preliminary alpha release to begin platform testing in | preparation for the next stable release. | | I built 2.4.2.418 on x86_64-pc-solaris2.11 (OpenIndiana 151a8) with | the Oracle Studio 12.3 toolchain. There was one unexpected failure | in the new test suite: | | 21: quote shell meta-characters in filenamesFAILED (libtool.at:120) | | Yes, I'm seeing this failure on quite a few of my test architectures too, but | haven't been able to get to the bottom of it. If you have any insight, I'd be | very happy to hear about it. Gary, in bug#15734 you sugested it was a problem with grep. On my UnixWare box, I tested with a GNU grep first in the path and #21 did not fail. Now, which part is tripping up the system grep and what to do about it, I do not know. ;-) -- Tim RiceMultitalents(707) 456-1146 t...@multitalents.net ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: bug#15734: libtool 2.4.2.418 in UnixWare
Hi Tim,
Thanks for the report.
On Oct 28, 2013, at 9:06 AM, Tim Rice t...@multitalents.net wrote:
On Sun, 27 Oct 2013, Tim Rice wrote:
| On Sun, 27 Oct 2013, Tim Rice wrote:
|
|
| UnixWare 7.1.4
|
| Things don't look so good on the alpha release.
| ..
| To: bug-libt...@gnu.org
| Subject: [GNU Libtool 2.4.2.418] testsuite: 9 10 11 15 16 18 21 122
123 124 125 129 failed
| ..
|
| Saw this in the build log.
| --
| GEN libtoolize
| UX:sed: ERROR: Command garbled: s|^m4trace: -1-
AC_CONFIG_AUX_DIR[([]*||
| GEN libltdl/argz.h
| --
This patch helps some.
.
--- libtool-2.4.2.418/Makefile.am.old 2013-01-25 20:19:11.0 -0800
+++ libtool-2.4.2.418/Makefile.am 2013-10-27 12:13:43.776276925 -0700
@@ -248,7 +248,7 @@
## ##
abs_aux_dir = `$(lt__cd) '$(srcdir)/$(aux_dir)' pwd`
-ltdl_ac_aux_dir = `$(extract_trace) AC_CONFIG_AUX_DIR
$(srcdir)/libltdl/configure.ac`
+ltdl_ac_aux_dir = `SED=$(SED) $(extract_trace) AC_CONFIG_AUX_DIR
$(srcdir)/libltdl/configure.ac`
configure_edit = $(bootstrap_edit) \
-e '/^\. /s|@auxscriptsdir\@|'$(abs_aux_dir)'|g' \
.
To: bug-libt...@gnu.org
Subject: [GNU Libtool 2.4.2.418] testsuite: 21 122 123 124 125 129 failed
Most of the remaining failures seem to be caused by the unset variable in the
testsuite
getting set to ‘no’ rather than ‘unset’ or ‘:’ as was originally intended on
your host.
However, Autotest already provides as_unset, so the following patch switches to
that:
diff --git a/tests/demo.at b/tests/demo.at
index f1fd9a8..c0a1486 100644
--- a/tests/demo.at
+++ b/tests/demo.at
@@ -796,7 +796,7 @@ rm -f libhello.la hell$EXEEXT
# If this check fails (i.e. the make succeeds), then the installed library
# was used, which is wrong.
-AT_CHECK([$unset LIBTOOL LIBTOOLIZE; $MAKE hell$EXEEXT
libhello_la_OBJECTS=hello.lo || (exit 1)],
+AT_CHECK([$as_unset LIBTOOL; $as_unset LIBTOOLIZE; $MAKE hell$EXEEXT
libhello_la_OBJECTS=hello.lo || (exit 1)],
[1], [ignore], [ignore])
AT_CLEANUP
diff --git a/tests/testsuite.at b/tests/testsuite.at
index ecbdfc2..99122be 100644
--- a/tests/testsuite.at
+++ b/tests/testsuite.at
@@ -51,11 +51,6 @@ fi
if test -n $to_tool_file_cmd; then
configure_options=$configure_options
lt_cv_to_tool_file_cmd=$to_tool_file_cmd
fi
-if (FOO=bar; unset FOO) /dev/null 21; then
- unset=unset
-else
- unset=false
-fi
: ${mkdir_p=$abs_top_srcdir/build-aux/install-sh -d}
# Fix relative paths in $lt_INSTALL
case $lt_INSTALL in
@@ -193,7 +188,7 @@ m4_define([LT_AT_CONFIGURE],
m4_define([LT_AT_MAKE],
[for target in m4_default([$1], [all])
do
- AT_CHECK([$unset LIBTOOL LIBTOOLIZE; $MAKE $target $2], [0], [ignore],
[ignore])
+ AT_CHECK([$as_unset LIBTOOL; $as_unset LIBTOOLIZE; $MAKE $target $2], [0],
[ignore], [ignore])
done
])
I’ve pushed this patch already.
The remaining failure looks to be a similar problem to the sed issue you
discovered but with
grep. Since extract-trace is supposed to work standalone, I’ll find a way to
have funclib.sh
find a suitable sed and grep, which will fix not only the problems your patch
works on, but
also the remaining test failure, and no doubt similar latent bugs in other
funclib.sh clients
(bootstrap and libtoolize).
Please, let me know if your still having issues after that.
Cheers,
--
Gary V. Vaughan (gary AT gnu DOT org)
signature.asc
Description: Message signed with OpenPGP using GPGMail
[SCM] GNU Libtool branch, master, updated. v2.4.2-419-geea1df8
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project GNU Libtool. The branch, master has been updated via eea1df80de2239ae2962786cbcb33fa3e3b4533a (commit) via 4427784fe74e8f18c781d62624a0adb647893849 (commit) from e168b14b1bd4bb59a9142259cad60d85d2c7bdab (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit eea1df80de2239ae2962786cbcb33fa3e3b4533a Author: Gary V. Vaughan g...@gnu.org Date: Sun Oct 27 13:02:07 2013 +1300 maint: post-release administrivia * NEWS: Add header line for next release. * .prev-version: Record previous version. * cfg.mk (old_NEWS_hash): Auto-update. commit 4427784fe74e8f18c781d62624a0adb647893849 Author: Gary V. Vaughan g...@gnu.org Date: Sun Oct 27 11:52:43 2013 +1300 version 2.4.2.418 * NEWS: Record release date. --- Summary of changes: .prev-version |2 +- NEWS |3 +++ cfg.mk|2 +- 3 files changed, 5 insertions(+), 2 deletions(-) diff --git a/.prev-version b/.prev-version index 8e8299d..9d45785 100644 --- a/.prev-version +++ b/.prev-version @@ -1 +1 @@ -2.4.2 +2.4.2.418 diff --git a/NEWS b/NEWS index e872922..0c85812 100644 --- a/NEWS +++ b/NEWS @@ -2,6 +2,9 @@ NEWS - list of user-visible changes between releases of GNU Libtool * Noteworthy changes in release ?.? (-??-??) [?] + +* Noteworthy changes in release 2.4.2.418 (2013-10-27) [alpha] + ** New features: - Moved to gnulib release infrastructure. diff --git a/cfg.mk b/cfg.mk index 652b821..6d308de 100644 --- a/cfg.mk +++ b/cfg.mk @@ -24,7 +24,7 @@ update-copyright-env := UPDATE_COPYRIGHT_FORCE=1 UPDATE_COPYRIGHT_USE_INTERVALS=1 # Set format of NEWS -old_NEWS_hash := d41d8cd98f00b204e9800998ecf8427e +old_NEWS_hash := c7c9fc43ba42057e4f8bd593a0c2e086 manual_title = Portable Dynamic Shared Object Management hooks/post-receive -- GNU Libtool
[SCM] GNU Libtool annotated tag, v2.4.2.418, created. v2.4.2.418
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project GNU Libtool. The annotated tag, v2.4.2.418 has been created at 8ce3ae0ad103366fbc2511b55f8a174f1975937a (tag) tagging 4427784fe74e8f18c781d62624a0adb647893849 (commit) replaces v2.4.2 tagged by Gary V. Vaughan on Sun Oct 27 11:52:43 2013 +1300 - Log - libtool 2.4.2.418 -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) iEYEABECAAYFAlJsR7sACgkQFRMICSmD1gaN+gCfRv2uPNKGjnxawuhiSVwNQtwr x64AoI5coiNyu5XWdXRgI8IHYUIj288A =qwCV -END PGP SIGNATURE- Alan Modra (5): libtool: initial powerpc*le-linux support libtool: fix mangled powerpc*le-linux support patch libtool: refix unmangled powerpc*le-linux support patch libtool: fix refixed unmangled powerpc*le-linux support patch bootstrap: make first char of IFS a space. Andreas Schwab (2): Pass through -g* so that debugging information is not dropped Pass through -g* so that debugging information is not dropped Bernhard Voelker (1): bootstrap: always auto-add .gitignore files at the top. Bob Friesenhahn (1): Fixed func_split_equals shell quoting syntax error encountered with Brad Smith (3): Update/simplify OpenBSD support Update/simplify OpenBSD support libtool: add bitrig support. Brook Moses (1): libtool: improve comments for _LT_ENABLE_LOCK implementation. Brooks Moses (4): * AUTHORS: Add myself to committers list. libtool: Discard -mllvm $arg options when linking. libtool: Fix comment indentation libtool: Remove unneeded quotes in assignment. DJ Delorie (1): libtool: Add TPF settings for LT_SYS_DLOPEN_SELF David 'Digit' Turner (1): libtool: Add Android/Linux support. David Edelsohn (2): AIX PIC shared library support AIX PIC shared library support Fabian Groffen (1): libtool: Fix x86_64-pc-solaris2.* GNU ld breakage Gary V. Vaughan (321): Post-release administrivia. build: avoid spurious bootstrap_edit call. build: compare `revision' rather than `correctver' in Makefile.am. build: avoid unnecessary directory changes in Makefile rules. build: factor Makefile.am `m4sh' invocations to LT_M4SH. build: name temporary files in `Makefile.am' consistently. build: make better use of automatic variables in `Makefile.am'. build: don't hardcode repeated long paths in Makefile rules. build: eliminate `ltmain.in' and `libtoolize.in' intermediate files. build: eliminate superfluous temporary files from `Makefile.am'. maint: simplify and improve safety of bootstrap process. maint: let make employ user's `SED' setting. Makefile: try to be robust against shell meta-chars in filenames. maint: use aux_dir consistently in all files. maint: use macro_dir consistently in all files. CLEANUP: fix error from pushing too far up the branch. maint: DRYing out `Makefile.am' file paths. maint: factor out ltmain.sh variable deletion. maint: pass directory declarations in configure.ac into Makefile. tests: DRYing out `tests/sh.test'. tests: remove unused `aux_dir' variable from `getopt-m4sh.test'. maint: don't run help2man on programs not-yet-built. maint: tidy, sort and consolidate .gitignore files. maint: add gnulib submodule. maint: use gnulib's (pending saner) bootstrap script. maint: use gnulib's canonical COPYING files. maint: use gnulib's canonical fdl.texi. maint: use gnulib's maintainer-makefile module. maint: don't make autobuild a hard bootstrap requirement. tests: ensure VPATH autom4te search path can find autotests. maint: use gnulib's maint.mk and support scripts release procedure. maint: use gnulib's git-version-gen instead of mkstamp. maint: use gnulib's gitlog-to-changelog instead of a ChangeLog file. libtoolize: fix some long-standing sed substitution bugs tests: add a keyword `expensive' to very long running tests. maint: ensure bootstrap runs from dist tarball. maint: add autobuild prerequisite only if autobuild.m4 is absent. build: support AM_SILENT_RULES build: substitute paths into defs.m4sh instead of recalculating. maint: dynamically strip unused scripts from libltdl Makefile. maint: rename the debug shell command variable to `debug_cmd'. libtoolize: fix a scoping bug in func_aclocal_update_check. libtoolize: rename `--subproject' option, and make it work. tests: fix parsing of configure output by pic_flag.at. maint: substitute static directory names. maint: calculate required mkinstalldirs calls during `make install'. tests: prefix absolute directory variables with 'abs_
libtool-2.4.2.418 released [alpha]
Libtoolers! The Libtool Team is pleased to announce the release of libtool 2.4.2.418. This is a preliminary alpha release to begin platform testing in preparation for the next stable release. GNU Libtool hides the complexity of using shared libraries behind a consistent, portable interface. GNU Libtool ships with GNU libltdl, which hides the complexity of loading dynamic runtime libraries (modules) behind a consistent, portable interface. Here are the compressed sources: ftp://alpha.gnu.org/gnu/libtool/libtool-2.4.2.418.tar.gz (1.6MB) ftp://alpha.gnu.org/gnu/libtool/libtool-2.4.2.418.tar.xz (920KB) Here are the GPG detached signatures[*]: ftp://alpha.gnu.org/gnu/libtool/libtool-2.4.2.418.tar.gz.sig ftp://alpha.gnu.org/gnu/libtool/libtool-2.4.2.418.tar.xz.sig Use a mirror for higher download bandwidth: http://www.gnu.org/order/ftp.html [*] Use a .sig file to verify that the corresponding file (without the .sig suffix) is intact. First, be sure to download both the .sig file and the corresponding tarball. Then, run a command like this: gpg --verify libtool-2.4.2.418.tar.gz.sig If that command fails because you don't have the required public key, then run this command to import it: gpg --keyserver keys.gnupg.net --recv-keys 2983D606 and rerun the 'gpg --verify' command. This release was bootstrapped with the following tools: Autoconf 2.69 Automake 1.14 Gnulib 5191b35 NEWS * Noteworthy changes in release 2.4.2.418 (2013-10-27) [alpha] ** New features: - Moved to gnulib release infrastructure. - M4 is now used for scanning the M4 macros in your configure.ac that 'libtoolize' looks at to determine what files you want, and where you would like them installed. This means that you can compose your version number or any other argument that Libtoolize needs to know at M4 time using git-version-gen from gnulib, for example. - Invoking 'libtoolize --ltdl' no longer maintains a separate autoconf macro directory in the libltdl tree, but automatically adjusts the installed libltdl configuration files to share whatever macro directory is declared by the parent project. (Note: if you were already sharing a macro directory with AC_CONFIG_MACRO_DIR(ltdl/m4) or similar, that still works as does any other directory choice). - Invoking 'libtoolize --ltdl' no longer maintains a separate auxiliary scripts directory in the libltdl tree, but automatically adjusts the installed libltdl configuration files to share whatever auxiliary scripts directory is declared by the parent project. (Note: if you were already sharing an auxiliary directory with subproject libltdl using AC_CONFIG_AUX_DIR(ltdl/config) or similar, that still works as does any other directory choice). - The legacy tests have all been migrated to the Autotest harness. - The Autotest testsuite can be run without the especially time consuming tests with: make check-local TESTSUITEFLAGS='-k !expensive' ** Bug fixes: - Fix a long-standing latent bug in autom4te include path for autotests with VPATH builds. - Fix a long-standing latent bug in libtoolize that could delete lines from libltdl/Makefile.am in recursive mode due to underquoting in a sed script. - Fix a long-standing bug in libtoolize, by outputting the 'putting auxiliary files in' header with 'libtoolize --ltdl --subproject'. - Fix a long-standing bug in libtoolize subproject installation, by not installing a set of autoconf macro files into the parent project if there is no configure.ac present to use them. - The libtoolize subproject mode selector is now named '--subproject' and is equivalent to the implied '--subproject' mode when no other mode is selected; '--standalone' never worked, and is no longer accepted. - Libtool and libtoolize no longer choke on paths with a comma in them. - In the case where $SHELL does not have the same enhanced features (e.g. the ability to parse 'var+=append') as $CONFIG_SHELL, libtool will now correctly fallback to using only vanilla shell features instead of failing with a parse at startup. - Correctly recognize import libraries when Microsoft dumpbin is used as the name lister and extend the dumpbin wrapper to find symbols in import libraries using the -headers option of dumpbin. Also fix a bug in the dumpbin wrapper that could lead to broken symbol listings in some corner cases. - Use the improved Microsoft dumpbin support to mend preloading of import libraries for Microsoft Visual C/C++. - No longer mangle module-definition (.def) files when feeding them to the Microsoft Visual C/C++ linker via the -export-symbols argument to the libtool script, thus matching how .def files are handled when using GNU tools. - Recognize more variants (e.g. those starting with a LIBRARY statement) of module-definitions (.def) files when using them instead
Re: Libtool library used but 'LIBTOOL' is undefined
I am not sure I understand you; Here
http://www.mesa3d.org/install.htmlthey say to install in the standard
way: configure-make-make install.
In the attachment you can find all stderr and stdout from configure and
make. configure step is ok while I receive errors during make step.
On Sat, Sep 21, 2013 at 5:15 PM, Robert Boehne rboe...@gmail.com wrote:
Mesa
On Sep 21, 2013 1:21 AM, Giuseppe Aprea giuseppe.ap...@gmail.com
wrote:
Thanks for your answer but I am not sure I understand it. Are you talking
about libtool, automake or mesalib installation?
The file I attached is given by configure+make. More in detail, the
configure works fine while the make steps gives an error.
g
On Fri, Sep 20, 2013 at 6:50 PM, Robert Boehne rboe...@gmail.com wrote:
You seem to have mismatched bits of Makefiles and configure. To
install, you should simply unpack a tar ball and run configure. It looks
like you have regenerated some of these things on an inconsistent way.
HTH,
Robert Boehne
On Sep 20, 2013 10:35 AM, Giuseppe Aprea giuseppe.ap...@gmail.com
wrote:
Hi all,
I have a problem during mesalib installation which seems connected
with libtool. I guess the problem may be due to my environment since I
have automake and libtool installed in non-standard places.
libtool is under ${GLOBAL_PREFIX}/libtool/${LIBTOOL_VERSION}/
(version=2.4.2)
automake is under ${GLOBAL_PREFIX}/automake/${AUTOMAKE_VERSION}
(version=1.12.6)
pkg-config is under ${GLOBAL_PREFIX}/pkg-config/${PKGCONFIG_VERSION}
(version=0.28)
trying to install mesalib under
${GLOBAL_PREFIX}/mesalib/${MESALIB_VERSION},
during make I receive lots of errors like:
src/mesa/drivers/dri/radeon/Makefile.am:42: The usual way to define
'LIBTOOL' is to add 'LT_INIT'
src/mesa/drivers/dri/radeon/Makefile.am:42: to 'configure.ac' and
run 'aclocal' and 'autoconf' again.
src/mesa/drivers/dri/radeon/Makefile.am:42: If 'LT_INIT' is in '
configure.ac', make sure
src/mesa/drivers/dri/radeon/Makefile.am:42: its definition is in
aclocal's search path.
src/mesa/drivers/dri/swrast/Makefile.am:39: error: Libtool library
used but 'LIBTOOL' is undefined
src/mesa/drivers/dri/swrast/Makefile.am:39: The usual way to define
'LIBTOOL' is to add 'LT_INIT'
src/mesa/drivers/dri/swrast/Makefile.am:39: to 'configure.ac' and
run 'aclocal' and 'autoconf' again.
src/mesa/drivers/dri/swrast/Makefile.am:39: If 'LT_INIT' is in '
configure.ac', make sure
src/mesa/drivers/dri/swrast/Makefile.am:39: its definition is in
aclocal's search path.
src/mesa/drivers/osmesa/Makefile.am:35: error: Libtool library used
but 'LIBTOOL' is undefined
src/mesa/drivers/osmesa/Makefile.am:35: The usual way to define
'LIBTOOL' is to add 'LT_INIT'
src/mesa/drivers/osmesa/Makefile.am:35: to 'configure.ac' and run
'aclocal' and 'autoconf' again.
src/mesa/drivers/osmesa/Makefile.am:35: If 'LT_INIT' is in '
configure.ac', make sure
src/mesa/drivers/osmesa/Makefile.am:35: its definition is in
aclocal's search path.
src/mesa/drivers/x11/Makefile.am:35: error: Libtool library used but
'LIBTOOL' is undefined
src/mesa/drivers/x11/Makefile.am:35: The usual way to define
'LIBTOOL' is to add 'LT_INIT'
src/mesa/drivers/x11/Makefile.am:35: to 'configure.ac' and run
'aclocal' and 'autoconf' again.
src/mesa/drivers/x11/Makefile.am:35: If 'LT_INIT' is in 'configure.ac',
make sure
src/mesa/drivers/x11/Makefile.am:35: its definition is in
aclocal'ssearch path.
src/mesa/libdricore/Makefile.am:68: error: Libtool library used but
'LIBTOOL' is undefined
src/mesa/libdricore/Makefile.am:68: The usual way to define
'LIBTOOL' is to add 'LT_INIT'
src/mesa/libdricore/Makefile.am:68: to 'configure.ac' and run
'aclocal' and 'autoconf' again.
src/mesa/libdricore/Makefile.am:68: If 'LT_INIT' is in 'configure.ac',
make sure
src/mesa/libdricore/Makefile.am:68: its definition is in aclocal'ssearch
path.
src/mesa/program/Makefile.am:41: error: Libtool library used but
'LIBTOOL' is undefined
src/mesa/program/Makefile.am:41: The usual way to define 'LIBTOOL'
is to add 'LT_INIT'
src/mesa/program/Makefile.am:41: to 'configure.ac' and run 'aclocal'
and 'autoconf' again.
src/mesa/program/Makefile.am:41: If 'LT_INIT' is in 'configure.ac',
make sure
src/mesa/program/Makefile.am:41: its definition is in aclocal'ssearch
path.
I am working on a cluster where i am supposed to install my stuff as
non-root so I am forced to install in non-standard paths.I defined
ACLOCAL=aclocal -I${GLOBAL_PREFIX}/pkg-config/${PKGCONFIG
_VERSION}/share/aclocal and then run configure and make; complete
output is in attachment.
It seems I need to define LT_INIT in configure.ac but it is already
defined (from configure.ac in root meslib src folder):
LT_PREREQ([2.2])
LT_INIT([disable-static])
I also tried to set LIBTOOL=${GLOBAL_PREFIX}/libtool/${LIBTOOL
_VERSION}/bin/libtool but it didn't help.
I would like to ask if anyone can give
Re: libtool - warnings when installing GMP using DESTDIR
Thanks, Richard. I realize that there are off-the-shelf build tools available - open source and otherwise. (There are also prebuilt toolchains available for many architectures.) Ultimately, I probably will move to using one, and I'll keep Yocto/Poky in mind. Right now, I'm doing things the hard way, mainly as a learning exercise. Thanks again, Michael ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool - warnings when installing GMP using DESTDIR
It just dawned on me... is it that the output from the finish operation the help that the manual refers to? And the ldconfig -n command in the output a suggested command to be run by the SA in order to create the appropriate links? If so, I apologize for being a bit slow on the uptake... just let me know and chalk it up to SUE. Thanks, Michael ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool - warnings when installing GMP using DESTDIR
On Thu, 2013-09-19 at 15:58 -0400, Michael Young wrote: I'm trying to do a staged build/install of libgmp(xx) release 5.1.2. This is part of an effort to develop a general build system (mostly bash scripts, make files, etc.) for toolchains I will be using. I intend to use these scripts to build both native and cross-builds, depending on configuration / arguments, so using DESTDIR for prefixing the install tree is important. Right now, I'm working on native builds on an Ubuntu 12.04 32-bit x86 machine; libtool version = 2.4.2.) I can't help with the libtool issue but there are several build systems out there that already have these issues solves such as the one I work on: http://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs.html which runs on Linux and can build cross compilers targeting the common architectures and the cross compiler itself can run on linux, windows and osx. Cheers, Richard ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool - warnings when installing GMP using DESTDIR
The relinking warning is just to let you know it is linking, it isn't a
potential problem.
Robert Boehne
On Sep 19, 2013 6:21 PM, Michael Young young@gmail.com wrote:
I was originally going to post this to the gmp-discuss list, but after
reviewing
it, it seems like it fits better here. Please kindly redirect me if this
is
better handled elsewhere...
I'm trying to do a staged build/install of libgmp(xx) release 5.1.2. This
is
part of an effort to develop a general build system (mostly bash
scripts, make
files, etc.) for toolchains I will be using. I intend to use these
scripts to
build both native and cross-builds, depending on configuration /
arguments, so
using DESTDIR for prefixing the install tree is important. Right now, I'm
working on native builds on an Ubuntu 12.04 32-bit x86 machine; libtool
version = 2.4.2.)
When building/installing gmp, I use DESTDIR with make install (as follows,
with
the configured prefix being
/home/youngmj/DevTools_3/gmp/Version_5.1.2/gmp__native/install), as
follows:
make install DESTDIR=/home/youngmj/tmp
I get the following warning / output:
***
*snip*
libtool: install: warning: relinking `libgmpxx.la'
libtool: install: (cd
/home/youngmj/tmp/home/youngmj/DevTools_3/gmp/Version_5.1.2/gmp__native/build;
/bin/bash
/home/youngmj/tmp/home/youngmj/DevTools_3/gmp/Version_5.1.2/gmp__native/build/libtool
--tag CXX --mode=relink g++ -version-info 7:2:3 -o libgmpxx.la -rpath
/home/youngmj/DevTools_3/gmp/Version_5.1.2/gmp__native/install/lib dummy.lo
cxx/isfuns.lo cxx/ismpf.lo cxx/ismpq.lo cxx/ismpz.lo cxx/ismpznw.lo
cxx/limits.lo cxx/osdoprnti.lo cxx/osfuns.lo cxx/osmpf.lo cxx/osmpq.lo
cxx/osmpz.lo libgmp.la -inst-prefix-dir /home/youngmj/tmp)
libtool: relink: g++ -fPIC -DPIC -shared -nostdlib
/usr/lib/gcc/i686-linux-gnu/4.6/../../../i386-linux-gnu/crti.o
/usr/lib/gcc/i686-linux-gnu/4.6/crtbeginS.o .libs/dummy.o
cxx/.libs/isfuns.o cxx/.libs/ismpf.o cxx/.libs/ismpq.o cxx/.libs/ismpz.o
cxx/.libs/ismpznw.o cxx/.libs/limits.o cxx/.libs/osdoprnti.o
cxx/.libs/osfuns.o cxx/.libs/osmpf.o cxx/.libs/osmpq.o cxx/.libs/osmpz.o
-Wl,-rpath
-Wl,/home/youngmj/DevTools_3/gmp/Version_5.1.2/gmp__native/install/lib
-L/home/youngmj/tmp/home/youngmj/DevTools_3/gmp/Version_5.1.2/gmp__native/install/lib
-L/home/youngmj/DevTools_3/gmp/Version_5.1.2/gmp__native/install/lib -lgmp
-L/usr/lib/gcc/i686-linux-gnu/4.6
-L/usr/lib/gcc/i686-linux-gnu/4.6/../../../i386-linux-gnu
-L/usr/lib/gcc/i686-linux-gnu/4.6/../../../../lib -L/lib/i386-linux-gnu
-L/lib/../lib -L/usr/lib/i386-linux-gnu -L/usr/lib/../lib -L.
-L/usr/lib/gcc/i686-linux-gnu/4.6/../../.. -lstdc++ -lm -lc -lgcc_s
/usr/lib/gcc/i686-linux-gnu/4.6/crtendS.o
/usr/lib/gcc/i686-linux-gnu/4.6/../../../i386-linux-gnu/crtn.o
-Wl,-soname -Wl,libgmpxx.so.4 -o .libs/libgmpxx.so.4.3.2
libtool: install: /usr/bin/install -c .libs/libgmpxx.so.4.3.2T
/home/youngmj/tmp/home/youngmj/DevTools_3/gmp/Version_5.1.2/gmp__native/install/lib/libgmpxx.so.4.3.2
libtool: install: (cd
/home/youngmj/tmp/home/youngmj/DevTools_3/gmp/Version_5.1.2/gmp__native/install/lib
{ ln -s -f libgmpxx.so.4.3.2 libgmpxx.so.4 || { rm -f libgmpxx.so.4
ln -s libgmpxx.so.4.3.2 libgmpxx.so.4; }; })
libtool: install: (cd
/home/youngmj/tmp/home/youngmj/DevTools_3/gmp/Version_5.1.2/gmp__native/install/lib
{ ln -s -f libgmpxx.so.4.3.2 libgmpxx.so || { rm -f libgmpxx.so ln -s
libgmpxx.so.4.3.2 libgmpxx.so; }; })
libtool: install: /usr/bin/install -c .libs/libgmpxx.lai
/home/youngmj/tmp/home/youngmj/DevTools_3/gmp/Version_5.1.2/gmp__native/install/lib/
libgmpxx.la
libtool: install: /usr/bin/install -c .libs/libgmp.a
/home/youngmj/tmp/home/youngmj/DevTools_3/gmp/Version_5.1.2/gmp__native/install/lib/libgmp.a
libtool: install: chmod 644
/home/youngmj/tmp/home/youngmj/DevTools_3/gmp/Version_5.1.2/gmp__native/install/lib/libgmp.a
libtool: install: ranlib
/home/youngmj/tmp/home/youngmj/DevTools_3/gmp/Version_5.1.2/gmp__native/install/lib/libgmp.a
libtool: install: /usr/bin/install -c .libs/libgmpxx.a
/home/youngmj/tmp/home/youngmj/DevTools_3/gmp/Version_5.1.2/gmp__native/install/lib/libgmpxx.a
libtool: install: chmod 644
/home/youngmj/tmp/home/youngmj/DevTools_3/gmp/Version_5.1.2/gmp__native/install/lib/libgmpxx.a
libtool: install: ranlib
/home/youngmj/tmp/home/youngmj/DevTools_3/gmp/Version_5.1.2/gmp__native/install/lib/libgmpxx.a
libtool: install: warning: remember to run `libtool --finish
/home/youngmj/DevTools_3/gmp/Version_5.1.2/gmp__native/install/lib'
*snip*
[BTW - the T in the .so library version (4th line) looks wierd... can
anyone
verify this is OK?]
The second warning is not the primary problem - I run the finish command
once I
move the installation into place. The first warning (relinking) is what
I'm most
concerned about. I see where the warning is coming from - the following is
in
libgmpxx.la after the build and verification (make check), but prior to
install
Libtool library used but 'LIBTOOL' is undefined
Hi all,
I have a problem during mesalib installation which seems connected with
libtool. I guess the problem may be due to my environment since I have
automake and libtool installed in non-standard places.
libtool is under ${GLOBAL_PREFIX}/libtool/${LIBTOOL_VERSION}/
(version=2.4.2)
automake is under ${GLOBAL_PREFIX}/automake/${AUTOMAKE_VERSION}
(version=1.12.6)
pkg-config is under ${GLOBAL_PREFIX}/pkg-config/${PKGCONFIG_VERSION}
(version=0.28)
trying to install mesalib under ${GLOBAL_PREFIX}/mesalib/${MESALIB_VERSION},
during make I receive lots of errors like:
src/mesa/drivers/dri/radeon/Makefile.am:42: The usual way to define
'LIBTOOL' is to add 'LT_INIT'
src/mesa/drivers/dri/radeon/Makefile.am:42: to 'configure.ac' and run
'aclocal' and 'autoconf' again.
src/mesa/drivers/dri/radeon/Makefile.am:42: If 'LT_INIT' is in '
configure.ac', make sure
src/mesa/drivers/dri/radeon/Makefile.am:42: its definition is in
aclocal'ssearch path.
src/mesa/drivers/dri/swrast/Makefile.am:39: error: Libtool library used but
'LIBTOOL' is undefined
src/mesa/drivers/dri/swrast/Makefile.am:39: The usual way to define
'LIBTOOL' is to add 'LT_INIT'
src/mesa/drivers/dri/swrast/Makefile.am:39: to 'configure.ac' and run
'aclocal' and 'autoconf' again.
src/mesa/drivers/dri/swrast/Makefile.am:39: If 'LT_INIT' is in '
configure.ac', make sure
src/mesa/drivers/dri/swrast/Makefile.am:39: its definition is in
aclocal'ssearch path.
src/mesa/drivers/osmesa/Makefile.am:35: error: Libtool library used but
'LIBTOOL' is undefined
src/mesa/drivers/osmesa/Makefile.am:35: The usual way to define 'LIBTOOL'
is to add 'LT_INIT'
src/mesa/drivers/osmesa/Makefile.am:35: to 'configure.ac' and run
'aclocal' and 'autoconf' again.
src/mesa/drivers/osmesa/Makefile.am:35: If 'LT_INIT' is in 'configure.ac',
make sure
src/mesa/drivers/osmesa/Makefile.am:35: its definition is in
aclocal'ssearch path.
src/mesa/drivers/x11/Makefile.am:35: error: Libtool library used but
'LIBTOOL' is undefined
src/mesa/drivers/x11/Makefile.am:35: The usual way to define 'LIBTOOL' is
to add 'LT_INIT'
src/mesa/drivers/x11/Makefile.am:35: to 'configure.ac' and run 'aclocal'
and 'autoconf' again.
src/mesa/drivers/x11/Makefile.am:35: If 'LT_INIT' is in 'configure.ac',
make sure
src/mesa/drivers/x11/Makefile.am:35: its definition is in
aclocal'ssearch path.
src/mesa/libdricore/Makefile.am:68: error: Libtool library used but
'LIBTOOL' is undefined
src/mesa/libdricore/Makefile.am:68: The usual way to define 'LIBTOOL' is
to add 'LT_INIT'
src/mesa/libdricore/Makefile.am:68: to 'configure.ac' and run 'aclocal'
and 'autoconf' again.
src/mesa/libdricore/Makefile.am:68: If 'LT_INIT' is in 'configure.ac',
make sure
src/mesa/libdricore/Makefile.am:68: its definition is in aclocal's search
path.
src/mesa/program/Makefile.am:41: error: Libtool library used but 'LIBTOOL'
is undefined
src/mesa/program/Makefile.am:41: The usual way to define 'LIBTOOL' is to
add 'LT_INIT'
src/mesa/program/Makefile.am:41: to 'configure.ac' and run 'aclocal' and
'autoconf' again.
src/mesa/program/Makefile.am:41: If 'LT_INIT' is in 'configure.ac', make
sure
src/mesa/program/Makefile.am:41: its definition is in aclocal's search
path.
I am working on a cluster where i am supposed to install my stuff as
non-root so I am forced to install in non-standard paths.I defined ACLOCAL=
aclocal -I${GLOBAL_PREFIX}/pkg-config/${PKGCONFIG_VERSION}/share/aclocal
and then run configure and make; complete output is in attachment.
It seems I need to define LT_INIT in configure.ac but it is already defined
(from configure.ac in root meslib src folder):
LT_PREREQ([2.2])
LT_INIT([disable-static])
I also tried to set LIBTOOL=${GLOBAL_PREFIX}/libtool/${LIBTOOL_VERSION}/bin/
libtool but it didn't help.
I would like to ask if anyone can give me any help, please.
Any suggestion is welcome!
Thanks in advance.
mylog.bz2
Description: BZip2 compressed data
___
https://lists.gnu.org/mailman/listinfo/libtool
