libtool changes for HP-UX IA64 support

libtool changes for HP-UX IA64 support

[Steve Ellcey]

Since it doesn't look like we will be able to update libtool in binutils
for the 2.12 release, I have created a patch for the libtool that is
checked in to binutils.  I am hoping someone can review it and check it
in.  I don't have write permission but I do have a copyright assignment
on file.  HP-UX IA64 support is already in the top-of-tree libtool so
there is no problem with that, these changes could also be put into the
GCC tree if desired but I am less concerned with that as GCC 3.1 won't
have full HP-UX IA64 support anyway and I am hoping that by the time GCC
3.2 is released libtool would have been updated to the latest sources.

Steve Ellcey
sje@cup.hp.com


2002-01-22  Steve Ellcey <sje@cup.hp.com>
	* libtool.m4 (HPUX_IA64_MODE): Set to 32 or 64 based on ABI.
	(lt_cv_deplibs_check_method, lt_cv_file_magic_cmd,
	lt_cv_file_magic_test_file): Set to appropriate values for HP-UX IA64.
	* ltcf-c.sh (archive_cmds, hardcode_*): Ditto.
	* ltconfig (shlibpath_*, dynamic_linker, library_names_spec,
	soname_spec, sys_lib_search_path_spec): Ditto.


*** src.orig/libtool.m4	Tue Jan 22 15:40:53 2002
--- src/libtool.m4	Tue Jan 22 15:40:28 2002
*************** case $host in
*** 159,164 ****
--- 159,180 ----
    rm -rf conftest*
    ;;
  
+ ia64-*-hpux*)
+   # Find out which ABI we are using.
+   echo 'int i;' > conftest.$ac_ext
+   if AC_TRY_EVAL(ac_compile); then
+     case "`/usr/bin/file conftest.o`" in
+     *ELF-32*)
+       HPUX_IA64_MODE="32"
+       ;;
+     *ELF-64*)
+       HPUX_IA64_MODE="64"
+       ;;
+     esac
+   fi
+   rm -rf conftest*
+   ;;
+ 
  *-*-sco3.2v5*)
    # On SCO OpenServer 5, we need -belf to get full-featured binaries.
    SAVE_CFLAGS="$CFLAGS"
*************** gnu*)
*** 568,576 ****
    ;;
  
  hpux10.20*|hpux11*)
!   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
    ;;
  
  irix5* | irix6*)
--- 584,601 ----
    ;;
  
  hpux10.20*|hpux11*)
!   case $host_cpu in
!   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
    ;;
  
  irix5* | irix6*)
*** src.orig/ltcf-c.sh	Tue Jan 22 15:41:03 2002
--- src/ltcf-c.sh	Tue Jan 22 15:40:39 2002
*************** else
*** 417,439 ****
      ;;
  
    hpux9* | hpux10* | hpux11*)
!     if test $with_gcc = yes; then
!       case "$host_os" in
!       hpux9*) archive_cmds='$rm $output_objdir/$soname~$CC -shared -fPIC ${wl}+b ${wl}$install_libdir -o $output_objdir/$soname $libobjs $deplibs $compiler_flags~test $output_objdir/$soname = $lib || mv $output_objdir/$soname $lib' ;;
!       *) archive_cmds='$CC -shared -fPIC ${wl}+h ${wl}$soname ${wl}+b ${wl}$install_libdir -o $lib $libobjs $deplibs $compiler_flags' ;;
!       esac
!     else
!       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' ;;
!       esac
!     fi
!     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*)
--- 417,448 ----
      ;;
  
    hpux9* | hpux10* | hpux11*)
