Re: [gimpwin-dev] Re: g-libs renaming and DIR emulation

[Charles Wilson <cwilson ece gatech edu>]

Hans Breuer wrote:
> At 11:56 01.10.01 +0300, Tor Lillqvist wrote:
>
> > ... 
> >
> >
> > > Renaming from glib-$(major.minor).dll
> > > to libglib-$(major.minor.micro).dll
> > Actually it was from 
> > 	glib-$(major).$(minor).dll 
> > to
> > 	libglib-1.3-$(lt_current_minus_age).dll

Recall that libtool *computes* $(major) and $(minor) from the lt_ c:r:a 
version numbers.  They don't (or shouldn't) have much relation to the 
package "major" and "minor" version numbers, and aren't necessarily 
equal to "1" and "3" just because the source code release happens to be 
called glib-1.3.10.tar.gz.

"libglib-1.3-$(lt_current_minus_age).dll" is good.  (I don't 
particularly like including the package revision number "-1.3-" in the 
DLL name, but that's a "top level" decision. It won't interfere with 
MSwindows-ish runtime loading.  Fine).

From my earlier message in this thread, recall that 
"lt_current_minus_age" is *exactly* what the libtool people recommend 
for windows.  (See earlier message for analysis and explanation)

> > [...]
> >
> > I think it is a good idea to have all three ways to build a certain
> > release of GLib DLLs produce the same name DLLs and import libraries.
> Huh ? The whole point of the 'cyg' prefix is to get a different name
> for probably incompatible versions of the 'same' dll.

It looks like Tor wasn't arguing against that.  Cygwin can still be 
'cyg'.  He's just saying that msvc-built and mingw-built should have the 
same prefix.  I'm not convinced, but (a) I'm not adamant either way, and 
(b) my opinion really doesn't matter. :-)

BTW, the latest mingw linker builds DLLs with the "auto-import" support 
mechanisms (a de-vectorized table of pointers for DATA exports) built 
in.  The msvc versions will not have that support.

Now, if you're using the __declspec(dllexport) modifiers on DATA exports 
when building under mingw, then this doesn't matter.  And of course you 
*have* to use them on DATA exports when building under MSVC, since 
microsoft doesn't support Paul Sokolovsky's 'auto-import' scheme that is 
implemented in current binutils on both cygwin and mingw.

Point: as long as you follow the "old" rules -- careful attention to 
__declspec(dll*port) -- everything will just work on both MSVC and 
mingw, and the DLL's will be interoperable.  No problems, even though 
the mingw DLL's will be slightly different.  BUT, if you decide set 
things up so that gtk-config (pkgconfig -gtk, whatever) explicitly uses 
the auto-import stuff when building under mingw, THEN you have to be 
careful -- the MSVC dll's won't be able to support that usage.

IOW, mingw DLL's can be used by mingw and MSVC, but MSVC dll's can only 
be used by mingw IFF mingw glib/gtk configurations do NOT access the 
added auto-import functionality.

> But I agree, that glib from msvc and mingw should be named equally
> as long as they are interchangeable. Though I still prefer to not
> declare libtools 'lib' prefix as new standard for the win32 platform. 
> AFAIK it is possible to use the previous naming scheme with libtool
> too.

See above discussion.

> > Eventually I probably would like to remove the makefile.mingw stuff
> > altogether, and always use auto*/configure/libtool when bulding with
> > gcc. 
> IMO this is the main difference in our approaches. I always try
> to keep the tool chain on windows as short as possible (everything
> provided by msvc and perl if there's no way around it).
>
> Maybe it's only my impression that with the standard  *nix tool
> chain the auto* stuff is always the weakest link. And if it breaks
> one often requires an auto* expert or at least knowledge with
> three additional languages (perl, m4, bash).
>
> With simple handwritten makefiles for msvc the chances to not
> break the win32 build are much higher. If it breaks it usually
> does at the def files, which should be simple to fix for
> everyone (and would probably be required for the auto*/mingw 
> built too ...

Having done a lot of porting from *nix to cygwin, I disagree.  auto* 
packages are MUCH easier to port, in general -- except when trying to 
build DLL's -- which is the whole point of the current discussion, I 
realize that.   However, with upcoming improvements to libtool, even 
THAT may soon be quite easy.

Custom makefiles seem to have a habit of bitrotting, IMO.

> > For MSVC users there will still have to be the parallell
> > makefile.msc files. (Unless one would require MSVC users to have
> > Cygwin installed, and use the build/win32/cl-wrapper program as
> > compiler. This does indeed work, at least almost...)

Urk, now *that* is ugly.  Okay, I dislike custom makefiles in general, 
but it seems that MSVC will always be an unwanted stepchild in this 
respect, and have its own set of .msc makefiles.

--Chuck