Re: [Gimp-developer] Re: gimp 1.3.x for windows

At 07:26 18.09.02 +0300, Tor Lillqvist wrote:
>MecaT writes:
> > I wondering if ever gimp for windows with gtk2 will be builded? I am ot 
> > waiting for any date of release, but can you tell me - will be gimp 
> > 1.3.x ported on windows? 
>
From Gimp ChageLog :

2002-09-06  Hans Breuer  <[email protected]>

	* */*/makefile.msc : updated

>Hans Breuer has done it (at least at some time) using MSVC. Hans, can
>you tell us more?
>
Currently almost all of Gimp 1.3 form app/* needs to be build as 
static libraries cause otherwise there are unresolved externals
due to circular dependencies. 

A clean build for win32 would require to have a defined build 
order for all the parts, where a latter dll only depends on 
functions or variables from modules build earlier in the 
process.

The attached Dia diagram does show some of the current problems 
as well as kind of the desired build order, as I see it.
The 'higher level' libraries are not connected because there are
so many unresolved issues in the lower level libraries ...

>If I understand corrrectly, Hans had to build some of the libraries in
>GIMP 1.3 as static libraries, even if they really are supposed to be
>dynamic (DLLs). (They are shared libraries on Unix (but I think GIMP
>1.3 is developed only on Linux).)
>
Yupp. It goes so far that even one library from a lib*/ directory, 
i.e. libgimptool needs to be build as static lib. libgimpproxy is 
currently not build at all - but appears to be not required either.

>I ran into problems myself when I tried to build it (some months ago)
>(using autoconfiscation, libtool and gcc) because of problems with the
>libraries, the code as it currently is seems to assume ELF
>features. I.e., it that there can be unresolved symbols in shared
>libraries that get resolved at run time either from the main program
>or from another shared library. Or something like that, don't remember
>exactly.
>
That's an additional problem where the same library needs to resolve 
some of it's imported symbols depending on the process it runs in.

The only part I know of where this is the case is libgimpwidgets. 
Another candidate for it appears to be libgimp<tool/proxy> if it 
finally gets really used.

For libgimpwidgets there is the win32 specific libgimp-glue.c to 
implement the runtime linking. It probably could be simply ported
to gmodule usage if other OS need it too.

>(ELF is the object file format used by for instance Linux and
>Solaris. But there are several Unixes that don't use ELF. I wonder
>whether GIMP 1.3 has been built on some of these more obscure Unixes?)
>
Doesn't libtool on other platforms simply solve such problems by 
building all static libraries ?

	Hans