[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #32383] NSClassFromString returns nil on MinGw if the string class

From: Nicola Pero
Subject: [bug #32383] NSClassFromString returns nil on MinGw if the string class is in a shared library and hasn't yet been used
Date: Wed, 09 Feb 2011 23:15:52 +0000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20101209 CentOS/3.6-2.el5.centos Firefox/3.6.13

Follow-up Comment #7, bug #32383 (project gnustep):

> -- is this what you are referring to in order
> to get the class loaded?

Yes and no.  Obviously referring to the class by name to get it
loaded kind of defeats the purpose of NSClassFromString() ;-)

I was referring to a standard trick that is used by
GNUstep programs on Windows to get DLLs to load correctly, which
refers to the entire DLL, not single classes.  I'm not sure
it would work in this case, though, I'd suggest you try.

For example, here is a copy&paste from the Renaissance (a GNUstep library)
manual that explains the trick in that
context --


"2.5.2 A small tweak to get it to work on Microsoft Windows

If you are only using the NSBundle Additions API, you can have a problem on
Microsoft Windows where you need to reference something inside a library to
get it linked in. The recommended workaround is to add the following line (or
a similar one) to your program (typically in your main.m file):

int (*linkRenaissanceIn)(int, const char **) = GSMarkupApplicationMain;

This defines a (dummy) function pointer called linkRenaissanceInt, and
generates a reference to GSMarkupApplicationMain which fixes the problem."


You could try doing something similar.  Identify a public
function in your DLL (or create a dummy one if missing).

Then, in your program, add a variable somewhere which is a 
function pointer, and initialize it with the function in the
DLL.  That references a symbol inside the DLL, and should cause
it to be loaded.

Does it help with your problem ?

> and i've always assumed that NSClassFromString would work
> at any time after the +load method (if it is implemented)
> had, or would have been called.

Yes, that is correct.  Brock's problem is that unless you drag
the class in somehow (by referencing it explicitly in your
source code, which IIRC causes the compiler to emit
a reference to the class), the class is not loaded, and the +load
method is not called.  Hence, when you call NSClassFromString(),
the class is not returned because it has not been loaded yet. :-(



Reply to this item at:


  Message sent via/by Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]