Re: Interix support for libtool

[Ralf Wildenhues]

Hi Thorsten, Todd, others,

Just a couple of comments/questions to the patch:

* Thorsten Glaser wrote on Sun, Jul 03, 2005 at 09:22:03PM CEST:
> 
> 2005-07-03    Thorsten Glaser <address@hidden>
> 
>       * libtool.m4: Add support for Interix (Microsoft Services
>         for Unix) 3.0/3.5 based systems using gcc as compiler.
>         Originally from NetBSD(R) pkgsrc(R).
> 
> Index: libtool.m4
> ===================================================================
> RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v
> retrieving revision 1.314.2.95
> diff -p -u -r1.314.2.95 libtool.m4
> --- libtool.m4        3 Jul 2005 18:15:58 -0000       1.314.2.95
> +++ libtool.m4        3 Jul 2005 19:19:58 -0000
> @@ -725,6 +725,10 @@ AC_CACHE_VAL([lt_cv_sys_max_cmd_len], [d
>      lt_cv_sys_max_cmd_len=`expr $lt_cv_sys_max_cmd_len \/ 4`
>      lt_cv_sys_max_cmd_len=`expr $lt_cv_sys_max_cmd_len \* 3`
>      ;;
> +  interix*)
> +    # We know the value 262144 and hardcode it with a safety zone (like BSD)
> +    lt_cv_sys_max_cmd_len=196608
> +    ;;
>    osf*)
>      # Dr. Hans Ekkehard Plesser reports seeing a kernel panic running 
> configure
>      # due to this test when exec_disable_arg_limit is 1 on Tru64. It is not
> @@ -1451,6 +1455,18 @@ hpux9* | hpux10* | hpux11*)
>    postinstall_cmds='chmod 555 $lib'
>    ;;
>  
> +interix3*)
> +  version_type=linux
> +  need_lib_prefix=no
> +  need_version=no
> +  library_names_spec='${libname}${release}${shared_ext}$versuffix 
> ${libname}${release}${shared_ext}$major ${libname}${shared_ext}'
> +  soname_spec='${libname}${release}${shared_ext}$major'
> +  dynamic_linker='Interix 3.x GNU ld.so.1 (PE, like ELF)'
> +  shlibpath_var=LD_LIBRARY_PATH
> +  shlibpath_overrides_runpath=yes
> +  hardcode_into_libs=yes
> +  ;;
> +
>  irix5* | irix6* | nonstopux*)
>    case $host_os in
>      nonstopux*) version_type=nonstopux ;;
> @@ -2253,6 +2269,11 @@ hpux10.20* | hpux11*)
>    esac
>    ;;
>  
> +interix3*)
> +  # PIC code is broken on Interix 3.x, that's why |\.a not |_pic\.a here
> +  lt_cv_deplibs_check_method='match_pattern /lib[[^/]]+(\.so|\.a)$'
> +  ;;
> +
>  irix5* | irix6* | nonstopux*)
>    case $LD in
>    *-32|*"-32 ") libmagic=32-bit;;
> @@ -3157,6 +3178,17 @@ case $host_os in
>       ;;
>      esac
>      ;;
> +  interix3*)
> +    # Hack: On Interix 3.x, we cannot compile PIC because of a broken gcc.
> +    # Instead, shared libraries are loaded at an image base (0x10000000 by
> +    # default) and relocated if they conflict, which is a slow very memory
> +    # consuming and fragmenting process.  To avoid this, we pick a random,
> +    # 256 KiB-aligned image base between 0x50000000 and 0x6FFC0000 at link
> +    # time.  Moving up from 0x10000000 also allows more sbrk(2) space.  It
> +    # is ksh-specific code, but on Interix, the system /bin/sh is a pdksh.
> +    _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared $pic_flag $libobjs $deplibs 
> $compiler_flags ${wl}-h,$soname ${wl}--image-base,$((RANDOM % 16#1000 / 2 * 
> 16#40000 + 16#50000000)) -o $lib'

Hmm.  I'd prefer code which is not shell-dependent, on two grounds:
first, at some point in the future a different shell might be en vogue
there, second, it might eventually be achievable to cross-compile.

Maybe something cheap like this?

# 4096 = 0x1000, 262144 = 0x40000, 83886080 = 0x5000000
_LT_AC_TAGVAR(archive_cmds, $1)='img_base=`expr ${RANDOM-$$} % 4096 / 2 \* 
262144 + 83886080`~
                                 $CC -shared $pic_flag $libobjs $deplibs 
$compiler_flags ${wl}-h,$soname ${wl}--image-base,$img_base -o $lib'

Would it maybe be beneficial if Libtool allowed to specify an image
base?  (I'm not quite sure we want this -- unless a central authority
hands out image bases to library authors, there'll hardly be any _real_
gain).

> +    _LT_AC_TAGVAR(archive_expsym_cmds, $1)='sed s,^,_, $export_symbols 
> >$output_objdir/$soname.expsym && $CC -shared $pic_flag $libobjs $deplibs 
> $compiler_flags ${wl}-h,$soname 
> ${wl}--retain-symbols-file,$output_objdir/$soname.expsym 
> ${wl}--image-base,$((RANDOM % 16#1000 / 2 * 16#40000 + 16#50000000)) -o $lib'

Same here, also s/&&/~/.  Can't gcc use -version-script here?

(BTW: gcc should be able to use -version-script in many cases on BSDs as
well -- it'd be really cool if someone who knows BSD internals could
sort out the corner cases!  Libtool using --retain-symbols-file is
really a kludge.)

> +    ;;
>    irix5* | irix6*)
>      case $cc_basename in
>        CC*)
> @@ -3734,6 +3766,16 @@ if AC_TRY_EVAL(ac_compile); then
>      esac
>    done
>  
> +  case "$host_os" in

(No quotes necessary here.)

> +  interix3*)
> +    # Interix 3.x installs completely hosed .la files for C++, so rather
> +    # than hack all around it, let's just trust "g++" to DTRT.

What does this mean?  In what way are the files hosed?
(I'm asking because there might be a clean fix.)

> +    predep_objects_CXX=
> +    postdep_objects_CXX=
> +    postdeps_CXX=

If we need to go this way, then it's:
  _LT_AC_TAGVAR(postdep_objects, $1)=
  ..

Fortran should be able to use this as well..

> +    ;;
> +  esac
> +
>    # Clean up.
>    rm -f a.out a.exe
>  else
> @@ -4706,6 +4748,10 @@ AC_MSG_CHECKING([for $compiler option to
>        # DJGPP does not support shared libraries at all
>        _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)=
>        ;;
> +    interix3*)
> +      # Interix 3.x gcc -fpic/-fPIC options generate broken code.
> +      # Instead, we relocate shared libraries at runtime.
> +      ;;
>      sysv4*MP*)
>        if test -d /usr/nec; then
>       _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)=-Kconform_pic
> @@ -4796,6 +4842,12 @@ AC_MSG_CHECKING([for $compiler option to
>           ;;
>       esac
>       ;;
> +      interix*)
> +     # This is not gcc, but c89, which is MS Visual C++
> +     # We do not support c89 in MirPorts, so for GNU Libtool
> +     # special handling is needed. c89 does not support
> +     # generation of shared libraries at all.
> +     ;;

So does that mean this special handling is still needed here?

I have not checked your patch thoroughly: does it ensure, that in
AC_LIBTOOL_PROG_LD_SHLIBS
  _LT_AC_TAGVAR(ld_shlibs, $1)=no
is set for interix/non-gcc?

>        irix5* | irix6* | nonstopux*)
>       case $cc_basename in
>         CC*)
> @@ -4972,6 +5024,11 @@ AC_MSG_CHECKING([for $compiler option to
>        _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-fno-common'
>        ;;
>  
> +    interix3*)
> +      # Interix 3.x gcc -fpic/-fPIC options generate broken code.
> +      # Instead, we relocate shared libraries at runtime.
> +      ;;
> +
>      msdosdjgpp*)
>        # Just because we use GCC doesn't mean we suddenly get shared libraries
>        # on systems that don't support them.
> @@ -5240,6 +5297,10 @@ ifelse([$1],[CXX],[
>        with_gnu_ld=no
>      fi
>      ;;
> +  interix*)
> +    # XXX we just hope/assume this is gcc and not c89
> +    with_gnu_ld=yes
> +    ;;

Does
  test "$GCC" = yes
not work on interix?   What motivated this comment?

>    openbsd*)
>      with_gnu_ld=no
>      ;;
> @@ -5339,6 +5400,22 @@ EOF
>        fi
>        ;;
>  
> +    interix3*)
> +      _LT_AC_TAGVAR(hardcode_direct, $1)=yes
> +      _LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
> +      _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-rpath,$libdir'
> +      _LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
> +      # Hack: On Interix 3.x, we cannot compile PIC because of a broken gcc.
> +      # Instead, shared libraries are loaded at an image base (0x10000000 by
> +      # default) and relocated if they conflict, which is a slow very memory
> +      # consuming and fragmenting process.  To avoid this, we pick a random,
> +      # 256 KiB-aligned image base between 0x50000000 and 0x6FFC0000 at link
> +      # time.  Moving up from 0x10000000 also allows more sbrk(2) space.  It
> +      # is ksh-specific code, but on Interix, the system /bin/sh is a pdksh.
> +      _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared $pic_flag $libobjs 
> $deplibs $compiler_flags ${wl}-h,$soname ${wl}--image-base,$((RANDOM % 
> 16#1000 / 2 * 16#40000 + 16#50000000)) -o $lib'
> +      _LT_AC_TAGVAR(archive_expsym_cmds, $1)='sed s,^,_, $export_symbols 
> >$output_objdir/$soname.expsym && $CC -shared $pic_flag $libobjs $deplibs 
> $compiler_flags ${wl}-h,$soname 
> ${wl}--retain-symbols-file,$output_objdir/$soname.expsym 
> ${wl}--image-base,$((RANDOM % 16#1000 / 2 * 16#40000 + 16#50000000)) -o $lib'

Same as above.

> +      ;;
> +
>      linux*)
>        if $LD --help 2>&1 | grep ': supported targets:.* elf' > /dev/null; 
> then
>       tmp_addflag=

Another general comment: sometimes, the match is done for interix*,
sometimes for interix3*.  I have no idea in which way this is relevant,
or in which way interix major versions differ.  Restricting to 3 might
hinder upward compatibility in case the next version has little relevant
changes.  (I'll rely on your judgement here, if you say it is ok like
this.)

Yet another question: Is there incentive to fix gcc on interix, so that
it can actually create PIC code?

Out of curiosity: it'd be nice to know how much of the Libtool test
suite actually passes on Interix with these patches applied.

Thanks,
Ralf