|
Archives
D Programming
D
D.gnu
digitalmars.D
digitalmars.D.bugs
digitalmars.D.dtl
digitalmars.D.dwt
digitalmars.D.announce
digitalmars.D.learn
digitalmars.D.debugger
C/C++ Programming
c++
c++.announce
c++.atl
c++.beta
c++.chat
c++.command-line
c++.dos
c++.dos.16-bits
c++.dos.32-bits
c++.idde
c++.mfc
c++.rtl
c++.stl
c++.stl.hp
c++.stl.port
c++.stl.sgi
c++.stlsoft
c++.windows
c++.windows.16-bits
c++.windows.32-bits
c++.wxwindows
digitalmars.empire
digitalmars.DMDScript
|
D.gnu - Link/Run Problems on Mac OS X (10.2.8)
↑ ↓ ← → "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
↑ ↓ ← → "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.
↑ ↓ ← → =?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
↑ ↓ ← → "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
↑ ↓ ← → =?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);
|
|