libtool
[Top][All Lists]
Advanced

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

Re: PA64 and libtool


From: ross . alexander
Subject: Re: PA64 and libtool
Date: Thu, 15 Aug 2002 12:12:13 +0100

>> My interpretation of Jeff's comment is now, don't go looking for a 64bit
>> build environment, but do check based on the output of $CC.

> No, these are not mutually exclusive.  config.guess is only usable to
> discover properties about the build machine.  When build and host differ,
> it is not possible to do any tests (CC or otherwise) to discover
> properties about the host or target.

> The configure options override config.guess (ie., if a user configured
> libtool using "--build=hppa2.0w-hp-hpux11.00", it would be incorrect for
> configure to change this to "build=hppa64-hp-hpux11.00").

As far as I know, --build will override config.guess.  This is one of the
reasons not to do any tests in libtool, because override the specified
build.  If the actual compile environment is different, then that is the
user's fault, not our :-(

As for the hppa64 vs hppa2.0w debate, it seems clear that currently returns
the potential environment, not that actual build environment.  This pretty
much means hppa2.0 == hppa2.0n == hppa2.0w as far as autoconf et al is
concerned.  The only useful thing about hppa2.0w is that if we do test
in libtool the output of $CC then we only do it if the OS can support 64bit
executing (assuming host==build).

If we do this, then the code in each libtool macro would look something
like this

case $host_cpu
ia64)
  Do IA64 stuff
hppa*64*)
  Do 64bit stuff
hppa2.0w)
  Check for __LP64__ (for example)
    Do 64bit
  else
    Do 32bit stuff
hppa2.0 | hppa2.0n | hppa1.1 | hppa1.0 | *)
  Do 32bit stuff
esac

Personally I find this somewhat long winded and ugly.  I think I will
submit a patch for libtool with
just checks $host_cpu and anybody who wants to build for 64bit has to
explicitly set --build.
I know this isn't perfect by any means, but it does mean we something in
libtool-1.4e so
people can start building standand packages.

I actually find the 64bit ELF environment better than the 32bit SOM one.  I
has considerably less
quirks for a start.

Cheers,

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"


                                                                                
                                              
                      "John David                                               
                                              
                      Anglin"                  To:       address@hidden         
                                
                      <address@hidden        cc:       address@hidden, 
address@hidden, address@hidden,    
                      .nrc.ca>                  address@hidden                  
                                  
                                               Subject:  Re: PA64 and libtool   
                                              
                      14/08/2002 17:39                                          
                                              
                                                                                
                                              
                                                                                
                                              




> My interpretation of Jeff's comment is now, don't go looking for a 64bit
> build
> environment, but do check based on the output of $CC.

No, these are not mutually exclusive.  config.guess is only usable to
discover properties about the build machine.  When build and host differ,
it is not possible to do any tests (CC or otherwise) to discover
properties about the host or target.

The configure options override config.guess (ie., if a user configured
libtool using "--build=hppa2.0w-hp-hpux11.00", it would be incorrect for
configure to change this to "build=hppa64-hp-hpux11.00").

> So
>
> a) MUST use hppa*64* if --build=hppa64-hp-hpux11.?? (1)

Yes but it is possible to consider doing away with hppa64 (see below).
The tests in libtool.m4 actually use the "host" triplet for configuration.

> b) SHOULD check in either libtool or config.guess based on $CC (2)

I would prefer config.guess.  It's seems simpler and applicable to other
packages that may need to know the architecture.

If we do away with hppa64, then libtool will have to do some kind of
compilation check to determine which arch to configure for.  This won't
work in a cross configuration.  So, some other configure option would
be needed (--with-arch=????).  There is a proposed patch to gcc to add
such a capability to its configuration process to set compiler defaults.
The options handled by the gcc patch are: --with-cpu, --with-schedule,
--with-arch, --with-tune, and --with-float.  --with-schedule is used
on the PA.  The purpose of it is similar to --with-tune on other ports.

> (1) Since under autoconf-2.5x, build will automatically set host unless
> specified.

