MacOSX Cocoa problems/questions

[Ceylo]

Hum ok thanks. I'll have look at it.

[Ceylo]

I've tried to build your program, but I failed.

The OpenAL and SFML frameworks can be used for the ppc and i386 architectures. And when running "cmake -LH" I can read this:

Code: [Select]

// Build architectures for OSX
CMAKE_OSX_ARCHITECTURES:STRING=i386
But at link time, the build process shows this :

Code: [Select]

Linking CXX executable gamestone
ld: warning: in /Library/Frameworks/OpenAL.framework/OpenAL, missing required architecture x86_64 in file
And then I can read there are loads of undefined symbols from the OpenAL and sfml-window libraries.

This happens because the sources have actually been compiled for the x86_64 architecture instead of i386 ! I dunno how to fix this as the environment variable already looks to be set up fine.

And the SFML Window-based project does not show me any error when using Command+Q.

Thus until I can get a full and minimal working code producing the "leaks" errors, I may not be able to fix the issue.

I've had a look at the quit menu settings: it calls -[NSApplication terminate:] which is the default behavior for a Cocoa application. Besides there should still remain the NSAutoreleasePool object of the AppController singleton, which probably means it has been destroyed externally. This can happen if you made an autorelease pool before before the one used by SFML and release yours (see Memory Management Programming Guide for Cocoa : Autorelease Pools). I've some ideas, but I need to know one thing first : does the application you make explicitly use Cocoa ? (thus not through SFML)

Ceylo

[alaterale]

Interesting.  I've not seen those kinds of build errors before.  I've built this on 32 and 64 bit systems (x86 and ppc) before without seeing that kind of stuff.  How did you start the build process?  Typically its something like this(after the svn retrieval):
> cd gamestone/Build/CMake
> cmake .
> make
Did you get any cmake errors for missing libraries (at the cmake . step)?  Except for OpenGL and OpenAL (and whatever cocoa needs), all the dependencies should be included, and be the same on your system.  What version of OSX are you using?  What version of GCC are you compiling with?  I'm still trying to perfect the build process (as well as the build documentation), so it would be a big help to figure out why it didn't work for you.  I haven't tried to build with 10.6 or with 10.2 or below yet, so I dunno if that could be it.  Could you give me a listing of all the errors at the beginning (not the missing symbol ones, since I imagine that there's an error earlier on that would cause those).

As for other uses of Cocoa, SFML Window is the only thing for that.  All of the stuff I wrote is purely C/C++.  I think the pool and leak issues are gone, just that weird surface error remains, unless that's also a memory leaking issue.  Not sure what svn version you tested, but recently I was updating a few things, so I hope you didn't get it inbetween that.  It should build as is from svn now, and I'm curious exactly what kind of library issues you're having.

[Ceylo]

I did the build process as you wrote.
I'm using Mac OS X 10.6 (the default architecture is x86_64) and I use GCC 4.2.

There is absolutely no error while compiling, only at link time.
Here is the full log (only rebuilding what failed) if you want it : gamestone-log.txt.

As for other uses of Cocoa, SFML Window is the only thing for that. All of the stuff I wrote is purely C/C++. I think the pool and leak issues are gone, just that weird surface error remains, unless that's also a memory leaking issue. Not sure what svn version you tested, but recently I was updating a few things, so I hope you didn't get it inbetween that. It should build as is from svn now, and I'm curious exactly what kind of library issues you're having.

Nothing in the Mac OS X port has been changed recently, so I don't think it should be the point. And... I didn't understand you provide the sources of libraries that the SFML website already provides compiled.

[alaterale]

Thanks for posting that info, it helps a lot.  So far, I see that you're not using Cmake 2.6, which could be a problem if the 2.4 modules aren't providing the right path or environment information.  I set the minimum version in the cmakefile to 2.6, but for some reason it still lets you continue after that warning

If you're using 10.6, that could be it too (esp combined with an old version of cmake).  I have a friend who just got 10.6 and I will ask him to try this out as well.  At least the GCC version is 4 and above, which is another requirement.

