[Top][All Lists]
[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)
- Re: 64bit HPUX problems, ross . alexander, 2002/08/13
- Re: 64bit HPUX problems, ross . alexander, 2002/08/13
- Re: 64bit HPUX problems,
ross . alexander <=
- Re: 64bit HPUX problems, Albert Chin, 2002/08/13
- Re: 64bit HPUX problems, Albert Chin, 2002/08/13
- Re: 64bit HPUX problems, John David Anglin, 2002/08/13
- Re: 64bit HPUX problems, John David Anglin, 2002/08/13
- Re: 64bit HPUX problems, Jeff Law, 2002/08/14
- Re: 64bit HPUX problems, John David Anglin, 2002/08/14
- Re: 64bit HPUX problems, Jeff Law, 2002/08/14
- Re: 64bit HPUX problems, John David Anglin, 2002/08/14
- Re: 64bit HPUX problems, Jeff Law, 2002/08/14
- Re: 64bit HPUX problems, John David Anglin, 2002/08/14