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

At 07:52 18.09.02 +0200, Sven Neumann wrote:
>Hi,
>
>Tor Lillqvist <[email protected]> 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