Hi,

Tor Lillqvist writes:

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?

Hans Breuer has done it (at least at some time) using MSVC. Hans, can you tell us more?

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).)

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.

I doubt that this an ELF-only feature. To me it sounds like libtool on Windows is not doing the right things here. Anyway, we should try to get this issue resolved.

Salut, Sven

At 07:52 18.09.02 +0200, Sven Neumann wrote:

Hi,

Tor Lillqvist writes:

[...]

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.

I doubt that this an ELF-only feature. To me it sounds like libtool on Windows is not doing the right things here. Anyway, we should try to get this issue resolved.

My msvc build is not using libtool, so it is by no means is a libtool limitation. There two issue levels:

a) having a dependency against a library which can not be fully build before, because it self has unresolved symbols. The module to link against is known at compile time.

b) linking against a module which is runtime context dependent, i.e. the concrete module name is only known at runtime.

The following link does call 1) implicit linking and 2) explicit linking to be done from the programmer for every function.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/HT ML/_core_link_an_executable_to_a_dll.asp

I see three ways to resolve these issues for The Gimp :

1) build as static libs (this is how it's currently done cause it requires no source changes and only small makefile tweaking) 2) a) resolve circular dependencies at compile time by using a two step build process for any concerned library. The first step would only generate the required import libraries for other libraries. The second step than uses them to create the DLLs. This does not require source changes but would be a major pain in the ass in all the makefile.msc's.
b) write glue code as currently done for libgimpwigets for all required runtime linking.
3) Change the sources to have a clean dependency stack, i.e. no circular dependencies.

Regards, Hans

-------- Hans "at" Breuer "dot" Org ----------- Tell me what you need, and I'll tell you how to get along without it. -- Dilbert

Hi,

Hans Breuer writes:

3) Change the sources to have a clean dependency stack, i.e. no circular dependencies.

could you outline which circular dependencies you are talking about so that we can discuss if this solution would be feasible ?

Salut, Sven

At 17:50 19.09.02 +0200, Sven Neumann wrote:

Hi,

Hans Breuer writes:

3) Change the sources to have a clean dependency stack, i.e. no circular dependencies.

could you outline which circular dependencies you are talking about so that we can discuss if this solution would be feasible ?

As noted in a previous mail (which is 'held until the list moderator can review' cause I were subscribed with an older mail address) :

Building DLLs on win32 does require all symbols to be imported by it to be availble at compile time from anothers (already build) DLL. A first example :

app/config calls gimp_thumbnail_size_get_type()
gimp_preview_size_get_type()
gimp_image_base_type_get_type()
gimp_cursor_mode_get_type()
gimp_help_browser_type_get_type()
implemented by app/core/core-enums.c and gimp_unit_get_identifier()
implemented elsewhere.
So you need to build app/core before app/config and app/base, while app/base needs app/config to build and app/core needs app/base ...

Another concrete small example:

app/vectors implements GimpVectors which is derived form GimpItem implemented in app/core/gimpitem.c. app/core/gimpitem.c:gimp_item_name_changed uses the 'dynamic cast' GIMP_IS_VECTORS(item) which is implemented by app/vectors/gimpvectors.c:gimp_vectors_get_type().

So to build app/core you need app/vectors build first - and vice versa.

Such circular dependencies can be overcome by first building the export libraries only for both modules and finally use them in a second build step to create the DLLs.
But this is difficult to do portable, requires additional code to be written _and_ doesn't look like a clean solution. Shouldn't a module low in the depency stack depend on modules above it ?

The above are only small examples of the build problems with app/core. There is much more missing to make the appcore.dll. One issue are all the undo_push_ functions currently implemented by app/undo.c. There already seems to be a provision to solve this named GimpUndo, but almost all of app/undo.c requires porting to it.

Another issue which probably would require a special solution are the modules app/xcf, app/pdb and app/paint which depend on app/core but get initialized and destroyed by app/core/gimp.c. To solve this, one could either move The Gimp Object out of core or do some dynamic loading of the subsystems as suggested by the diagram attached to my previous mail and now available at:

http://hans.breuer.org/gimp/the-gimp-modular.htm

To sum up: The Gimp sources are already moving in the right direction [thanks Mitch and Sven there are less unresolved symbols with almost any cvs update] but at the moment the task to build all of gimp/app/* as separate dynamic loadable libraries is too huge for me. Also at the moment I don't even see a concrete benefit to do so. The latter will change to make such things like dynamic loadable tools possible for non ELF binaries (or at least for win32).

Regards, Hans

-------- Hans "at" Breuer "dot" Org ----------- Tell me what you need, and I'll tell you how to get along without it. -- Dilbert

Hi,

Hans Breuer writes:

app/config calls
gimp_thumbnail_size_get_type()
gimp_preview_size_get_type()
gimp_image_base_type_get_type()
gimp_cursor_mode_get_type()
gimp_help_browser_type_get_type()
implemented by app/core/core-enums.c and gimp_unit_get_identifier()
implemented elsewhere.
So you need to build app/core before app/config and app/base, while app/base needs app/config to build and app/core needs app/base ...

Another concrete small example:

app/vectors implements GimpVectors which is derived form GimpItem implemented in app/core/gimpitem.c. app/core/gimpitem.c:gimp_item_name_changed uses the 'dynamic cast' GIMP_IS_VECTORS(item) which is implemented by app/vectors/gimpvectors.c:gimp_vectors_get_type().

So to build app/core you need app/vectors build first - and vice versa.

all this is in the core and there's no need to build libraries in the different subdirectories of app. There's just one executable built here and thus circular dependencies between the different subdirectories are IMHO tolerable. In some cases they are even unavoidable (or only avoidable with unreasonable effort). I don't see why you are trying to build DLLs here at all. The Unix build doesn't create dynamic libaries in app neither.

Salut, Sven