NXConstantString missing
Vladimir Pouzanov
I've got some free time to work both on my ObjectiveC web framework
and pure linux cocotron builds. Got basic code working but lots of
source files fail with
error: cannot find interface declaration for 'NXConstantString'
I've got the corresponding .h file from gcc and put it into Foundation/
objc adding the required #import into every file that fails. Is there
any cleaner solution for this?
--
Sincerely,
Vladimir "Farcaller" Pouzanov
SCC
What compiler are you using? A stock gcc or the patched CDT one? The
Cocotron Objective-C runtime expects that you are using the patched
compiler. You should be able to apply the patches and build gcc on the
target system, but it's not a standard procedure we have setup at this
point.
Chris
Vladimir Pouzanov
11 авг. 2008, в 07:49, SCC написал(а):
Stock gcc 4.1.2. It's pretty useless to make a patched gcc at this
point.
I've got my helloworld.m building but failing at runtime. While
digging into the code I've noticed that
1) my build script failed to recognize *.s, so objc/platform_linux/
objc_msg_sendv.s has been never built
2) I've added -lobjc at some point, so it used wrong objc_msg_sendv
I've removed gcc objc and now missing two references:
__gnu_objc_personality_v0
__objc_class_name_NXConstantString
Should I try ripping that off my gcc's objc lib?
Vladimir Pouzanov
> I've removed gcc objc and now missing two references:
> __gnu_objc_personality_v0
> __objc_class_name_NXConstantString
Fixed NXConstantString by copying its implementation into cocotron's
objc. Still failing at __gnu_objc_personality_v0. If I get all
correct, cocotron does provide all the objc runtime, so it should not
depend on GCC's libobjc. So where do I miss __gnu_objc_personality_v0?
If I try to link with -lobjc it seem to override the runtime, failing
at calls like this:
ObjC:OBJCDoesNotRecognizeSelector:+[NSString (null)(134520992)]
Any hints?
Johannes Fortmann
though our runtime shares a few characteristics with the gnu runtime,
they are not identical.
Our runtime is designed to be as close as possible to the next
runtime, while preserving some simplicity/portability of the gnu
runtime. AFAIR (without looking deeply into our gcc code), we're
basically using all the next data structures, but a gnu-like message
dispatch mechanism, and the gnu way of registering new objective-c
modules via a constructor.
If you compile with the regular gcc, you will get gnu data structures.
That means that stuff like classes, selectors, methods and categories
will not be registered properly. The gcc programmers know that, and
helpfully inserted a marker function, _gnu_objc_personality_v0, to
make you realize that mistake at link time. Now, at this point, you
could add your own void _gnu_objc_personality_v0() somewhere. I'd be
genuinely surprised if it didn't break horribly at runtime (still, I'd
try it just for kicks :-) ).
The correct way to do this would be to build the cocotron gcc. Besides
the correct runtime behaviour, you'll get for..in, properties, and all
that other objc2.0 stuff. You want gcc-4.3.1 from the svn at
http://code.google.com/p/cocotron-tools-gpl3. Here's a guess at the
configure line:
/path-to-source/configure -v --prefix=/where-it-goes/ --with-gnu-as --
with-gnu-ld --without-newlib --disable-multilib --disable-libssp --
disable-nls --disable-libobjc --enable-libffi --enable-objc-gc --
enable-languages=c,objc,c++,obj-c++ --enable-checking=release
This may or may not work. But the chances of success are far greater
than with what you're trying.
Hope that wasn't too discouraging; I'm really interested if you'll get
this to work.
Cheers,
Johannes
Vladimir Pouzanov
11 авг. 2008, в 15:10, Johannes Fortmann написал(а):
> The gcc you use compiles code for use with the gnu runtime. Even
> though our runtime shares a few characteristics with the gnu runtime,
> they are not identical.
> Hope that wasn't too discouraging; I'm really interested if you'll get
> this to work.
To sum it up and to see that I'm getting everything correctly. The
runtime is being split into two parts. The invocation logics and other
objc stuff (that's provided as libobjc or cocotron's Foundation) and
metadata that's being compiled by GCC into .o files. Right?
So, it's absolutely not possible to use vanilla gcc with other runtime
- they wouldn't just work with each other.
That's pretty discouraging. I thought it would be possible to provide
an user with buildable (by their vanilla gcc) Foundation library.
Seems that now I'll have to write "build your own obj-c patched gcc
HOWTO" :)
PS: looking at svn I see binutils there. Guessing that stock binutils
is a non-go too?
Johannes Fortmann
On 11 Aug., 14:31, Vladimir Pouzanov <farcal...@gmail.com> wrote:
> 11 авг. 2008, в 15:10, Johannes Fortmann написал(а):
>
> > The gcc you use compiles code for use with the gnu runtime. Even
> > though our runtime shares a few characteristics with the gnu runtime,
> > they are not identical.
> > ...
> > Hope that wasn't too discouraging; I'm really interested if you'll get
> > this to work.
>
> To sum it up and to see that I'm getting everything correctly. The
> runtime is being split into two parts. The invocation logics and other
> objc stuff (that's provided as libobjc or cocotron's Foundation) and
> metadata that's being compiled by GCC into .o files. Right?
> So, it's absolutely not possible to use vanilla gcc with other runtime
> - they wouldn't just work with each other.
>
> That's pretty discouraging. I thought it would be possible to provide
> an user with buildable (by their vanilla gcc) Foundation library.
worked around.
By providing your own OBJCInitializeProcess and _objc_execClass
functions, you should be able to initialize the cocotron runtime from
the GNU structures instead of the Next structures.
The differences between the data structures are very subtle, so you
might be able to keep a lot of code. You would have to look at how the
gnu runtime's execClass is called (specifically, how the struct
looks), then take a few pointers from OBJCInitializeProcess_Darwin
(note that there, we use the fact that our module struct is binary-
compatible to the one the darwin gcc produces; that might well be true
for the GNU runtime, too). It certainly would involve a bit of trial-
and-error, but it should be possible.
However, that still won't get you the missing compiler features. The
FSF gcc doesn't support properties, for..in, and I'm not sure about
@synchronized and @try/@catch. So I'd try to use the patched gcc if I
were you.
> Seems that now I'll have to write "build your own obj-c patched gcc
> HOWTO" :)
building, just ask here.
> PS: looking at svn I see binutils there. Guessing that stock binutils
> is a non-go too?
F and -framework, so we can use them with Xcode. If you don't need
that functionality, you won't need the binutils.
Good luck,
Johannes
SCC
On Aug 11, 11:45 am, Johannes Fortmann
> The runtime thing isn't the only problem here; in fact, it could be
> worked around.
> By providing your own OBJCInitializeProcess and _objc_execClass
> functions, you should be able to initialize the cocotron runtime from
> the GNU structures instead of the Next structures.
> The differences between the data structures are very subtle, so you
> might be able to keep a lot of code. You would have to look at how the
> gnu runtime's execClass is called (specifically, how the struct
> looks), then take a few pointers from OBJCInitializeProcess_Darwin
> (note that there, we use the fact that our module struct is binary-
> compatible to the one the darwin gcc produces; that might well be true
> for the GNU runtime, too). It certainly would involve a bit of trial-
> and-error, but it should be possible.
of areas too, you'd have to modify dispatch and selector unique-ing at
the minimum.
I would highly recommend using the gcc patches.
Chris
Vladimir Pouzanov
11 авг. 2008, в 19:39, SCC написал(а):
It wasn't that hard. GCC is mostly working (some Win32 compiler issue
is reproducible on linux too, see ticket 141). Cocotron builds
correctly (I still have to add several sources to CMake build file,
but it should work). Test source is running:
$ ./test
ObjC:internal error, unable to locate NSUserDefaults.plist,
path=(null), bundle at ../cocotron/Contents/Resources
2008-08-05 00:43:46.038 [6309] hello, linux cocoa world!
Now it's time for more fun, like implementing missing api :)
PS: I think I'll just make combined gcc-cocotron installation script,
so users could get both patched gcc and runtime in one package.