!     case "$host_cpu" in
!     ia64*)
!       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' ;;
!     *)
!       if test $with_gcc = yes; then
!         case "$host_os" in
!         hpux9*) archive_cmds='$rm $output_objdir/$soname~$CC -shared -fPIC ${wl}+b ${wl}$install_libdir -o $output_objdir/$soname $libobjs $deplibs $compiler_flags~test $output_objdir/$soname = $lib || mv $output_objdir/$soname $lib' ;;
!         *) archive_cmds='$CC -shared -fPIC ${wl}+h ${wl}$soname ${wl}+b ${wl}$install_libdir -o $lib $libobjs $deplibs $compiler_flags' ;;
!         esac
!       else
!         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' ;;
!         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.
!       ;;
!     esac
      export_dynamic_flag_spec='${wl}-E'
+     hardcode_direct=yes
      ;;
  
    irix5* | irix6*)
*** src.orig/ltconfig	Tue Jan 22 15:40:57 2002
--- src/ltconfig	Tue Jan 22 15:40:34 2002
*************** gnu*)
*** 1155,1168 ****
  hpux9* | hpux10* | hpux11*)
    # Give a soname corresponding to the major version so that dld.sl refuses to
    # link against other versions.
-   dynamic_linker="$host_os dld.sl"
    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 $lib'
    ;;
--- 1155,1186 ----
  hpux9* | hpux10* | hpux11*)
    # Give a soname corresponding to the major version so that dld.sl refuses to
    # link against other versions.
    version_type=sunos
    need_lib_prefix=no
    need_version=no
!   case "$host_cpu" in
!   ia64*)
!     dynamic_linker="$host_os dld.so"
!     shlibpath_var=LD_LIBRARY_PATH
!     library_names_spec='${libname}${release}.so$versuffix ${libname}${release}.so$major $libname.so'
!     soname_spec='${libname}${release}.so$major'
!     shlibpath_var=LD_LIBRARY_PATH
!     shlibpath_overrides_runpath=yes # Unless +noenvvar is specified.
!     if test "X$HPUX_IA64_MODE" = X32; then
!       sys_lib_search_path_spec="/usr/lib/hpux32 /usr/local/lib/hpux32/usr/local/lib"
!     else
!       sys_lib_search_path_spec="/usr/lib/hpux64 /usr/local/lib/hpux64"
!     fi
!     sys_lib_dlsearch_path_spec=$sys_lib_search_path_spec
!     ;;
!   *)
!     dynamic_linker="$host_os dld.sl"
!     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'
!     ;;
!   esac
    # HP-UX runs *really* slowly unless shared libraries are mode 555.
    postinstall_cmds='chmod 555 $lib'
    ;;

Re: libtool changes for HP-UX IA64 support

[Alexandre Oliva]

On Jan 22, 2002, Steve Ellcey <sje@cup.hp.com> wrote:

> Since it doesn't look like we will be able to update libtool in binutils
> for the 2.12 release, I have created a patch for the libtool that is
> checked in to binutils.  I am hoping someone can review it and check it
> in.

I have reviewed the patch, and it looks quite reasonable to me, but
I'll defer the decision on checking it in to the release manager.

If it's not asking for too much, I'd appreciate to have chunks of code
that are not in the original libtool snapshot enclosed in # GCC LOCAL
comments, like other similar changes that have already been
installed.  Would you please make this change?


After this patch goes in, every configure script in directories that
use libtool must be rebuilt, such that it gets the changes to
libtool.m4.

