hppa*64* and dependent libraries
Dependent libraries for hppa64* is funky. $ cd /tmp/a $ ld -b +h lib1.sl.0 -o lib1.sl obj1.o obj2.o -lc $ elfdump -L lib1.sl | head 0 Needed libc.2 1 Soname lib1.sl.0 $ cd /tmp/b $ ld -b +h lib2.sl.0 -o lib2.sl ../a/lib1.sl obj3.o obj4.o -lc $ elfdump -L lib2.sl | head 0 Needed lib1.sl.0 1 Needed libc.2 2 Soname lib2.sl.0 $ cd /tmp $ ld -b +h lib3.sl.0 -o lib3.sl a/lib1.sl b/lib2.sl obj5.o ld: Can't find dependent library "libl1.sl.0" $ ld -b +h lib3.sl.0 -o lib3.sl -La b/lib2.sl obj5.o According to http://docs.hp.com/hpux/onlinedocs/B2355-90655/B2355-90655.html: * All DT_NEEDED entries with no "/" in the libname are subject to dynamic path lookup. We have two possible solutions: (1) ld -b +h lib2.sl.0 -o lib2.sl -L/tmp/a ../a/lib1.sl obj3.o obj4.o -lc (2) ld -b +h lib2.sl.0 -o lib2.sl -L/tmp/a -l1 obj3.o obj4.o -lc I've confirmed the above behaviour with a post to the HP-UX Developer Mailing List. It's frustrating that even though we explicitly list a/lib1.sl in the link line, it doesn't help. So, is there anything in libtool to already do this? If not, do we adopt solution #1 or #2? -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: hppa*64* and dependent libraries
On Sat, Dec 14, 2002 at 03:22:42AM -0600, Albert Chin wrote:
> Dependent libraries for hppa64* is funky.
>
> $ cd /tmp/a
> $ ld -b +h lib1.sl.0 -o lib1.sl obj1.o obj2.o -lc
> $ elfdump -L lib1.sl | head
> 0 Needed libc.2
> 1 Soname lib1.sl.0
> $ cd /tmp/b
> $ ld -b +h lib2.sl.0 -o lib2.sl ../a/lib1.sl obj3.o obj4.o -lc
> $ elfdump -L lib2.sl | head
> 0 Needed lib1.sl.0
> 1 Needed libc.2
> 2 Soname lib2.sl.0
> $ cd /tmp
> $ ld -b +h lib3.sl.0 -o lib3.sl a/lib1.sl b/lib2.sl obj5.o
> ld: Can't find dependent library "libl1.sl.0"
> $ ld -b +h lib3.sl.0 -o lib3.sl -La b/lib2.sl obj5.o
>
> According to
> http://docs.hp.com/hpux/onlinedocs/B2355-90655/B2355-90655.html:
> * All DT_NEEDED entries with no "/" in the libname are subject to
>dynamic path lookup.
>
> We have two possible solutions:
> (1) ld -b +h lib2.sl.0 -o lib2.sl -L/tmp/a ../a/lib1.sl obj3.o obj4.o -lc
> (2) ld -b +h lib2.sl.0 -o lib2.sl -L/tmp/a -l1 obj3.o obj4.o -lc
>
> I've confirmed the above behaviour with a post to the HP-UX Developer
> Mailing List. It's frustrating that even though we explicitly list
> a/lib1.sl in the link line, it doesn't help.
>
> So, is there anything in libtool to already do this? If not, do we
> adopt solution #1 or #2?
Ok, there is another option:
(3) ld -b +h lib2.sl.0 -o lib2.sl +b /tmp/a ../a/lib1.sl obj3.o obj4.o -lc
I've chosen to use option #3 because libtool has code to handle most
of it. I've configure hppa64 such that:
hardcode_direct=no
hardcode_into_libs=yes
hardcode_libdir_flag_spec='${wl}+b ${wl}$libdir'
However, I now have the problem that I need '+b' for ld and '-Wl,+b'
for cc. Because there is not a separate $hardcode_libdir_flag_spec for
ld/cc, I have to hack libtool.m4 like:
case "${LD}" in
*/ld*)
wl=
esac
eval dep_rpath=\"$hardcode_libdir_flag_spec\"
This is gross. I have no problem modifying $hardcode_libdir_flag_spec
so it's rewritten as:
hardcode_libdir_flag_spec="`if linking with ld; then +b $libdir;
else ${wl}+b ${wl}$libdir`"
However, I don't see an easy way to detect at runtime whether or not
we're using ld/cc to link/compile. So, what do I do? Should I
introduce a separate hardcode_libdir_flag_spec for creating shared
libraries and one for creating programs?
BTW, this is relative to 1.4 but the same problems no doubt exist in
HEAD.
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
RE: hppa*64* and dependent libraries
Title: RE: hppa*64* and dependent libraries
Albert,
Post the patch you have for 1.4. I'm curious as to why you need to set $wl at all,
if linking is being done with "ld" then ${wl}="" for any flag. IMHO, if that
isn't being done properly we need to find out why.
Thanks,
Robert
-Original Message-
From: Albert Chin [mailto:[EMAIL PROTECTED]]
Sent: Saturday, December 14, 2002 5:18 PM
To: [EMAIL PROTECTED]
Subject: Re: hppa*64* and dependent libraries
On Sat, Dec 14, 2002 at 03:22:42AM -0600, Albert Chin wrote:
However, I now have the problem that I need '+b' for ld and '-Wl,+b'
for cc. Because there is not a separate $hardcode_libdir_flag_spec for
ld/cc, I have to hack libtool.m4 like:
case "${LD}" in
*/ld*)
wl=
esac
eval dep_rpath=\"$hardcode_libdir_flag_spec\"
This is gross. I have no problem modifying $hardcode_libdir_flag_spec
so it's rewritten as:
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: hppa*64* and dependent libraries
On Wed, Dec 18, 2002 at 07:45:36PM -0500, Boehne, Robert wrote:
> Post the patch you have for 1.4. I'm curious as to why you need to
> set $wl at all, if linking is being done with "ld" then ${wl}="" for
> any flag. IMHO, if that isn't being done properly we need to find
> out why.
There's a small patch in here too for IRIX so just ignore it.
As an example, the following links libpng 1.2.4 as a shared library
and a test program:
...
/bin/sh ./libtool --mode=link cc +DD64 +O2 +ESlit +Onofltacc
+Oentrysched +Odataprefetch +Onolimit
-L/opt/TWWfsw/zlib11/lib/pa20_64 -o libpng.la -rpath
/opt/TWWfsw/libpng12/lib/pa20_64 -version-info 2:2:0 -module png.lo
pngerror.lo pngget.lo pngmem.lo pngpread.lo pngrio.lo pngread.lo
pngrtran.lo pngrutil.lo pngset.lo pngtrans.lo pngwio.lo pngwrite.lo
pngwtran.lo pngwutil.lo -lz -lm
rm -fr .libs/libpng.la .libs/libpng.* .libs/libpng.*
/usr/ccs/bin/ld -b +h libpng.sl.2 -o .libs/libpng.sl.2.2 png.o
pngerror.o pngget.o pngmem.o pngpread.o pngrio.o pngread.o pngrtran.o
pngrutil.o pngset.o pngtrans.o pngwio.o pngwrite.o pngwtran.o
pngwutil.o +b /opt/TWWfsw/zlib11/lib/pa20_64
-L/opt/TWWfsw/zlib11/lib/pa20_64
/opt/TWWfsw/zlib11/lib/pa20_64/libz.sl -lm -lc
(cd .libs && rm -f libpng.sl.2 && ln -s libpng.sl.2.2 libpng.sl.2)
...
/bin/sh ./libtool --mode=link cc +DD64 +O2 +ESlit +Onofltacc
+Oentrysched +Odataprefetch +Onolimit
-L/opt/TWWfsw/zlib11/lib/pa20_64 -o pngtest pngtest.o libpng.la -lz
-lm
cc +DD64 +O2 +ESlit +Onofltacc +Oentrysched +Odataprefetch +Onolimit
-o .libs/pngtest pngtest.o -L/opt/TWWfsw/zlib11/lib/pa20_64
./.libs/libpng.sl /opt/TWWfsw/zlib11/lib/pa20_64/libz.sl -lm -Wl,+b
-Wl,/opt/TWWfsw/libpng12/lib/pa20_64:/opt/TWWfsw/zlib11/lib/pa20_64
...
--
albert chin ([EMAIL PROTECTED])
-- snip snip
Index: libtool.m4
===
RCS file: /cvsroot/libtool/libtool/libtool.m4,v
retrieving revision 1.166.2.45
diff -u -3 -p -r1.166.2.45 libtool.m4
--- libtool.m4 11 Oct 2002 16:06:07 - 1.166.2.45
+++ libtool.m4 19 Dec 2002 01:21:10 -
@@ -910,7 +910,14 @@ AC_CACHE_VAL(lt_cv_prog_cc_pic,
# Is there a better lt_cv_prog_cc_static that works with the bundled CC?
lt_cv_prog_cc_wl='-Wl,'
lt_cv_prog_cc_static="${lt_cv_prog_cc_wl}-a ${lt_cv_prog_cc_wl}archive"
- lt_cv_prog_cc_pic='+Z'
+ case "$host_cpu" in
+ hppa*64*|ia64*)
+ # +Z the default
+ ;;
+ *)
+ lt_cv_prog_cc_pic='+Z'
+ ;;
+ esac
;;
irix5* | irix6* | nonstopux*)
@@ -1627,23 +1634,41 @@ else
hpux9* | hpux10* | hpux11*)
case $host_os in
hpux9*) archive_cmds='$rm $output_objdir/$soname~$LD -b +b $install_libdir -o
$output_objdir/$soname $libobjs $deplibs $linker_flags~test $output_objdir/$soname =
$lib || mv $output_objdir/$soname $lib' ;;
-*) archive_cmds='$LD -b +h $soname +b $install_libdir -o $lib $libobjs $deplibs
$linker_flags' ;;
+*)
+ case "$host_cpu" in
+ hppa*64*|ia64*)
+ archive_cmds='$LD -b +h $soname -o $lib $libobjs $deplibs $linker_flags'
+ ;;
+ *)
+ archive_cmds='$LD -b +h $soname +b $install_libdir -o $lib $libobjs $deplibs
+$linker_flags'
+ ;;
+ esac
+ ;;
+esac
+case "$host_cpu" in
+hppa*64*|ia64*)
+ hardcode_direct=no
+ hardcode_into_libs=yes
+ ;;
+*)
+ hardcode_direct=yes
+ export_dynamic_flag_spec='${wl}-E'
+ ;;
esac
hardcode_libdir_flag_spec='${wl}+b ${wl}$libdir'
hardcode_libdir_separator=:
-hardcode_direct=yes
hardcode_minus_L=yes # Not in the search PATH, but as the default
-# location of the library.
-export_dynamic_flag_spec='${wl}-E'
+# location of the library
;;
irix5* | irix6* | nonstopux*)
if test "$GCC" = yes; then
archive_cmds='$CC -shared $libobjs $deplibs $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'
+ hardcode_libdir_flag_spec='${wl}-rpath ${wl}$libdir'
else
archive_cmds='$LD -shared $libobjs $deplibs $linker_flags -soname $soname `test
-n "$verstring" && echo -set_version $verstring` -update_registry
${output_objdir}/so_locations -o $lib'
+ hardcode_libdir_flag_spec='-rpath $libdir'
fi
-hardcode_libdir_flag_spec='${wl}-rpath ${wl}$libdir'
hardcode_libdir_separator=:
link_all_deplibs=yes
;;
@@ -2122,12 +2148,21 @@ hpux9* | hpux10* | hpux11*)
version_type=sunos
need_lib_prefix=no
need_version=no
- shlibpath_var=SHLIB_PATH
- shlibpath_overrides_runpath=no # +s is required to enable SHLIB_PATH
library_names_spec='${libname}${release}.sl$versuffix ${libname}${release}.sl$major
$libname.sl'
soname_spec='${libname}${release}.sl$major'
# HP-UX runs *really* slowly unless shared libraries are mode 555.
postinstall_cmds='chmod 555 $l
Re: hppa*64* and dependent libraries
> Albert,
>
> Post the patch you have for 1.4. I'm curious as to why you need to set $wl
> at all,
> if linking is being done with "ld" then ${wl}="" for any flag. IMHO, if
> that
> isn't being done properly we need to find out why.
Just to add to the confusion, this is my original patch.
Dave
--
J. David Anglin [EMAIL PROTECTED]
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
2002-07-09 John David Anglin <[EMAIL PROTECTED]>
* libtool.m4 (hpux10.20*|hpux11*): Add lt_cv_deplibs_check_method and
lt_cv_file_magic_test_file defines for hppa*64*.
* ltcf-c.sh (hpux9* | hpux10* | hpux11*): Add hardcode_direct,
hardcode_shlibpath_var and hardcode_libdir_flag_spec defines for
hppa*64*.
* ltcf-cxx.sh (hpux*): Likewise.
* ltcf-gcj.sh (hpux9* | hpux10* | hpux11*): Likewise.
* ltconfig (hpux9* | hpux10* | hpux11*): Add dynamic_linker,
shlibpath_var, shlibpath_overrides_runpath, library_names_spec,
soname_spec, sys_lib_search_path_spec and sys_lib_dlsearch_path_spec
for hppa*64*. Update default values for sys_lib_search_path_spec and
sys_lib_dlsearch_path_spec.
Index: libtool.m4
===
RCS file: /cvs/src/src/libtool.m4,v
retrieving revision 1.8
diff -u -3 -p -r1.8 libtool.m4
--- libtool.m4 28 Jan 2002 04:59:30 - 1.8
+++ libtool.m4 7 Jul 2002 18:16:03 -
@@ -584,15 +584,18 @@ gnu*)
;;
hpux10.20*|hpux11*)
+ lt_cv_file_magic_cmd=/usr/bin/file
case $host_cpu in
+ hppa*64*)
+[lt_cv_deplibs_check_method='file_magic (s[0-9][0-9][0-9]|ELF-[0-9][0-9]) shared
+object file - PA-RISC [0-9].[0-9]']
+lt_cv_file_magic_test_file=/usr/lib/pa20_64/libc.sl
+;;
hppa*)
[lt_cv_deplibs_check_method='file_magic (s[0-9][0-9][0-9]|PA-RISC[0-9].[0-9])
shared library']
-lt_cv_file_magic_cmd=/usr/bin/file
lt_cv_file_magic_test_file=/usr/lib/libc.sl
;;
ia64*)
[lt_cv_deplibs_check_method='file_magic (s[0-9][0-9][0-9]|ELF-[0-9][0-9]) shared
object file - IA64']
-lt_cv_file_magic_cmd=/usr/bin/file
lt_cv_file_magic_test_file=/usr/lib/hpux32/libc.so
;;
esac
Index: ltcf-c.sh
===
RCS file: /cvs/src/src/ltcf-c.sh,v
retrieving revision 1.11
diff -u -3 -p -r1.11 ltcf-c.sh
--- ltcf-c.sh 28 Jan 2002 04:59:30 - 1.11
+++ ltcf-c.sh 7 Jul 2002 18:16:03 -
@@ -422,7 +422,8 @@ else
hardcode_direct=no
hardcode_shlibpath_var=no
archive_cmds='$LD -b +h $soname -o $lib $libobjs $deplibs $linker_flags'
- hardcode_libdir_flag_spec='-L$libdir' ;;
+ hardcode_libdir_flag_spec='-L$libdir'
+ ;;
*)
if test $with_gcc = yes; then
case "$host_os" in
@@ -435,14 +436,23 @@ else
*) archive_cmds='$LD -b +h $soname +b $install_libdir -o $lib $libobjs
$deplibs $linker_flags' ;;
esac
fi
- hardcode_libdir_flag_spec='${wl}+b ${wl}$libdir'
- hardcode_libdir_separator=:
- hardcode_minus_L=yes # Not in the search PATH, but as the default
- # location of the library.
+ case "$host_cpu" in
+ hppa*64*)
+ hardcode_direct=no
+ hardcode_shlibpath_var=no
+ hardcode_libdir_flag_spec='-L$libdir'
+ ;;
+ *)
+ hardcode_direct=yes
+ hardcode_libdir_flag_spec='${wl}+b ${wl}$libdir'
+ hardcode_libdir_separator=:
+ hardcode_minus_L=yes # Not in the search PATH, but as the default
+# location of the library.
+ export_dynamic_flag_spec='${wl}-E'
+ ;;
+ esac
;;
esac
-export_dynamic_flag_spec='${wl}-E'
-hardcode_direct=yes
;;
irix5* | irix6*)
Index: ltcf-cxx.sh
===
RCS file: /cvs/src/src/ltcf-cxx.sh,v
retrieving revision 1.13
diff -u -3 -p -r1.13 ltcf-cxx.sh
--- ltcf-cxx.sh 4 Jul 2002 22:51:16 - 1.13
+++ ltcf-cxx.sh 7 Jul 2002 18:16:03 -
@@ -252,17 +252,29 @@ case $host_os in
if test $with_gnu_ld = no; then
case "$host_cpu" in
ia64*)
+ hardcode_direct=yes
hardcode_libdir_flag_spec='-L$libdir'
- hardcode_shlibpath_var=no ;;
+ hardcode_shlibpath_var=no
+ hardcode_libdir_separator=:
+ export_dynamic_flag_spec='${wl}-E'
+ hardcode_minus_L=yes # Not in the search PATH, but as the default
+ # location of the library.
+ ;;
+ hppa*64*)
+ hardcode_direct=no
+ hardcode_libdir_flag_spec='-L$libdir'
+ hardcode_shlibpath_var=no
+ ;;
*)
- hardcode_libdir_flag_spec='${wl}+b ${wl}$libdir' ;;
+ hardcode_direct=yes
+ hardcode_libdir_flag_spec='${wl}+b ${wl}$libdir'
+ hardcode_libdir_separator=:
+ export_dyna
Re: hppa*64* and dependent libraries
> Dependent libraries for hppa64* is funky. > > $ cd /tmp/a > $ ld -b +h lib1.sl.0 -o lib1.sl obj1.o obj2.o -lc > $ elfdump -L lib1.sl | head > 0 Needed libc.2 > 1 Soname lib1.sl.0 > $ cd /tmp/b > $ ld -b +h lib2.sl.0 -o lib2.sl ../a/lib1.sl obj3.o obj4.o -lc > $ elfdump -L lib2.sl | head > 0 Needed lib1.sl.0 > 1 Needed libc.2 > 2 Soname lib2.sl.0 > $ cd /tmp > $ ld -b +h lib3.sl.0 -o lib3.sl a/lib1.sl b/lib2.sl obj5.o > ld: Can't find dependent library "libl1.sl.0" > $ ld -b +h lib3.sl.0 -o lib3.sl -La b/lib2.sl obj5.o > > According to > http://docs.hp.com/hpux/onlinedocs/B2355-90655/B2355-90655.html: > * All DT_NEEDED entries with no "/" in the libname are subject to >dynamic path lookup. > > We have two possible solutions: > (1) ld -b +h lib2.sl.0 -o lib2.sl -L/tmp/a ../a/lib1.sl obj3.o obj4.o -lc > (2) ld -b +h lib2.sl.0 -o lib2.sl -L/tmp/a -l1 obj3.o obj4.o -lc > > I've confirmed the above behaviour with a post to the HP-UX Developer > Mailing List. It's frustrating that even though we explicitly list > a/lib1.sl in the link line, it doesn't help. > > So, is there anything in libtool to already do this? If not, do we > adopt solution #1 or #2? I suggest neither. I believe that you don't want to try to hardcode the full path of libraries. It is better to use "+b" to set the embedded path. This is equivalent to the -rpath option when GNU ld is used. The standard dynamic path search order is LD_LIBRARY_PATH, SHLIB_PATH and then the embedded path. The default is for all three to be enabled. The enables and search order can be changed with chatr if desired. I personally like the dynamic path lookup and dislike the hardcoded paths used with the 32-bit SOM linker. With the hardcoded paths, it not possible to move libraries. It can also cause other problems. An example is GCC. GCC builds paths relative to its tool directory which is installed in a version specific directory. This caused libraries like libstdc++.sl to have dependencies which included the path to the gcc tool directory. If you removed the gcc tool directory, then applications linked with libstdc++.sl no longer worked. I removed the dot dots from the dependencies a few months ago. The downside in doing this is that it is now no longer possible to move the gcc tool directory by inserting a symbolic link. Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6605) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: hppa*64* and dependent libraries
> I suggest neither. I believe that you don't want to try to hardcode > the full path of libraries. It is better to use "+b" to set the embedded > path. This is equivalent to the -rpath option when GNU ld is used. The other way to set the embedded path is to use "-L" and "-l", and NOT use "+b". The linker will also add LPATH to the end of the constructed embedded path. Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6605) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: hppa*64* and dependent libraries
On Thu, Dec 19, 2002 at 12:45:55PM -0500, John David Anglin wrote: > > ... > > > > We have two possible solutions: > > (1) ld -b +h lib2.sl.0 -o lib2.sl -L/tmp/a ../a/lib1.sl obj3.o obj4.o -lc > > (2) ld -b +h lib2.sl.0 -o lib2.sl -L/tmp/a -l1 obj3.o obj4.o -lc > > > > I've confirmed the above behaviour with a post to the HP-UX Developer > > Mailing List. It's frustrating that even though we explicitly list > > a/lib1.sl in the link line, it doesn't help. > > > > So, is there anything in libtool to already do this? If not, do we > > adopt solution #1 or #2? > > I suggest neither. I believe that you don't want to try to hardcode > the full path of libraries. It is better to use "+b" to set the embedded > path. This is equivalent to the -rpath option when GNU ld is used. > The standard dynamic path search order is LD_LIBRARY_PATH, SHLIB_PATH > and then the embedded path. The default is for all three to be enabled. > The enables and search order can be changed with chatr if desired. I agree that we should use +b to embed the path. Is everyone else in agreement? -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: hppa*64* and dependent libraries
> I agree that we should use +b to embed the path. Is everyone else in > agreement? What about the alternative "-L" and "-l" approach which ia64 uses and I adopted in my original patch? I tried to stay away from using "+b". Maybe I am missing something but the package which I have built seem to have a reasonable embedded path. For example, /bin/sh ./libtool --mode=link gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -O2 -o ld-new ldgram.o ldlex.o lexsup.o ldlang.o mri.o ldctor.o ldmain.o ldwrite.o ldexp.o ldemul.o ldver.o ldmisc.o ldfile.o ldcref.o eelf64hppa.o ../bfd/libbfd.la ../libiberty/libiberty.a mkdir .libs gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -O2 -o .libs/ld-new ldgram.o ldlex.o lexsup.o ldlang.o mri.o ldctor.o ldmain.o ldwrite.o ldexp.o ldemul.o ldver.o ldmisc.o ldfile.o ldcref.o eelf64hppa.o ../bfd/.libs/libbfd.sl ../libiberty/libiberty.a -L/opt/gnu64/lib The installed version of ld has the embedded path shared library dynamic path search: LD_LIBRARY_PATHenabled first SHLIB_PATH enabled second embedded path enabled third /opt/gnu64/lib:/opt/gnu64/lib/gcc-lib/hppa64-hp-hpux11.00/3.3:/opt/gnu64/lib/gcc-lib/hppa64-hp-hpux11.00/3.3/../../../../hppa64-hp-hpux11.00/lib:/usr/ccs/bin:/usr/ccs/lib/pa20_64:/opt/langtools/lib/pa20_64:/opt/gnu64/lib/gcc-lib/hppa64-hp-hpux11.00/3.3/../../.. shared library list: libbfd-2.13.90.sl libc.2 The important addition by libtool is "-L/opt/gnu64/lib" to the gcc link command. This comes because ../bfd/.libs/libbfd.sl has the embedded path /opt/gnu64/lib. It has this because the libtool command to build it had "-rpath /opt/gnu64/lib". It is true that the embedded path doesn't contain a path to libbfd.sl in its build location but I don't think you want that unless that's its final location. The testsuite scripts use LD_LIBRARY_PATH to modify the search path when you want to test the library in its build location prior to install. This all seems reasonable to me. This was generated using my original libtool patch for binutils. Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6605) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: hppa*64* and dependent libraries
> /usr/ccs/bin/ld -b +h libpng.sl.2 -o .libs/libpng.sl.2.2 png.o > pngerror.o pngget.o pngmem.o pngpread.o pngrio.o pngread.o pngrtran.o > pngrutil.o pngset.o pngtrans.o pngwio.o pngwrite.o pngwtran.o > pngwutil.o -L/opt/TWWfsw/zlib11/lib/pa20_64 > -L/opt/TWWfsw/zlib11/lib/pa20_64 -L/opt/TWWfsw/zlib11/lib/pa20_64 > /opt/TWWfsw/zlib11/lib/pa20_64/libz.sl -lm -lc There's something strange in the '-L' options. How come three zlib11s and no libpng12? > $ elfdump -L .libs/libnpg.sl | grep Rpath > 4 Rpath >/opt/TWWfsw/zlib11/lib/pa20_64:/opt/TWWfsw/zlib11/lib/pa20_64:/opt/TWWfsw/zlib11/lib/pa20_64 > > Ick! You might be able to see why the second /opt/TWWfsw/zlib11/lib/pa20_64 occurs in the path using -Wl,-v. You are correct that "+b" is explicit and there may be times when you you don't want a "-L" directory in the embedded path. I wonder if libtool could check for a user "+b" option and append the specified path to the accumulated rpath. Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6605) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: hppa*64* and dependent libraries
On Thu, Dec 19, 2002 at 03:13:13PM -0500, John David Anglin wrote:
> > I agree that we should use +b to embed the path. Is everyone else in
> > agreement?
>
> What about the alternative "-L" and "-l" approach which ia64 uses and
> I adopted in my original patch? I tried to stay away from using "+b".
> Maybe I am missing something but the package which I have built seem
> to have a reasonable embedded path. For example,
I integrated your -L patch and get the following with libpng-1.2.4:
...
/bin/sh ./libtool --mode=link cc +DD64 +O2 +ESlit +Onofltacc
+Oentrysched +Odataprefetch +Onolimit
-L/opt/TWWfsw/zlib11/lib/pa20_64 -o libpng.la -rpath
/opt/TWWfsw/libpng12/lib/pa20_64 -version-info 2:2:0 -module png.lo
pngerror.lo pngget.lo pngmem.lo pngpread.lo pngrio.lo pngread.lo
pngrtran.lo pngrutil.lo pngset.lo pngtrans.lo pngwio.lo pngwrite.lo
pngwtran.lo pngwutil.lo -lz -lm
rm -fr .libs/libpng.la .libs/libpng.* .libs/libpng.*
/usr/ccs/bin/ld -b +h libpng.sl.2 -o .libs/libpng.sl.2.2 png.o
pngerror.o pngget.o pngmem.o pngpread.o pngrio.o pngread.o pngrtran.o
pngrutil.o pngset.o pngtrans.o pngwio.o pngwrite.o pngwtran.o
pngwutil.o -L/opt/TWWfsw/zlib11/lib/pa20_64
-L/opt/TWWfsw/zlib11/lib/pa20_64 -L/opt/TWWfsw/zlib11/lib/pa20_64
/opt/TWWfsw/zlib11/lib/pa20_64/libz.sl -lm -lc
(cd .libs && rm -f libpng.sl.2 && ln -s libpng.sl.2.2 libpng.sl.2)
(cd .libs && rm -f libpng.sl && ln -s libpng.sl.2.2 libpng.sl)
ar cru .libs/libpng.a png.o pngerror.o pngget.o pngmem.o pngpread.o
pngrio.o pngread.o pngrtran.o pngrutil.o pngset.o pngtrans.o pngwio.o
pngwrite.o pngwtran.o pngwutil.o
...
$ elfdump -L .libs/libnpg.sl | grep Rpath
4 Rpath
/opt/TWWfsw/zlib11/lib/pa20_64:/opt/TWWfsw/zlib11/lib/pa20_64:/opt/TWWfsw/zlib11/lib/pa20_64
Ick!
What I really like about +b is that it makes it explicit. The big
advantage of -L is that it is additive whereas +b is not (i.e. +b /a
+b /b => +b /b, where you want /a:/b). However, libtool will add in
the necessary `:' but if someone has LDFLAGS="-Wl,+b,/path", then
/path won't be in the colon-separated path built by libtool.
Below is the patch against 1.4 with your -L addition.
--
albert chin ([EMAIL PROTECTED])
-- snip snip
Index: libtool.m4
===
RCS file: /cvsroot/libtool/libtool/libtool.m4,v
retrieving revision 1.166.2.45
diff -u -3 -p -r1.166.2.45 libtool.m4
--- libtool.m4 11 Oct 2002 16:06:07 - 1.166.2.45
+++ libtool.m4 19 Dec 2002 22:50:39 -
@@ -910,7 +910,14 @@ AC_CACHE_VAL(lt_cv_prog_cc_pic,
# Is there a better lt_cv_prog_cc_static that works with the bundled CC?
lt_cv_prog_cc_wl='-Wl,'
lt_cv_prog_cc_static="${lt_cv_prog_cc_wl}-a ${lt_cv_prog_cc_wl}archive"
- lt_cv_prog_cc_pic='+Z'
+ case "$host_cpu" in
+ hppa*64*|ia64*)
+ # +Z the default
+ ;;
+ *)
+ lt_cv_prog_cc_pic='+Z'
+ ;;
+ esac
;;
irix5* | irix6* | nonstopux*)
@@ -1627,23 +1634,43 @@ else
hpux9* | hpux10* | hpux11*)
case $host_os in
hpux9*) archive_cmds='$rm $output_objdir/$soname~$LD -b +b $install_libdir -o
$output_objdir/$soname $libobjs $deplibs $linker_flags~test $output_objdir/$soname =
$lib || mv $output_objdir/$soname $lib' ;;
-*) archive_cmds='$LD -b +h $soname +b $install_libdir -o $lib $libobjs $deplibs
$linker_flags' ;;
+*)
+ case "$host_cpu" in
+ hppa*64*|ia64*)
+ archive_cmds='$LD -b +h $soname -o $lib $libobjs $deplibs $linker_flags'
+ ;;
+ *)
+ archive_cmds='$LD -b +h $soname +b $install_libdir -o $lib $libobjs $deplibs
+$linker_flags'
+ ;;
+ esac
+ ;;
+esac
+case "$host_cpu" in
+hppa*64*|ia64*)
+ hardcode_direct=no
+ hardcode_shlibpath_var=no
+ hardcode_into_libs=yes
+ hardcode_libdir_flag_spec='-L$libdir'
+ ;;
+*)
+ export_dynamic_flag_spec='${wl}-E'
+ hardcode_direct=yes
+ hardcode_libdir_flag_spec='${wl}+b ${wl}$libdir'
+ hardcode_libdir_separator=:
+ hardcode_minus_L=yes # Not in the search PATH, but as the default
+ # location of the library
+ ;;
esac
-hardcode_libdir_flag_spec='${wl}+b ${wl}$libdir'
-hardcode_libdir_separator=:
-hardcode_direct=yes
-hardcode_minus_L=yes # Not in the search PATH, but as the default
-# location of the library.
-export_dynamic_flag_spec='${wl}-E'
;;
irix5* | irix6* | nonstopux*)
if test "$GCC" = yes; then
archive_cmds='$CC -shared $libobjs $deplibs $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'
+ hardcode_libdir_flag_spec='${wl}-rpath ${wl}$libdir'
else
archive_cmds='$LD -shared $libobjs $deplibs $linker_flags -soname $soname `test
-n "$verstring" && echo -set_version $verstring` -update_registry
${output_objdir}/
Re: hppa*64* and dependent libraries
On Thu, Dec 19, 2002 at 06:22:58PM -0500, John David Anglin wrote: > > /usr/ccs/bin/ld -b +h libpng.sl.2 -o .libs/libpng.sl.2.2 png.o > > pngerror.o pngget.o pngmem.o pngpread.o pngrio.o pngread.o pngrtran.o > > pngrutil.o pngset.o pngtrans.o pngwio.o pngwrite.o pngwtran.o > > pngwutil.o -L/opt/TWWfsw/zlib11/lib/pa20_64 > > -L/opt/TWWfsw/zlib11/lib/pa20_64 -L/opt/TWWfsw/zlib11/lib/pa20_64 > > /opt/TWWfsw/zlib11/lib/pa20_64/libz.sl -lm -lc > > There's something strange in the '-L' options. How come three zlib11s > and no libpng12? Because we're *building* libpng. Here's what you get during the same build for a test program linked against the newly-built libpng.sl: ... /bin/sh ./libtool --mode=link cc +DD64 +O2 +ESlit +Onofltacc +Oentrysched +Odataprefetch +Onolimit -L/opt/TWWfsw/zlib11/lib/pa20_64 -o pngtest pngtest.o libpng.la -lz -lm cc +DD64 +O2 +ESlit +Onofltacc +Oentrysched +Odataprefetch +Onolimit -o .libs/pngtest pngtest.o -L/opt/TWWfsw/zlib11/lib/pa20_64 ./.libs/libpng.sl /opt/TWWfsw/zlib11/lib/pa20_64/libz.sl -lm -L/opt/TWWfsw/libpng12/lib/pa20_64 -L/opt/TWWfsw/zlib11/lib/pa20_64 creating pngtest ... > > $ elfdump -L .libs/libnpg.sl | grep Rpath > > 4 Rpath >/opt/TWWfsw/zlib11/lib/pa20_64:/opt/TWWfsw/zlib11/lib/pa20_64:/opt/TWWfsw/zlib11/lib/pa20_64 > > > > Ick! > > You might be able to see why the second /opt/TWWfsw/zlib11/lib/pa20_64 > occurs in the path using -Wl,-v. Well, there are three -L's so you get three duplicate paths in Rpath. Is this what you're talking about? I think +b /a:/a:/a would exhibit the same problem. > You are correct that "+b" is explicit and there may be times when you > you don't want a "-L" directory in the embedded path. I wonder if > libtool could check for a user "+b" option and append the specified > path to the accumulated rpath. We wrote http://freshmeat.net/projects/wrapld/?topic_id=46 for this purpose but as it replaces /usr/ccs/bin/ld, it's not really an option. If libtool did this for +b on HP-UX, it would have to do it for -rpath on Tru64 UNIX and -blibpath on AIX as well. The other thing I don't like about -L is that if someone has LDFLAGS="-L[path to static library]", then this path gets added to Rpath. If I change the link line to the following (using libz.la rather than -L[path to zlib] -lz): ... /bin/sh ./libtool --mode=link cc +DD64 +O2 +ESlit +Onofltacc +Oentrysched +Odataprefetch +Onolimit -o libpng.la -rpath /opt/TWWfsw/libpng12/lib/pa20_64 -version-info 2:2:0 -module png.lo pngerror.lo pngget.lo pngmem.lo pngpread.lo pngrio.lo pngread.lo pngrtran.lo pngrutil.lo pngset.lo pngtrans.lo pngwio.lo pngwrite.lo pngwtran.lo pngwutil.lo /opt/TWWfsw/zlib11/lib/pa20_64/libz.la -lm rm -fr .libs/libpng.la .libs/libpng.* .libs/libpng.* /usr/ccs/bin/ld -b +h libpng.sl.2 -o .libs/libpng.sl.2.2 png.o pngerror.o pngget.o pngmem.o pngpread.o pngrio.o pngread.o pngrtran.o pngrutil.o pngset.o pngtrans.o pngwio.o pngwrite.o pngwtran.o pngwutil.o -L/opt/TWWfsw/zlib11/lib/pa20_64 -L/opt/TWWfsw/zlib11/lib/pa20_64 /opt/TWWfsw/zlib11/lib/pa20_64/libz.sl -lm -lc ... $ elfdump -L .libs/libpng.sl | grep Rpath 4 Rpath /opt/TWWfsw/zlib11/lib/pa20_64:/opt/TWWfsw/zlib11/lib/pa20_64 -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: hppa*64* and dependent libraries
> If I change the link line to the following (using libz.la rather than > -L[path to zlib] -lz): > ... > /bin/sh ./libtool --mode=link cc +DD64 +O2 +ESlit +Onofltacc > +Oentrysched +Odataprefetch +Onolimit -o libpng.la -rpath > /opt/TWWfsw/libpng12/lib/pa20_64 -version-info 2:2:0 -module png.lo > pngerror.lo pngget.lo pngmem.lo pngpread.lo pngrio.lo pngread.lo > pngrtran.lo pngrutil.lo pngset.lo pngtrans.lo pngwio.lo pngwrite.lo > pngwtran.lo pngwutil.lo /opt/TWWfsw/zlib11/lib/pa20_64/libz.la -lm > rm -fr .libs/libpng.la .libs/libpng.* .libs/libpng.* > /usr/ccs/bin/ld -b +h libpng.sl.2 -o .libs/libpng.sl.2.2 png.o > pngerror.o pngget.o pngmem.o pngpread.o pngrio.o pngread.o pngrtran.o > pngrutil.o pngset.o pngtrans.o pngwio.o pngwrite.o pngwtran.o > pngwutil.o -L/opt/TWWfsw/zlib11/lib/pa20_64 > -L/opt/TWWfsw/zlib11/lib/pa20_64 /opt/TWWfsw/zlib11/lib/pa20_64/libz.sl > -lm -lc > ... > $ elfdump -L .libs/libpng.sl | grep Rpath > 4 Rpath /opt/TWWfsw/zlib11/lib/pa20_64:/opt/TWWfsw/zlib11/lib/pa20_64 This one looks like a libtool bug in that it outputs duplicate -L options. Of course, you might argue that HP ld shouldn't duplicate the paths either. It appears that all these problems are a result of HP trying to modify their tools from their original SOM idiom to the newer ELF idiom, trying to maintain backwards compatibility rather than starting fresh. I now see a whole bunch of areas where it just doesn't work well. None of these problems will occur with the GNU linker as it supports the rpath option but unfortunately it has other problems. Anyway, I would like to see the basic support added for hppa64. Then, it can be worked out which of the two approaches is better. This also affects ia64-hpux, so I think Steve Ellcey at HP needs to be involved in the discussion. Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6605) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
