Re: [Rhythmbox-devel] building rhythmbox for win32 with MinGW/MSYS

[Jonathan Matthew <jonathan d14n org>]

On Sun, Mar 08, 2009 at 11:04:00AM +0100, Brecht Sanders wrote:
> Hi,
> I was just trying if rhythmbox can be built on Windows using the MinGW  
> compiler under the MSYS build environment.
> I was able to build the minimum dependancies and was able to run configure.
> When compiling there were some obstacles which I believe should be  
> possible to solve.

Interesting.  A few people have tried, but I don't think anyone's
got this far before.

>
> - The most common problem is that DATADIR is defined in both gnome and  
> MinGW's objidl.h. I was able to work around this by putting #include  
> <windows.h> as the first line on each source file that had this problem.  
> However the DATADIR in shell/main.c won't work then because it won't be  
> a string anymore.

I don't know what to do about this.  

> - mkdir() only takes one parameter on Windows

Any code that wants to create directories should be using g_mkdir, most
likely.

> - I got an undefined reference to gnome_authentication_manager_init() in  
> metadata/rb-metadata-dbus-service.c

This call does not exist in svn trunk.

> - kill() doesn't exist on Windows, but it's used in  
> metadata/rb-metadata-dbus-client.c right before g_spawn_close_pid(), is  
> this necessary?

More or less.

> - some files include gdk/gdkx.h and use XID which doesn't exist on Windows

use #if defined(GDK_WINDOWING_X11) for this

> Anyway, after addressing all this points (admittedly sometimes in a  
> dirty way by commenting out some things) I was able compile everything.  
> However linking failed with the output below. Basically there are a lot  
> of undefined references. Any idea why this happens?

There are a few missing libraries and functions that don't exist there -
gdk_x11_display_get_user_time doesn't exist when using gdk-win32;
localtime_r doesn't exist on windows (I don't think it would be safe to
just use a non-threadsafe localtime() there); and gnome_vfs_volume_eject
probably just means something needs to link against libgnomevfs.

Linking works differently on different platforms.  I've forgotten
everything I ever knew about linking on windows, so all I can really do
is explain how the code is structured at the moment.  It's kind of a
mess, but it works well enough on linux and (apparently) solaris.

The 'rhythmbox' binary contains everything in the shell directory,
everything in the podcast directory, the plugin management code
(plugins/*.c), the source implementations (not interfaces) from the
sources directory, the python bindings (if enabled), 

The 'rhythmbox-core' shared library contains everything else that isn't
a plugin.  This uses some symbols from the rhythmbox binary, and that
uses some symbols from this library.

Plugins use symbols from both the rhythmbox binary and the
rhythmbox-core library.  Apparently it doesn't matter if they don't link
against either of those.

The rest of the link errors you're seeing are code in the rhythmbox
binary failing to see symbols in the rhythmbox-core library.  Maybe the
library isn't being built correctly, maybe the link order needs to be
rearranged.. I don't know.