Re: [gimpwin-dev] g-libs renaming and DIR emulation
- From: Hans Breuer <hans breuer org>
- To: gimpwin-dev yahoogroups com
- Cc: gtk-devel-list gnome org
- Subject: Re: [gimpwin-dev] g-libs renaming and DIR emulation
- Date: Tue, 02 Oct 2001 00:21:18 +0200
At 17:52 01.10.01 -0400, Charles Wilson wrote:
>Tor Lillqvist wrote:
>First step is to make sure that the mingw and cygwin versions of libtool
>work properly. However, that seems to require an intermingled set of
>updates -- use the latest versions of auto*, cygwin-1.3.3 or later, etc.
>We're a-working on it...
Wow, this is exactly what I always wanted. First rely on a not yet
released part in your tool chain ... :-(
>> Note that this part of Hans's mail was based on a
>> misunderstanding. The micro version number isn't included in the DLL
>> name, it just looks like that as long as the micro version keeps
>> increasing while binary_age is kept at zero...
>Ah, I see. So the release-micro-version-number is tied in to the
>libtool-ish "revision-of-current-interface" number?
>> but what Hans didn't
Maybe I should have been clearer in my original mail or my first
My argueing was mainly against the libtoolish 'lib' prefix and
only beside that about the IMHO questionable (more unnecessary
downloads/updates than actually solved problems) of the addition
of the 'interface age number' in the dll name (but not in the
import library name which does not include version numbers at
And even shorter: are the libtool naming conventions _really_
appropriate for dlls builds with msvc for the _native_ win32
>I'll download current CVS and check. Where do I do to get the
>win32-branch? What repository, and branch tag do I use? Or should I be
>looking at HEAD?
It's HEAD. And before the currently discussed change it was building
from glib over pango and gtk up to Gimp head (at least with msvc and
short after my commits :)
-------- Hans "at" Breuer "dot" Org -----------
Tell me what you need, and I'll tell you how to
get along without it. -- Dilbert
] [Thread Prev