Hello,

Could someone perhaps post (or e-mail me) with their own EXACT steps that they took to compile GDC on their computer? I'm having a hell of a time trying to get things working. I can compile GDC 0.8, no problem. I can compile a D file to an object (.o) file, no problem. I can compile and link standalone D programs that don't require anything but whats provided in phobos, no problem.

However, I would like to link to SDL which I have installed via fink. But when I go to compile/link, I get the following error:

$ gdc test.d -L/sw/lib -lSDL

/usr/bin/ld: /usr/lib/crt1.o illegal reference to symbol: __objcInit defined in indirectly referenced dynamic library /usr/lib/libobjc.A.dylib
collect2: ld returned 1 exit status

So then, I think "okay thats in the Obj-C runtime, I guess I have to link that in". So then I do:

$ gdc test.d -L/sw/lib -lSDL -lobjc

and it links fine. But then when I go to execute it, it vomits a bunch of stuff to the terminal that looks like:

$ ./a.out

kCGErrorInvalidConnection : CGSNewWindow: Invalid connection
2004-11-19 03:56:05.865 a.out[5831] _NXCreateWindow: error creating window (1002)
kCGErrorInvalidConnection : CGSSetWindowProperty: Invalid connection
kCGErrorInvalidConnection : CGSInvalidateWindowShadow: Invalid connection
kCGErrorInvalidConnection : CGSSetWindowListAlpha: Invalid connection
kCGErrorIllegalArgument : CGSLockWindowRectBits: Invalid window
kCGErrorFailure : Failed to create window context device.
kCGErrorFailure : CGWindowContextCreate: failed to create context.
2004-11-19 03:56:05.930 a.out[5831] _initWithWindowNumber: error creating graphics ctxt object for ctxt:0, window:-1
kCGErrorFailure : CGContextResetClip: invalid context

	...which goes on and on, ending with:

2004-11-19 03:56:08.817 a.out[5831] *** _NSAutoreleaseNoPool(): Object 0x1219ac0 of class _NSThemeWidget autoreleased with no pool in place - just leaking
2004-11-19 03:56:08.817 a.out[5831] *** _NSAutoreleaseNoPool(): Object 0x1219eb0 of class NSView autoreleased with no pool in place - just leaking
2004-11-19 03:56:08.817 a.out[5831] *** _NSAutoreleaseNoPool(): Object 0x1211bc0 of class NSIdEnumerator autoreleased with no pool in place - just leaking
2004-11-19 03:56:08.818 a.out[5831] *** _NSAutoreleaseNoPool(): Object 0xa3075aa4 of class NSCFString autoreleased with no pool in place - just leaking

So, how are you guys getting the compiler to work on your systems? How are you linking against system libraries? I know I'm still on Jaguar (10.2.8), but I can't afford to upgrade right now. Besides, I don't see why it wouldn't work unless someone can enlighten me as to why.

Thanks very much in advance you for your time!

