Need help building CS on MacOS X

[backeroo]

Hi there,

when trying to build CS on MacOS X 10.4.7, i ran into the follwing error, with every svn-release i've tried so far:

./include/csutil/spinlock.h: In member function 'bool CS::SpinLock::DoLockWait()':
./include/csutil/spinlock.h:169: error: invalid conversion from 'volatile pthread_mutex_t*' to 'pthread_mutex_t*'
./include/csutil/spinlock.h:169: error:   initializing argument 1 of 'int pthread_mutex_lock(pthread_mutex_t*)'
./include/csutil/spinlock.h: In member function 'bool CS::SpinLock::DoLockTry()':
./include/csutil/spinlock.h:177: error: invalid conversion from 'volatile pthread_mutex_t*' to 'pthread_mutex_t*'
./include/csutil/spinlock.h:177: error:   initializing argument 1 of 'int pthread_mutex_trylock(pthread_mutex_t*)'
./include/csutil/spinlock.h: In member function 'void CS::SpinLock::DoRelease()':
./include/csutil/spinlock.h:186: error: invalid conversion from 'volatile pthread_mutex_t*' to 'pthread_mutex_t*'
./include/csutil/spinlock.h:186: error:   initializing argument 1 of 'int pthread_mutex_unlock(pthread_mutex_t*)'
./include/csutil/spinlock.h: In member function 'void CS::SpinLock::Init()':
./include/csutil/spinlock.h:194: error: invalid conversion from 'volatile pthread_mutex_t*' to 'pthread_mutex_t*'
./include/csutil/spinlock.h:194: error:   initializing argument 1 of 'int pthread_mutex_init(pthread_mutex_t*, const pthread_mutexattr_t*)'

    g++ -c -o ./out/macosxppc/optimize/libs/csutil/memheap.o -I. -I./include -I./include -pipe -Wmost -Wno-unknown-pragmas -fvisibility=hidden -I/usr/local/include -Wno-long-double -force_cpusubtype_ALL -fno-common -fno-exceptions -O3 -fomit-frame-pointer -ffast-math -DCS_CRYSTALSPACE_LIB -Ilibs/csutil/ptmalloc -Ilibs/csutil/ptmalloc/sysdeps/pthread -DCS_CONFIGDIR='"/usr/local/etc/crystalspace"' -DCS_PLUGINDIR='"/usr/local/lib/crystalspace"'  libs/csutil/memheap.cpp

Can someone give me a hint how to fix this for macosx?

regards

  backeroo

[DaveG]

First of all, stick with the revisions in the guide:
PS CVS date: "2006-07-07 00:00:00 UTC"  (or latest, if you don't care about compatability with the public server)
CS SVN revison: 24890
CEL SVN revison: 2046

Try building with that set, and if it's still not working we'll need to drag dfryer over.

Please also post your GCC version.

[backeroo]

I've started with an earlier one from the Compile Guide ( i think it has been updated meanwhile..) shortly after the 0.15 release.
with the same error. I hoped it would have been fixed with a newer Release but it's still in the current ( 24905 ).

I've tried with gcc 3.1, 3.3 and 4.01.

Maybe it's related to ( just a wild guess ) libstdc++ which has recently been updated from 6.0.3 to 6.0.4 as it seems ( maybe with the 10.4.7 update ) on my System.

thanks,

any help is appreciated, as i also can't run the distributed binary ( crashes with a "Pure virtual funtion called" ).

regards

 backeroo

[Bereror]

If you want to experiment, open include/csutil/spinlock.h in the CS directory and modify the lines that give you errors.

Like the line 169. Change if(!pthread_mutex_lock(&l)) to if(!pthread_mutex_lock((pthread_mutex_t *)&l)).

Same should be valid for other errors that you get there.

I have no idea if it works or not, but you may give it a try.

[backeroo]

In fact i'm willing to try everything to get back on the Track.
But even if that works, it's a little bit strange to me. I'm not a c++ guy, but if i get this right, this is a typecast, and the error is more about the volatile thing, which allows other threads to update the var or const ( my understanding from what i got from the net about the volatile-keyword.)

I would rather suspect he problem in the declaration of the Lock, wich maybe confuses the macosx-gcc.

spinlock.h:
...
  #else
    typedef pthread_mutex_t Lock;
  #endif
   
    volatile uint c;
    volatile Lock l;
...

but, once again, i'm not so familiar with c++. If i'm talking nonsens, don't hesitate to state it. I just don't understand why it works on other unix-based systems ( Linux ). As far as i know, Apple just altered the gcc to support all their GUI-Stuff.

but BTW.: I works (means compiles) so far. Let's see where it get's me. Thanks.

regards

  backeroo

[Bereror]

It works fine with gcc 3.4.6 on Linux. CS has its own forums at http://community.crystalspace3d.org/forum/index.php, so I guess it would be wise to bring it up there. It is not an PS issue.

[backeroo]

You're right, it's not a PS Issue. But i thought that at least someone should have encountered, and solved, the same issue, so that there may be a fix or  a workaround already exists ( as it turned out to be, as far as i can see now.)
 
With your suggested alteration, CS has build fine. So, with a little luck, i will end up with a working PS Client.

thanks a lot.

regards

  backeroo

[dfryer]

GCC 3.3 on 10.3.9 treats it as a warning, not an error, which is why I've avoided any trouble so far.  It is indeed a CS problem that must be resolved.

[backeroo]

I just want to thank everyone for their help. Finally i've got the client working.

The reason for my Problems with the client is maybe worth a note.

I'd started again to build the client myself as i run into Problems with the distributed binary from dfryer wich kept crashing with
"pure virtual function called." What i got from the CS Forums was, that this is maybe caused by an unclean build. As there were others using this client without Problems, i'd rather supected an unclean environment on my side, so i wanted to build the client myself, so that i may could debug what's going wrong. After applying Bereror's fix for the CS compile error, i was able to build the whole thing, and ended up again with the same "pure virtual funtion called" error.
So i did again ktrace/kdump, and noticed an call to a library in /usr/local/lib/crystalspace. As i was pretty sure that this can't be right, i've checked the Directory and found a crystalspace installatioin which was about one year old. No Idea hoe it has got there in the first place. After i've deleted this ancient files, not only my build started to  work, also i was able to run the binary from dfryer. 

So, what did we learn from this? I have no Idea.

regards

  backeroo

[dfryer]

You've learned how hard it is to make a working PS Release