[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, 9 Jul 2002 13:46:35 +0100 |
Albert,
Further investigation would suggest that a test like
if echo __LP64__ | $CC -E - | grep __LP__ > /dev/null; then
# do 32 bit SOM stuff
else
# do 64 ELF stuff
fi
The two problems I have encountered so far the lv_cv_file_magic
and sys_lib_search_path_spec.
Can somebody email we the latest beta of libtool so I can create
some patches because I don't have external CVS access.
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
03/07/2002 16:27
Please respond to
libtool
On Wed, Jul 03, 2002 at 04:06:16PM +0100, address@hidden
wrote:
> I don't think we can't really rely on cflags because because the user
could
> be using gcc, in which
> case we would have to look for __LP64__ (I think). I think it might be
> easier to check
> $host_cpu for hppa2.0w. However, a user wanting to build for 32bit would
> then have
> to set the build to hppa2.0n-hp-hpux*.
You can check CFLAGS. If they're using GCC, then have a separate case
statement to handle that:
case "$CFLAGS" in
*-DD64*)
if test "$GCC" = yes; then
else
fi ;;
*)
;;
esac
You can also try compiling something and running file/odump/elfdump on
the result to test if the default is a 32/64-bit object file (I
imagine the output should be different for 32/64-bit executables).
I'm leaning towards checking $CFLAGS though.
--
albert chin (address@hidden)