- Brian :-(
email antigrav at sbcglobal dot net



-----------------------------------
PS: here are my exact steps I took:
-----------------------------------

mkdir gdc
cd gdc

curl -O http://home.earthlink.net/~dvdfrdmn/d/gdc-0.8.tgz
curl -O ftp://gcc.gnu.org/pub/gcc/releases/gcc-3.3.4/gcc-{core,java,g++}-3.3.4.tar.bz2

for i in *.tar.bz2; do tar jxvf $i; done

cd gcc-3.3.4/gcc
tar zxvf ../../gdc-0.8.tgz
patch -p1 < d/patch-gcc-3.3.x

cd ..
mkdir build.gdc
cd build.gdc

../configure --prefix=/opt/gcc/3.3.4 --enable-languages=c,c++,java,d
make
mkdir -p /opt/gcc/3.3.4
make install

mkdir phobos
cd phobos

export PATH="/opt/gcc/3.3.4/1:$PATH"
../../gcc/d/phobos/configure --prefix=/opt/gcc/3.3.4
make
make install

On Fri, 19 Nov 2004 05:14:33 -0600, Brian Chapman <nospam-for-brian@see-post-for-address.net> wrote:
>
> export PATH="/opt/gcc/3.3.4/1:$PATH"
>

Sorry, that was a typo. I meant:

export PATH="/opt/gcc/3.3.4:$PATH"


...for those that don't know, that's just to make sure the new compilers are in the front of the path so they are found before the system compilers.

Brian Chapman wrote:

> Could someone perhaps post (or e-mail me) with their own EXACT steps that  they took to compile GDC on their computer? I'm having a hell of a time  trying to get things working. I can compile GDC 0.8, no problem. I can  compile a D file to an object (.o) file, no problem. I can compile and  link standalone D programs that don't require anything but whats provided  in phobos, no problem.

http://www.algonet.se/~afb/d/Makefile

make prep
make gdc
sudo make gdc-install
make phobos
sudo make phobos-install
make clean

Tested with Mac OS X 10.3 and GCC 3.4 (and 3.3 too),
looks like it is more or less identical to yours.


> However, I would like to link to SDL which I have installed via fink. But  when I go to compile/link, I get the following error:
> 
> $ gdc test.d -L/sw/lib -lSDL
> 
> /usr/bin/ld: /usr/lib/crt1.o illegal reference to symbol: __objcInit  defined in indirectly referenced dynamic library /usr/lib/libobjc.A.dylib
> collect2: ld returned 1 exit status
> 
> So then, I think "okay thats in the Obj-C runtime, I guess I have to link  that in". So then I do:
> 
> $ gdc test.d -L/sw/lib -lSDL -lobjc

Correct. SDL for Mac OS X currently requires Cocoa.

You could also run the command: "sdl-config --libs" ?
(unfortunately, that does not work with SDL.framework)

I prefer to not use Fink, since you end up with links
to /sw hierarchy that makes it tough for the end user.

(i.e. I use Fink programs, but link towards the System)


> and it links fine. But then when I go to execute it, it vomits a bunch of  stuff to the terminal that looks like:
> 
> $ ./a.out

That is a problem with SDL (not D). You need to link with SDLmain,
or else the objective-C runtime won't be initialized properly...

This means that your D main can *only* call upon SDLmain,
everything else can't be done until *it* calls your function:

extern(C) int SDL_main(int argc, char **argv);

Unfortunately, the SDLmain function is called main (such a hack!),
so you need to patch that to not conflict with D's main function.
(code for such a patched SDLmain is in the sdl/ directory below)


> So, how are you guys getting the compiler to work on your systems? How are  you linking against system libraries? I know I'm still on Jaguar (10.2.8),  but I can't afford to upgrade right now. Besides, I don't see why it  wouldn't work unless someone can enlighten me as to why.

I have some source code SDL and OpenGL, for D (gdc) on Mac OS X at:
http://cgi.algonet.se/htbin/cgiwrap/afb/cvsweb/d/

It has a Makefile all the linker flags and such, that you need...
(you can download everything as a .zip, from the CVS link above)

It runs a few SDL samples and GL "gears", without problems.
Using SDL 1.2.7 and OpenGL 1.2.1, also has a modern GLUT


The same code should also work on Linux, as far as I know.

--anders

Anders!

Thank you very much for helping me out! With the information you provided I was able to get it linking to the system librarys and running with no problems.


On Fri, 19 Nov 2004 12:38:37 +0100, Anders F Björklund <afb@algonet.se> wrote:
>
> Correct. SDL for Mac OS X currently requires Cocoa.
>
> You could also run the command: "sdl-config --libs" ?
> (unfortunately, that does not work with SDL.framework)
>
> I prefer to not use Fink, since you end up with links
> to /sw hierarchy that makes it tough for the end user.
>
> (i.e. I use Fink programs, but link towards the System)

Oh, I agree. I just use fink for simplifying development. If I build an .app, then I usually embed SDL so the user doesn't even have to have the SDL runtime installed. It adds about 400k (uncompressed) to the bundle though.


> That is a problem with SDL (not D). You need to link with SDLmain,
> or else the objective-C runtime won't be initialized properly...
>
> This means that your D main can *only* call upon SDLmain,
> everything else can't be done until *it* calls your function:
>
> extern(C) int SDL_main(int argc, char **argv);
>
> Unfortunately, the SDLmain function is called main (such a hack!),
> so you need to patch that to not conflict with D's main function.

Doh! I had forgotten about SDLmain. I was actually in the process of customizing my own version a little so I knew I didn't want to link to the one thats built in fink, but then I got focused on gettnig D to work and forgot about SDLmain all together. LOL.

So many levels of indirection! I take it, it goes like this:

At run time, the C runtime calls main (int,char**),
which is in the D runtime, a.k.a. Phobos.

Phobos, in turn, calls your D program's main (char[][]),
which we need to call SDLmain's main (int,char**),
of which we rename to something else to avoid conflict

So then SDLmain's renamed main calls SDL_main (int,char**),
which, of course, we need to provide as usual.

No wonder I got confused! ;-)

Well thanks again man. I was about to get depressed. LOL.

Cheers,
Brian

Brian Chapman wrote:

> So many levels of indirection! I take it, it goes like this:
> 
> At run time, the C runtime calls main (int,char**),
> which is in the D runtime, a.k.a. Phobos.
> 
> Phobos, in turn, calls your D program's main (char[][]),
> which we need to call SDLmain's main (int,char**),
> of which we rename to something else to avoid conflict
> 
> So then SDLmain's renamed main calls SDL_main (int,char**),
> which, of course, we need to provide as usual.
> 
> No wonder I got confused! ;-)

And a problem is that since Linux doesn't use/need a SDLmain,
and since the Windows implementation can be duplicated in D,
developers on those platforms thus don't feel they need to
link with SDLmain and patch the "main" function. :-(

Which means that their programs will work on Linux and
Windows, but crash on Mac OS X (and possibly others too?)
The approach that I've suggested works on all platforms.

GLUT has a much more sensible approach, so no patching
is needed there (it uses less preprocessor "main" hacks)

--anders

PS.
In code, the above procedure looks like:

1.

> int main(char[][] args)
> {
> 	return SDL_InitApplication(args);
> }

2. (from "sdl.main" module)

> int SDL_InitApplication(char[][] args)
> {
>     char*[] c_args = new char*[args.length];
>     foreach (int i, char[] arg; args) {
>         c_args[i] = toStringz(arg);
>     }
> 
>     version (Windows)
>         return D_console_main(c_args.length, cast(char**) c_args);
>     else version (darwin)         return D_main(c_args.length, cast(char**) c_args);
>     else
>         return SDL_main(c_args.length, cast(char**) c_args);
> }

3.

> // user should always supply this function:
> extern(C) int SDL_main(int argc, char **argv);