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