AW: Interix Shared Libraries

[Duft Markus]

Sure it would be great to see my changes incorporated in libtool! ;o)

I'll give func_win32_libid a try, although i'm not sure (after looking at it) 
if this will really work ;o// we'l see...

For the other hunks i'll generate another patch to make the changes wgcc only, 
and post that patch to sf.net again.

For results with wgcc:

./db/bin/libdb-4.3.so.dll
./glib/bin/libglib-2.0.so.0.800.3.dll
./glib/bin/libgmodule-2.0.so.0.800.3.dll
./glib/bin/libgobject-2.0.so.0.800.3.dll
./glib/bin/libgthread-2.0.so.0.800.3.dll
./interix-rpc/bin/librpc.so.0.0.0.dll
./libiconv/bin/libcharset.so.1.0.0.dll
./libiconv/bin/libiconv.so.2.2.0.dll
./libIDL/bin/libIDL-2.so.0.0.0.dll
./logtool/bin/liblogtool.so.0.0.0.dll
./mico/bin/idl2311.dll
./mico/bin/mico2311.dll
./mico/bin/micocoss2311.dll
./openldap/bin/liblber-2.3.so.0.2.12.dll
./openldap/bin/libldap-2.3.so.0.2.12.dll
./openldap/bin/libldap_r-2.3.so.0.2.12.dll
./openssl/bin/libcrypto.so.dll
./openssl/bin/libssl.so.dll
./ORBit2/bin/libORBit-2.so.0.0.0.dll
./ORBit2/bin/libORBit-imodule-2.so.0.0.0.dll
./ORBit2/bin/libORBitCosNaming-2.so.0.0.0.dll
./ORBit2/lib/bin/Everything_module.so.dll
./popt/bin/libpopt.so.0.0.0.dll
./pthreads-w32/bin/pthreadVC2d.dll
./readline/bin/history5.so.dll
./readline/bin/libhistory.so.dll
./readline/bin/libreadline.so.dll
./readline/bin/readline5.so.dll
./wgcc/bin/libpxwc.so.0.0.0.dll
./zlib/bin/libz.so.1.2.3.dll

All together it's exactly 162 dll's, but the rest is company internal stuff 
;o). Although not all of them
(but all of the above) are built using libtool/wgcc combo, one can see that it 
at least seems to work ;o)

I'll look into other tests, etc.

Regards, Markus

-----Ursprüngliche Nachricht-----
Von: Ralf Wildenhues [mailto:address@hidden 
Gesendet: Dienstag, 4. Juli 2006 13:00
An: Duft Markus
Cc: address@hidden
Betreff: Re: Interix Shared Libraries

Hello Markus,

* Duft Markus wrote on Tue, Jul 04, 2006 at 08:43:59AM CEST:
>  
> To bring some (good) news (i think ;o)). I wrote a little compiler 
> wrapper you may have heard of -> wgcc
> (www.sourceforge.net/projects/interix-wgcc) which behaves like gcc and 
> uses microsofts toolchain in the background. As of 0.6.0 the shared 
> library support is quite stable. I also created a little patch for 
> libtool 1.5.22 which allows building it shared with wgcc.

Is there interest in getting these changes merged into Libtool?
Support for newer interix major versions is interesting in any case.
Some of your changes look like they break the support for gcc, though, 
especially these are problematic:

| diff -rubB libtool-1.5.22.orig/libtool.m4 libtool-1.5.22/libtool.m4
| --- libtool-1.5.22.orig/libtool.m4    2006-07-03 07:48:02.000000000 +0200
| +++ libtool-1.5.22/libtool.m4 2006-07-03 07:49:41.000000000 +0200
| @@ -2361,7 +2361,8 @@
|  
|  interix*)
|    # 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)$'
| +  lt_cv_deplibs_check_method='pass_all'
| +  #lt_cv_deplibs_check_method='match_pattern /lib[[^/]]+(\.so|\.a)$'
|    ;;
|  
|  irix5* | irix6* | nonstopux*)
| @@ -3245,7 +3246,7 @@
|      _LT_AC_TAGVAR(hardcode_direct, $1)=no
|      _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'
| +    _LT_AC_TAGVAR(export_dynamic_flag_spec, $1)=''
|      # 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 @@ -5542,7 +5543,7 @@
|        _LT_AC_TAGVAR(hardcode_direct, $1)=no
|        _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'
| +      _LT_AC_TAGVAR(export_dynamic_flag_spec, $1)=''
|        # 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
| 

For the first hunk, you could probably try func_win32_libid (see Cygwin) when 
using wgcc (maybe also with gcc), but you'll have to test that.
The other hunks would probably work when special-cased for wgcc only (does the 
wrapper only handle C or also C++, Fortran, whatnot?).

I'd prefer to see test results for both wgcc and gcc (see README for how to 
report failures) before applying anything, and we'd need a copyright 
disclaimers (details off-list).

Cheers, and thanks for sharing this,
Ralf