World: r3wp

it took me just a few hours to have OpenGL running in an extension.... 
 which includes downloading all the OGL libs, and C compiler and 
stuff.

well, for those of you who are on devchat... you can see my (humorous) 
host-lib compilation post there, but for all others... just I just 
want to tell the world that... 

ITS ALIVE!!!! hehehahahahaha (evil grin and laugther)...


yep, I am on the short list of lucky individuals who got the host 
code, and it compiled the very first time I tried, so, mission accomplished 
and congratulations to Carl.

Maxim - on Windows, or some other system?

on windows... I  don't have my Mac setup for compiling yet.

Cyphre has reported compiling on code::blocks (don't know what OS)

OK, and what compiler have you used?

MSVC express edition... the free version.

so far, I really like the Device model, there's nothing like C OOP 
without the ++  

Exactly like the Amiga philosophy used to be.  :-)


I guess C++ coders will just be screaming as to why this isn't all 
classes and objects...  but its simple to code in any case

As long as the host code can be integrated into existing C++ code 
that's good for me. I'll be testing that ASAP.

Just being able to compile the host source with a C++ compiler would 
be sufficient - having declarations still work, for instance. The 
rest could be handled with shim code, basicaly what most of the host 
code is anyways.

So far, that is - see recent blogs for details.

I try all to keep away from C++ these days. It just gives to much 
hassles when going from one compiler to the next.

Guys, there's a trouble with OS-X or so it seems. Any experienced 
OS-X coder to help? Message from Carl on R3 Chat:


I must set OS X on the back burner... I've wasted far too much time 
on it.

There are three choices on it:
1. find a tool that does what 
I need
2. make a tool that does what I need
3. join all the sources 
into one large .c compile

Note that gcc -fvisibility=hidden does 
not work, nor does __private_extern__ wor
k either.

I've got to 
get on with other projects now. So, if you happen to find the soluti
on, 
let me know. (PS, yes, using GCC > 4.0.)

Some explanation:


Back to OS X, the problem is that they're not really libs, they're 
.a's. This ev
en appears to be the case when -dynamic-lib is used.

I 
should mention that I've had -dynamic-lib built OS X libr3 and host 
working fo
r several days. But, the libr3 isn't in the form I want, 
because it's not intern
ally linked and resolved. Examining it with 
nm it looks like just a concat of .o
 files.

Specifically, I want 
all internal symbols resolved, and I only want to export th
e library 
interface.

If OS X only builds libs (dynamic or otherwise) as concatenated 
.o files, that's
 a serious breach of coding ethics! There are two 
reasons:

1. it means I can link against the internal interfaces 
- a serious short circuit
 in code encapsulation rules.

2. it means 
I can discover the entire internal structure of any product... say 
I
 want to peek inside Photoshop to see how it does something.

If 
I nm a lib that's been properly prepared, I should only see its API, 
nothing
else. So far, this has not been possible on OS X.

I suppose 
I could easily confirm this by nm'ing some of the various apps I 
have
on OS X and checking if I can see their internals. Let's hope 
not.

Wow, that explains why Apple has to sue developers for using undocumented 
APIs instead of just not exporting them.

wow

Well, I think I found the solution - it looks like Carl's assesmenmt 
of dylibs was wrong. Solutions posted in reply to him in chat.

I've been under that impression myself... but haven't found an exact 
solution.