Right.  I was confused here.  In autoconf-2.13, it's the other way
around (host sets build) :-(  This is the format binutils and gcc
currently use.

> (2) This can be done either by cpp __LP64__, as .LEVEL or file a.out.

There is a lot of confusion about the interpretation of the first
element of a configuration triplet.  It is referred to as the "cpu"
portion but it is more closely related to the code architecture
than to a specific cpu.

It is possible to specify compiler options that change the default
architecture.  It's also possible to specify --build=hppa1.1-hp-hpux11.00
on a 64-bit capable PA cpu.  This may be because a user wants to
generate code that runs on older machines.

I think either .LEVEL or file a.out can be used.  The file command
provides more information but it is not in as nice a format.

> Questions
>
> a) If we don't use config.guess,
>
> *1) do we put the checks in each function?
> *2) in some common code (maybe _LT_AC_LOCK) and modify $host_cpu?
> *3) in some common code and set some other flag (eg HPUX_HPPA_MODE)?

See the IA64 ABI check.

> b) Have I missed anything?
> c) Any other problems?
>
> I personally perfer changing config.guess, and using $host_cpu, because
> this
> makes the code in libtool.m4 very straight forward (see below).

I think there are a few more things to change but I agree.

> --- libtool.m4.orig     2002-07-29 11:17:16.000000000 +0100
> +++ libtool.m4    2002-08-14 10:33:19.000000000 +0100
> @@ -1215,32 +1215,46 @@ gnu*)
>  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
> -  if test "$host_cpu" = ia64; then
> +  case $host_cpu in
> +  ia64*)
>      hardcode_into_libs=yes
>      dynamic_linker="$host_os dld.so"
>      shlibpath_var=LD_LIBRARY_PATH
>      shlibpath_overrides_runpath=yes # Unless +noenvvar is specified.
>      library_names_spec='${libname}${release}.so$versuffix ${libname}
${release}.so$major $libname.so'
>      soname_spec='${libname}${release}.so$major'
>      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
> -  else
> +    ;;
> +  hppa*64*)
> +    hardcode_into_libs=yes
> +    dynamic_linker="$host_os dld.sl"
> +    shlibpath_var=LD_LIBRARY_PATH # How should we handle SHLIB_PATH
> +    shlibpath_overrides_runpath=yes # Unless +noenvvar is specified.
> +    library_names_spec='${libname}${release}.sl$versuffix ${libname}
${release}.sl$major $libname.sl'
> +    soname_spec='${libname}${release}.sl$major'
> +    sys_lib_search_path_spec="/usr/lib/pa20_64 /usr/ccs/lib/pa20_64"
> +    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'
> -  fi
> +    sys_lib_search_path_spec="/lib /usr/lib /usr/ccs/lib"
> +    sys_lib_dlsearch_path_spec=$sys_lib_search_path_spec
> +  esac
>    # HP-UX runs *really* slowly unless shared libraries are mode 555.
>    postinstall_cmds='chmod 555 $lib'
>    ;;
>
>  irix5* | irix6* | nonstopux*)
>    case $host_os in
> @@ -1941,19 +1955,26 @@ freebsd*)
>  gnu*)
>    lt_cv_deplibs_check_method=pass_all
>    ;;
>
>  hpux10.20* | hpux11*)
>    lt_cv_file_magic_cmd=/usr/bin/file
> -  if test "$host_cpu" = ia64; then
> +  case $host_cpu in
> +  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_test_file=/usr/lib/hpux32/libc.so
> -  else
> +    ;;
> +  hppa*64*)
> +    lt_cv_deplibs_check_method='file_magic ELF-64 shared object file -
PA-RISC [[0-9]].[[0-9]]'
> +    lt_cv_file_magic_test_file=/usr/lib/pa20_64/libc.sl
> +    ;;
> +  *)
>      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_test_file=/usr/lib/libc.sl
> -  fi
> +    ;;
> +  esac
>    ;;
>
>  irix5* | irix6* | nonstopux*)
>    case $host_os in
>    irix5* | nonstopux*)
>      # this will be overridden with pass_all, but let us keep it just in
case
>
>
>
---------------------------------------------------------------------------------

>
> 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"
>
>
>


--
J. David Anglin                                  address@hidden
National Research Council of Canada              (613) 990-0752 (FAX:
952-6605)









reply via email to

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