libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 64bit HPUX problems


From: ross . alexander
Subject: Re: 64bit HPUX problems
Date: Tue, 13 Aug 2002 17:08:42 +0100

Albert,

>From Jeff Law,

> We certainly don't want to go into 64bit mode unless it's explicitly been
> asked for.  If you can actually run the compiler, then checking for
> __LP64__ should get you this information.  Alternately if you can't run
> the compiler, go into 64bit mode for hppa64-*-* configurations only.

> jeff

This is the reason for not putting automatic behaviour into libtool.
Whether or not config.guess should report hppa64 if C compiler would
produce
64bit code (ie __LP64__ is set) is not really up to me.

The problem with comparisons with solaris is that 32bit and 64bit
environments
are pretty similar, ie both ELF.  The HPUX ELF behaviour really is
completely
different to SOM.  I will have a look at the AIX code tomorrow, but again,
the caveat above should apply.

I'm not making myself clear on the problem with hardcode_into_libs.  The
bug is
below in full glory.

make[1]: Entering directory `/opt/dev64/tmp/glib-2.0.6/glib/libcharset'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/opt/dev64/tmp/glib-2.0.6/glib/libcharset'
make[1]: Entering directory `/opt/dev64/tmp/glib-2.0.6/glib'
/bin/sh ../libtool --mode=link gcc  -g -O2 -Wall -D_REENTRANT  -o
libglib-2.0.la -rpath /opt/gtk+-2.0/lib -version-info 0:6:0 -export-dynamic
garray.lo gasyncqueue.lo gbacktrace.lo gbsearcharray.lo gcache.lo
gcompletion.lo gconvert.lo gdataset.lo gdate.lo gdir.lo gerror.lo
gfileutils.lo ghash.lo ghook.lo giochannel.lo glist.lo gmain.lo gmarkup.lo
gmem.lo gmessages.lo gnode.lo gpattern.lo gprimes.lo gqsort.lo gqueue.lo
grel.lo grand.lo gscanner.lo gshell.lo gslist.lo gstrfuncs.lo gstring.lo
gthread.lo gthreadpool.lo gtimer.lo gtree.lo guniprop.lo gutf8.lo
gunibreak.lo gunicollate.lo gunidecomp.lo gutils.lo
libcharset/libcharset.la giounix.lo gspawn.lo      -liconv -lintl -liconv
rm -fr .libs/libglib-2.0.la .libs/libglib-2.0.* .libs/libglib-2.0.*
gcc -shared  garray.lo gasyncqueue.lo gbacktrace.lo gbsearcharray.lo
gcache.lo gcompletion.lo gconvert.lo gdataset.lo gdate.lo gdir.lo gerror.lo
gfileutils.lo ghash.lo ghook.lo giochannel.lo glist.lo gmain.lo gmarkup.lo
gmem.lo gmessages.lo gnode.lo gpattern.lo gprimes.lo gqsort.lo gqueue.lo
grel.lo grand.lo gscanner.lo gshell.lo gslist.lo gstrfuncs.lo gstring.lo
gthread.lo gthreadpool.lo gtimer.lo gtree.lo guniprop.lo gutf8.lo
gunibreak.lo gunicollate.lo gunidecomp.lo gutils.lo giounix.lo gspawn.lo
-Wl,--whole-archive libcharset/.libs/libcharset.al -Wl,--no-whole-archive
-L/opt/dev64/lib libcharset/.libs/libcharset.al -R/opt/dev64/lib -lc
/opt/dev64/lib/libintl.sl /opt/dev64/lib/libiconv.sl -lc  -Wl,-soname
-Wl,libglib-2.0.sl.0 -o .libs/libglib-2.0.sl.0.6
gcc: unrecognized option `-R/opt/dev64/lib'
(cd .libs && rm -f libglib-2.0.sl.0 && ln -s libglib-2.0.sl.0.6
libglib-2.0.sl.0)
(cd .libs && rm -f libglib-2.0.sl && ln -s libglib-2.0.sl.0.6
libglib-2.0.sl)
creating libglib-2.0.la
(cd .libs && rm -f libglib-2.0.la && ln -s ../libglib-2.0.la
libglib-2.0.la)
make[1]: Leaving directory `/opt/dev64/tmp/glib-2.0.6/glib'
address@hidden 17:04:24 $

The -R/opt/dev64/lib comes from the depencies of libintl.la.

It should not be there, as far as I can tell.  If I turn
hardcode_into_libs, it still manages to lurk.

