Mac OS X 10.6 x86_64 build

[fzn]

Hello,

I complied a 64 bit build based on SVN trunk from july the 12th,
OpenAL trunk from today (with a slight modification - replaced a call to CompareAndSwap with one to CompareAndSwap64).

As 64 bit executables cannot depend on 32bit libraries, I had issues building project after updating to SL.

As it was quite boring, and a couple fixes had to be made to dependences, I can provide you with extlibs, and/or information.

Just ask

SFML-1.5_osx_i86_64.tar.gz.bz2

PS: Tell me if I forgot to include anything

[Ceylo]

Hello,

Thanks for the help. I'm currently downloading your archive (taking some time as free looks to be limiting upload rate).

I'm wondering which trunk you're talking of ? The one I know has always been unavailable...
But anyway, you shouldn't have to worry about OpenAL because 64 bits support requires Mac OS X 10.5 which already provides a good 64 bits OpenAL framework (Mac OS X 10.4 was providing a buggy one). Thus in any case if a 64 bits version of SFML is provided, it won't support Mac OS X 10.4 and therefore not the buggy framework.

So if you finish to link SFML against the OS OpenAL framework, just delete OpenAL.framework from trunk/extlibs/bin. But... the Subversion repository also lacks a 64 bits version of sndfile. System, Network and Window packages should work without any trouble. As for the Graphics packages, it requires a 64 bits version of FreeType which is currently missing too (I'm trying to fix this).

Ceylo


Edit: download ended... and I must say I'm both really surprised and pleased :shock: . May I ask how you did build the sndfile framework ? Which sndfile version is it ? Does it include external libraries support ? (FLAC/Ogg vorbis) Which freetype version is it too ?
As for your CompareAndSwap modification, could you explain why you did this ? and why you believe this fix is safe ?

[fzn]

To answer your questions in good orded:

OpenAL
Trunk lies here: svn://connect.creativelabs.com/OpenAL

in file oalAtomicStack.h, I added

Code: [Select]

#include <libkern/OSAtomic.h> and changed:

Code: [Select]

bool compare_and_swap(T *oldvalue, T *newvalue, T **pvalue)
{
return OSAtomicCompareAndSwap64((int64_t) oldvalue, (int64_t) newvalue, (int64_t*) pvalue); // HACK
//return CompareAndSwap64(UInt32(oldvalue), UInt32(newvalue), (UInt32 *)pvalue);

}
I then replaced every occurrence of "ALvoid" and "ALCvoid"by void (those are opaque types typedef'd to void, yet gcc was complaining)

Ah last but not least, as Apple says, CoreAudio directory structure changed in SL, which implies modifying the .xcodeproj and/or some header files.

(IMO there isn't a full time OS X maintainer for OpenAL at the moment =) )

sndfile
Version: libsndfile-1.0.20

./configure && make
sudo glibtool --mode=install libsndfile.la ~

then replace the library that lies in the existing framework by the .dylib it just buit. Vorbis support is here, I didn't check with flac.

freetype
Version: freetype-2.3.9
It's built the same way as sndfile

The goal was to get the SFML running on x86_64 heh, that's all.
If you're doing it the same way I did, and Xcode generates code for other archs, it will fail

CompareAndSwap?
openal's CompareAndSwap as it's written on the SVN HEAD revision calls corefondation's CompareAndSwap, which takes uint32's as arguments. Thus, as memory addresses are 64 bit integers, it just won't work.

I'm not sure if this fix is safe. Semantically, it seems like it is, yet I did not read calling code, so I won't bet anything

[Ceylo]

To answer your questions in good orded:

OpenAL
Trunk lies here: svn://connect.creativelabs.com/OpenAL

Well... did I miss something ?

Ceylos-MacBook:~ lucas$ svn checkout svn://connect.creativelabs.com/OpenAL
svn: Can't connect to host 'connect.creativelabs.com': Connection refused

This is the path I always tried to use but it always failed.

in file oalAtomicStack.h, I added

Code: [Select]

#include <libkern/OSAtomic.h> and changed:

Code: [Select]

bool compare_and_swap(T *oldvalue, T *newvalue, T **pvalue)
{
return OSAtomicCompareAndSwap64((int64_t) oldvalue, (int64_t) newvalue, (int64_t*) pvalue); // HACK
//return CompareAndSwap64(UInt32(oldvalue), UInt32(newvalue), (UInt32 *)pvalue);

}
I then replaced every occurrence of "ALvoid" and "ALCvoid"by void (those are opaque types typedef'd to void, yet gcc was complaining)

Ah last but not least, as Apple says, CoreAudio directory structure changed in SL, which implies modifying the .xcodeproj and/or some header files.

(IMO there isn't a full time OS X maintainer for OpenAL at the moment =) )

Do you know wether there are important fixes in the OpenAL Subversion repository ? Because if not it would be much easier to use the framework provided with Mac OS X (no need to update/take care of other possible issues/etc).

sndfile
Version: libsndfile-1.0.20

./configure && make
sudo glibtool --mode=install libsndfile.la ~

then replace the library that lies in the existing framework by the .dylib it just buit. Vorbis support is here, I didn't check with flac.

Yay I learnt something today ! (I didn't know this way of using the .la file ). Could you check for the FLAC support ? That's the one causing me problems. At the end of the sndfile configuration you should see something like "External libraries support : yes". If it says "no", even if you have the ogg [vorbis] libraries installed, all the external libraries support will be dropped, so neither ogg nor flac.

freetype
Version: freetype-2.3.9
It's built the same way as sndfile

Ok thanks !

The goal was to get the SFML running on x86_64 heh, that's all.
If you're doing it the same way I did, and Xcode generates code for other archs, it will fail

I knew this but I enjoy the intention .

[fzn]

SVN Creative Labs

MBP:temp frozen$ svn checkout svn://connect.creativelabs.com/OpenAL  truc
A    truc/trunk

MBP:temp frozen$ svn --version
svn, version 1.6.3 (r38063)
    compilé Jul 15 2009, 14:24:06

I have to say that I thought Xcode would always link against frameworks that lie in the proper system directories. So I (maybe wrongly, can't tell, file deleted) assumed that the version supplied with 10.6 didn't have 64 bit code (that puzzled me a bit). If you want me to test, provide me with the original 10.6 framework

sndfile
I learnt about libtool today too, thank you Google if you read this. Beware by the way, there is an Apple tool called libtool. GNU libtool is named glibtool (Logical, heh >_>).

External libraries support was disabled. The configuration script activates it when flac, ogg, vorbis, and vorbisenc are installed. I ran into problems while building the flac library, namely this kind of things:

Code: [Select]

ranlib: archive member: .libs/libFLAC.a(lpc_asm.o) cputype (7) does not match previous archive members cputype (16777223) (all members must match)

I might give it a look one of those days, but school will resume soon, and I'm going to be quite busy. Curiously, it seems that the flac cvs hasn't been upgraded in months. Stupéfiant =)

[Ceylo]

SVN Creative Labs

MBP:temp frozen$ svn checkout svn://connect.creativelabs.com/OpenAL  truc
A    truc/trunk

MBP:temp frozen$ svn --version
svn, version 1.6.3 (r38063)
    compilé Jul 15 2009, 14:24:06

Ceylos-MacBook:~ lucas$ svn --version
svn, version 1.6.2 (r37639)
   compiled May 20 2009, 01:36:41

I'll try to update but... I don't think compatibility has been broken only because of a sub-minor version change.

I have to say that I thought Xcode would always link against frameworks that lie in the proper system directories. So I (maybe wrongly, can't tell, file deleted) assumed that the version supplied with 10.6 didn't have 64 bit code (that puzzled me a bit). If you want me to test, provide me with the original 10.6 framework

Did I read correctly ? You... deleted the framework from the System ? Oo

External libraries support was disabled. The configuration script activates it when flac, ogg, vorbis, and vorbisenc are installed. I ran into problems while building the flac library, namely this kind of things:

Code: [Select]

ranlib: archive member: .libs/libFLAC.a(lpc_asm.o) cputype (7) does not match previous archive members cputype (16777223) (all members must match)

I might give it a look one of those days, but school will resume soon, and I'm going to be quite busy. Curiously, it seems that the flac cvs hasn't been upgraded in months. Stupéfiant =)

That's exactly the issue I got and I found no solution for now :/ .

[fzn]

Quoted from libflac's README:

--disable-asm-optimizations : Disables the compilation of the
assembly routines.  Many routines have assembly versions for
speed and `configure' is pretty good about knowing what is
supported, but you can use this option to build only from the
C sources.  May be necessary for building on OS X (Intel)

It built successfully. I rebuilt libsndfile also, and vorbis and flac files work.

Code: [Select]


sh-3.2# ./sndfile-play queen\ -\ another\ one\ bites\ the\ dust\ \(9\ sec.\).flac
Playing queen - another one bites the dust (9 sec.).flac
sh-3.2# ./sndfile-play Livin\'_On_Borrowed_Time_zero.ogg
Playing Livin'_On_Borrowed_Time_zero.ogg
^C


I thought I had removed the framework from the system, but I actually did not

[Ceylo]

Well.. I didn't even think of having a look at the README file..... I sometimes wonder where my brain has gone...

Thanks anyway, that should do it !

[fzn]

Celyo, did you manage to build sfml2 branch on the SVN repository? When I looked at it, a couple months ago, I gave up after I saw the GL back-end wasn't coded. It seems the directory structure is gone. If you had any success, just tell. I'm looking forward to being able to build a nice, multi-arch, up-to-date, package

[Ceylo]

There is no Mac OS X version of SFML 2. What you can see in this branch is just a copy of the main trunk.

As explained in this discussion, I won't make the port for this SFML version. We're still looking for someone to go on the work.

[fzn]

Well, maybe I'll get it to work

[Ceylo]

The Window and Graphics packages will NOT work. There is no Mac OS X implementation matching the current Window class declaration (until someone writes it of course).

Maybe you can achieve to use the System, Network and Audio packages though.

[Ceylo]

Here are the SFML frameworks with 64 bits support : SFML-1.6-ppc+i386+x86_64.

These are not on the SFML Subversion repository for now, I would like to get some feedbacks first.

You may notice there is no more OpenAL framework in the package. This is due to the fact SFML is now linked against the OS framework. Same for the freetype library.