[gimpwin-dev] glib under mingw32 debian cross compiler, problem with windres : gmodule-win32res.lo: file not recognized: File format not recognized

[Tor Lillqvist <tml iki fi>]

James Michael DuPont writes:
> Hopefully we can get all the cool gnome apps running under windows

Correct me if I am wrong, but doesn't it go like this:

GNOME is intended to provide on Unix some of the (high-level) features
in Windows, that on Windows are implemented with stuff like COM and
OLE (I am really not an expert in this issues, so bear with me if I
babble). It does this using CORBA at the low level.

Why would one then need to port GNOME as such to Windows? It wouldn't
interoperate with native Windows applications anyway, i.e. you could
not include some object that interfaces through COM/OLE/whatever in a
GNOME container that uses CORBA, or vice versa.

Or is it just eye candy you are after ;-)

> The problem is with the resource compiler : 
> gmodule-win32res.lo   and
> gobject-win32res.lo   are dependant on the command :
> ../build/win32/lt-compile-resource gmodule.rc gmodule-win32res.lo
> which complains that :
> Using zero as build number

That is just an informational message, not a warning or error.

> gmodule-win32res.lo: file not recognized: File format not recognized

The .lo file that the lt-compile-resource script produces is a
"libtool object file", which actually is a small text file that
contains some assignment lines. (Read lt-compile-resource, it's a
relatively simple shell script.) 

At least .lo files are small text files on my setup (on Windows, not
cross-compilation). Maybe with cross-compilation from Unix, .lo files
are actually symbolic links to the real .o files? Or just .o files
with another name? If so, you need to modify the lt-compile-resource
script to just do a symlink or rename instead of creating the small
text file. Or you can drop the resource file stuff from the makefiles,
it's not essential for the DLLs.

Why is this resource crap needed at all, you might ask? I want to
include version resources in the GLib etc DLLs. (I.e. what you see in
Explorer if you right-click a DLL and select Properties:Version.) 

It's just a hack that has evolved over time. Without feedback, I
haven't bothered to try to improve it. As the compile-resource script
says:

# This is just my (tml iki fi) idea, if somebody comes up with a
# better way to generate version number resources, don't hesitate to
# suggest.

Please do try. The essential feature the (lt-)compile-resource script
provides to me is that after a "make clean", the resource file gets
recompiled with a bumped build number. (This happens only if the build
number "stamp" file is present, which it is supposed to be only on the
"official packager's" machine, so that new releases of "official" DLLs
can be recognized from increasing version number resources. Of course,
"official" is a silly word to use without offices or officers.)

--tml