Re: Supporting -export-dynamic on AIX
On Tue, Aug 08, 2006 at 02:58:44PM -0500, Albert Chin wrote:
>
> Another version. Patch against branch-1-5 only. I've reordered where
> --export-dynamic occurs so we don't have to worry about the above.
Our use of both $export_dynamic_symbols_cmds and
$export_dynamic_flag_spec somewhat breaks the "whether a program can
dlopen itself" test:
case $lt_cv_dlopen in
dlopen)
save_CPPFLAGS="$CPPFLAGS"
test "x$ac_cv_header_dlfcn_h" = xyes && CPPFLAGS="$CPPFLAGS -DHAVE_DLFCN_H"
save_LDFLAGS="$LDFLAGS"
wl=$lt_prog_compiler_wl eval LDFLAGS=\"\$LDFLAGS $export_dynamic_flag_spec\"
...
Why? Because we set $export_dynamic_flag_spec to:
_LT_AC_TAGVAR(export_dynamic_flag_spec,
$1)="\${wl}$exp_sym_flag:\$export_symbols"
so, in the above LDFLAGS="$LDFLAGS -Wl,-bexport:". Because -bexport:
requires an argument, we get an error from the linker:
ld: 0706-015 The -b export option needs a parameter.
Option syntax: -b export:PARM
We could make this test pass by creating conftest.exp, setting
export_symbols=conftest.exp, and adding "fnord" to it:
save_LDFLAGS="$LDFLAGS"
echo fnord >conftest.exp
wl=$lt_prog_compiler_wl export_symbols=conftest.exp \
eval LDFLAGS=\"\$LDFLAGS $export_dynamic_flag_spec\"
Should we do this or let it continue failing?
--
albert chin ([EMAIL PROTECTED])
Re: Supporting -export-dynamic on AIX
On Sun, Jul 02, 2006 at 10:58:23PM +0900, Peter O'Gorman wrote:
> On Tue, 2006-06-20 at 12:12 -0500, Albert Chin wrote:
>
> Albert also questioned the documentation:
>
> > On some operating systems, a program symbol must be specially
> > declared
> > in order to be dynamically resolved with the `dlsym' (or equivalent)
> > function.
> >
> > Libtool provides the `-export-dynamic' and `-module' link flags
> > (*note Link mode::), which do this declaration. You need to use
> > these
> > flags if you are linking an application program that dlopens other
> > modules or a libtool library that will also be dlopened.
> >
> > Should the last sentence above end with ", respectively"?
>
> I think this is a documentation bug. -export-dynamic does not imply
> -module, there is a line of code in ltmain that adds dlname to the .la
> file if either -module or -export-dynamic was specified, but this only
> "works" if modules and libraries are otherwise equivalent, so it should
> probably be removed and the documentation adjusted for HEAD, thoughts?
> Either way this patch does not affect that behavior at all.
>
> Here are patches against branch-1-5 and HEAD, okay (with apropriate
> ChangeLog, of course)?
Another version. Patch against branch-1-5 only. I've reordered where
--export-dynamic occurs so we don't have to worry about the above.
--
albert chin ([EMAIL PROTECTED])
Index: libtool.m4
===
RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v
retrieving revision 1.314.2.162
diff -u -p -r1.314.2.162 libtool.m4
--- libtool.m4 3 Aug 2006 14:31:47 - 1.314.2.162
+++ libtool.m4 8 Aug 2006 13:16:45 -
@@ -2911,6 +2911,13 @@ case $host_os in
exp_sym_flag='-bexport'
no_entry_flag='-bnoentry'
+
+ if $NM -V 2>&1 | grep 'GNU' > /dev/null; then
+ _LT_AC_TAGVAR(export_dynamic_symbols_cmds, $1)='$NM -Bpg $objs $libobjs
$old_deplibs $old_convenience | awk '\''{ if (((\[$]2 == "T") || (\[$]2 == "D")
|| (\[$]2 == "B")) && ([substr](\[$]3,1,1) != ".")) { print \[$]3 } }'\'' |
sort -u > $export_symbols'
+ else
+ _LT_AC_TAGVAR(export_dynamic_symbols_cmds, $1)='$NM -BCpg $objs
$libobjs $old_deplibs $old_convenience | awk '\''{ if (((\[$]2 == "T") ||
(\[$]2 == "D") || (\[$]2 == "B")) && ([substr](\[$]3,1,1) != ".")) { print
\[$]3 } }'\'' | sort -u > $export_symbols'
+ fi
+ _LT_AC_TAGVAR(export_dynamic_flag_spec,
$1)="\${wl}$exp_sym_flag:\$export_symbols"
fi
# When large executables or shared objects are built, AIX ld can
@@ -3974,6 +3981,7 @@ _LT_AC_TAGVAR(archive_cmds_need_lc, $1)=
_LT_AC_TAGVAR(allow_undefined_flag, $1)=
_LT_AC_TAGVAR(always_export_symbols, $1)=no
_LT_AC_TAGVAR(archive_expsym_cmds, $1)=
+_LT_AC_TAGVAR(export_dynamic_symbols_cmds, $1)=
_LT_AC_TAGVAR(export_dynamic_flag_spec, $1)=
_LT_AC_TAGVAR(hardcode_direct, $1)=no
_LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)=
@@ -4209,6 +4217,7 @@ if test -f "$ltmain"; then
_LT_AC_TAGVAR(lt_prog_compiler_pic, $1) \
_LT_AC_TAGVAR(lt_prog_compiler_static, $1) \
_LT_AC_TAGVAR(lt_prog_compiler_no_builtin_flag, $1) \
+_LT_AC_TAGVAR(export_dynamic_symbols_cmds, $1) \
_LT_AC_TAGVAR(export_dynamic_flag_spec, $1) \
_LT_AC_TAGVAR(thread_safe_flag_spec, $1) \
_LT_AC_TAGVAR(whole_archive_flag_spec, $1) \
@@ -4243,6 +4252,7 @@ if test -f "$ltmain"; then
_LT_AC_TAGVAR(old_archive_from_new_cmds, $1) | \
_LT_AC_TAGVAR(archive_cmds, $1) | \
_LT_AC_TAGVAR(archive_expsym_cmds, $1) | \
+_LT_AC_TAGVAR(export_dynamic_symbols_cmds, $1) | \
_LT_AC_TAGVAR(module_cmds, $1) | \
_LT_AC_TAGVAR(module_expsym_cmds, $1) | \
_LT_AC_TAGVAR(old_archive_from_expsyms_cmds, $1) | \
@@ -4455,6 +4465,7 @@ link_static_flag=$lt_[]_LT_AC_TAGVAR(lt_
no_builtin_flag=$lt_[]_LT_AC_TAGVAR(lt_prog_compiler_no_builtin_flag, $1)
# Compiler flag to allow reflexive dlopens.
+export_dynamic_symbols_cmds=$lt_[]_LT_AC_TAGVAR(export_dynamic_symbols_cmds,
$1)
export_dynamic_flag_spec=$lt_[]_LT_AC_TAGVAR(export_dynamic_flag_spec, $1)
# Compiler flag to generate shared objects directly from archives.
@@ -5480,6 +5491,7 @@ ifelse([$1],[CXX],[
_LT_AC_TAGVAR(archive_expsym_cmds, $1)=
_LT_AC_TAGVAR(old_archive_From_new_cmds, $1)=
_LT_AC_TAGVAR(old_archive_from_expsyms_cmds, $1)=
+ _LT_AC_TAGVAR(export_dynamic_symbols_cmds, $1)=
_LT_AC_TAGVAR(export_dynamic_flag_spec, $1)=
_LT_AC_TAGVAR(whole_archive_flag_spec, $1)=
_LT_AC_TAGVAR(thread_safe_flag_spec, $1)=
@@ -5
Re: Support -library=stlport4 with Sun C++ compiler
On Thu, Aug 03, 2006 at 11:44:17PM +0900, Peter O'Gorman wrote: > > I just applied Ralf's patches, then saw this. It's okay with me as > is, do you insist on the variable name change? I can see the value, > but am tired of applying patches for this :) No, I don't insist. As long as it works. -- albert chin ([EMAIL PROTECTED])
Re: Support -library=stlport4 with Sun C++ compiler
On Thu, Aug 03, 2006 at 02:50:31PM +0200, Ralf Menzel wrote: > Albert Chin <[EMAIL PROTECTED]> writes: > > Good catch. Updated patch attached. > > > > 2006-08-01 Albert Chin <[EMAIL PROTECTED]> > > > > * libtool.m4 (AC_LIBTOOL_POSTDEP_PREDEP) [ solaris ]: > > Don't set $postdeps to "-lCstd -lCrun" if > > "-library=stlport4" set in CXXFLAGS as stlport4 C++ > > library incompatible with Cstd C++ library. Use > > '-library=Cstd -library=Crun' instead of '-lCstd -lCrun'. > > > > 2006-08-01 Albert Chin <[EMAIL PROTECTED]> > > > > * libltdl/m4/libtool.m4 (_LT_SYS_HIDDEN_LIBDEPS) [ solaris ]: > > Don't set $postdeps to "-lCstd -lCrun" if > > "-library=stlport4" set in CXXFLAGS as stlport4 C++ > > library incompatible with Cstd C++ library. Use > > '-library=Cstd -library=Crun' instead of '-lCstd -lCrun'. > > I found some problems with the patches: > > 1. In the patch for libtool-HEAD the 'for ... do' line is superflous. > > 2. _LT_AC_TAGVAR doesn't seem to work with libtool-HEAD. I used >_LT_TAGVAR, which seems to work. > > 3. In libtool-HEAD the patch addresses the Sun C compiler for Linux >and not for Solaris, while the patch for libtool-1-5 addresses the >Solaris compiler and ignores the linux version. > > The following patches seem to work for me: Good catch. I should have tested the new patches! Updated patches attached. 2006-08-03 Albert Chin <[EMAIL PROTECTED]> * libltdl/m4/libtool.m4 (_LT_SYS_HIDDEN_LIBDEPS) [ linux, solaris ]: Remove unterminated for loop from last patch; change variable name from $solaris_use_stlport4 to $suncpp_use_stlport4 as Sun C++ on GNU/Linux might need this feature as well; add -library=stlport4 to solaris section as well. 2006-08-03 Albert Chin <[EMAIL PROTECTED]> * libtool.m4 (AC_LIBTOOL_POSTDEP_PREDEP) [ linux, solaris ]: Change variable name from $solaris_use_stlport4 to $suncpp_use_stlport4 as Sun C++ on GNU/Linux might need this feature as well; add -library=stlport4 to linux section as well. -- albert chin ([EMAIL PROTECTED]) Index: libtool.m4 === RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v retrieving revision 1.314.2.161 diff -u -p -r1.314.2.161 libtool.m4 --- libtool.m4 2 Aug 2006 13:35:37 - 1.314.2.161 +++ libtool.m4 3 Aug 2006 13:45:30 - @@ -3913,7 +3920,23 @@ linux*) case `$CC -V 2>&1 | sed 5q` in *Sun\ C*) # Sun C++ 5.9 -_LT_AC_TAGVAR(postdeps,$1)='-lCstd -lCrun' + +# The more standards-conforming stlport4 library is +# incompatible with the Cstd library. Avoid specifying +# it if it's in CXXFLAGS. Ignore libCrun as +# -library=stlport4 depends on it. +case " $CXX $CXXFLAGS " in +*" -library=stlport4 "*) + suncpp_use_stlport4=yes + ;; +esac + +# Adding this requires a known-good setup of shared libraries for +# Sun compiler versions before 5.6, else PIC objects from an old +# archive will be linked into the output, leading to subtle bugs. +if test "$suncpp_use_stlport4" != yes; then + _LT_AC_TAGVAR(postdeps,$1)='-library=Cstd -library=Crun' +fi ;; esac ;; @@ -3927,14 +3950,14 @@ solaris*) # -library=stlport4 depends on it. case " $CXX $CXXFLAGS " in *" -library=stlport4 "*) - solaris_use_stlport4=yes + suncpp_use_stlport4=yes ;; esac # Adding this requires a known-good setup of shared libraries for # Sun compiler versions before 5.6, else PIC objects from an old # archive will be linked into the output, leading to subtle bugs. -if test "$solaris_use_stlport4" != yes; then +if test "$suncpp_use_stlport4" != yes; then _LT_AC_TAGVAR(postdeps,$1)='-library=Cstd -library=Crun' fi ;; Index: libltdl/m4/libtool.m4 === RCS file: /cvsroot/libtool/libtool/libltdl/m4/libtool.m4,v retrieving revision 1.77 diff -u -p -r1.77 libtool.m4 --- libltdl/m4/libtool.m4 2 Aug 2006 13:35:30 - 1.77 +++ libltdl/m4/libtool.m4 3 Aug 2006 13:45:41 - @@ -6343,15 +6343,14 @@ linux*) # incompatible with the Cstd library. Avoid specifying # it if it's in CXXFLAGS. Ignore libCrun as # -library=stlport4 depends on it. -for cc_flag in $CXXFLAGS; do case " $CXX $CXXFLAGS " in *" -library=stlport4 "*) - solaris_use_stlport4=yes + suncpp_use_stlport4=yes
Re: Support -library=stlport4 with Sun C++ compiler
On Tue, Aug 01, 2006 at 02:12:31PM +0900, Peter O'Gorman wrote: > > On Aug 1, 2006, at 1:38 PM, Albert Chin wrote: > > >Sun C++ supports two C++ libraries, -library=Cstd (default), and the > >newer -library=stlport4. They are incompatible. Therefore, libtool's > >use of -lCstd (equivalent to -library=Cstd) should not be assigned to > >$postdeps if -library=stlport4 is in CXXFLAGS. Patch attached. > > > >Patch against branch-1-5 and branch-2.0 attached. > > This makes sense, but branch-2-0 is dead :-) > > Before I apply it though, do we also want to check CXX for - > library=stlport4 ? Someone could do CXX='CC -library=stlport4' and > expect libtool not to add CStd etc. Can't we do > > case" $CXX $CXXFLAGS " in >*" -library=stlport4 "*) solaris_use_stlport4=yes ;; > esac > > To save the loop too? Good catch. Updated patch attached. 2006-08-01 Albert Chin <[EMAIL PROTECTED]> * libtool.m4 (AC_LIBTOOL_POSTDEP_PREDEP) [ solaris ]: Don't set $postdeps to "-lCstd -lCrun" if "-library=stlport4" set in CXXFLAGS as stlport4 C++ library incompatible with Cstd C++ library. Use '-library=Cstd -library=Crun' instead of '-lCstd -lCrun'. 2006-08-01 Albert Chin <[EMAIL PROTECTED]> * libltdl/m4/libtool.m4 (_LT_SYS_HIDDEN_LIBDEPS) [ solaris ]: Don't set $postdeps to "-lCstd -lCrun" if "-library=stlport4" set in CXXFLAGS as stlport4 C++ library incompatible with Cstd C++ library. Use '-library=Cstd -library=Crun' instead of '-lCstd -lCrun'. -- albert chin ([EMAIL PROTECTED]) Index: libtool.m4 === RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v retrieving revision 1.314.2.160 diff -u -p -r1.314.2.160 libtool.m4 --- libtool.m4 28 Jul 2006 16:57:36 - 1.314.2.160 +++ libtool.m4 1 Aug 2006 16:57:51 - @@ -3921,10 +3928,22 @@ linux*) solaris*) case $cc_basename in CC*) +# The more standards-conforming stlport4 library is +# incompatible with the Cstd library. Avoid specifying +# it if it's in CXXFLAGS. Ignore libCrun as +# -library=stlport4 depends on it. +case " $CXX $CXXFLAGS " in +*" -library=stlport4 "*) + solaris_use_stlport4=yes + ;; +esac + # Adding this requires a known-good setup of shared libraries for # Sun compiler versions before 5.6, else PIC objects from an old # archive will be linked into the output, leading to subtle bugs. -_LT_AC_TAGVAR(postdeps,$1)='-lCstd -lCrun' +if test "$solaris_use_stlport4" != yes; then + _LT_AC_TAGVAR(postdeps,$1)='-library=Cstd -library=Crun' +fi ;; esac ;; Index: libltdl/m4/libtool.m4 === RCS file: /cvsroot/libtool/libtool/libltdl/m4/libtool.m4,v retrieving revision 1.76 diff -u -p -r1.76 libtool.m4 --- libltdl/m4/libtool.m4 28 Jul 2006 17:01:05 - 1.76 +++ libltdl/m4/libtool.m4 1 Aug 2006 16:58:11 - @@ -6338,7 +6338,21 @@ linux*) case `$CC -V 2>&1 | sed 5q` in *Sun\ C*) # Sun C++ 5.9 -_LT_TAGVAR(postdeps,$1)='-lCstd -lCrun' + +# The more standards-conforming stlport4 library is +# incompatible with the Cstd library. Avoid specifying +# it if it's in CXXFLAGS. Ignore libCrun as +# -library=stlport4 depends on it. +for cc_flag in $CXXFLAGS; do +case " $CXX $CXXFLAGS " in +*" -library=stlport4 "*) + solaris_use_stlport4=yes + ;; +esac + +if test "$solaris_use_stlport4" != yes; then + _LT_AC_TAGVAR(postdeps,$1)='-library=Cstd -library=Crun' +fi ;; esac ;;
Support -library=stlport4 with Sun C++ compiler
Sun C++ supports two C++ libraries, -library=Cstd (default), and the newer -library=stlport4. They are incompatible. Therefore, libtool's use of -lCstd (equivalent to -library=Cstd) should not be assigned to $postdeps if -library=stlport4 is in CXXFLAGS. Patch attached. Patch against branch-1-5 and branch-2.0 attached. 2006-07-31 Albert Chin <[EMAIL PROTECTED]> * libtool.m4 (AC_LIBTOOL_POSTDEP_PREDEP) [ solaris ]: Don't set $postdeps to "-lCstd -lCrun" if "-library=stlport4" set in CXXFLAGS as stlport4 C++ library incompatible with Cstd C++ library. Use '-library=Cstd -library=Crun' instead of '-lCstd -lCrun'. 2006-07-31 Albert Chin <[EMAIL PROTECTED]> * m4/libtool.m4 (_LT_SYS_HIDDEN_LIBDEPS) [ solaris ]: Don't set $postdeps to "-lCstd -lCrun" if "-library=stlport4" set in CXXFLAGS as stlport4 C++ library incompatible with Cstd C++ library. Use '-library=Cstd -library=Crun' instead of '-lCstd -lCrun'. -- albert chin ([EMAIL PROTECTED]) Index: libtool.m4 === RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v retrieving revision 1.314.2.160 diff -u -p -r1.314.2.160 libtool.m4 --- libtool.m4 28 Jul 2006 16:57:36 - 1.314.2.160 +++ libtool.m4 1 Aug 2006 04:28:45 - @@ -3921,10 +3928,25 @@ linux*) solaris*) case $cc_basename in CC*) +# The more standards-conforming stlport4 library is +# incompatible with the Cstd library. Avoid specifying +# it if it's in CXXFLAGS. Ignore libCrun as +# -library=stlport4 depends on it. +for cc_flag in $CXXFLAGS; do + case $cc_flag in + *-library=stlport4*) + solaris_use_stlport4=yes + break + ;; + esac +done + # Adding this requires a known-good setup of shared libraries for # Sun compiler versions before 5.6, else PIC objects from an old # archive will be linked into the output, leading to subtle bugs. -_LT_AC_TAGVAR(postdeps,$1)='-lCstd -lCrun' +if test "$solaris_use_stlport4" != yes; then + _LT_AC_TAGVAR(postdeps,$1)='-library=Cstd -library=Crun' +fi ;; esac ;; Index: m4/libtool.m4 === RCS file: /cvsroot/libtool/libtool/m4/Attic/libtool.m4,v retrieving revision 1.125.2.76 diff -u -p -r1.125.2.76 libtool.m4 --- m4/libtool.m4 24 Aug 2005 15:05:20 - 1.125.2.76 +++ m4/libtool.m4 1 Aug 2006 04:28:53 - @@ -5919,7 +5919,22 @@ m4_if([$1], [CXX], solaris*) case $cc_basename in CC*) -_LT_TAGVAR(postdeps,$1)='-lCstd -lCrun' +# The more standards-conforming stlport4 library is +# incompatible with the Cstd library. Avoid specifying +# it if it's in CXXFLAGS. Ignore libCrun as +# -library=stlport4 depends on it. +for cc_flag in $CXXFLAGS; do + case $cc_flag in + *-library=stlport4*) + solaris_use_stlport4=yes + break + ;; + esac +done + +if test "$solaris_use_stlport4" != yes; then + _LT_AC_TAGVAR(postdeps,$1)='-library=Cstd -library=Crun' +fi ;; esac esac
Re: Supporting -export-dynamic on AIX
On Sun, Jul 02, 2006 at 10:58:23PM +0900, Peter O'Gorman wrote: > Here are patches against branch-1-5 and HEAD, okay (with apropriate > ChangeLog, of course)? The patch I submitted doesn't work when the command-line length is exceeded so the patch needs a little more work. I'll try to address this soon. -- albert chin ([EMAIL PROTECTED])
Re: TODO Addition
On Mon, Jun 19, 2006 at 07:42:40AM +0200, Ralf Wildenhues wrote: > * Albert Chin wrote on Mon, Jun 19, 2006 at 07:37:00AM CEST: > > Addition to TODO file. Should I expand on why this is needed or is it > > obvious? > > It's obvious why you want this, and why this is needed in many > situations. There are some intricate exceptions, though. > > As to how to realize it: it needs only a slight generalization of my > proposed per-deplib flags patch. > > Also, the in-tree TODO file is hopelessly outdated. Any chance you > could just add this to http://wiki.azazil.net/GnuLibtoolProject/RoadMap > for now? Sure. -- albert chin ([EMAIL PROTECTED])
TODO Addition
Addition to TODO file. Should I expand on why this is needed or is it obvious? -- albert chin ([EMAIL PROTECTED]) -- snip snip Index: TODO === RCS file: /cvsroot/libtool/libtool/TODO,v retrieving revision 1.71 diff -u -p -r1.71 TODO --- TODO3 Dec 2005 17:36:15 - 1.71 +++ TODO19 Jun 2006 05:35:31 - @@ -188,6 +188,8 @@ GNU Libtool * Add caching mechanism. Look at `libtool-cache' from Robert ??gren. +* Preserve the order of the command-line and make changes in-place, + if required. 2.4. libtool autoconf macros
Remove hardcode_libdir_flag_spec_ld for hppa*64*|ia64*
The most recent changelog entry for the 1.5 branch has: 2006-06-12 Ralf Wildenhues <[EMAIL PROTECTED]> * ltmain.in (link mode): Disregard `hardcode_libdir_flag_spec_ld' if we're using `$CC' to link. * libtool.m4 () [ hpux10, hpux11; hppa*64*, ia64* ] : Removed. Reported by Roger While <[EMAIL PROTECTED]>. However, one entry for hardcode_libdir_flag_spec_ld remains (patch below to remove). Did you skip this on purpose? -- albert chin ([EMAIL PROTECTED]) -- snip snip Index: libtool.m4 === RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v retrieving revision 1.314.2.158 diff -u -p -r1.314.2.158 libtool.m4 --- libtool.m4 12 Jun 2006 05:25:26 - 1.314.2.158 +++ libtool.m4 14 Jun 2006 15:45:39 - @@ -6051,7 +6066,6 @@ _LT_EOF case $host_cpu in hppa*64*|ia64*) - _LT_AC_TAGVAR(hardcode_libdir_flag_spec_ld, $1)='+b $libdir' _LT_AC_TAGVAR(hardcode_direct, $1)=no _LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no ;;
Re: HP-UX hppa64 and gcc
On Mon, Jun 12, 2006 at 08:05:45AM +0200, Ralf Wildenhues wrote: > Hi Albert, > > * Albert Chin wrote on Mon, Jun 12, 2006 at 07:37:11AM CEST: > > On Mon, Jun 12, 2006 at 07:25:32AM +0200, Ralf Wildenhues wrote: > > > * Ralf Wildenhues wrote on Thu, Jan 05, 2006 at 02:03:49PM CET: > > > > * Albert Chin wrote on Wed, Jan 04, 2006 at 11:49:35PM CET: > > > > > On Wed, Jan 04, 2006 at 10:19:27AM +0100, Roger While wrote: > > > > > > Libtool 1.5.22 > > > > > > There is a problem on HP-UX 64 bit when using gcc. > > > > > > Problem is at line 3167 in libtool.m4 : > > > > > > _LT_AC_TAGVAR(hardcode_libdir_flag_spec_ld, $1)='+b $libdir' > > > > > > > > > > > > gcc doesn't like that ! > > > > > > We can ditch hardcode_libdir_flag_spec_ld for HP-UX. > > > > > > > > In the C++ case, yes, but for some HP-UX cases we use $LD still. > > > > and we still need to revisit the choice of $CC vs $LD based upon > > > compiler version, not HP-UX version. > > > > Why? For HP-UX 11.00 and above, why would you ever use $LD? > > See this thread: > http://lists.gnu.org/archive/html/bug-libtool/2006-06/msg1.html Wow. That compiler is from June 2000! http://h21007.www2.hp.com/dspp/tech/tech_TechDocumentDetailPage_IDX/1,1701,1255,00.html -- albert chin ([EMAIL PROTECTED])
Re: HP-UX hppa64 and gcc
On Mon, Jun 12, 2006 at 07:25:32AM +0200, Ralf Wildenhues wrote: > * Ralf Wildenhues wrote on Thu, Jan 05, 2006 at 02:03:49PM CET: > > * Albert Chin wrote on Wed, Jan 04, 2006 at 11:49:35PM CET: > > > On Wed, Jan 04, 2006 at 10:19:27AM +0100, Roger While wrote: > > > > Libtool 1.5.22 > > > > There is a problem on HP-UX 64 bit when using gcc. > > > > Problem is at line 3167 in libtool.m4 : > > > > _LT_AC_TAGVAR(hardcode_libdir_flag_spec_ld, $1)='+b $libdir' > > > > > > > > gcc doesn't like that ! > > > > Thank you for the bug report. > > > > > We can ditch hardcode_libdir_flag_spec_ld for HP-UX. > > > > In the C++ case, yes, but for some HP-UX cases we use $LD still. > > Wouldn't a better fix be something like this (not yet tested)? > > Roger, could you try whether this works for you? > > > > Actually, we should just ditch the variable altogether and compute it > > anew from hardcode_libdir_flag_spec by emptying $wl if we decide to link > > with $LD. (Not for branch-1-5, this would change interface.) > > > > and we still need to revisit the choice of $CC vs $LD based upon > compiler version, not HP-UX version. Why? For HP-UX 11.00 and above, why would you ever use $LD? -- albert chin ([EMAIL PROTECTED])
Missed $hardcode_direct_absolute in CXX tag
I missed the addition of $hardcode_direct_absolute for the CXX tag.
2006-05-23 Albert Chin <[EMAIL PROTECTED]>
* libltdl/m4/libtool.m4 (_LT_LANG_CXX_CONFIG)
[ aix4*, aix5*, hpux10*, hpux11* ]: Forgot to add
hardcode_direct_absolute for CXX tag.
--
albert chin ([EMAIL PROTECTED])
-- snip snip
Index: libltdl/m4/libtool.m4
===
RCS file: /cvsroot/libtool/libtool/libltdl/m4/libtool.m4,v
retrieving revision 1.72
diff -u -p -r1.72 libtool.m4
--- libltdl/m4/libtool.m4 18 May 2006 16:32:21 - 1.72
+++ libltdl/m4/libtool.m4 23 May 2006 18:42:33 -
@@ -5308,6 +5308,7 @@ if test "$_lt_caught_CXX_error" != yes;
_LT_TAGVAR(archive_cmds, $1)=''
_LT_TAGVAR(hardcode_direct, $1)=yes
+_LT_TAGVAR(hardcode_direct_absolute, $1)=yes
_LT_TAGVAR(hardcode_libdir_separator, $1)=':'
_LT_TAGVAR(link_all_deplibs, $1)=yes
_LT_TAGVAR(file_list_spec, $1)='${wl}-f,'
@@ -5595,6 +5596,7 @@ if test "$_lt_caught_CXX_error" != yes;
;;
*)
_LT_TAGVAR(hardcode_direct, $1)=yes
+_LT_TAGVAR(hardcode_direct_absolute, $1)=yes
_LT_TAGVAR(hardcode_minus_L, $1)=yes # Not in the search PATH,
# but as the default
# location of the library.
Add $CPPFLAGS $CFLAGS to early-libtool.at
The HP compiler on HP-UX 10.20 doesn't operate in ANSI mode by default. You need to add -Ae to $CFLAGS. However, tests/early-libtool.at assumes the compiler is ANSI-compliant by default. This causes test 37 and 38 to fail on this platform because the .c files compiled require an ANSI compiler. 2005-06-18 Albert Chin-A-Young <[EMAIL PROTECTED]> * tests/early-libtool.at: Pass $CPPFLAGS and $CFLAGS to compiler when compiling for extra flags that might be needed for ANSI-compliance, 64-bit, etc. The environment we compile with should match the environment libtool was compiled with. -- albert chin ([EMAIL PROTECTED]) -- snip snip Index: tests/early-libtool.at === RCS file: /cvsroot/libtool/libtool/tests/early-libtool.at,v retrieving revision 1.7 diff -u -p -r1.7 early-libtool.at --- tests/early-libtool.at 4 Dec 2005 14:48:09 - 1.7 +++ tests/early-libtool.at 18 May 2006 08:38:17 - @@ -44,9 +44,13 @@ EXEEXT = @EXEEXT@ LIBTOOL = @LIBTOOL@ OBJEXT = @OBJEXT@ -COMPILE = $(CC) $(DEFAULT_INCLUDES) -LTCOMPILE = $(LIBTOOL) --mode=compile --tag=CC $(CC) $(DEFAULT_INCLUDES) -LINK = $(LIBTOOL) --mode=link --tag=CC $(CC) -o $@ +CPPFLAGS = @CPPFLAGS@ +CFLAGS = @CFLAGS@ +LDFLAGS = @LDFLAGS@ + +COMPILE = $(CC) $(CPPFLAGS) $(CFLAGS) $(DEFAULT_INCLUDES) +LTCOMPILE = $(LIBTOOL) --mode=compile --tag=CC $(CC) $(CPPFLAGS) $(CFLAGS) $(DEFAULT_INCLUDES) +LINK = $(LIBTOOL) --mode=link --tag=CC $(CC) $(CFLAGS) $(LDFLAGS) -o $@ all: hell$(EXEEXT) @@ -135,10 +139,10 @@ hello (void) _EOF # Prove that we can run libtool from inside configure: -$SHELL ./libtool --mode=compile --tag=CC "$CC" -I. -I$srcdir \ --c -o hello.lo hello.c || exit 1 -$SHELL ./libtool --mode=link --tag=CC "$CC" -o libhello.la \ --rpath /notexist hello.lo || exit 1 +$SHELL ./libtool --mode=compile --tag=CC "$CC" $CPPFLAGS $CFLAGS \ +-I. -I$srcdir -c -o hello.lo hello.c || exit 1 +$SHELL ./libtool --mode=link --tag=CC "$CC" $CFLAGS $LDFLAGS \ +-o libhello.la -rpath /notexist hello.lo || exit 1 AC_CONFIG_FILES([Makefile]) AC_OUTPUT @@ -154,8 +158,12 @@ EXEEXT = @EXEEXT@ LIBTOOL = @LIBTOOL@ OBJEXT = @OBJEXT@ -COMPILE = $(CC) $(DEFAULT_INCLUDES) -LINK = $(LIBTOOL) --mode=link --tag=CC $(CC) -o $@ +CPPFLAGS = @CPPFLAGS@ +CFLAGS = @CFLAGS@ +LDFLAGS = @LDFLAGS@ + +COMPILE = $(CC) $(CPPFLAGS) $(CFLAGS) $(DEFAULT_INCLUDES) +LINK = $(LIBTOOL) --mode=link --tag=CC $(CC) $(CFLAGS) $(LDFLAGS) -o $@ hell$(EXEEXT): main.$(OBJEXT) libhello.la $(LINK) main.$(OBJEXT) libhello.la
Re: Ignore hardcode_direct=yes if results in static lib entry
On Wed, May 17, 2006 at 09:55:42PM +0200, Ralf Wildenhues wrote: > * Albert Chin wrote on Wed, May 17, 2006 at 06:35:06PM CEST: > > On Wed, May 17, 2006 at 05:17:54PM +0200, Ralf Wildenhues wrote: > > > * Gary V. Vaughan wrote on Wed, May 17, 2006 at 05:11:46PM CEST: > > > > Ralf Wildenhues wrote: > > > > >* Albert Chin wrote on Wed, May 17, 2006 at 03:18:09AM CEST: > > > > > > > > > >>The following patch addresses > > > > >>http://lists.gnu.org/archive/html/libtool/2006-04/msg00044.html. I > > > > >>added a new variable, hardcode_direct_static, to indicate if > > > > >>hardcode_direct=yes would hardcode a static library dependency. This > > > > >>impacts HP-UX/PA and AIX. > > > > Thanks. It would be great if you could explain that "static library > > > dependency" does _not_ have to do with static libraries at all -- what > > > a confusing name IMHO! Maybe we should think of a better one. Is that > > > what HP-UX is using in their documentation? > > > > I couldn't find a name for this in the HP documentation so I made > > something up :) However, the output of 'chatr' has 'static' in the > > type of the DT_NEEDED line so that's where I came up with the name. > > OK. So let's name the thingy hardcode_direct_absolute. Ok. > I'm still not convinced this approach is right at all; here's why: > First, there are more bugs in the description: you're not going after > the fact that the absolute DT_NEEDED entry cannot be overridden by > $shlibpath_var, but that the absolute DT_NEEDED entry just isn't > overridden by any other paths, not even DT_RPATH. > > Here's why: it may be possible that the system allows absolute DT_NEEDED > entries, but that shlibpath_overrides_runpath=no. Then you're still out > of luck when trying to "relocate" stuff. But once indirect dependencies > come into play, this issue is still important, because now you don't > only have the runpaths in that library at hand, but also those of the > objects that are already loaded and higher up in the graph. True. > What I'm trying to say: the current description doesn't make it clear > that from a Libtool POV these variables are orthogonal to each other. Ok, so should I contribute a new patch with the rewording? > I actually believe that the absolute DT_NEEDED is actually the > normal case with most of the systems we have hardcode_direct=yes > for; I just need some time to go check and prove that. Then, the > right fix would be to kill this variable again and just reorder the > hardcode methods in ltmain.in. -- albert chin ([EMAIL PROTECTED])
Re: HEAD link-order.at fails when hardcode_direct=yes
On Wed, May 17, 2006 at 04:48:24PM +0200, Ralf Wildenhues wrote: > * Albert Chin wrote on Wed, May 17, 2006 at 02:44:49PM CEST: > > > > + case $hardcode_direct$hardcode_direct_static in > > + yesno) > > +AT_CHECK([if $EGREP relinking stderr; then > > + $EGREP " .*\/new\/lib/libb$shrext_cmds > > .*\/old\/lib/libcee$shrext_cmds" stdout > > + else :; fi], [0], [ignore], [], [echo "wrong link order"]) > > +;; > > You shouldn't grep for $shrext_cmds. It's called *_cmds because it may > contain commands. The right way is to > module=no > eval shared_ext=\"$shrext_cmds\" The patch below fixes this. I skipped it because I knew I wouldn't need it for HP-UX/AIX :) 2006-05-17 Albert Chin <[EMAIL PROTECTED]> Ralf Wildenhues <[EMAIL PROTECTED]> * tests/link-order.at: Don't use $shrext_cmds directly because it might contain commands. -- albert chin ([EMAIL PROTECTED]) -- snip snip Index: tests/link-order.at === RCS file: /cvsroot/libtool/libtool/tests/link-order.at,v retrieving revision 1.10 diff -u -p -r1.10 link-order.at --- tests/link-order.at 17 May 2006 14:28:40 - 1.10 +++ tests/link-order.at 17 May 2006 16:38:15 - @@ -23,6 +23,9 @@ AT_KEYWORDS([libtool]) eval `$LIBTOOL --config | $EGREP '^(hardcode_direct|hardcode_direct_static|shrext_cmds)='` LDFLAGS="$LDFLAGS -no-undefined" +module=no +eval shared_ext=\"$shrext_cmds\" + prefix_old=`pwd`/old prefix_new=`pwd`/new mkdir src $prefix_old $prefix_new $prefix_old/lib $prefix_new/lib @@ -72,7 +75,7 @@ aix* | interix*) ;; # These systems hav case $hardcode_direct$hardcode_direct_static in yesno) AT_CHECK([if $EGREP relinking stderr; then - $EGREP " .*\/new\/lib/libb$shrext_cmds .*\/old\/lib/libcee$shrext_cmds" stdout + $EGREP " .*\/new\/lib/libb$shared_ext .*\/old\/lib/libcee$shared_ext" stdout else :; fi], [0], [ignore], [], [echo "wrong link order"]) ;; *)
Re: Ignore hardcode_direct=yes if results in static lib entry
On Wed, May 17, 2006 at 05:00:04PM +0200, Ralf Wildenhues wrote: > * Albert Chin wrote on Wed, May 17, 2006 at 03:18:09AM CEST: > > The following patch addresses > > http://lists.gnu.org/archive/html/libtool/2006-04/msg00044.html. I > > added a new variable, hardcode_direct_static, to indicate if > > hardcode_direct=yes would hardcode a static library dependency. This > > impacts HP-UX/PA and AIX. > > > > Patch against HEAD. > > Does the testsuite pass with this? Yes. -- albert chin ([EMAIL PROTECTED])
Re: Ignore hardcode_direct=yes if results in static lib entry
On Wed, May 17, 2006 at 05:59:23PM +0200, Ralf Wildenhues wrote: > > > >* Albert Chin wrote on Wed, May 17, 2006 at 03:18:09AM CEST: > > > > > > > >>The following patch addresses > > > >>http://lists.gnu.org/archive/html/libtool/2006-04/msg00044.html. I > > > >>added a new variable, hardcode_direct_static, to indicate if > > > >>hardcode_direct=yes would hardcode a static library dependency. This > > > >>impacts HP-UX/PA and AIX. > > I think this should be set for OpenBSD as well, no? Possibly. OpenBSD does seem to have this problem, from my limited testing. -- albert chin ([EMAIL PROTECTED])
Re: Ignore hardcode_direct=yes if results in static lib entry
On Wed, May 17, 2006 at 05:17:54PM +0200, Ralf Wildenhues wrote: > * Gary V. Vaughan wrote on Wed, May 17, 2006 at 05:11:46PM CEST: > > Ralf Wildenhues wrote: > > >* Albert Chin wrote on Wed, May 17, 2006 at 03:18:09AM CEST: > > > > > >>The following patch addresses > > >>http://lists.gnu.org/archive/html/libtool/2006-04/msg00044.html. I > > >>added a new variable, hardcode_direct_static, to indicate if > > >>hardcode_direct=yes would hardcode a static library dependency. This > > >>impacts HP-UX/PA and AIX. > > > >This patch is missing a documentation update (doc/libtool.texi). > > > > I'll commit one presently. > > Thanks. It would be great if you could explain that "static library > dependency" does _not_ have to do with static libraries at all -- what > a confusing name IMHO! Maybe we should think of a better one. Is that > what HP-UX is using in their documentation? I couldn't find a name for this in the HP documentation so I made something up :) However, the output of 'chatr' has 'static' in the type of the DT_NEEDED line so that's where I came up with the name. -- albert chin ([EMAIL PROTECTED])
Re: HEAD link-order.at fails when hardcode_direct=yes
On Tue, Apr 25, 2006 at 02:55:09PM -0500, Albert Chin wrote: > On systems with hardcode_direct=yes, the following section in > tests/link-order.at will fail: > AT_CHECK([if $EGREP relinking stderr; then > $EGREP ' -L.*\/new\/lib -lb -L.*\/old\/lib -lcee' stdout > else :; fi], [0], [ignore], [], [echo "wrong link order"]) > > Why? Because "-L.*\/new\/lib -lb" will be converted to > .*\/new\/lib/liblb$shrext_cmds. > > Patch attached. Note, the new RE doesn't fully address what you > intended. The original libtool output: > libtool: install: warning: relinking `src/liba.la' > stdout: > libtool: install: (cd /opt/build/libtool/tests/testsuite.dir/14; /bin/sh > /opt/build/libtool/libtool --mode=relink cc -z +O2 +Olit=all +Onofltacc > +Oentrysched +Odataprefetch +Onolimit -no-undefined -o src/liba.la src/a.lo > src/libb.la -L/opt/build/libtool/tests/testsuite.dir/14/old/lib -lcee -rpath > /opt/build/libtool/tests/testsuite.dir/14/new/lib ) > libtool: relink: cc -b -Wl,+h -Wl,liba.sl.0 -Wl,+b > -Wl,/opt/build/libtool/tests/testsuite.dir/14/new/lib -o > src/.libs/liba.sl.0.0 src/.libs/a.o > /opt/build/libtool/tests/testsuite.dir/14/new/lib/libb.sl > -L/opt/build/libtool/tests/testsuite.dir/14/old/lib > /opt/build/libtool/tests/testsuite.dir/14/old/lib/libcee.sl -lc > > Note the link order above is: > /opt/build/libtool/tests/testsuite.dir/14/new/lib/libb.sl > -L/opt/build/libtool/tests/testsuite.dir/14/old/lib > /opt/build/libtool/tests/testsuite.dir/14/old/lib/libcee.sl > rather than what you probably want: > /opt/build/libtool/tests/testsuite.dir/14/new/lib/libb.sl > /opt/build/libtool/tests/testsuite.dir/14/old/lib/libcee.sl > > But the ".*" pattern sucks up the > "-L/opt/build/libtool/tests/testsuite.dir/14/old/lib". Updated patch for new hardcode_direct_static variable: http://lists.gnu.org/archive/html/libtool-patches/2006-05/msg00018.html Patch against HEAD. 2006-05-16 Albert Chin-A-Young <[EMAIL PROTECTED]> * tests/link-order.at: Take hardcode_direct and hardcode_direct_static into consideration when testing link order. -- albert chin ([EMAIL PROTECTED]) -- snip snip Index: tests/link-order.at === RCS file: /cvsroot/libtool/libtool/tests/link-order.at,v retrieving revision 1.9 diff -u -p -r1.9 link-order.at --- tests/link-order.at 5 Feb 2006 09:56:44 - 1.9 +++ tests/link-order.at 17 May 2006 00:58:16 - @@ -20,6 +20,7 @@ AT_SETUP([Link order test.]) AT_KEYWORDS([libtool]) +eval `$LIBTOOL --config | $EGREP '^(hardcode_direct|hardcode_direct_static|shrext_cmds)='` LDFLAGS="$LDFLAGS -no-undefined" prefix_old=`pwd`/old @@ -68,10 +69,18 @@ case $host_os in aix* | interix*) ;; # These systems have different path syntax *) # Do not error if we do not relink (e.g. static-only systems) - AT_CHECK([if $EGREP relinking stderr; then - $EGREP ' -L.*\/new\/lib -lb -L.*\/old\/lib -lcee' stdout - else :; fi], [0], [ignore], [], [echo "wrong link order"]) - ;; + case $hardcode_direct$hardcode_direct_static in + yesno) +AT_CHECK([if $EGREP relinking stderr; then + $EGREP " .*\/new\/lib/libb$shrext_cmds .*\/old\/lib/libcee$shrext_cmds" stdout + else :; fi], [0], [ignore], [], [echo "wrong link order"]) +;; + *) +AT_CHECK([if $EGREP relinking stderr; then + $EGREP " -L.*\/new\/lib -lb -L.*\/old\/lib -lcee" stdout + else :; fi], [0], [ignore], [], [echo "wrong link order"]) +;; + esac esac for i in old new; do
Ignore hardcode_direct=yes if results in static lib entry
The following patch addresses
http://lists.gnu.org/archive/html/libtool/2006-04/msg00044.html. I
added a new variable, hardcode_direct_static, to indicate if
hardcode_direct=yes would hardcode a static library dependency. This
impacts HP-UX/PA and AIX.
Patch against HEAD.
2006-05-16 Albert Chin-A-Young <[EMAIL PROTECTED]>
* libltdl/config/ltmain.m4sh, libltdl/m4/libtool.m4
(_LT_LINKER_SHLIBS, _LT_LANG_CXX_CONFIG, _LT_LANG_F77_CONFIG,
_LT_LANG_FC_CONFIG) [ aix4*, aix5*, hpux10*, hpux11* ]:
Introduce a new variable, hardcode_direct_static, which
would ignore hardcode_direct=yes if the result would create a
static library dependency. Static library dependencies are
immune to $shlibpath_var.
--
albert chin ([EMAIL PROTECTED])
-- snip snip
Index: libltdl/config/ltmain.m4sh
===
RCS file: /cvsroot/libtool/libtool/libltdl/config/ltmain.m4sh,v
retrieving revision 1.43
diff -u -p -r1.43 ltmain.m4sh
--- libltdl/config/ltmain.m4sh 14 May 2006 08:20:11 - 1.43
+++ libltdl/config/ltmain.m4sh 17 May 2006 00:58:16 -
@@ -3832,7 +3832,8 @@ func_mode_link ()
fi
;;
relink)
- if test "$hardcode_direct" = yes; then
+ if test "$hardcode_direct" = yes &&
+test "$hardcode_direct_static" = no; then
add="$dir/$linklib"
elif test "$hardcode_minus_L" = yes; then
add_dir="-L$dir"
@@ -3887,7 +3888,8 @@ func_mode_link ()
add_dir=
add=
# Finalize command for both is simple: just hardcode it.
- if test "$hardcode_direct" = yes; then
+ if test "$hardcode_direct" = yes &&
+ test "$hardcode_direct_static" = no; then
add="$libdir/$linklib"
elif test "$hardcode_minus_L" = yes; then
add_dir="-L$libdir"
Index: libltdl/m4/libtool.m4
===
RCS file: /cvsroot/libtool/libtool/libltdl/m4/libtool.m4,v
retrieving revision 1.65
diff -u -p -r1.65 libtool.m4
--- libltdl/m4/libtool.m4 15 May 2006 16:40:43 - 1.65
+++ libltdl/m4/libtool.m4 17 May 2006 00:58:16 -
@@ -3967,6 +3968,7 @@ m4_if([$1], [CXX], [
_LT_TAGVAR(export_symbols_cmds, $1)='$NM $libobjs $convenience |
$global_symbol_pipe | $SED '\''s/.* //'\'' | sort | uniq > $export_symbols'
_LT_TAGVAR(hardcode_automatic, $1)=no
_LT_TAGVAR(hardcode_direct, $1)=no
+ _LT_TAGVAR(hardcode_direct_static, $1)=no
_LT_TAGVAR(hardcode_libdir_flag_spec, $1)=
_LT_TAGVAR(hardcode_libdir_flag_spec_ld, $1)=
_LT_TAGVAR(hardcode_libdir_separator, $1)=
@@ -4316,6 +4318,7 @@ _LT_EOF
_LT_TAGVAR(archive_cmds, $1)=''
_LT_TAGVAR(hardcode_direct, $1)=yes
+ _LT_TAGVAR(hardcode_direct_static, $1)=yes
_LT_TAGVAR(hardcode_libdir_separator, $1)=':'
_LT_TAGVAR(link_all_deplibs, $1)=yes
_LT_TAGVAR(file_list_spec, $1)='${wl}-f,'
@@ -4561,6 +4564,7 @@ _LT_EOF
_LT_TAGVAR(hardcode_libdir_flag_spec_ld, $1)='+b $libdir'
_LT_TAGVAR(hardcode_libdir_separator, $1)=:
_LT_TAGVAR(hardcode_direct, $1)=yes
+ _LT_TAGVAR(hardcode_direct_static, $1)=yes
_LT_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
# hardcode_minus_L: Not really in the search PATH,
# but as the default location of the library.
@@ -4605,6 +4609,7 @@ _LT_EOF
;;
*)
_LT_TAGVAR(hardcode_direct, $1)=yes
+ _LT_TAGVAR(hardcode_direct_static, $1)=yes
_LT_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
# hardcode_minus_L: Not really in the search PATH,
@@ -4975,6 +4980,11 @@ _LT_TAGDECL([], [hardcode_libdir_separat
_LT_TAGDECL([], [hardcode_direct], [0],
[Set to "yes" if using DIR/libNAME${shared_ext} during linking hardcodes
DIR into the resulting binary])
+_LT_TAGDECL([], [hardcode_direct_static], [0],
+[Set to "yes" if using DIR/libNAME${shared_ext} during linking hardcodes
+DIR into the resulting binary and the resulting library dependency is
+static, impossible to change by setting ${shlibpath_var} if the
+library is relocated])
_LT_TAGDECL([], [hardcode_minus_L], [0],
[Set to "yes" if using the -LDIR flag during linking hardcodes DIR
into the resulting binary])
@@ -5134,6 +5144,7 @@ _LT_TAGVAR(always_export_symbols, $1)=no
_LT_TAGVAR(archive_expsym_cmds, $1)=
_LT_TAGVAR(export_dynamic_flag_spec, $1)=
_LT_TAGVAR(hardcode_direct, $1)=no
+_LT_TAGVAR(hardcode_direct_static, $1)=no
_LT_TAGVAR(hardcode_libdir_flag_spec, $1)=
_LT_TAGVAR(hardcode_libdir_fl
Remove duplicate hardcode_direct=yes for AIX
$hardcode_direct is set twice for AIX.
2006-04-29 Albert Chin-A-Young <[EMAIL PROTECTED]>
* libltdl/m4/libtool.m4 (_LT_LINKER_SHLIBS) [ aix ]:
$hardcode_direct is set twice.
--
albert chin ([EMAIL PROTECTED])
-- snip snip
Index: libltdl/m4/libtool.m4
===
RCS file: /cvsroot/libtool/libtool/libltdl/m4/libtool.m4,v
retrieving revision 1.63
diff -u -p -U14 -r1.63 libtool.m4
--- libltdl/m4/libtool.m4 28 Mar 2006 18:11:28 - 1.63
+++ libltdl/m4/libtool.m4 30 Apr 2006 01:08:30 -
@@ -4283,29 +4284,29 @@ _LT_EOF
_LT_TAGVAR(hardcode_direct, $1)=yes
_LT_TAGVAR(hardcode_libdir_separator, $1)=':'
_LT_TAGVAR(link_all_deplibs, $1)=yes
_LT_TAGVAR(file_list_spec, $1)='${wl}-f,'
if test "$GCC" = yes; then
case $host_os in aix4.[[012]]|aix4.[[012]].*)
# We only want to do this on AIX 4.2 and lower, the check
# below for broken collect2 doesn't work under 4.3+
collect2name=`${CC} -print-prog-name=collect2`
if test -f "$collect2name" &&
strings "$collect2name" | $GREP resolve_lib_name >/dev/null
then
# We have reworked collect2
- _LT_TAGVAR(hardcode_direct, $1)=yes
+ :
else
# We have old collect2
_LT_TAGVAR(hardcode_direct, $1)=unsupported
# It fails to find uninstalled libraries when the uninstalled
# path is not listed in the libpath. Setting hardcode_minus_L
# to unsupported forces relinking
_LT_TAGVAR(hardcode_minus_L, $1)=yes
_LT_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir'
_LT_TAGVAR(hardcode_libdir_separator, $1)=
fi
;;
esac
shared_flag='-shared'
if test "$aix_use_runtimelinking" = yes; then
HEAD link-order.at fails when hardcode_direct=yes
On systems with hardcode_direct=yes, the following section in tests/link-order.at will fail: AT_CHECK([if $EGREP relinking stderr; then $EGREP ' -L.*\/new\/lib -lb -L.*\/old\/lib -lcee' stdout else :; fi], [0], [ignore], [], [echo "wrong link order"]) Why? Because "-L.*\/new\/lib -lb" will be converted to .*\/new\/lib/liblb$shrext_cmds. Patch attached. Note, the new RE doesn't fully address what you intended. The original libtool output: libtool: install: warning: relinking `src/liba.la' stdout: libtool: install: (cd /opt/build/libtool/tests/testsuite.dir/14; /bin/sh /opt/build/libtool/libtool --mode=relink cc -z +O2 +Olit=all +Onofltacc +Oentrysched +Odataprefetch +Onolimit -no-undefined -o src/liba.la src/a.lo src/libb.la -L/opt/build/libtool/tests/testsuite.dir/14/old/lib -lcee -rpath /opt/build/libtool/tests/testsuite.dir/14/new/lib ) libtool: relink: cc -b -Wl,+h -Wl,liba.sl.0 -Wl,+b -Wl,/opt/build/libtool/tests/testsuite.dir/14/new/lib -o src/.libs/liba.sl.0.0 src/.libs/a.o /opt/build/libtool/tests/testsuite.dir/14/new/lib/libb.sl -L/opt/build/libtool/tests/testsuite.dir/14/old/lib /opt/build/libtool/tests/testsuite.dir/14/old/lib/libcee.sl -lc Note the link order above is: /opt/build/libtool/tests/testsuite.dir/14/new/lib/libb.sl -L/opt/build/libtool/tests/testsuite.dir/14/old/lib /opt/build/libtool/tests/testsuite.dir/14/old/lib/libcee.sl rather than what you probably want: /opt/build/libtool/tests/testsuite.dir/14/new/lib/libb.sl /opt/build/libtool/tests/testsuite.dir/14/old/lib/libcee.sl But the ".*" pattern sucks up the "-L/opt/build/libtool/tests/testsuite.dir/14/old/lib". 2006-05-25 Albert Chin-A-Young <[EMAIL PROTECTED]> * tests/link-order.at: Take hardcode_direct into consideration when testing link order. -- albert chin ([EMAIL PROTECTED]) Index: tests/link-order.at === RCS file: /cvsroot/libtool/libtool/tests/link-order.at,v retrieving revision 1.9 diff -u -3 -p -r1.9 link-order.at --- tests/link-order.at 5 Feb 2006 09:56:44 - 1.9 +++ tests/link-order.at 25 Apr 2006 19:51:16 - @@ -20,6 +20,7 @@ AT_SETUP([Link order test.]) AT_KEYWORDS([libtool]) +eval `$LIBTOOL --config | $EGREP '^(hardcode_direct|shrext_cmds)='` LDFLAGS="$LDFLAGS -no-undefined" prefix_old=`pwd`/old @@ -68,10 +69,18 @@ case $host_os in aix* | interix*) ;; # These systems have different path syntax *) # Do not error if we do not relink (e.g. static-only systems) - AT_CHECK([if $EGREP relinking stderr; then - $EGREP ' -L.*\/new\/lib -lb -L.*\/old\/lib -lcee' stdout - else :; fi], [0], [ignore], [], [echo "wrong link order"]) - ;; + case $hardcode_direct in + yes) +AT_CHECK([if $EGREP relinking stderr; then + $EGREP " .*\/new\/lib/libb$shrext_cmds .*\/old\/lib/libcee$shrext_cmds" stdout + else :; fi], [0], [ignore], [], [echo "wrong link order"]) +;; + no) +AT_CHECK([if $EGREP relinking stderr; then + $EGREP " -L.*\/new\/lib -lb -L.*\/old\/lib -lcee" stdout + else :; fi], [0], [ignore], [], [echo "wrong link order"]) +;; + esac esac for i in old new; do
Re: fail.at woes
On Fri, Feb 03, 2006 at 05:39:41PM +0100, Ralf Wildenhues wrote: > fail.at fails on IRIX and AIX: their linkers will warn about duplicate > symbols when creating a shared library, but they will then go on to > happily discard the duplicate definitions and exit with zero. I think Tru64 UNIX does this as well. -- albert chin ([EMAIL PROTECTED])
Re: Solaris whole_archive_flags fixes
On Fri, Feb 03, 2006 at 05:03:35PM +0100, Ralf Wildenhues wrote: > We still did not have whole_archive_flag_spec right for Solaris. > The whole issue is pretty simple to really solve though: no `$wl' > for Solaris cc/CC/f77/f90/f95 compilers, always `-Wl,' for GCC. > > To increase the chance of being correct this time, I have tested > these compilers:[1]. And I have reread most threads of the last 18 > months that dealt with Solaris, to make sure there was no report > that disproved this solution. > > OK to apply to both branches? I guess I should have done more testing with my original patch :) http://lists.gnu.org/archive/html/libtool-patches/2004-02/msg00138.html Good work. Thanks. -- albert chin ([EMAIL PROTECTED])
Re: per-deplib static/dynamic flags
On Wed, Feb 01, 2006 at 05:40:51PM -0600, Bob Friesenhahn wrote:
> On Wed, 1 Feb 2006, Albert Chin wrote:
> >
> >Fine. -Bstatic on Linux means "Do not link against shared libraries."
> >anyway.
>
> Good. GCC uses -B to mean something else. So -Bstatic is a
> linker-only option. It is likely useful to use something new which
> won't be confusing due the different meaning between GCC and ld.
How about -static-only and -shared-only?
Note though that Ralf has -Bstatic defined as:
If @var{output-file} is a program, prefer linking statically
^^
This is not -Bstatic under Linux according to ld(1). If this is what
is intended, then -prefer-static is back :)
--
albert chin ([EMAIL PROTECTED])
Re: per-deplib static/dynamic flags
On Wed, Feb 01, 2006 at 12:47:51AM -0600, Bob Friesenhahn wrote: > On Tue, 31 Jan 2006, Albert Chin wrote: > > >On Mon, Jan 30, 2006 at 10:28:52PM +0100, Ralf Wildenhues wrote: > >>- Should the corresponding libtool flags be named `-Bstatic' resp. > >> `-Bdynamic'? Those were the most common names I could find, but IMHO > >> they are not very self-explanatory for users not used to them. > > > >-prefer-static, -prefer-dynamic/-prefer-shared? The -Bxxx doesn't seem > >similar with current libtool options. > > At least for the static case, I would prefer the link to entirely fail > if a static library is requested but one can not be found. Usually > there is a very important reason to use a static library if it has > specifically been requested. So the wording should not be 'prefer' > for the static case. I agree that the -B syntax does not fit the > style of other libtool options (but does match many linkers). Fine. -Bstatic on Linux means "Do not link against shared libraries." anyway. -- albert chin ([EMAIL PROTECTED])
Re: per-deplib static/dynamic flags
On Mon, Jan 30, 2006 at 10:28:52PM +0100, Ralf Wildenhues wrote: > - Should the corresponding libtool flags be named `-Bstatic' resp. > `-Bdynamic'? Those were the most common names I could find, but IMHO > they are not very self-explanatory for users not used to them. -prefer-static, -prefer-dynamic/-prefer-shared? The -Bxxx doesn't seem similar with current libtool options. -- albert chin ([EMAIL PROTECTED])
Re: FYI: update years
On Wed, Jan 11, 2006 at 06:25:06PM +0100, Ralf Wildenhues wrote: > The other half of the annual change. Applied to HEAD and branch-1-5, > respectively (also fixing some past missing years in branch-1-5). > For those asking about changes to year without other changes: in some > cases we generate `--version' output from this, so it's really needed. > And anyway, we'll likely make changes anyway till the next release; > some other files still needed updates for last year. Isn't this a question of Copyright law, which easily trounces --version? -- albert chin ([EMAIL PROTECTED])
Re: several AIX questions
On Sun, Nov 20, 2005 at 08:08:50PM +0100, Ralf Wildenhues wrote: > 1) This patch from HEAD: > | 2004-09-26 Albert Chin-A-Young <[EMAIL PROTECTED]> > | > | * m4/libtool.m4 (_LT_LINKER_SHLIBS) [aix]: In archive_expsym_cmds, > | move -bnoentry linker option before $compiler_flags to honor any > | possible -e entries in LDFLAGS. > > http://lists.gnu.org/archive/html/libtool-patches/2004-09/msg00321.html > > has been applied to the C case only (and not backported to branch-1-5). > Should it not be for C++ as well? What's the reason for it anyway? http://lists.gnu.org/archive/html/libtool-patches/2004-04/msg00085.html Yes, it should be applied to C++ as well. > Also, should it not also be applied to the ia64 case? Dunno. Don't have access to AIX/IA. > 3) This thing has me stunned (non-rtl case): mdemo-exec on *uninstalled* > modules works, whereas on *installed* ones it fails; reason: we don't > install the .so files. We > ar cru libfoo.a libfoo.so.0 > and then install libfoo.a only. What's the right way to fix this? > Install libfoo.so.0 as well? Is there maybe some root-only trickery > necessary so that the installed .so file isn't necessary (I think not)? Won't the above insert a copy of libfoo.so.0 into libfoo.a? If mdemo-exec isn't linked with -brtl, why wouldn't it find libfoo.a? -- albert chin ([EMAIL PROTECTED])
Link with +nodefaultrpath on HP-UX/IA-64
Addresses the +nodefaultrpath issue raised in
http://lists.gnu.org/archive/html/libtool/2005-11/msg0.html. If a
library is linked and LDFLAGS is set to -L[path] without any +b,
[path] is hard-coded into the library. So, we can either require the
user to set LDFLAGS="-Wl,+nodefaultrpath" or pass +nodefaultrpath by
default when creating shared libraries. This patch applies the latter.
--
albert chin ([EMAIL PROTECTED])
-- snip snip
[HEAD]
2005-11-14 Albert Chin <[EMAIL PROTECTED]>
* libtool.m4 (_LT_LINKER_SHLIBS, _LT_LANG_CXX_CONFIG)
[ hpux11 ]: Pass +nodefaultrpath when linking on ia64*.
Index: libltdl/m4/libtool.m4
===
RCS file: /cvsroot/libtool/libtool/libltdl/m4/libtool.m4,v
retrieving revision 1.43
diff -u -3 -p -r1.43 libtool.m4
--- libltdl/m4/libtool.m4 12 Nov 2005 11:54:13 - 1.43
+++ libltdl/m4/libtool.m4 14 Nov 2005 22:37:14 -
@@ -4394,18 +4395,24 @@ _LT_EOF
hpux11*)
if test "$GCC" = yes -a "$with_gnu_ld" = no; then
case $host_cpu in
- hppa*64*|ia64*)
+ hppa*64*)
_LT_TAGVAR(archive_cmds, $1)='$CC -shared ${wl}+h ${wl}$soname -o
$lib $libobjs $deplibs $compiler_flags'
;;
+ ia64*)
+ _LT_TAGVAR(archive_cmds, $1)='$CC -shared ${wl}+h ${wl}$soname
${wl}+nodefaultrpath -o $lib $libobjs $deplibs $compiler_flags'
+ ;;
*)
_LT_TAGVAR(archive_cmds, $1)='$CC -shared -fPIC ${wl}+h ${wl}$soname
${wl}+b ${wl}$install_libdir -o $lib $libobjs $deplibs $compiler_flags'
;;
esac
else
case $host_cpu in
- hppa*64*|ia64*)
+ hppa*64*)
_LT_TAGVAR(archive_cmds, $1)='$CC -b ${wl}+h ${wl}$soname -o $lib
$libobjs $deplibs $compiler_flags'
;;
+ ia64*)
+ _LT_TAGVAR(archive_cmds, $1)='$CC -b ${wl}+h ${wl}$soname
${wl}+nodefaultrpath -o $lib $libobjs $deplibs $compiler_flags'
+ ;;
*)
_LT_TAGVAR(archive_cmds, $1)='$CC -b ${wl}+h ${wl}$soname ${wl}+b
${wl}$install_libdir -o $lib $libobjs $deplibs $compiler_flags'
;;
@@ -5440,9 +5447,12 @@ if test "$_lt_caught_CXX_error" != yes;
;;
aCC*)
case $host_cpu in
- hppa*64*|ia64*)
+ hppa*64*)
_LT_TAGVAR(archive_cmds, $1)='$CC -b ${wl}+h ${wl}$soname -o
$lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags'
;;
+ ia64*)
+ _LT_TAGVAR(archive_cmds, $1)='$CC -b ${wl}+h ${wl}$soname
${wl}+nodefaultrpath -o $lib $predep_objects $libobjs $deplibs $postdep_objects
$compiler_flags'
+ ;;
*)
_LT_TAGVAR(archive_cmds, $1)='$CC -b ${wl}+h ${wl}$soname
${wl}+b ${wl}$install_libdir -o $lib $predep_objects $libobjs $deplibs
$postdep_objects $compiler_flags'
;;
@@ -5461,8 +5471,11 @@ if test "$_lt_caught_CXX_error" != yes;
if test "$GXX" = yes; then
if test $with_gnu_ld = no; then
case $host_cpu in
- ia64*|hppa*64*)
+ hppa*64*)
_LT_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib -fPIC
${wl}+h ${wl}$soname -o $lib $predep_objects $libobjs $deplibs $postdep_objects
$compiler_flags'
+ ;;
+ ia64*)
+ _LT_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib -fPIC
${wl}+h ${wl}$soname ${wl}+nodefaultrpath -o $lib $predep_objects $libobjs
$deplibs $postdep_objects $compiler_flags'
;;
*)
_LT_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib -fPIC
${wl}+h ${wl}$soname ${wl}+b ${wl}$install_libdir -o $lib $predep_objects
$libobjs $deplibs $postdep_objects $compiler_flags'
[1.5]
2005-11-14 Albert Chin <[EMAIL PROTECTED]>
* libtool.m4 (_LT_AC_LANG_CXX_CONFIG, AC_LIBTOOL_PROG_LD_SHLIBS)
[ hpux11 ]: Pass +nodefaultrpath when linking on ia64*.
Index: libtool.m4
===
RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v
retrieving revision 1.314.2.134
diff -u -3 -p -r1.314.2.134 libtool.m4
--- libtool.m4 13 Nov 2005 19:36:34 - 1.314.2.134
+++ libtool.m4 14 Nov 2005 22:36:34 -
@@ -3153,9 +3153,12 @@ case $host_os in
;;
aCC*)
case $host_cpu in
- hppa*64*|ia64*)
+ hppa*64*)
_LT_AC_TAGVAR(archive_cmds, $1)='$CC -b ${wl}+h ${wl}$soname -o $lib
$predep_objects $libobjs $deplibs $postdep_objects $compiler_flags'
;;
+ ia64*)
+ _LT_AC_TAGVAR(archive_cmds, $1)='$CC -b ${wl}+h ${wl}$soname
${wl}+nodefaultrpath -o $lib $predep_objects $li
Re: On HP-UX 11.x, link with cc, not ld (sync with HEAD)
On Fri, Nov 11, 2005 at 05:52:20PM -0600, Albert Chin wrote:
> On Fri, Nov 11, 2005 at 10:36:08PM +0100, Ralf Wildenhues wrote:
> > > --- libtool.m410 Nov 2005 18:29:38 - 1.314.2.128
> > > +++ libtool.m411 Nov 2005 03:44:03 -
> > > @@ -5792,7 +5792,26 @@ EOF
> > >_LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
> > >;;
> > >
> > > -hpux10* | hpux11*)
> > > +hpux10*)
> > > + if test "$GCC" = yes; then
> >
> > HEAD has here:
> > if test "$GCC" = yes -a "$with_gnu_ld" = no
> >
> > oversight in your backport?
> > (In any case, I'll change the `-a' to `&& test' then, for consistency).
>
> Yep. Anyway, GNU ld doesn't work on HP-UX.
Updated patch attached.
--
albert chin ([EMAIL PROTECTED])
Index: libtool.m4
===
RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v
retrieving revision 1.314.2.131
diff -u -3 -p -r1.314.2.131 libtool.m4
--- libtool.m4 12 Nov 2005 11:54:40 - 1.314.2.131
+++ libtool.m4 12 Nov 2005 15:13:02 -
@@ -5798,7 +5798,26 @@ EOF
_LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
;;
-hpux10* | hpux11*)
+hpux10*)
+ if test "$GCC" = yes -a "$with_gnu_ld" = no; then
+ _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared -fPIC ${wl}+h ${wl}$soname
${wl}+b ${wl}$install_libdir -o $lib $libobjs $deplibs $compiler_flags'
+ else
+ _LT_AC_TAGVAR(archive_cmds, $1)='$LD -b +h $soname +b $install_libdir
-o $lib $libobjs $deplibs $linker_flags'
+ fi
+ if test "$with_gnu_ld" = no; then
+ _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}+b ${wl}$libdir'
+ _LT_AC_TAGVAR(hardcode_libdir_separator, $1)=:
+
+ _LT_AC_TAGVAR(hardcode_direct, $1)=yes
+ _LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
+
+ # hardcode_minus_L: Not really in the search PATH,
+ # but as the default location of the library.
+ _LT_AC_TAGVAR(hardcode_minus_L, $1)=yes
+ fi
+ ;;
+
+hpux11*)
if test "$GCC" = yes -a "$with_gnu_ld" = no; then
case $host_cpu in
hppa*64*|ia64*)
@@ -5811,10 +5830,10 @@ EOF
else
case $host_cpu in
hppa*64*|ia64*)
- _LT_AC_TAGVAR(archive_cmds, $1)='$LD -b +h $soname -o $lib $libobjs
$deplibs $linker_flags'
+ _LT_AC_TAGVAR(archive_cmds, $1)='$CC -b ${wl}+h ${wl}$soname -o $lib
$libobjs $deplibs $compiler_flags'
;;
*)
- _LT_AC_TAGVAR(archive_cmds, $1)='$LD -b +h $soname +b $install_libdir
-o $lib $libobjs $deplibs $linker_flags'
+ _LT_AC_TAGVAR(archive_cmds, $1)='$CC -b ${wl}+h ${wl}$soname ${wl}+b
${wl}$install_libdir -o $lib $libobjs $deplibs $compiler_flags'
;;
esac
fi
Re: On HP-UX 11.x, link with cc, not ld (sync with HEAD)
On Fri, Nov 11, 2005 at 10:36:08PM +0100, Ralf Wildenhues wrote:
> Hi Albert,
>
> * Albert Chin wrote on Fri, Nov 11, 2005 at 04:48:48AM CET:
> >
> > 2005-11-10 Albert Chin-A-Young <[EMAIL PROTECTED]>
> >
> > * libtool.m4 (AC_LIBTOOL_PROG_LD_SHLIBS) [ hpux10 ]:
> > Link with cc rather than ld (backport from HEAD).
>
> This patch is ok with one nit, see below.
>
> Cheers,
> Ralf
>
> > --- libtool.m4 10 Nov 2005 18:29:38 - 1.314.2.128
> > +++ libtool.m4 11 Nov 2005 03:44:03 -
> > @@ -5792,7 +5792,26 @@ EOF
> >_LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
> >;;
> >
> > -hpux10* | hpux11*)
> > +hpux10*)
> > + if test "$GCC" = yes; then
>
> HEAD has here:
> if test "$GCC" = yes -a "$with_gnu_ld" = no
>
> oversight in your backport?
> (In any case, I'll change the `-a' to `&& test' then, for consistency).
Yep. Anyway, GNU ld doesn't work on HP-UX.
Thanks.
--
albert chin ([EMAIL PROTECTED])
On HP-UX 11.x, link with cc, not ld (sync with HEAD)
On HEAD, we link with cc rather than ld on HP-UX 11.x. Backport to
1.5. Dunno why I didn't do this long time ago when I submitted the cc
linking patches for Solaris, IRIX, etc.
2005-11-10 Albert Chin-A-Young <[EMAIL PROTECTED]>
* libtool.m4 (AC_LIBTOOL_PROG_LD_SHLIBS) [ hpux10 ]:
Link with cc rather than ld (backport from HEAD).
--
albert chin ([EMAIL PROTECTED])
Index: libtool.m4
===
RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v
retrieving revision 1.314.2.128
diff -u -3 -p -r1.314.2.128 libtool.m4
--- libtool.m4 10 Nov 2005 18:29:38 - 1.314.2.128
+++ libtool.m4 11 Nov 2005 03:44:03 -
@@ -5792,7 +5792,26 @@ EOF
_LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
;;
-hpux10* | hpux11*)
+hpux10*)
+ if test "$GCC" = yes; then
+ _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared -fPIC ${wl}+h ${wl}$soname
${wl}+b ${wl}$install_libdir -o $lib $libobjs $deplibs $compiler_flags'
+ else
+ _LT_AC_TAGVAR(archive_cmds, $1)='$LD -b +h $soname +b $install_libdir
-o $lib $libobjs $deplibs $linker_flags'
+ fi
+ if test "$with_gnu_ld" = no; then
+ _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}+b ${wl}$libdir'
+ _LT_AC_TAGVAR(hardcode_libdir_separator, $1)=:
+
+ _LT_AC_TAGVAR(hardcode_direct, $1)=yes
+ _LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
+
+ # hardcode_minus_L: Not really in the search PATH,
+ # but as the default location of the library.
+ _LT_AC_TAGVAR(hardcode_minus_L, $1)=yes
+ fi
+ ;;
+
+hpux11*)
if test "$GCC" = yes -a "$with_gnu_ld" = no; then
case $host_cpu in
hppa*64*|ia64*)
@@ -5805,10 +5824,10 @@ EOF
else
case $host_cpu in
hppa*64*|ia64*)
- _LT_AC_TAGVAR(archive_cmds, $1)='$LD -b +h $soname -o $lib $libobjs
$deplibs $linker_flags'
+ _LT_AC_TAGVAR(archive_cmds, $1)='$CC -b ${wl}+h ${wl}$soname -o $lib
$libobjs $deplibs $compiler_flags'
;;
*)
- _LT_AC_TAGVAR(archive_cmds, $1)='$LD -b +h $soname +b $install_libdir
-o $lib $libobjs $deplibs $linker_flags'
+ _LT_AC_TAGVAR(archive_cmds, $1)='$CC -b ${wl}+h ${wl}$soname ${wl}+b
${wl}$install_libdir -o $lib $libobjs $deplibs $compiler_flags'
;;
esac
fi
Re: Sync C++ linking on HEAD with branch-1-5
On Wed, Nov 09, 2005 at 08:23:05PM -0600, Albert Chin wrote: > On Wed, Nov 09, 2005 at 09:51:12PM +0100, Ralf Wildenhues wrote: > > * Albert Chin wrote on Wed, Nov 09, 2005 at 05:11:09PM CET: > > It's hpux10*|hpux11*, and hppa*64*|ia64*, and aCC|g++, right? > > I can vouch for it on hpux11*, hppa*64*, and ia64*, for aCC and g++. > We don't have hpux10* to test it on. Documentation for the old C++ compiler on HP (aCC): http://docs.hp.com/en/1314/options.htm It documents use of '-b' to create a shared library: http://docs.hp.com/en/1314/options.htm#option-b >From this documentation: CAUTION: You must use the aCC command to link your HP aC++ programs and libraries. This ensures that all libraries and other files needed by the linker are available. This URL also documents using aCC to create shared libraries: http://docs.hp.com/en/1314/libs.htm#shlib > Want me to factor out hpux10 like we did for the cc case? Looks like this is not needed. Actually, looking at my patch, it only changes it for hppa*64, ia64*. aCC, on these platforms, is always the correct method to link shared libraries. -- albert chin ([EMAIL PROTECTED])
Re: Sync C++ linking on HEAD with branch-1-5
On Wed, Nov 09, 2005 at 09:51:12PM +0100, Ralf Wildenhues wrote: > * Albert Chin wrote on Wed, Nov 09, 2005 at 05:11:09PM CET: > > When linking C++ libraries/programs, link with the compiler, not the > > linker. Syncs with branch-1-5. > > Erm, I can't see this in branch-1-5. Oops. My fault. It isn't. I was looking at our patched version. > It's hpux10*|hpux11*, and hppa*64*|ia64*, and aCC|g++, right? I can vouch for it on hpux11*, hppa*64*, and ia64*, for aCC and g++. We don't have hpux10* to test it on. > Does something fail without the patch (what)? Should I apply it to > branch-1-5 as well? The recommended way to create shared libraries on HP-UX 11.x with aCC is 'CC -b'. This is a similar change to using 'cc -b' to create shared libraries on HP-UX 11.x rather than ld. Want me to factor out hpux10 like we did for the cc case? -- albert chin ([EMAIL PROTECTED])
Sync C++ linking on HEAD with branch-1-5
When linking C++ libraries/programs, link with the compiler, not the
linker. Syncs with branch-1-5.
--
albert chin ([EMAIL PROTECTED])
-- snip snip
2005-11-09 Albert Chin-A-Young <[EMAIL PROTECTED]>
* libltdl/m4/libtool.m4 (_LT_LANG_CXX_CONFIG): Sync C++
linking on HP-UX with branch-1-5. Use C++ compiler for
linking rather than ld.
Index: libltdl/m4/libtool.m4
===
RCS file: /cvsroot/libtool/libtool/libltdl/m4/libtool.m4,v
retrieving revision 1.36
diff -u -3 -p -r1.36 libtool.m4
--- libltdl/m4/libtool.m4 7 Nov 2005 18:28:25 - 1.36
+++ libltdl/m4/libtool.m4 9 Nov 2005 16:06:29 -
@@ -5429,7 +5430,7 @@ if test "$_lt_caught_CXX_error" != yes;
aCC*)
case $host_cpu in
hppa*64*|ia64*)
- _LT_TAGVAR(archive_cmds, $1)='$LD -b +h $soname -o $lib
$linker_flags $libobjs $deplibs'
+ _LT_TAGVAR(archive_cmds, $1)='$CC -b ${wl}+h ${wl}$soname -o
$lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags'
;;
*)
_LT_TAGVAR(archive_cmds, $1)='$CC -b ${wl}+h ${wl}$soname
${wl}+b ${wl}$install_libdir -o $lib $predep_objects $libobjs $deplibs
$postdep_objects $compiler_flags'
@@ -5450,7 +5451,7 @@ if test "$_lt_caught_CXX_error" != yes;
if test $with_gnu_ld = no; then
case $host_cpu in
ia64*|hppa*64*)
- _LT_TAGVAR(archive_cmds, $1)='$LD -b +h $soname -o $lib
$linker_flags $libobjs $deplibs'
+ _LT_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib -fPIC
${wl}+h ${wl}$soname -o $lib $predep_objects $libobjs $deplibs $postdep_objects
$compiler_flags'
;;
*)
_LT_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib -fPIC
${wl}+h ${wl}$soname ${wl}+b ${wl}$install_libdir -o $lib $predep_objects
$libobjs $deplibs $postdep_objects $compiler_flags'
Re: Fix libtool on HP-UX/IA-64
On Sat, Nov 05, 2005 at 08:34:23AM +0100, Ralf Wildenhues wrote:
> * Albert Chin wrote on Fri, Nov 04, 2005 at 06:15:49PM CET:
> > The following patch fixes libtool-1.5 on HP-UX 11.23/IA-64.
> > 1. If you specify +b and -L, -L doesn't embed the path into
> > DT_RPATH. Hence, removal of hardcode_minus_L=yes.
> > 2. If you specify only -L's without +nodefaultrpath, they are
> > embedded into DT_RPATH.
> > 3. It's just easier to rely on +b throughout, like hppa*64.
> >
> > There is one problem. If a library is created _without_ +b (because it
> > has no dependencies) but -L in LDFLAGS, the paths from -L will get
> > hardcoded into the library. Uck! The fix is to add
> > ${wl}+nodefaultrpath. Should we do this for _every_ library we create
> > on ia64*? I say yes.
>
> I agree. The patch is ok with me. Could you be bothered to
> forward-port to HEAD though? Knowing me, the logic is just a
> tad too nontrivial that I won't mess it up without testing.
> I'll apply to both branches then.
Patch below.
--
albert chin ([EMAIL PROTECTED])
-- snip snip
2005-11-04 Albert Chin-A-Young <[EMAIL PROTECTED]>
* libtool.m4 (_LT_LINKER_SHLIBS, _LT_LANG_CXX_CONFIG):
hardcode_libdir_flag_spec and hardcode_minus_L are the
same for hppa*64 and ia64*. Don't set
hardcode_libdir_flag_spec='-L$libdir' on ia64* because
if you specify +b and -L, +b overrides what is set into
DT_RPATH.
Index: libltdl/m4/libtool.m4
===
RCS file: /cvsroot/libtool/libtool/libltdl/m4/libtool.m4,v
retrieving revision 1.32
diff -u -3 -p -r1.32 libtool.m4
--- libltdl/m4/libtool.m4 1 Nov 2005 16:24:10 - 1.32
+++ libltdl/m4/libtool.m4 5 Nov 2005 17:26:55 -
@@ -4383,25 +4383,15 @@ _LT_EOF
esac
fi
if test "$with_gnu_ld" = no; then
+ _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}+b ${wl}$libdir'
+ _LT_TAGVAR(hardcode_libdir_separator, $1)=:
+
case $host_cpu in
- hppa*64*)
- _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}+b ${wl}$libdir'
- _LT_TAGVAR(hardcode_libdir_separator, $1)=:
+ hppa*64*|ia64*)
_LT_TAGVAR(hardcode_direct, $1)=no
_LT_TAGVAR(hardcode_shlibpath_var, $1)=no
;;
- ia64*)
- _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir'
- _LT_TAGVAR(hardcode_direct, $1)=no
- _LT_TAGVAR(hardcode_shlibpath_var, $1)=no
-
- # hardcode_minus_L: Not really in the search PATH,
- # but as the default location of the library.
- _LT_TAGVAR(hardcode_minus_L, $1)=yes
- ;;
*)
- _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}+b ${wl}$libdir'
- _LT_TAGVAR(hardcode_libdir_separator, $1)=:
_LT_TAGVAR(hardcode_direct, $1)=yes
_LT_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
@@ -5396,32 +5386,21 @@ if test "$_lt_caught_CXX_error" != yes;
hpux10*|hpux11*)
if test $with_gnu_ld = no; then
+ _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}+b ${wl}$libdir'
+ _LT_TAGVAR(hardcode_libdir_separator, $1)=:
+
case $host_cpu in
-hppa*64*)
- _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}+b ${wl}$libdir'
- _LT_TAGVAR(hardcode_libdir_separator, $1)=:
- ;;
-ia64*)
- _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir'
+hppa*64*|ia64*)
;;
*)
- _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}+b ${wl}$libdir'
- _LT_TAGVAR(hardcode_libdir_separator, $1)=:
_LT_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
;;
esac
fi
case $host_cpu in
- hppa*64*)
-_LT_TAGVAR(hardcode_direct, $1)=no
-_LT_TAGVAR(hardcode_shlibpath_var, $1)=no
-;;
- ia64*)
+ hppa*64*|ia64*)
_LT_TAGVAR(hardcode_direct, $1)=no
_LT_TAGVAR(hardcode_shlibpath_var, $1)=no
-_LT_TAGVAR(hardcode_minus_L, $1)=yes # Not in the search PATH,
-# but as the default
-# location of the library.
;;
*)
_LT_TAGVAR(hardcode_direct, $1)=yes
Fix libtool on HP-UX/IA-64
The following patch fixes libtool-1.5 on HP-UX 11.23/IA-64.
1. If you specify +b and -L, -L doesn't embed the path into
DT_RPATH. Hence, removal of hardcode_minus_L=yes.
2. If you specify only -L's without +nodefaultrpath, they are
embedded into DT_RPATH.
3. It's just easier to rely on +b throughout, like hppa*64.
There is one problem. If a library is created _without_ +b (because it
has no dependencies) but -L in LDFLAGS, the paths from -L will get
hardcoded into the library. Uck! The fix is to add
${wl}+nodefaultrpath. Should we do this for _every_ library we create
on ia64*? I say yes. I'll deal with that issue and some others in a
separate patch.
--
albert chin ([EMAIL PROTECTED])
-- snip snip
2005-11-04 Albert Chin-A-Young <[EMAIL PROTECTED]>
* libtool.m4 (AC_LIBTOOL_LANG_CXX_CONFIG,
AC_LIBTOOL_PROG_LD_SHLIBS): hardcode_libdir_flag_spec
and hardcode_minus_L are the same for hppa*64 and
ia64*. Don't set hardcode_libdir_flag_spec='-L$libdir'
on ia64* because if you specify +b and -L, +b overrides
what is set into DT_RPATH.
Index: libtool.m4
===
RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v
retrieving revision 1.314.2.120
diff -u -3 -p -r1.314.2.120 libtool.m4
--- libtool.m4 1 Nov 2005 16:24:58 - 1.314.2.120
+++ libtool.m4 4 Nov 2005 16:46:03 -
@@ -3143,34 +3143,23 @@ case $host_os in
;;
hpux10*|hpux11*)
if test $with_gnu_ld = no; then
+ _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}+b ${wl}$libdir'
+ _LT_AC_TAGVAR(hardcode_libdir_separator, $1)=:
+
case $host_cpu in
- hppa*64*)
- _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}+b ${wl}$libdir'
+ hppa*64*|ia64*)
_LT_AC_TAGVAR(hardcode_libdir_flag_spec_ld, $1)='+b $libdir'
- _LT_AC_TAGVAR(hardcode_libdir_separator, $1)=:
-;;
- ia64*)
- _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir'
;;
*)
- _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}+b ${wl}$libdir'
- _LT_AC_TAGVAR(hardcode_libdir_separator, $1)=:
_LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
;;
esac
fi
case $host_cpu in
-hppa*64*)
+hppa*64*|ia64*)
_LT_AC_TAGVAR(hardcode_direct, $1)=no
_LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
;;
-ia64*)
- _LT_AC_TAGVAR(hardcode_direct, $1)=no
- _LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
- _LT_AC_TAGVAR(hardcode_minus_L, $1)=yes # Not in the search PATH,
- # but as the default
- # location of the library.
- ;;
*)
_LT_AC_TAGVAR(hardcode_direct, $1)=yes
_LT_AC_TAGVAR(hardcode_minus_L, $1)=yes # Not in the search PATH,
@@ -5828,26 +5817,16 @@ EOF
esac
fi
if test "$with_gnu_ld" = no; then
+ _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}+b ${wl}$libdir'
+ _LT_AC_TAGVAR(hardcode_libdir_separator, $1)=:
+
case $host_cpu in
- hppa*64*)
- _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}+b ${wl}$libdir'
+ hppa*64*|ia64*)
_LT_AC_TAGVAR(hardcode_libdir_flag_spec_ld, $1)='+b $libdir'
- _LT_AC_TAGVAR(hardcode_libdir_separator, $1)=:
- _LT_AC_TAGVAR(hardcode_direct, $1)=no
- _LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
- ;;
- ia64*)
- _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir'
_LT_AC_TAGVAR(hardcode_direct, $1)=no
_LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
-
- # hardcode_minus_L: Not really in the search PATH,
- # but as the default location of the library.
- _LT_AC_TAGVAR(hardcode_minus_L, $1)=yes
;;
*)
- _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}+b ${wl}$libdir'
- _LT_AC_TAGVAR(hardcode_libdir_separator, $1)=:
_LT_AC_TAGVAR(hardcode_direct, $1)=yes
_LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
Re: SCO/bugfix patch 5 of 10: ltmain.in: exclude -lc on SCO platforms
On Fri, Nov 04, 2005 at 05:56:24PM +0100, Ralf Wildenhues wrote: > Hi Tim, Kean, > > * Tim Rice wrote on Thu, Nov 03, 2005 at 05:25:02PM CET: > > On Sun, 30 Oct 2005, Kean Johnston wrote: > > >Kean Johnston wrote: > > >> Patch 5 of 10 attached ... > > > > > >Tim caught a small ommission. A corrected patch is attached. > > Hmm. We're pretty wary of adding system-specifics to ltmain, and I do > agree with Albert that this ugly. OTOH, I do see the given negative > consequences, too. They are rather unacceptable. > > Is gettext the only package that exposes this? Could you be bothered > to write a bug report (or have already done so)? Well, Tim said we do it for other platforms so I say we accept the patch: *-*-os2*) # These systems don't actually have a C library (as such) test "X$arg" = "X-lc" && continue ;; -- albert chin ([EMAIL PROTECTED])
Remove duplicate settion of archive_expsym_cmds=yes on AIX
always_export_symbols is set before the if statement enclosing the
code below so remove duplicates.
Patch against branch-1-5.
2005-10-30 Albert Chin-A-Young <[EMAIL PROTECTED]>
* libtool.m4 (AC_LIBTOOL_LANG_CXX_CONFIG,
AC_LIBTOOL_PROG_LD_SHLIBS): Remove duplicate
always_export_symbols=yes for AIX.
--
albert chin ([EMAIL PROTECTED])
-- snip snip
Index: libtool.m4
===
RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v
retrieving revision 1.314.2.115
diff -u -3 -p -r1.314.2.115 libtool.m4
--- libtool.m4 9 Oct 2005 06:26:21 - 1.314.2.115
+++ libtool.m4 31 Oct 2005 06:13:28 -
@@ -2930,8 +2930,6 @@ case $host_os in
# -berok will link without error, but may produce a broken library.
_LT_AC_TAGVAR(no_undefined_flag, $1)=' ${wl}-bernotok'
_LT_AC_TAGVAR(allow_undefined_flag, $1)=' ${wl}-berok'
- # -bexpall does not export symbols beginning with underscore (_)
- _LT_AC_TAGVAR(always_export_symbols, $1)=yes
# Exported symbols can be pulled into shared objects from archives
_LT_AC_TAGVAR(whole_archive_flag_spec, $1)=' '
_LT_AC_TAGVAR(archive_cmds_need_lc, $1)=yes
@@ -5626,8 +5624,6 @@ EOF
# -berok will link without error, but may produce a broken library.
_LT_AC_TAGVAR(no_undefined_flag, $1)=' ${wl}-bernotok'
_LT_AC_TAGVAR(allow_undefined_flag, $1)=' ${wl}-berok'
- # -bexpall does not export symbols beginning with underscore (_)
- _LT_AC_TAGVAR(always_export_symbols, $1)=yes
# Exported symbols can be pulled into shared objects from archives
_LT_AC_TAGVAR(whole_archive_flag_spec, $1)=' '
_LT_AC_TAGVAR(archive_cmds_need_lc, $1)=yes
Re: bootstrap warning
On Fri, Oct 28, 2005 at 10:05:07AM +0200, Ralf Wildenhues wrote: > * Albert Chin wrote on Thu, Oct 27, 2005 at 11:56:31PM CEST: > > On Wed, Oct 26, 2005 at 06:55:11AM -0600, Eric Blake wrote: > > > > > > - diff vcl.tmp $(srcdir)/stamp-vcl >/dev/null \ > > > + diff vcl.tmp $(srcdir)/stamp-vcl >/dev/null 2>/dev/null \ > > > > Rather than ">/dev/null 2>/dev/null", use ">/dev/null 2>&1". > > Yep, will change on my next commit. > Curious though, is there a non-asthetical reason to do this? No. -- albert chin ([EMAIL PROTECTED])
Re: bootstrap warning
On Wed, Oct 26, 2005 at 06:55:11AM -0600, Eric Blake wrote: > --- Makefile.am 26 Oct 2005 10:42:02 - 1.173 > +++ Makefile.am 26 Oct 2005 12:50:39 - > @@ -138,7 +138,7 @@ $(srcdir)/stamp-vcl: vcl-tmp clean-ltmai > vcl-tmp: > @set dummy `$(MKSTAMP) < $(srcdir)/ChangeLog`; shift; \ > echo "$$1" > vcl.tmp; \ > - diff vcl.tmp $(srcdir)/stamp-vcl >/dev/null \ > + diff vcl.tmp $(srcdir)/stamp-vcl >/dev/null 2>/dev/null \ > || (echo "Updating stamp-vcl"; cp vcl.tmp $(srcdir)/stamp-vcl) > [EMAIL PROTECTED] -f vcl.tmp Rather than ">/dev/null 2>/dev/null", use ">/dev/null 2>&1". -- albert chin ([EMAIL PROTECTED])
Re: UnixWare -lc fixes
On Mon, Oct 17, 2005 at 09:53:29PM -0700, Tim Rice wrote: > After looking over some stuff in > http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00839.html that related > to libtool and some off list emails with Kean Johnston (the author of > the gcc patch) and Ralf Wildenhues, I realize my UnixWare patch > was incomplete. On UnixWare and OpenServer 5&6 we never want -lc on the > command line. cc / CC takes care of that for us (and always gets it right). > Setting build_libtool_need_lc=no takes care of most of it but that > doesn't account for Makefiles adding -lc. Like this snip from > gettext-0.14.5/gettext-runtime/intl/Makefile.in > .. > libintl.la libgnuintl.la: $(OBJECTS) > $(LIBTOOL) --mode=link \ > $(CC) $(CPPFLAGS) $(CFLAGS) $(XCFLAGS) $(LDFLAGS) -o $@ \ > $(OBJECTS) @LTLIBICONV@ @INTL_MACOSX_LIBS@ $(LIBS) -lc \ > -version-info $(LTV_CURRENT):$(LTV_REVISION):$(LTV_AGE) \ > -rpath $(libdir) \ > -no-undefined > .. > > I had been patching Makefiles (post configure) in packages to strip out -lc. > Now I realize libtool can do that for me. > > I've attached patches to branch-1-5 and HEAD. Ick. Packages like gettext need to be fixed, not libtool. Garbage in = Garbage out. -- albert chin ([EMAIL PROTECTED])
If -xarch passed in, don't set compiler_flags _only_ for GCC
HEAD sets compiler_flags in the code below regardless of whether or not GCC is the compiler. Why does branch-1-5 do it differently? If someone is building a 64-bit library with the Sun C++ compiler, -xarch=v9 won't get passed through and ld will try to create a 32-bit library, resulting in an error. 2005-10-17 Albert Chin-A-Young <[EMAIL PROTECTED]> * ltmain.in: When accepting -64, -mips[0-9], et. al. compiler flags, don't set compiler_flags only for GCC as the vendor compiler also requires this flag. Sync with HEAD. Reported by Donald Anderson <[EMAIL PROTECTED]>. -- albert chin ([EMAIL PROTECTED]) -- snip snip Index: ltmain.in === RCS file: /cvsroot/libtool/libtool/Attic/ltmain.in,v retrieving revision 1.334.2.90 diff -u -3 -p -r1.334.2.90 ltmain.in --- ltmain.in 17 Oct 2005 14:06:26 - 1.334.2.90 +++ ltmain.in 17 Oct 2005 20:57:59 - @@ -1550,9 +1550,7 @@ EOF esac compile_command="$compile_command $arg" finalize_command="$finalize_command $arg" -if test "$with_gcc" = "yes" ; then - compiler_flags="$compiler_flags $arg" -fi +compiler_flags="$compiler_flags $arg" continue ;;
Re: Solaris, combining a bunch of convenience archives
On Wed, Oct 12, 2005 at 09:02:08PM +0200, Ralf Wildenhues wrote: > * Albert Chin wrote on Wed, Oct 12, 2005 at 07:42:21PM CEST: > > On Wed, Oct 12, 2005 at 02:18:28PM +0200, Ralf Wildenhues wrote: > > > Since on Solaris we sometimes use `$CC' for linking though (CVS HEAD > > > uses $CC instead of $LD in this case), this is not sufficient. AFAICS > > > the linker driver fails when all he gets is `-Wl,..' args: > > > > > > $ cc -G -h libfoo.so.0 -o .libs/libfoo.so -Wl,-z > > > -Wl,allextract,.libs/libconv.a -Wl,-z -Wl,defaultextract -ldl -laio -lm > > > -lnsl -lsocket -lc -xarch=v9 -mt > > > usage: cc [ options] files. Use 'cc -flags' for details > > > > I haven't found a good way to persuade the compiler driver to invoke the > > > linker anyway yet.. does anybody have a better idea than going back to > > > linking with $LD (maybe only in the 64bit case)? Any suggestions? > > > > Infer from -xarch=v9? > > I don't understand what you are trying to say with this comment. > I have added `-xarch=v9' to the link line. cc ignores it. > > If I invoke ld directly, I have to add `-64', it does not understand > `-xarch=v9',.. If libtool sees -xarch=v9, it should add -64 to the linker command-line. -- albert chin ([EMAIL PROTECTED])
Re: Solaris, combining a bunch of convenience archives
On Wed, Oct 12, 2005 at 02:18:28PM +0200, Ralf Wildenhues wrote: > Since on Solaris we sometimes use `$CC' for linking though (CVS HEAD > uses $CC instead of $LD in this case), this is not sufficient. AFAICS > the linker driver fails when all he gets is `-Wl,..' args: > > $ cc -G -h libfoo.so.0 -o .libs/libfoo.so -Wl,-z > -Wl,allextract,.libs/libconv.a -Wl,-z -Wl,defaultextract -ldl -laio -lm -lnsl > -lsocket -lc -xarch=v9 -mt > usage: cc [ options] files. Use 'cc -flags' for details > > One workaround for the user would be to add a dummy object to the link > line. > > I haven't found a good way to persuade the compiler driver to invoke the > linker anyway yet.. does anybody have a better idea than going back to > linking with $LD (maybe only in the 64bit case)? Any suggestions? Infer from -xarch=v9? I really don't want to go back to linking with $LD (and, what happens for C++ where you must link with $CC?). -- albert chin ([EMAIL PROTECTED])
Re: FYI: support standalone libltdl [libtool--devo--1.0--patch-221]
On Tue, Aug 23, 2005 at 02:55:17AM +0100, Gary V. Vaughan wrote: > Reorganise the libtool tree to create a bootstrapped libltdl for > installation to the libtoolize master tree, so that libltdl is > useable even in the extreme case of when automake and autoconf are > not installed on the developers machine. Part of this change > requires some duplication of rules between Makefile.am (which > builds libltdl for this distribution) and libltdl/Makefile.am > (which is used by projects that libltoolize --ltdl --copy), so > libtool now really does use a single toplevel Makefile.am, and we > generate libltdl/Makefile.am from that: So the result of this is code under libltdl that has nothing to do with libltdl (ltmain.m4sh, libtool.m4, etc.)? Seems kinda odd. -- albert chin ([EMAIL PROTECTED])
Re: Libtool: Microsoft dumpbin as name lister
On Tue, Aug 23, 2005 at 09:53:58AM +0200, Peter Ekberg wrote:
> Albert Chin wrote:
> > > Running "link /dump" has the same effect as running "dumpbin"; so
> > > perhaps checking for MS Link is enough - if you have identified
> > > the MS linker, you can use it to list symbols (and I imagine
> > > libtool may need to know about the linker anyway).
> >
> > If dumpbin is an alias for "link" with some args, how about scrapping
> > use of dumpbin and replacing with the appropriate "link" command-line?
>
> As the same is true for "lib" == "link -lib" I have had the same
> thought. The problem is that link is most likely shadowed on the
> PATH on Cygwin. So, some care has to be taken to avoid the use
> of the wrong link program.
So, if "link" appears in multiple places in $PATH, we just need to
pick the "correct" one? Libtool does something similar for grep and
sed (i.e. pick the best one in $PATH that supports the longest
command-line).
> I dreamed up something like this:
>
> 1. Check if $CC is cl with a test compile to see if $CC
>defines _MSC_VER, if not bail.
>
> 2. If (first word of) $CC contains / or \, replace last
>path component (should be cl or cl.exe) with "link".
>
> 3. If (first word of) $CC does not contain / or \, use
>which(1) (or, if which should not be used for some reason,
>search the path manually) to locate the full path of
>$CC and replace last path component with "link".
>
> You now have good input for $LD.
>
> : ${NM="$LD -dump -symbols"}
> : ${AR="$LD -lib"}
>
> Any faults in the above? Comments?
Ick. Why not just test all available "link" programs in $PATH for the
features we want and pick the winner?
--
albert chin ([EMAIL PROTECTED])
Re: Libtool: Microsoft dumpbin as name lister
On Mon, Aug 22, 2005 at 03:39:19PM +0200, Tim Van Holder wrote: > FYI, the dumpbin.exe provided by Visual C++ is really just a stub > that calls link.exe (rather like symlinking unzip as zipinfo). > > Running "link /dump" has the same effect as running "dumpbin"; so > perhaps checking for MS Link is enough - if you have identified > the MS linker, you can use it to list symbols (and I imagine > libtool may need to know about the linker anyway). If dumpbin is an alias for "link" with some args, how about scrapping use of dumpbin and replacing with the appropriate "link" command-line? -- albert chin ([EMAIL PROTECTED])
Re: Cope with weird AIX chmod behavior
On Sun, Aug 21, 2005 at 04:21:08PM +0200, Ralf Wildenhues wrote: > This, on an AIX 5.1 below some /tmp-like directory: > > $ ls -ld .. . > drwx--S--- 15 username sys1024 Aug 21 09:01 .. > drwx--S--- 2 username sys 512 Aug 21 09:07 . > $ chmod u+w . > 0481-014 chmod: not all requested changes were made to . > $ chmod u-w . > $ ls -la > dr-x-- 2 username sys 512 Aug 21 09:07 . Works fine on our AIX 5.1 system with v5.1.0.35 of bos.rte.commands (package containing /usr/bin/chmod). > leads to this in configure output: > | checking if xlf supports -c -o file.o... chmod: not all requested changes > were made to . > | yes > > OK to apply this cleanup (all branches)? Does it hurt when we just kill > the g+s (then we would be in more trouble, as there are other places > which do this, too)? Should be ok. Considering our chmod works, it means IBM fixed a bug in it. So, if it's decided that g+s is bad, we could ask the user to upgrade. -- albert chin ([EMAIL PROTECTED])
Re: function-local variables in ltmain
On Tue, Aug 16, 2005 at 12:29:13PM +0100, Gary V. Vaughan wrote: > Ralf Wildenhues wrote: > >* Albert Chin wrote on Sat, Aug 13, 2005 at 09:56:43PM CEST: > > > >>On Sat, Aug 13, 2005 at 10:40:01AM +0200, Ralf Wildenhues wrote: > >> > >>>2) This looks somewhat ugly in the output, but to a certain extent, it > >>>is possible to emulate local variables with m4sh: see below. > >> > >>Way ugly. > > > >Yep. > > That doesn't matter. The output of gcc is ugly too! We should be > maintaining the source files (.m4sh), and anything that makes them > easier to read and edit is a good thing. > > >>Just seems to make libtool harder to maintain. > > Au contraire. Once any such mechanism has been debugged, it makes > libtool easier to maintain... as has been the case with several of the > refactorings I've done as we progress towards 2.0. But debugging libtool occurs with the _generated_ "libtool" script. Making the output sane should help debugging, not hinder it. Is this so much of a problem that we need such a big hammer to solve it? I don't recall seeing enough PRs to consider it. -- albert chin ([EMAIL PROTECTED])
Re: function-local variables in ltmain
On Sat, Aug 13, 2005 at 10:40:01AM +0200, Ralf Wildenhues wrote: > Gary once mentioned a plan to emulate local variables in m4sh. > (Or was it return values? I can't find it now). > > I have two ideas: > 1) Since we do assume the shell has functions, can we maybe also assume >the shell has /some/ way of declaring local variables? >If so, the CONFIG_COMMANDS to generate `libtool' could put it in: > local or > typeset > >Issue may arise if different semantics are employed by different >shells, e.g.: are local visible to functions called, how or whether >to access the global shadowing the local. > >Implicitly, branch-2-0 and HEAD already assume that the positional >parameters are function-local and restored after returning. > > > 2) This looks somewhat ugly in the output, but to a certain extent, it > is possible to emulate local variables with m4sh: see below. Way ugly. Just seems to make libtool harder to maintain. What's the point anyway? To keep function-specific variables from being clobbered? Was this so much of a problem before libtool had functions and everything was global? Seems like a solution looking for a problem. -- albert chin ([EMAIL PROTECTED])
Re: : libtool-1.9f: Added option "quiet" - only errors and warnings go through, now
On Sat, Aug 06, 2005 at 08:31:31AM +0200, Ralf Wildenhues wrote: > Hi Juergen, > > Juergen Leising writes: > >On Tue, Aug 02, 2005 at 05:29:54PM +0200, Ralf Wildenhues wrote: > >>OTOH, there is a different, and IMHO orthogonal component: even with > >>--silent, libtool outputs a little bit of information (which I believe > >>your patch works on as well). The question is: Should we add another > >>option to be completely silent, or maybe just make --silent be > >>completely silent? What do you/the others think? > > >..., exactly, this is what my patch was meant to be about: > >Complete silence. It's really useful when you try and find > >errors in third party software you are not too much familiar > >with. > > I would probably be inclined to accept a patch enforcing complete silence. > Nobody has stepped up to argue whether or not a new switch should be > necessary for this, I am pretty indifferent to this myself. Rather than another switch, how about if --silent is given more than one, libtool becomes "really silent". Kinda like --verbose being given more than once for some programs being more "verbose". -- albert chin ([EMAIL PROTECTED])
Silence errors when expr command-line exceeds command-line length limit
AIX sends messages like "/bin/expr: Arg list too long" to stderr. These should be ignored. Patch attached against CVS head. 2005-08-04 Albert Chin-A-Young <[EMAIL PROTECTED]> * config/ltmain.m4sh: Ignore errors from expr when determining if piece-wise linking should be done. -- albert chin ([EMAIL PROTECTED]) Index: config/ltmain.m4sh === RCS file: /cvsroot/libtool/libtool/config/ltmain.m4sh,v retrieving revision 1.78 diff -u -3 -p -r1.78 ltmain.m4sh --- config/ltmain.m4sh 4 Aug 2005 13:50:18 - 1.78 +++ config/ltmain.m4sh 4 Aug 2005 21:19:18 - @@ -5073,8 +5073,9 @@ EOF fi fi - if test "X$skipped_export" != "X:" && len=`expr "X$test_cmds" : ".*"` && - test "$len" -le "$max_cmd_len" || test "$max_cmd_len" -le -1; then + if test "X$skipped_export" != "X:" && + len=`expr "X$test_cmds" : ".*" 2>/dev/null` && + test "$len" -le "$max_cmd_len" || test "$max_cmd_len" -le -1; then : else # The command line is too long to link in one step, link piecewise @@ -6345,8 +6346,8 @@ fi\ fi eval cmds=\"$old_archive_cmds\" - if len=`expr "X$cmds" : ".*"` && -test "$len" -le "$max_cmd_len" || test "$max_cmd_len" -le -1; then + if len=`expr "X$cmds" : ".*" 2>/dev/null` && + test "$len" -le "$max_cmd_len" || test "$max_cmd_len" -le -1; then cmds=$old_archive_cmds else # the command line is too long to link in one step, link in parts
Re: libtool 2-0-linker-not-compiler.patch
On Fri, Jul 22, 2005 at 10:15:05AM +0200, Peter Ekberg wrote: > 2005-07-21 Peter Ekberg <[EMAIL PROTECTED]> > > * m4/libtool.m4 (_LT_LINKER_OPTION): Fix copy-paste bug, it is > the linker that is tested. Looks good. -- albert chin ([EMAIL PROTECTED])
Re: solaris archive_cmds change for sun CC c++ compiler
On Fri, Jul 22, 2005 at 09:55:13PM +0900, Peter O'Gorman wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Albert Chin wrote:
> | On Fri, Jul 22, 2005 at 12:26:21AM +0900, Peter O'Gorman wrote:
> |
> |>Index: libtool.m4
> |>===
> |>RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v
> |>retrieving revision 1.314.2.96
> |>diff -u -3 -p -u -r1.314.2.96 libtool.m4
> |>--- libtool.m4 8 Jul 2005 15:03:15 - 1.314.2.96
> |>+++ libtool.m4 21 Jul 2005 15:25:42 -
> |>@@ -3475,10 +3475,12 @@ case $host_os in
> |> case $cc_basename in
> |> CC*)
> |># Sun C++ 4.2, 5.x and Centerline C++
> |>+ _LT_AC_TAGVAR(archive_cmds_need_lc,$1)=yes
> |>+ _LT_AC_TAGVAR(postdeps,$1)='-lCstd -lCrun'
> |>_LT_AC_TAGVAR(no_undefined_flag, $1)=' -zdefs'
> |>- _LT_AC_TAGVAR(archive_cmds, $1)='$CC -G${allow_undefined_flag} -nolib
> - -h$soname -o $lib $predep_objects $libobjs $deplibs $postdep_objects
> $compiler_flags'
> |>+ _LT_AC_TAGVAR(archive_cmds, $1)='$CC -G${allow_undefined_flag}
> -h$soname
> - -o $lib $libobjs $deplibs $compiler_flags'
> |>_LT_AC_TAGVAR(archive_expsym_cmds, $1)='$echo "{ global:" >
> $lib.exp~cat
> $export_symbols | $SED -e "s/\(.*\)/\1;/" >> $lib.exp~$echo "local: *; };"
> >>$lib.exp~
> |>- $CC -G${allow_undefined_flag} -nolib ${wl}-M ${wl}$lib.exp -h$soname
> -o
> $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags~$rm
> $lib.exp'
> |>+ $CC -G${allow_undefined_flag} ${wl}-M ${wl}$lib.exp -h$soname -o $lib
> $libobjs $deplibs $compiler_flags~$rm $lib.exp'
> |
> |
> | Why do you remove $predep_objects and $postdep_objects?
>
> Because they are always empty.
Shouldn't that be the focus of a different patch? Maybe
$predep_objects and $postdep_objects are empty for aCC on HP-UX and
cxx on Tru64 UNIX as well? I'd rather see this patch encompass only
the required changes to affect adding -lCstd -lCrun and leave the rest
for another patch where $predep_objects and $postdep_objects would be
removed for all CXX tags. I'd kinda rather them remain as it makes
less difference between the CXX tags.
--
albert chin ([EMAIL PROTECTED])
Re: libtool 2-0-noinst-link-MAKE-instead-of-make.patch
On Fri, Jul 22, 2005 at 10:15:02AM +0200, Peter Ekberg wrote: > 2005-07-21 Peter Ekberg <[EMAIL PROTECTED]> > > * tests/demo-noinst-link.test: $make is empty on MSYS, replace > with $MAKE. Makes the test pass for MinGW. Looks good. -- albert chin ([EMAIL PROTECTED])
Re: libtool 2-0-disable-fortran.patch
On Fri, Jul 22, 2005 at 10:14:56AM +0200, Peter Ekberg wrote: > 2005-07-21 Peter Ekberg <[EMAIL PROTECTED]> > > * m4/libtool.m4 (_LT_PROG_F77): Set it up so that saying F77=: > to configure disables the fortran tests in the testsuite. Ick. Why not just F77=? -- albert chin ([EMAIL PROTECTED])
Re: solaris archive_cmds change for sun CC c++ compiler
On Fri, Jul 22, 2005 at 12:26:21AM +0900, Peter O'Gorman wrote:
> Index: libtool.m4
> ===
> RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v
> retrieving revision 1.314.2.96
> diff -u -3 -p -u -r1.314.2.96 libtool.m4
> --- libtool.m4 8 Jul 2005 15:03:15 - 1.314.2.96
> +++ libtool.m4 21 Jul 2005 15:25:42 -
> @@ -3475,10 +3475,12 @@ case $host_os in
> case $cc_basename in
>CC*)
> # Sun C++ 4.2, 5.x and Centerline C++
> + _LT_AC_TAGVAR(archive_cmds_need_lc,$1)=yes
> + _LT_AC_TAGVAR(postdeps,$1)='-lCstd -lCrun'
> _LT_AC_TAGVAR(no_undefined_flag, $1)=' -zdefs'
> - _LT_AC_TAGVAR(archive_cmds, $1)='$CC -G${allow_undefined_flag} -nolib
> -h$soname -o $lib $predep_objects $libobjs $deplibs $postdep_objects
> $compiler_flags'
> + _LT_AC_TAGVAR(archive_cmds, $1)='$CC -G${allow_undefined_flag}
> -h$soname -o $lib $libobjs $deplibs $compiler_flags'
> _LT_AC_TAGVAR(archive_expsym_cmds, $1)='$echo "{ global:" >
> $lib.exp~cat $export_symbols | $SED -e "s/\(.*\)/\1;/" >> $lib.exp~$echo
> "local: *; };" >> $lib.exp~
> - $CC -G${allow_undefined_flag} -nolib ${wl}-M ${wl}$lib.exp -h$soname -o
> $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags~$rm
> $lib.exp'
> + $CC -G${allow_undefined_flag} ${wl}-M ${wl}$lib.exp -h$soname -o $lib
> $libobjs $deplibs $compiler_flags~$rm $lib.exp'
Why do you remove $predep_objects and $postdep_objects?
--
albert chin ([EMAIL PROTECTED])
Re: solaris archive_cmds change for sun CC c++ compiler
On Fri, Jul 22, 2005 at 12:26:21AM +0900, Peter O'Gorman wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Peter O'Gorman wrote: > | Peter O'Gorman wrote: > | | Albert Chin wrote: > | | | > | | | For -lc, why don't you set archive_cmds_need_lc=yes for the CXX tag > | | | instead of hard-coding it? > > | I was wrong, it would, of course, be better in postdeps. Testing new > | patch now. > > And to reply to myself, yet again. Is this okay with forward ports? Looks ok to me though I haven't tested. -- albert chin ([EMAIL PROTECTED])
Re: solaris archive_cmds change for sun CC c++ compiler
On Tue, Jul 19, 2005 at 01:32:07PM +0900, Peter O'Gorman wrote: > On all versions of sun's compiler that I looked at, using c++ features > (e.g. cout!) requires adding -lCstd -lCrun and -lc to the link line. This > means that any library linking with -no-undefined fails to link properly > with this compiler. I have added these libraries to the archive_cmds. While > I was looking there, I saw an output_verbose_link_cmd that removes all the > objects from the list, thus making it useless, so I removed the -nolib and > set the output_verbose_link_cmd to 'echo'. > > Okay for all branches? (having been suitably changed for 2.0/HEAD, of > course). For -lc, why don't you set archive_cmds_need_lc=yes for the CXX tag instead of hard-coding it? And, why don't you set postdeps='-lCstd -lCrun'? -- albert chin ([EMAIL PROTECTED])
Re: FYI: libtool-1.5.18 -- installed files owned by non-root user
On Fri, Jul 08, 2005 at 06:27:51PM +0100, Gary V. Vaughan wrote: > Hallo Ralf, > > Sorry for the late review: > > On 8 Jul 2005, at 16:57, Ralf Wildenhues wrote: > >2005-07-08 Peter Breitenlohner <[EMAIL PROTECTED]> > > > >* Makefile.am (install-data-local): Have root own of installed > >files (but do not fail, for user installs). > > > >Index: Makefile.am > >=== > >RCS file: /cvsroot/libtool/libtool/Makefile.am,v > >retrieving revision 1.153 > >diff -u -r1.153 Makefile.am > >--- Makefile.am2 May 2005 09:20:24 -1.153 > >+++ Makefile.am8 Jul 2005 15:54:01 - > >@@ -254,6 +254,8 @@ > > done; \ > > ( cd $(srcdir)/m4 && $(AMTAR) chf - $$aclocalfiles; ) \ > > | ( umask 0 && cd $(DESTDIR)$(aclocaldir) && $(AMTAR) xf -; ) > >+chown -R root $(DESTDIR)$(ltdldatadir) && \ > >+chgrp -R root $(DESTDIR)$(ltdldatadir) || : > > What about: > > -chown -R root $(DESTDIR)$(ltdldatadir) 2>/dev/null > -chgrp -R root $(DESTDIR)$(ltdldatadir) 2>/dev/null I like this too. -- albert chin ([EMAIL PROTECTED])
Re: FYI: ksh bug on Tru64 UNIX causes current libtool failure
On Wed, Jul 06, 2005 at 09:46:31PM +0200, Ralf Wildenhues wrote: > * Ralf Wildenhues wrote on Wed, Jul 06, 2005 at 05:08:11AM CEST: > > > > This is a gentle reminder that this issue with Libtool HEAD/branch-2-0 > > on Tru64 sh is still unsolved. It'd be nice to get a solution into the > > next 2.0 release candidate, should such a solution exist. > > Stupid question: Does Tru64 sh need `^' quoted? The one Solaris one > does. I.e., does > echo Xbla | sed 1s,^X,, > work there? (Libtool currently does not quote this consistently.) On Tru64 UNIX 4.0D and 5.1: # /bin/ksh # echo Xbla | sed 1s,^X,, bla -- albert chin ([EMAIL PROTECTED])
Re: [rth@redhat.com: libjava build times]
On Thu, May 05, 2005 at 03:17:26PM +0200, Ralf Wildenhues wrote: > That one still needs testing, but the idea is to kill all quadratic > loops in the func_mode_link initialization: > > Stuff like > compile_command="$compile_command $qarg" > is better written as > $ECHO " $qarg" >&FD_COMPILE_COMMAND > > where FD_COMPILE_COMMAND is a m4 macro which evaluates to a file > descriptor for the file holding the contents of compile_command. > Same for oldobjs and a couple of other iteratively-set parameters. > The desired value is then retrieved quickly by > > compile_command=`$SED 's/^ //' <"$compile_command_file" | $NL2SP` Can you explain how the latter is faster? From inspection, I'd believe the first to be faster. -- albert chin ([EMAIL PROTECTED])
Re: IRIX 6.5 and exporting symbols.
On Wed, Mar 09, 2005 at 02:51:31PM +0100, Ralf Wildenhues wrote: > * Peter Ekberg wrote on Wed, Mar 09, 2005 at 02:11:40PM CET: > > This makes it work for me, the namespace is sadly polluted, > > but there is nothing we can do about that, short of hacking > > the gcc specs file or wait for gcc 3.5/4.0 to be released > > as indicated by this bugzilla entry: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15288 > > We should try to at least enable it for gcc >= 4.0, so Libtool won't > need to change again then. Plus, IRIX ld may have this fixed > eventually; did anyone bother SGI folks about this? We have an SGI support contract. I'll bug them if you want but you need to tell me what to put in the bug report. ld(1) says: -hidden_symbol symbol_list Used in conjunction with the -shared or -call_shared options. Marks the specified symbols as hidden. Use a comma to separate the symbols. This option is ignored if any symbols are specifically marked as exported using the -exported_symbol or -exports_file options. If you specify -hidden_symbol, all unspecified symbols are automatically exported, including those that were implicitly hidden when loading archive libraries. It is an error if any of these symbols are also specifically marked as hidden using the -exported_symbol or -exports_file options. See the NOTES section information regarding hiding and exporting defined symbols. (C, C++, F77, F90) If any of this is wrong, let me know what I should tell SGI. -- albert chin ([EMAIL PROTECTED])
Re: CC can be a program name *with arguments*
On Thu, Mar 03, 2005 at 01:49:20AM -0500, Charles Wilson wrote: > I have a few concerns about removing this functionality: namely, I > maintain a bunch of cygwin packages, and some of those use libtool but > not automake (nor, in one case, autoconf). Namely, libjpeg(*) and > ncurses; I'm sure there are others. > > (*) libjpeg builds its own libtool during configure, but it's too old to > build DLLs on cygwin so I replace it on-the-fly with the "installed" > version of libtool. Can't relibtoolize or autoconf because libjpeg > ships ONLY the configure script, not configure.in/ac. > > Breaking this behavior would make that much harder -- and would probably > force me to give up on providing shared libraries for ncurses, at the > very least. But, because ncurses is a dependency of so many other > packages -- and because libtool won't link a DLL if it has non-DLL > dependencies -- this would cause havoc and ripple thru the whole cygwin > distro. Similar effects may occur on other systems -- unless somebody > wants to fork the upstream ncurses and make it use the "full" autotool > system; the current maintainer's position on automake is quite clear. I have the configure.in for jpeg and a patch for proper libtool support in ncurses if you're willing to change your mind :) -- albert chin ([EMAIL PROTECTED])
Re: CC can be a program name *with arguments*
On Wed, Mar 02, 2005 at 03:38:58PM -0300, Alexandre Oliva wrote: > On Mar 2, 2005, "Peter O'Gorman" <[EMAIL PROTECTED]> wrote: > > > I am going to stand up again (because I like being shot down) and ask > > if the "stand alone utility" bit is really necessary. > > I wish it would just go away, or be properly implemented. I see so > many people being bitten by this that every now and then I think we > should just remove it and stop giving people the impression that it's > expected to work. Which is not to say that nobody would be able to > take the libtool script generated during libtool build and install > that, it's just that I'd rather no longer install it by default. > > Until we get as far as implementing something that enables us to use > the pre-installed libtool properly, which implies doing configuration > on-the-fly, recognizing ABI-changing flags and all such tricky stuff, > and possibly generating config bits in the current directory/.libs or > so. I agree! -- albert chin ([EMAIL PROTECTED])
-update_registry [arg] patch
There's a mix of -update_registry ${output_objdir}/... and
-update_registry ${objdir}/... The first works with a single Makefile
and subdirectory builds while the second does not. Patch for 1.5 and
2.0 attached.
--
albert chin ([EMAIL PROTECTED])
2005-02-24 Albert Chin-A-Young <[EMAIL PROTECTED]>
* libtool.m4: Output -update_registry information to
${output_objdir} directory, not ${objdir}. ${output_objdir}
will work when a project has a single Makefile and performs
builds in subdirectories. ${objdir} expects the source in
the current directory, breaking single-Makefile builds.
Index: libtool.m4
===
RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v
retrieving revision 1.314.2.67
diff -u -3 -p -r1.314.2.67 libtool.m4
--- libtool.m4 3 Feb 2005 15:01:20 - 1.314.2.67
+++ libtool.m4 24 Feb 2005 06:08:27 -
@@ -3097,7 +3097,7 @@ case $host_os in
case $cc_basename in
CC)
# SGI C++
- _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared -all -multigot
$predep_objects $libobjs $deplibs $postdep_objects $compiler_flags -soname
$soname `test -n "$verstring" && echo -set_version $verstring` -update_registry
${objdir}/so_locations -o $lib'
+ _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared -all -multigot
$predep_objects $libobjs $deplibs $postdep_objects $compiler_flags -soname
$soname `test -n "$verstring" && echo -set_version $verstring` -update_registry
${output_objdir}/so_locations -o $lib'
# Archives containing C++ object files must be created using
# "CC -ar", where "CC" is the IRIX C++ compiler. This is
@@ -3108,7 +3108,7 @@ case $host_os in
*)
if test "$GXX" = yes; then
if test "$with_gnu_ld" = no; then
- _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib
$predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname
${wl}$soname `test -n "$verstring" && echo ${wl}-set_version ${wl}$verstring`
${wl}-update_registry ${wl}${objdir}/so_locations -o $lib'
+ _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib
$predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname
${wl}$soname `test -n "$verstring" && echo ${wl}-set_version ${wl}$verstring`
${wl}-update_registry ${wl}${output_objdir}/so_locations -o $lib'
else
_LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib
$predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname
${wl}$soname `test -n "$verstring" && echo ${wl}-set_version ${wl}$verstring`
-o $lib'
fi
@@ -3272,7 +3272,7 @@ case $host_os in
;;
cxx)
_LT_AC_TAGVAR(allow_undefined_flag, $1)=' ${wl}-expect_unresolved
${wl}\*'
- _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared${allow_undefined_flag}
$predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname
$soname `test -n "$verstring" && echo ${wl}-set_version $verstring`
-update_registry ${objdir}/so_locations -o $lib'
+ _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared${allow_undefined_flag}
$predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname
$soname `test -n "$verstring" && echo ${wl}-set_version $verstring`
-update_registry ${output_objdir}/so_locations -o $lib'
_LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-rpath ${wl}$libdir'
_LT_AC_TAGVAR(hardcode_libdir_separator, $1)=:
@@ -3290,7 +3290,7 @@ case $host_os in
*)
if test "$GXX" = yes && test "$with_gnu_ld" = no; then
_LT_AC_TAGVAR(allow_undefined_flag, $1)=' ${wl}-expect_unresolved
${wl}\*'
- _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib
${allow_undefined_flag} $predep_objects $libobjs $deplibs $postdep_objects
$compiler_flags ${wl}-soname ${wl}$soname `test -n "$verstring" && echo
${wl}-set_version ${wl}$verstring` ${wl}-update_registry
${wl}${objdir}/so_locations -o $lib'
+ _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib
${allow_undefined_flag} $predep_objects $libobjs $deplibs $postdep_objects
$compiler_flags ${wl}-soname ${wl}$soname `test -n "$verstring" && echo
${wl}-set_version ${wl}$verstring` ${wl}-update_registry
${wl}${output_objdir}/so_locations -o $lib'
_LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-rpath
${wl}$libdir'
_LT_AC_TAGVAR(hardcode_libdir_separator, $1)=:
@@ -3331,10 +3331,10 @@ case $host_os in
;;
cxx)
_LT_AC_TAGVAR(allow_undefined_flag, $1)=' -expect_unresolved \*'
-
