[gcompris-devel] Re: gcompris-devel digest, Vol 1 #424 - 5 msgs

[Christof Petig]

bruno patin schrieb:
> Bruno and me (BrunoP.) are usinng win32/cygwin. In previous mail I said 
> that I foresaw to port to mingw (in order to delete unnecessary code 
> from cygwin) in another step. It will ask for a mingw port of the the 
> glib/gnome etc libraries or perhaps the use of the dll directly (for the 
> last point, I'm not used to doing that).

The links I gave in my last mail had been for MinGW. A gdi (native 
Windows) port of gtk is widely used by many projects.

About three years ago I struggled to build a mingw+gtk based dll on 
cygwin and finally gave up (I only used Msys or Linux as compilation 
host since then). But things have improved a lot and even libtool does 
what I expect when I cross compile (transparent dll creation)!

This leaves the only windows inflicted madness to dllex/import 
decorations for static variables and the need to satisfy every symbol at 
build time.

>> gcompris uses the dlopen system call
>> Perhaps I miss a library again or a compilation option difers.
>>  
>>
> The dlopen call is part of the cygwin libs (a wrapper of the LoadLibrary 
> call)  but... in unix (linux), the dlopen call can use symbols defined 
> in an exec and not in its windows counter part (due to the very nature 
> of windows) and the dll produced by cygwin are closed. It means that 
> they have to solve all the links internally (there are limits to what I 
> say but it is the problem we encounter for now) so when I will be at 
> this step, we'll see. I think as I know the structure of gcompris that 
> at max we'll have to export suymbols of the main in external dll but the 
> plugins having only a limited number of entry points could be simple.

I usually tackled this problem by using a common dll (which provides the 
needed functions/variables (remember to dllimport-decorate variables in 
the headers (the __imp_* undefined problem)!) to both the main program 
and libraries.

This restructuring might be too much for gcompris and a more viable 
solution would be to use libtooldynamicloader (libltdl.a) or help the 
ld.so port to windows (giving windows the ability to resolve symbols at 
runtime). This is similar to the overlay support in windows 3.x days.

> beginning with glib and using X11 (I agree we'll have to pass to windows 
> but I prefer to work in the same world then step by step adopting some 
> new libraries). Perhaps am I too cautious  :-\ .

Cygwin is more like linux than like Windows the only thing it shares 
with windows is the kernel and the dll mechanism.

So a port to mingw (Windows without X11) will be a port to a totally 
different architecture. But since using cygwin allows to make one 
familiar with the build environment (you can target mingw while 
compiling with cygwin) it is a good first step.

Cross compilation linux->mingw (which is not easy without someone at 
hand to help) would be another choice (actually I regard cygwin->mingw 
as cross compilation, too).

> I will do this work step by step and as the gcompris package do use only 
> the gnome canvas I think there will be no problem or so I hope  :-) .

> there am I. I take as a goal to deliver something finished as a first 
> port mid january in order to begin with deleting X11 and then porting to 
> mingw. What do you think of this planning ?

I think the biggest obstacle is the dynamic loader issue. Once this is 
solved everything else is daily work.

    Christof