Ticket #23 (closed defect: fixed)

Opened 8 months ago

Last modified 7 months ago

Tango build of GtkD on Win32 not working

Reported by: JJR Assigned to: Mike Wey
Priority: major Milestone: Pre-release 8
Component: Wrapper Version: 1.0
Keywords: Cc:

Description

There are a couple of errors when trying to build the gtkd library on windows. These are a result of assuming Tango/gtkd development is being done on linux only.

(1) Fix gtkc/paths.d for tango

Tango does not include the registry class that Phobos has, so gtkd does not compile here. A simple workaround is to assign a default path link for gtk+ dll directory and version out the registry portion. An alternate solution is port std.windows.registry from Phobos to Tango (a fair bit of work). A third option is to access the c registry functions from windows directly (still a fair bit of work).

(2) Fix the wrapper for glib/Spawn.d

Currently Spawn.d imports tango.stdc.posix.stdio which is linux only. This causes invalid definition errors during compile. The linux specific symbols are used in function execAsyncWithPipes in the same file with Tango. Apparently Phobos provides the symbols for win32 in std.c.stdio whereas Tango only provides them in tango.stdc.posix.stdio (linux only). This may be an issue with gtkd or Tango. Either way it needs to be fixed, perhaps reporting the problem to the Tango Team.

I worked around both these solutions with some version statements and was able to compile the cairo and gtkD examples using Tango. But we need more permanent fixes for these.

Attachments

gtkdPathTango.diff (3.1 kB) - added by Mike Wey on 02/16/08 12:15:58.
Tango support for paths.d

Change History

(follow-up: ↓ 2 ) 01/04/08 18:09:55 changed by Mike Wey

(2) gilb/Spawn.d only uses 'FILE* fdopen( int, char* )' from tango.stdc.posix.stdio, i found this ticket regarding fdopen and tango: http://www.dsource.org/projects/tango/ticket/237 , we could not import tango.stdc.posix.stdio and ad a extern(C) FILE* fdopen( int, char* ) for tango.

(in reply to: ↑ 1 ; follow-up: ↓ 4 ) 01/05/08 13:25:01 changed by JJR

Replying to Mike Wey:

(2) gilb/Spawn.d only uses 'FILE* fdopen( int, char* )' from tango.stdc.posix.stdio, i found this ticket regarding fdopen and tango: http://www.dsource.org/projects/tango/ticket/237 , we could not import tango.stdc.posix.stdio and ad a extern(C) FILE* fdopen( int, char* ) for tango.

Yes, it's a fairly simple fix. We can just add a the extern(C) and that will do it. Eventually, it might be better to use a more standard file function. I've been told that the reason fdopen is not available in Tango (on win32) is because it's a posix function and not a standard C function, so there's no guarantee that a library supports it on win32. Whether or not a compiler supports it on windows is dependent on the c library and compiler vendor. dm and dmd on win32 happen to provide it in dm's c library.

02/16/08 12:15:58 changed by Mike Wey

  • attachment gtkdPathTango.diff added.

Tango support for paths.d

02/16/08 12:23:59 changed by Mike Wey

I attached a diff with some changes to paths.d to supports Tango. I currently don't have a windows machine at hand to test it.



With the diff applied the Tango version will try to get the GTK_BASEPATH and return GTK_BASEPATH ~ "\\bin\\" and if it can't find the GTK_BASEPATH return an empty string to load the libraries fron the path. (or more specifically: http://msdn2.microsoft.com/en-us/library/ms682586(VS.85).aspx )



While the Phobos version will try the GTK_BASEPATH and and the register before returning the empty string.

(in reply to: ↑ 2 ) 02/18/08 17:42:42 changed by Mike Wey

Replying to JJR:

I've been told that the reason fdopen is not available in Tango (on win32) is because it's a posix function and not a standard C function, so there's no guarantee that a library supports it on win32.

Although fdopen is not in a version block. So it should be available on windows?

02/20/08 14:23:35 changed by Mike Wey

  • owner changed from JJR to Mike Wey.
  • status changed from new to assigned.

02/20/08 16:39:41 changed by Mike Wey

  • status changed from assigned to closed.
  • resolution set to fixed.

r438 closes this ticket.