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