Thanks, and sorry for consistently dropping the ball in this regard
:-(

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: libtool changes for HP-UX IA64 support

[Daniel Jacobowitz]

On Tue, Jan 22, 2002 at 11:33:58PM -0200, Alexandre Oliva wrote:
> On Jan 22, 2002, Steve Ellcey <sje@cup.hp.com> wrote:
> 
> > Since it doesn't look like we will be able to update libtool in binutils
> > for the 2.12 release, I have created a patch for the libtool that is
> > checked in to binutils.  I am hoping someone can review it and check it
> > in.
> 
> I have reviewed the patch, and it looks quite reasonable to me, but
> I'll defer the decision on checking it in to the release manager.
> 
> If it's not asking for too much, I'd appreciate to have chunks of code
> that are not in the original libtool snapshot enclosed in # GCC LOCAL
> comments, like other similar changes that have already been
> installed.  Would you please make this change?
> 
> 
> After this patch goes in, every configure script in directories that
> use libtool must be rebuilt, such that it gets the changes to
> libtool.m4.
> 
> Thanks, and sorry for consistently dropping the ball in this regard
> :-(

I'll take care of committing this patch, which I also think is
reasonable as a workaround until we're ready for the new libtool.  It
will probably sit until next week, though.


-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: libtool changes for HP-UX IA64 support

[Daniel Jacobowitz]

On Tue, Jan 22, 2002 at 04:07:56PM -0800, Steve Ellcey wrote:
> Since it doesn't look like we will be able to update libtool in binutils
> for the 2.12 release, I have created a patch for the libtool that is
> checked in to binutils.  I am hoping someone can review it and check it
> in.  I don't have write permission but I do have a copyright assignment
> on file.  HP-UX IA64 support is already in the top-of-tree libtool so
> there is no problem with that, these changes could also be put into the
> GCC tree if desired but I am less concerned with that as GCC 3.1 won't
> have full HP-UX IA64 support anyway and I am hoping that by the time GCC
> 3.2 is released libtool would have been updated to the latest sources.

Both I and Alexandre approve of this patch, so it certainly should go
in.  Is there anyone out there more familiar than I with what needs to
be regenerated to do this?

My installed auto* are different enough from the existing ones, and
even those on sourceware marked as 'right' for this tree take away all
the nice '\'s in Makefile.in's and produce some attrocious long lines.

If there's a new blessed version, it'd be nice to know what it was. 
I'd even suggest it should be in the tree somewhere!

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: libtool changes for HP-UX IA64 support

[Alexandre Oliva]

On Jan 28, 2002, Daniel Jacobowitz <drow@mvista.com> wrote:

> Both I and Alexandre approve of this patch, so it certainly should go
> in.  Is there anyone out there more familiar than I with what needs to
> be regenerated to do this?

Only configure files have to be rebuild with autoconf.

> My installed auto* are different enough from the existing ones, and
> even those on sourceware marked as 'right' for this tree take away all
> the nice '\'s in Makefile.in's and produce some attrocious long lines.

I often use an internal-to-Red Hat version of autotools, just because
that's what we use for our internal CVS repository, and it happens to
preserve Makefile.am line breaks in Makefile.in.  I think this
particular snapshot may be somewhere out there, but I don't know
where.  In this case, you don't have to rebuild the Makefile.ins, so
just touch them (or let them be rebuilt and then revert their changes
instead of checking them in) and you'll be fine.

> If there's a new blessed version, it'd be nice to know what it was. 
> I'd even suggest it should be in the tree somewhere!

IMO, we should aim at switching to automake 1.5, autoconf 2.52 and
then the next release of libtool.  Unless I'm mistaken, the migration
path is in the order I listed.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: libtool changes for HP-UX IA64 support

[Daniel Jacobowitz]

On Mon, Jan 28, 2002 at 02:09:03AM -0200, Alexandre Oliva wrote:
> On Jan 28, 2002, Daniel Jacobowitz <drow@mvista.com> wrote:
> 
> > Both I and Alexandre approve of this patch, so it certainly should go
> > in.  Is there anyone out there more familiar than I with what needs to
> > be regenerated to do this?
> 
> Only configure files have to be rebuild with autoconf.

What about various aclocal.m4's in the tree?  I guess it doesn't really
matter, as they're all in newlib or in sid, I think.

> I often use an internal-to-Red Hat version of autotools, just because
> that's what we use for our internal CVS repository, and it happens to
> preserve Makefile.am line breaks in Makefile.in.  I think this
> particular snapshot may be somewhere out there, but I don't know
> where.  In this case, you don't have to rebuild the Makefile.ins, so
> just touch them (or let them be rebuilt and then revert their changes
> instead of checking them in) and you'll be fine.

I'll just do that.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: libtool changes for HP-UX IA64 support

[Daniel Jacobowitz]

On Sun, Jan 27, 2002 at 11:39:22PM -0500, Daniel Jacobowitz wrote:
> On Mon, Jan 28, 2002 at 02:09:03AM -0200, Alexandre Oliva wrote:
> > On Jan 28, 2002, Daniel Jacobowitz <drow@mvista.com> wrote:
> > 
> > > Both I and Alexandre approve of this patch, so it certainly should go
> > > in.  Is there anyone out there more familiar than I with what needs to
> > > be regenerated to do this?
> > 
> > Only configure files have to be rebuild with autoconf.
> 
> What about various aclocal.m4's in the tree?  I guess it doesn't really
> matter, as they're all in newlib or in sid, I think.
> 
> > I often use an internal-to-Red Hat version of autotools, just because
> > that's what we use for our internal CVS repository, and it happens to
> > preserve Makefile.am line breaks in Makefile.in.  I think this
> > particular snapshot may be somewhere out there, but I don't know
> > where.  In this case, you don't have to rebuild the Makefile.ins, so
> > just touch them (or let them be rebuilt and then revert their changes
> > instead of checking them in) and you'll be fine.
> 
> I'll just do that.

Done.

2002-01-27  Daniel Jacobowitz  <drow@mvista.com>

        From Steve Ellcey <sje@cup.hp.com>:
        * libtool.m4 (HPUX_IA64_MODE): Set to 32 or 64 based on ABI.
        (lt_cv_deplibs_check_method, lt_cv_file_magic_cmd,
        lt_cv_file_magic_test_file): Set to appropriate values for HP-UX
        IA64.
        * ltcf-c.sh (archive_cmds, hardcode_*): Ditto.
        * ltconfig (shlibpath_*, dynamic_linker, library_names_spec,
        soname_spec, sys_lib_search_path_spec): Ditto.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: libtool changes for HP-UX IA64 support

[Alexandre Oliva]

On Jan 28, 2002, Daniel Jacobowitz <drow@mvista.com> wrote:

> What about various aclocal.m4's in the tree?  I guess it doesn't really
> matter, as they're all in newlib or in sid, I think.

They should be sinclude()ing ../libtool.m4, instead of relying on
aclocal to bring the wrong version in :-)

> I'll just do that.

Thanks,

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: libtool changes for HP-UX IA64 support

[Alexandre Oliva]

On Jan 23, 2002, Steve Ellcey <sje@cup.hp.com> wrote:

> Do you want me to send you an updated patch with the "# GCC LOCAL"
> comments included?

Never mind.  I could swear we had such markers in place for the other
changes, but since they are not there, there's little point in adding
them now.  Better have no marks than incomplete marks.

Please disregard my request for adding such marks.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: libtool changes for HP-UX IA64 support

[Steve Ellcey]

Daniel,

Do you want me to send you an updated patch with the "# GCC LOCAL"
comments included?  I looked in the libtool sources to see where this
was already being used but didn't see anything other then a change in
TIMESTAMP to include "with GCC-local changes".  It wouldn't take me long
to make a new patch with comments in front of my changes if that would
make it easier for you to commit the patch.

Steve Ellcey
sje@cup.hp.com

> > If it's not asking for too much, I'd appreciate to have chunks of code
> > that are not in the original libtool snapshot enclosed in # GCC LOCAL
> > comments, like other similar changes that have already been
> > installed.  Would you please make this change?
> > 
> > 
> I'll take care of committing this patch, which I also think is
> reasonable as a workaround until we're ready for the new libtool.  It
> will probably sit until next week, though.
> 
> 
> -- 
> Daniel Jacobowitz                           Carnegie Mellon University
> MontaVista Software                         Debian GNU/Linux Developer
>