RE: HEAD libltdl/libltdlc ....

[Duft Markus]

Charles Wilson <> wrote:
> Ralf Wildenhues wrote:
>>> +     case "$host_os:$LTCC" in
>>> +     interix*:*wgcc* | winnt*:*wgcc*)
>>> +           use_wgcc=yes;;
>>> +     *)
>>> +           use_wgcc=no ;;
> 
> What is host_os=winnt*? how is this detected, and what are the
> criteria (e.g. I wouldn't want cygwin or mingw wrongly identified as
> winnt, even tho both run on the WindowsNT/2k/XP/[Vista?] platforms)
> 

Hi,

At our company we're using a patched config.guess in every build which
tells winnt if the compiler is wgcc. Otherwise specify it by hand ;o)

> 
>> 
>>> +/* windows / wgcc definitions of shared library import
>>> + * wgcc has some benefits over the cygwin/mingw dll handling:
>> 
>> You need to learn not to put down other people's hard work (Cygwin)
>> in your own, when supplying patches to an independent work (Libtool).
>> Except for a preference for GNU, Libtool should be neutral in
>> language. 
> 
> Meh, I'm not offended, because it's true there are some awkward issues
> with cygwin/mingw and DLLs.  However, criticism should be *accurate*.
> In cygwin/mingw you need specify neither dllexport NOR dllimport,
> because we have autoimport AND autoexport[*].  ( this has its own
> drawbacks and limitations, tho. See
> http://www.haible.de/bruno/woe32dll.html [*] also, using a .def file
> or any declspec(dllexport) turns off autoexport, which is usually The
> Right Thing To Do, but sometimes causes awkward and hard to track
> build errors...) 
> 

I'm really sorry if it came over wrong, i never ment to put down
somebody's work! It's just that there _are_ problems with dlls, not only
with mingw/cygwin but with wgcc too. I just implemented a path of
handling it that was correct for my company. After that i tried to
somehow extend that so that it would be valid for a broader range of
use-cases. I think it _has_ some benefits, but on the other hand, of
course gcc has other benefits...

> 
> Plus, what if the cygwin/mingw platforms fixed these issues?  Then
> we'd have to go around correcting these sorts of comments, in areas of
> libtool that are actually part of the wgcc port and unrelated to
> cygwin/mingw!  That's not nice.  So: don't comment on other
> platforms/implementations *within the code*.  That stuff belongs on
> the mailing list...where "why don't the cygwin/mingw libtools do it
> in the same nifty way that the wgcc libtool does" might actually lead
> to some fruitful cross-pollination...

Hm, yes, you're right.

> 
>>> + * one needs to specify dllimport only, not dllexport since the
>>> + * compiler exports automatically. Additionally one can pass
>>> + * dllimport *allways*, except when building the sources them-
>>> + * selfes. The compiler generates code to support dllimport in
>>> + * static libraries.
> 
> like this ^^^^.  It appears to me that wgcc (and NOT cl.exe?)
> implements some form of Bruno Haible's ideas from
> 
> http://www.haible.de/bruno/woe32dll.html
> and
> http://lists.gnu.org/archive/html/libtool/2006-09/msg00000.html
> 
> That's pretty cool...but Bruno suggested that the relevant support be
> implemented in libtool itself, not (as you appear to have done) in a
> wrapper around the compiler.

You're right, i really read Bruno's ideas, and i did some work to put
some of them into wgcc, but still, most of the wgcc code was written
before i found that site. I'm really sorry about that, since it would
have saved me lot's of work ;o)

> 
> Now, maybe I'm totally off-base (see the word "appears" above, twice).
> But if not, then it would be helpful to cygwin/mingw if the
> "Bruno-support" were implemented somehow within libtool for use by
>   wgcc. Then, cygwin/mingw might be able to leverage it too, rather
> than that functionality be buried somewhere within wgcc.  Is that a
> possibility? 

I really think, that handling of such things belongs into the compiler,
or in this case, wrapper, not in libtool. But this could be talked about
;o)
Another thing is, that now wgcc is somehow stable, i don't get too much
time working on it, but of course it's still open source ... ;o)

Cheers, Markus