libtool
[Top][All Lists]
Advanced

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

Re: Interix Shared Libraries


From: Ralf Wildenhues
Subject: Re: Interix Shared Libraries
Date: Tue, 4 Jul 2006 13:00:26 +0200
User-agent: Mutt/1.5.11-2006-06-19

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




reply via email to

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