[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Fwd: Report: GNUstep on Win32]
From: |
Marc Ordinas i Llopis |
Subject: |
[Fwd: Report: GNUstep on Win32] |
Date: |
Tue, 24 Feb 2004 17:00:49 +0100 |
User-agent: |
Mozilla Thunderbird 0.5 (Windows/20040207) |
Hi everyone,
We are developing apps using GNUstep on windows, and I thought I'd try
to describe all the steps we follow to create our environment. We mostly
follow README.Mingw, so this is not in any way meant to substitute that
doc, it's just a disorganized tale of problems we found and how we
solved them.
--------------
Mingw and Msys
--------------
We currently use the current Mingw release (gcc 3.3.1, binutils 2.13.90,
w32api 2.5). Also, some of us use Msys 1.0.9 (I use emacs + eshell).
--------------
gnustep-make
--------------
Just to keep the discussion going, this is how we manage user paths on
Win32. We have modified user_home.c and NSUser.m so that they first try
to get a HOME environment variable (developers set this). If present,
they check that it does not contain spaces (as make barfs on those). If
not present or present with spaces, they get the user home from either
HOMEPATH or USERPROFILE as before, but it does not check for spaces as
in the last patch.
Installation goes perfectly.
--------------
libobjc
--------------
No problems there. We remove mingw's objc.dll and the objc headers, just
in case.
--------------
gnustep-base
--------------
We got XML to work by using the libxml2-2.4.12-1 package from
gnuwin32.sf.net instead fo the one in www.zlatkovic.com. We modified
the included xml2-config so it pointed to the correct dirs. To get it to
link we had to change GSXML.m in Additions and replace xmlFree() with
free(). Now it works perfectly, and we really needed it so that
autogsdoc could work.
For SSL we also got the packages from gnuwin32, but to the bundle to
compile we had to pass the options
--with-openssl-include=C:/GNUstep/System/Library/Headers
--with-openssl-library=C:/GNUstep/System/Library/Libraries
which are documented in SSL/configure but not in the main configure.
Also, I had to remove the ifneq ($(base),no) from SSL/GNUmakefile. I'd
correct all this but I don't know much about autoconf and friends.
We changed gdomap.c to not try to chdir to /tmp, as described by Wim
Oudshoorn in a recent message to gnustep-bug.
With this everything works great except gdnc, which tends to die
sometimes for reasons unknown.
--------------
gnustep-gui
--------------
We compiled it using the package libtiff-3.5.6b from gnuwin32. We also
got libjpeg from there, the one in package libtiff-3.5.6b-dep, as
tiff.dll needs jpeg62.dll and the jpeg package contains jpeg-62.dll
(notice the extra '-').
We are having lots of DLL problems, specially with paths, as some DLLs
want them in Win32 format and some in unix format. And there are so many
versions of them :) So we passed
--disable-jpeg --disable-png --disable-gsnd --disable-ungif
to configure and everything worked smoothly.
The linker complains about an undefined random() function in
NSBezierPath.m. To solve this, you have two options:
1. Change it to rand().
2. Include -liberty in libgnustep-gui-LIBRARIES_DEPEND_UPON in
Source/GNUmakefile.preamble.
I also tried to get Camaelon and it worked. It just had a small problem
getting the correct path for the theme bundle and I resolved it removing
all the post-processing NSFileManager does, like changing
C:/theme.bundle to ~C//theme.bundle. Those paths confuse Windows, and
then it refuses to load DLLs because it's such an spoiled brat!
--------------
gnustep-back
--------------
No problem at all, but the response time is a little long. If you just
change, in back/Source/win32/WIN32server.m in line 98 the parameter to
timerWithTimeInterval from 0.1 to 0.01, everything will be a lot more
responsive.
--------------
Nicola's tutorials
--------------
We've followed all of Nicola's tutorials and they work great, except the
one on Rennaissance which we haven't tried out yet.
--------------
Gorm
--------------
And just to show it off to the boss, we tried to get Gorm working :)
When compiling, we found out that palettes aren't prepared to be built
on Win32, so I include a patch for Instance/palette.make to make them
work as bundles do.
Also, an interesting thing is that palettes use classes exported from
the main program. This is possible to do on Win32, but the makefiles are
not prepared for it. I think not even dlltool is. I'll look into it later.
Anyway, we commented out the palettes and got it to compile and link,
but got a nasty error at startup, wich takes us to...
--------------
Debugging
--------------
We have the gdb-6.0 candidate from mingw installed and it works
perfectly with tools. With apps at init time the debugger stops with
Program received signal SIGSEGV, Segmentation fault.
0x77f9cec6 in ntdll!RtlpNtEnumerateSubKey () from ntdll.dll
Of course, as in any functions in ntdll.dll the stack is just trash. If
you continue, it'll do that three times and then go on as if nothing had
happened.
One curious thing about debugging is that if you have libobjc compiled
with debug info, every lib you load with objc classes in it *must* have
debug info. If not, the runtime complains about not finding classes.
And right now I'm stuck here. I can't find where the problem is, and I
have other work to do, so I guess I'll have just some minutes here and
there to keep trying this. It's a shame, because Gorm is an excellent
tool, and I'd love to see it working on Win32, even if it's just to show
off to some people here who are bent on using MFC for everything :)
Congrats and keep up the good work!
Marc Ordinas i Llopis,
Tragnarion Studios
Index: palette.make
===================================================================
RCS file: /cvsroot/gnustep/gnustep/core/make/Instance/palette.make,v
retrieving revision 1.22
diff -u -r1.22 palette.make
--- palette.make 16 Jan 2004 17:04:48 -0000 1.22
+++ palette.make 24 Feb 2004 14:06:50 -0000
@@ -53,10 +53,39 @@
# $(shell $(WHICH_LIB_SCRIPT) $(ALL_LIB_DIRS) $(ALL_PALETTE_LIBS) \
# debug=$(debug) profile=$(profile) shared=$(shared) libext=$(LIBEXT) \
# shared_libext=$(SHARED_LIBEXT))
+# On windows, this is unfortunately required.
+
+ifeq ($(WITH_DLL), yes)
+ LINK_PALETTE_AGAINST_ALL_LIBS = yes
+endif
+
+# On Apple, two-level namespaces require all symbols in bundles
+# to be resolved at link time.
+ifeq ($(FOUNDATION_LIB), apple)
+ LINK_PALETTE_AGAINST_ALL_LIBS = yes
+endif
+
+ifeq ($(LINK_PALETTE_AGAINST_ALL_LIBS), yes)
+PALETTE_LIBS += $(ADDITIONAL_GUI_LIBS) $(AUXILIARY_GUI_LIBS) $(BACKEND_LIBS) \
+ $(GUI_LIBS) $(ADDITIONAL_TOOL_LIBS) $(AUXILIARY_TOOL_LIBS) \
+ $(FND_LIBS) $(ADDITIONAL_OBJC_LIBS) $(AUXILIARY_OBJC_LIBS) $(OBJC_LIBS) \
+ $(SYSTEM_LIBS) $(TARGET_SYSTEM_LIBS)
+endif
+
+ALL_PALETTE_LIBS = \
+ $(shell $(WHICH_LIB_SCRIPT) \
+ $(ALL_LIB_DIRS) \
+ $(PALETTE_LIBS) \
+ debug=$(debug) profile=$(profile) shared=$(shared) \
+ libext=$(LIBEXT) shared_libext=$(SHARED_LIBEXT))
+
+ifeq ($(WITH_DLL),yes)
+PALETTE_OBJ_EXT = $(DLL_LIBEXT)
+endif
PALETTE_DIR_NAME = $(GNUSTEP_INSTANCE).palette
PALETTE_DIR = $(GNUSTEP_BUILD_DIR)/$(PALETTE_DIR_NAME)
-PALETTE_FILE_NAME = $(PALETTE_DIR_NAME)/$(GNUSTEP_TARGET_LDIR)/$(PALETTE_NAME)
+PALETTE_FILE_NAME =
$(PALETTE_DIR_NAME)/$(GNUSTEP_TARGET_LDIR)/$(PALETTE_NAME)$(PALETTE_OBJ_EXT)
PALETTE_FILE = $(GNUSTEP_BUILD_DIR)/$(PALETTE_FILE_NAME)
ifneq ($($(GNUSTEP_INSTANCE)_INSTALL_DIR),)
@@ -83,11 +112,23 @@
$(PALETTE_DIR)/$(GNUSTEP_TARGET_LDIR):
$(ECHO_CREATING)$(MKDIRS)
$(PALETTE_DIR)/$(GNUSTEP_TARGET_LDIR)$(END_ECHO)
+ifeq ($(WITH_DLL),yes)
+
+$(PALETTE_FILE) : $(OBJ_FILES_TO_LINK)
+ $(ECHO_LINKING)$(DLLWRAP) --driver-name $(CC) \
+ -o $(LDOUT)$(PALETTE_FILE) \
+ $(OBJ_FILES_TO_LINK) \
+ $(ALL_PALETTE_LIBS)$(END_ECHO)
+
+else # WITH_DLL
+
$(PALETTE_FILE) : $(OBJ_FILES_TO_LINK)
$(ECHO_LINKING)$(BUNDLE_LD) $(BUNDLE_LDFLAGS) $(ALL_LDFLAGS) \
-o $(LDOUT)$(PALETTE_FILE) \
$(OBJ_FILES_TO_LINK) \
$(ALL_PALETTE_LIBS)$(END_ECHO)
+
+endif # WITH_DLL
PRINCIPAL_CLASS = $(strip $($(GNUSTEP_INSTANCE)_PRINCIPAL_CLASS))
- [Fwd: Report: GNUstep on Win32],
Marc Ordinas i Llopis <=