Well, something has to have changed in SVN, since the 1.5 release I originally used had a ton of pooling issues, where 1.4 worked perfectly fine.  With 1.6 from svn, as you said earlier, there's no more huge piles of pool warnings, just that one particular one, so something had to have changed since 1.5.  All I did was copy over the same files from svn to what I had from 1.5.

If you're referring to the precompiled libraries, I never liked doing things that way, then you get into dependencies the user has, etc, different versions, packaging, and so on.  It's just easier to include the exact versions necessary, compile from source, and link it all together then.  And besides, this is something I'm going to be using for iphone and other embedded development too.  The people I've had test this so far haven't had any problems (aside from the weird thing from 1.5 and now this in 1.6 that we're discussing now), aside from getting the right build environment set up to begin with, so that could be the problem here.

[Ceylo]

I had actually also installed CMake 2.6 but I was also having CMake 2.4 and it was the one being used.

Actually... using CMake 2.6 produces loads of errors at compile time because of missing files. See gamestone-log-2.6.txt.

Well you're right: a lot of things have changed since SFML 1.5. I misunderstood a few points... :oops:  I never saw your CGSAddSurface message and I wonder whether it's related to your graphic card's driver.

Now about the precompiled libraries, I still don't understand why you just don't provide compiled versions of the libraries you need. You can still provide binaries of the version YOU need. This prevents every user from having to rebuild the whole stuff and you can still be positive the user is using the right version. The only reason I could see is if you added your own changes to theses libraries (and need to make other changes easily). Did you ?

[alaterale]

That is a pretty weird error log, but it seems like the first error has something to do with your setup and headers/frameworks.  Since it's referencing a standard header (in a 10.4 location) and it's missing...  Not sure exactly how that happened.  But again I've never seen those kinds of errors.  Does the dev tools package have a default setting for where headers are found?

I just talked to my friend who got 10.6 and it compiled (with a few regular warnings that python always gives off, since his version of GCC is higher than mine and at some point they stopped going easy on non ansi stuff).  Still awaiting more testing, but it seemed like he didn't run into the same errors.

Well, like I said, I prefer source compilation (and most of the people testing for me haven't had many problems other than setting up the right build environment, which again seems to be the problem here, unless they were building on windows, which is special case).  But in any case, it just gets more complicated when dealing with binary libraries, etc, when just compiling from source is easier for developers.  And, this really isn't the view that the average user will see anyway, since I'm going to be offering built executables that they just download and can use instantly without any kind of building.  I do also want to provide official xcode project files, but it's much more of a complicated tool than cmake is to get working right.  The trouble is, I never really know any fellow programmers using osx who want to contribute that kind of help.

I haven't changed the libraries too much, aside from updating where some external libraries were, and adding my own files to simplify the build process, but that's it.  All of my changes are documented in Docs/Libraries.txt.

I wish I could figure out why your build environment is referencing standard C++ headers that don't exist for you though.  I'll try to do some research into any special cmake changes I need to address to deal with multiple macosx sdk's installed at once.

[Ceylo]

I think I know why this is happening. Every time I try to use the Mac OS X 10.4 SDK with GCC 4.2 and Xcode, it tells me the 10.4 SDK is not compatible with GCC 4.2. But GCC 4.0 is.

I dunno how to tell CMake to use GCC 4.0 though.

[alaterale]

Just found out some info that might shed light on why cmake is doing this.

http://bugs.mysql.com/bug.php?id=38608
http://www.cmake.org/pipermail/cmake/2006-October/011538.html

Basically, I might have to do some kind of setting of MACOSX_DEPLOYMENT_TARGET or something... which I kind of hoped I could avoid so I could make the scripts more general (not to mention I also don't know yet how to get your osx version from cmake in order to set this..).  I'll try to think of something that will work out.

[Ceylo]

I don't thing it's related to the MACOSX_DEPLOYMENT_TARGET environment variable in any way (until you wish to no more support old Mac OS X versions). What I don't understand is why CMAKE_OSX_ARCHITECTURE is ignored.