malex984

Does anybody want to try an experimental OSX (arch: x86_32, OSX >= 10.6) build of the latest TDM?

oh, well... i'd like somebody else to try running the build which works for me just in order to make sure that it doesn't contain any implicit assumptions/dependencies about the host setup... but if nobody is up to it - i guess i will try to find out which of my experiments where unnecessary and prepare a minimal patch which would be immediately useable without any unusual fingering.

so... nobody is interested in TDM on OSX?

Well, i have a debug & release builds for OSX >= 10.6 on x86_32. Playable but non-stable. Anyone up for testing TDM under OSX?

I am having a bit of unexpected trouble running TDM on OSX: i needed to correct doom.script but it still fails to set player data due to a dictionary memory corruption while loading a map (rain.map from darkmod resources repo) :-( Maybe instead of using the most recent trunk sources I really have to use the 1.8 branch? Do you still have sources for the recently updated version of boost in trunk, so that I could update macosx OSX binaries without touching headers as well? Besides, the downloadable current official tdm_update.macosx is supposed to prove the same recent data files under OSX as one would get by updating now under Linux, right?

Please note that my patch is minimal one to let one to build TDM - the resulting binary may not do everything one expects. Therefore I'd advise testes to use binaries from darkmod SVN where I made some path&framework-related (quick-and-dirty + only for testing on Mac OS X) changes, or just wait a bit for another correcting patch, which I guess I will produce only after a good look at the final official 1.08 data files structure, e.g. on Linux.

As I said i can easily provide Mac OS X binaries (and they are already In darkmod repo) but suspect that they will probably be useless without recent data files... no?

Yeah it does for me, but it depends on used gcc (Xcode) and SDK versions due to the way how the static libraries boost and curl were build, as I reported at the very beginning Do you know *exactly* which libcurl version is being used? Well, you could point users to an additional patch if you are against incorporating it into the official 1.08...

Beside the minimal-changeset patch from above I am prepearing another one with some further modifications to path-related functions and fixes to idlib itself which might be good for TDM in general, but IMHO it would be better to test them on Linux and windows beforehand...

Ok, my patch is on ftp now: http://ftp.thedarkmo...tation.patch.7z If it is ok, i can submit it to darkmod_src, but i am no sure since i have heard it to be frozen now...? Note: the patch TDM is tested on Mac OS X 10.6.8 using Xcode 3.2.6 + SDK for 10.6 with gcc 4.2) Running the following commands produce universal dynamic library 'game.dylib' and application bundle 'Doom 3.app/' in created directory: 'sys/osx/build/Release' cd sys/osx/ xcodebuild -project Doom3.xcodeproj 'ARCHS=i386 ppc' -configuration Release -sdk macosx10.6 For debug build use "-configuration Debug" (results will be in sys/osx/build/Debug) Note: using "-sdk macosx10.5" (for minimal required OSX 10.5) required me to rebuilding libcurl for example with the following configuration: env MACOSX_DEPLOYMENT_TARGET=10.5 CFLAGS="-m32 -arch i386" LDFLAGS="-m32 -arch i386" ./configure --disable-ldap --without-libidn --without-zlib --without-ssl --enable-hidden-symbols --disable-shared --disable-debug --disable-dependency-tracking (and the same for ppc + combining universal binaries as per your wiki) due to the following error Undefined symbols: "_fopen$UNIX2003", referenced from: _Curl_cookie_output in libcurl.a(cookie.o) _Curl_cookie_init in libcurl.a(cookie.o) _file_do in libcurl.a(file.o) _file_do in libcurl.a(file.o) _Curl_parsenetrc in libcurl.a(netrc.o) _readfromfile in libcurl.a(formdata.o) _Curl_getFormData in libcurl.a(formdata.o) ld: symbol(s) not found collect2: ld returned 1 exit status

It's good to hear. Yeah, i am.

Ok, I am trying to make my fixes suitable for submitting into the common svn but I have to figure out better ways to solve some of the problems

Hm, that worked for me. You could also try using https:// instead of git:// .

make sure to use the latest commit in master branch for git checkout (as i saw an explicit git checkout SHA1ID in the PKGBUILD from AUR)

Besides, there will be several issues of compiling TDM under OSX from the current SVN sources as I did not committed my fixes there yet since I was trying to fix the filesystem/path related parts. I can of course provide a patch to be applied on top of current SVN.

Well, sharing binaries is not a problem, provided TDM team lets me do that, Guys? Besides, @New Horizon, if you have the darkmod svn access - I put universal binaries there some time ago - it would be nice if somebody other than me tries them out...

I posted my currently used and expected Mac OS X setup in http://forums.thedarkmod.com/topic/14125-resource-search-path-under-mac-os-x/page__view__findpost__p__296378

Alternatively, rather than doing all of that I could simply change the meanings and initialization of fs_* variables instead, for instance as follows: look for everything in current directory (where the .app binary is located), for missions use ./fms/, forget about $HOME/Library/.... altogether. But where should I look for D3 stuff with this alternative..? What do you say?

Building goes without any problems whatsoever. New tdm_update.macosx is in SVN now. No need in a XCode project as it is not an Apple application bundle.

Yes, i suppose something like that.

Ok. I will take a look at that. Besides I wanted to note that the current MacOsX build will only try to change $HOME/Library/Application Support/Doom 3/ and its children. For instance it will create "darkmod" there for storing downloaded fms and currentfms.txt. Which also means that fms folder and currentfms.txt from the delivered "darkmod" folder are ignored (unless it is placed in the location mentioned previously).

Yes. Provided the folder is named "darkmod", and optional D3 resources are in the folder named "base", which is in the same place as the "darkmod" folder. Could one test your delivery mechanism before it goes public?

Oh. That folder IS the Apple application bundle and it contains an executable module Together with all the necessary resource files. Mac OS X users need that folder as it is ( of course without the svn stuff )! And yes it can live in any folder provided there is the darkmod/ resource folder is its parent directory (which should also contain "base/" with D3 resources). For instance it can live in the directory named darkmod containing all the TDM resources. This is the result of my changes to the meanings and setting of fs_* variables, according to your note #35 above.

xml parses xml files alright (i even saved them temporary again while debugging) but afterwards they will not be added to user/system trees as i described in http://forums.thedar...post__p__296223

Yeah, works fine for me (Although i still have my toolbar-related changes in there).