make[1]: Entering directory `/opt/dev64/tmp/glib-2.0.6/glib'
/bin/sh ../libtool --mode=link gcc  -g -O2 -Wall -D_REENTRANT  -o
libglib-2.0.la -rpath /opt/gtk+-2.0/lib -version-info 0:6:0 -export-dynamic
garray.lo gasyncqueue.lo gbacktrace.lo gbsearcharray.lo gcache.lo
gcompletion.lo gconvert.lo gdataset.lo gdate.lo gdir.lo gerror.lo
gfileutils.lo ghash.lo ghook.lo giochannel.lo glist.lo gmain.lo gmarkup.lo
gmem.lo gmessages.lo gnode.lo gpattern.lo gprimes.lo gqsort.lo gqueue.lo
grel.lo grand.lo gscanner.lo gshell.lo gslist.lo gstrfuncs.lo gstring.lo
gthread.lo gthreadpool.lo gtimer.lo gtree.lo guniprop.lo gutf8.lo
gunibreak.lo gunicollate.lo gunidecomp.lo gutils.lo
libcharset/libcharset.la giounix.lo gspawn.lo      -liconv -lintl -liconv
rm -fr .libs/libglib-2.0.la .libs/libglib-2.0.* .libs/libglib-2.0.*
gcc -shared  garray.lo gasyncqueue.lo gbacktrace.lo gbsearcharray.lo
gcache.lo gcompletion.lo gconvert.lo gdataset.lo gdate.lo gdir.lo gerror.lo
gfileutils.lo ghash.lo ghook.lo giochannel.lo glist.lo gmain.lo gmarkup.lo
gmem.lo gmessages.lo gnode.lo gpattern.lo gprimes.lo gqsort.lo gqueue.lo
grel.lo grand.lo gscanner.lo gshell.lo gslist.lo gstrfuncs.lo gstring.lo
gthread.lo gthreadpool.lo gtimer.lo gtree.lo guniprop.lo gutf8.lo
gunibreak.lo gunicollate.lo gunidecomp.lo gutils.lo giounix.lo gspawn.lo
-Wl,--whole-archive libcharset/.libs/libcharset.al -Wl,--no-whole-archive
-Wl,--rpath -Wl,/opt/dev64/lib -Wl,--rpath -Wl,/opt/dev64/lib
-L/opt/dev64/lib libcharset/.libs/libcharset.al -R/opt/dev64/lib -lc
/opt/dev64/lib/libintl.sl /opt/dev64/lib/libiconv.sl -lc  -Wl,-soname
-Wl,libglib-2.0.sl.0 -o .libs/libglib-2.0.sl.0.6
gcc: unrecognized option `-R/opt/dev64/lib'


Cheers and many thanks

Ross

---------------------------------------------------------------------------------

Ross Alexander                           "He knows no more about his
MIS - NEC Europe Limited            destiny than a tea leaf knows
Work ph: +44 20 8752 3394         the history of East India Company"


                                                                                
                                              
                      Albert Chin                                               
                                              
                      <address@hidden        To:       address@hidden           
                              
                      enword.com>              cc:       address@hidden         
                                             
                                               Subject:  Re: 64bit HPUX 
problems                                              
                      13/08/2002 16:43                                          
                                              
                      Please respond to                                         
                                              
                      libtool                                                   
                                              
                                                                                
                                              
                                                                                
                                              




On Tue, Aug 13, 2002 at 04:32:25PM +0100, address@hidden
wrote:
> The change to config.guess is to detect whether the compiler is set
> produce 64bit code.  The concensus (I think) is that hppa2.0w
> represents a 64bit OS with 32bit tools where as hppa*64* represents
> a 64bit tool chain.  A design decision was made by myself that
> libtool itself will not  check for the 64bit environment.  Either
> the user will specify it with the --build flag or config.guess will
> detect (if that change is allowed).

'hppa2.0w' represents the architecture. It has nothing to do with
HP-UX.

I disagree with using $host or $build to determine whether or not the
user wants a 32-bit or 64-bit build. Solaris 64-bit builds definitely
don't work this way. Ditto for IRIX 64-bit builds.

Why not do it the way AIX does for runtime linking by setting the
appropriate flags if a 64-bit build is requested (using your __LP64__
trick)?

> As for hardcode_into_libs, these values where taken from the IA64
> values as this is an HPUX ELF system, which is actually much closer
> in behaviour to PA64 behaviour than the 32bit SOM environment.
> However, I'm easy and if anybody comes out with a categorical
> statement either way, I'll go that way.
>
> It does fix the problem with -R poluting the $deplibs variable.  All
> I need is some pointers to exactly which lines on code I should be
> looking at.

So you want to know where to set hardcode_into_libs? Look at
libtool.m4's hp section:
  ...
  hpux9* | hpux10* | hpux11*)
    # Give a soname corresponding to the major version so that dld.sl
refuses to
    # link against other versions.
  ...

Just add a case statement in the above so:
    case $host_os in
    hpux10* | hpux11* )
      hardcode_into_libs=yes
      ;;
    esac

--
albert chin (address@hidden)









reply via email to

[Prev in Thread] Current Thread [Next in Thread]