www.digitalmars.com         C & C++   DMDScript  

D.gnu - Link/Run Problems on Mac OS X (10.2.8)

reply "Brian Chapman" <nospam-for-brian see-post-for-address.net> writes:
Hello,

Could someone perhaps post (or e-mail me) with their own EXACT steps tha=
t  =

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 provide=
d  =

in phobos, no problem.

However, I would like to link to SDL which I have installed via fink. Bu=
t  =

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.dyli=
b
collect2: ld returned 1 exit status

So then, I think "okay thats in the Obj-C runtime, I guess I have to lin=
k  =

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 o=
f  =

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 wind=
ow  =

(1002)
kCGErrorInvalidConnection : CGSSetWindowProperty: Invalid connection
kCGErrorInvalidConnection : CGSInvalidateWindowShadow: Invalid connectio=
n
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 creatin=
g  =

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 leak=
ing
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 a=
re  =

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.t=
ar.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=3D/opt/gcc/3.3.4 --enable-languages=3Dc,c++,java,d=

make
mkdir -p /opt/gcc/3.3.4
make install

mkdir phobos
cd phobos

export PATH=3D"/opt/gcc/3.3.4/1:$PATH"
../../gcc/d/phobos/configure --prefix=3D/opt/gcc/3.3.4
make
make install
Nov 19 2004
next sibling parent "Brian Chapman" <nospam-for-brian see-post-for-address.net> writes:
On Fri, 19 Nov 2004 05:14:33 -0600, Brian Chapman  =

<nospam-for-brian see-post-for-address.net> wrote:
 export PATH=3D"/opt/gcc/3.3.4/1:$PATH"
Sorry, that was a typo. I meant: export PATH=3D"/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 compile= rs.
Nov 19 2004
prev sibling parent reply =?ISO-8859-15?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
Nov 19 2004
parent reply "Brian Chapman" <nospam-for-brian see-post-for-address.net> writes:
Anders!

Thank you very much for helping me out! With the information you provide=
d  =

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=F6rklund <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 t= he = 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
Nov 19 2004
parent =?ISO-8859-15?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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);
Nov 20 2004