Using the CVS head, in core/base/Headers/Additions/GNUstepBase/
GSObjCRuntime.h the constant GNUSTEP_WITH_DLL is checked and only if
BUILD_libgnustep_base_DLL is defined is __MINGW32__ checked as to
whether GS_EXPORT and GS_DECLARE are defined as __declspec(dllexport).
This seems to cause pr
If it doesn't build for you, what error are you getting ?
undefined references to gnustep-base functions and methods such as
NSLog. This occurs building any of the Tools, including autogsdoc and
cvtenc. I initially thought it was the GNUSTEP_WITH_DLL setting but
it now looks more like lib
Compiling and installing GNUstep on a WinXP SP2 machine works pretty
well, command line tools compile and run without problems.
In the past applications have built and at least run. On the most
recent (CVS head) version, my app dies attempting to load the bundle:
2005-07-07 09:15:25.000 App
c:\msys\1.0\home\leigh\Sources\FTDITest\ThummerComms.app
\ThummerComms.exe: Uncaught exception
NSInternalInconsistencyException, reason: NSApplication.m:217
Assertion failed in initialize_gnustep_backend. Can't load
object file from backend at path c:/GNUstep/System/Library/
Bundles/
Ok, attempting to take Richard's advice, I attempted to update from
the CVS repository, reconfigure core/make and core/base and then
build. It now seems building libgnustep-base.dll.a is broken, in that
it is now 145074 bytes long, whereas in the previous build it used to
be approximately 6
Attempting to load a class header file after adding a method to an
instance in Gorm (CVS) produces a warning that this will break
actions/outlets to/from instances. This seems to be a major problem
to use when developing, since we can expect to add methods in the
source after the initial cr
I've been trying to use GNUstep & MinGW to produce a working Win32
application. One of the goals is to have the application behave as a
first class Windows application, in particular to launch it from the
Start menu without requiring MSYS and openapp to be running. Our
target group of users
