Duke4.net Forums: Building EDuke32 on Mac OS X - Duke4.net Forums

Jump to content

Hide message Show message
Welcome to the Duke4.net Forums!

Register an account now to get access to all board features. After you've registered and logged in, you'll be able to create topics, post replies, send and receive private messages, disable the viewing of ads and more!

  • 7 Pages +
  • 1
  • 2
  • 3
  • 4
  • 5
  • Last »
  • You cannot start a new topic
  • You cannot reply to this topic

Building EDuke32 on Mac OS X

User is offline   Tetsuo 

  • 89

#61

The latest build has been working pretty good for me.. a tad slower in some places than a previous build but mostly good. The save game system is still busted for me personally but I've no idea if it's because of my setup or what. It happened on a previous hard drive and a new hard drive after I had it replaced.

The new icons are good although I have my own Duke3D icons that I like to use... it's also nice especially for now users that it's now packed into an .app bundle. I was mostly just upgrading Rheonie's .app bundle with the newer binaries when they come out.

--Tetsuo

It's funny how the colors of the real world only seem really real when you viddy them on the screen. -- Alex Delarge, A Clockwork Orange
0

User is offline   Helixhorned 

  • EDuke32 Senior Developer
  • 697

#62

View PostTetsuo, on 29 February 2012 - 12:29 PM, said:

The save game system is still busted for me personally but I've no idea if it's because of my setup or what. It happened on a previous hard drive and a new hard drive after I had it replaced.

Is something being reported to the log?

(o~ Lunatic home: documentation, stand-alone LuaJIT, LunaCON and utilities ~o)
0

User is offline   Tetsuo 

  • 89

#63

Nothing is being reported no errors in the log regarding savegames or otherwise.... it just doesn't save when I try to save... and I'm very sure permissions to the eduke32 folder in application support are correct and such.

--Tetsuo

It's funny how the colors of the real world only seem really real when you viddy them on the screen. -- Alex Delarge, A Clockwork Orange

This post has been edited by Tetsuo: 29 February 2012 - 01:32 PM

0

User is offline   LSDNinja 

  • 14

#64

First up, I have to say that I'm not a programmer, so when I say I've been hacking away that's literally what I mean: I spent days chopping and changing things around *just* to get the sources to compile. From there, it was mostly adapting the changes I already made to changes you made upstream as well as accounting for other problems that crept in. As a non-programmer, I realise that some of the "solutions" to these various "problems" may not exactly be the best way of handling them, which was another reason I put them out there, to get some ideas from people who actually do know wtf they're doing. I'm not really looking to get any of this stuff committed, just throwing it out there to get new ideas and to help others who might be struggling in similar situations to what I encountered.

View PostHendricks266, on 28 February 2012 - 05:21 PM, said:

I hope I didn't cockblock you with my .app bundles. However, the icon I put together is impeccable if I do say so myself. :D


Actually, you made things a tad easier on that front since all I was doing before was manually copying the compiled binaries into one of Rhoenies old .app bundles. I was thinking of making one for Mapster, but lacked sufficient knowledge and resources (notably, a decent sized icon :rolleyes:) which, combined with not being a big mapper meant I never followed through on it. Having it as part of the main build sequence is a decent time-saver as well.

Quote

I think ideally we should support PPC since there is a user base for it, especially given that Duke is an old game and players of old games may have old hardware, but you do raise valid concerns. The Apple/lib 64-bit linking seems like an important if not urgent problem, but if at all possible it should contain PowerPC libs as well.


View PostHelixhorned, on 29 February 2012 - 07:45 AM, said:

It would be nice to have an outspoken PPC user around, since currenltly we have no feedback of whether that build works at all (I'm leaning more toward "no" though). If nobody cares for that platform anymore, I'd say we gut it.


This is sort of my position too. Apple have ceased supporting PowerPC at their end meaning it's only going to get more difficult to maintain support for it moving forward at yours. If enough people cared about it then it might just be worth it, but to be perfectly honest I'm not really seeing that.

Quote

The same issues apply to both of these: The way you have made these changes are destructive to what one of the devs has implemented in the past. Ideally they should complement or be switched on or off. For example, I don't see an issue with including both /opt/local and /usr/local but I don't know in what order they should be sorted. The stripped C++ Standard Library was put in place for a reason so it should stay and only be replaced if a solution absolutely cannot be found.


Both of those changes were in the "what it took to get it to build for me" basket in that I recognise that my solutions may not be ideal, but they did work. Personally, I think it's safe to assume the vast majority of people attempting this will have MacPorts installed since that is the predominant ports system for OS X and leave that particular path as it is, perhaps with a note in the wiki along the lines of "If you use Homebrew (or whatever) instead of MacPorts, change this path...".

The whole supc++/stdc++ situation is a little murkier since I get the idea there's a little more in play here than just individual OS/toolchain support. According to the comment that accompanies that line it's "overridden for OSes that don't have the cutdown stdc++ that is supc++" which I take to mean that in cases where it can't use supc++ it will use stdc++ instead. The fact that it isn't in my case suggest there's a bug in whatever logic determines whether or not supc++ is present. If there's a better solution here then I'm all ears, but I should also point out that when I was looking for a solution here it was someone on this forum that suggested replacing STDCPPLIB in Makefile.shared which would seem to indicate otherwise. At the end of the day though, it's no big deal since I only put it out there to help others who may be struggling with this, if that turns into a better solution being put forward that's great.

Quote

Both of these changes are good, but they remind me that with SVN 1.7 it is not safe to assume that every folder of a repository has a ".svn" folder since the software now has a more git-like style with one single ".svn" folder in the repository's root. This applies to both osxbuild.sh and synthesis.sh.


My zip tweak doesn't assume anything, it doesn't matter is there's one .svn folder or a hundred, it ignores them all and if it doesn't find any, no big deal. You raise an interesting point about git, so I added *.git* to the exclude list as well. It shouldn't matter if git only maintains a single .git folder out of the way of anything zip is likely to come into contact with, but it doesn't hurt to be prepared.

If, on the other hand, you mean the way the script uses the presence of a .svn folder to determine whether or not it's being run from source checked out of an svn repository then I agree that things can get a little hairy. A cheap short-term hack would simply be to check for the presence of a .svn dir two levels ( if [ -d "../../.svn" ] then; ) up from where you run osxbuild.sh before entering into the whole svn info business which should put you into the repository root, but the best way would probably be finding a way of getting the revision information without relying on the presence of a source control metadata folder at all. You freely admit in synthesis.sh that this approach is "ugly" so perhaps this can be the incentive for finding a better way?

edit2: I incorporated the "../../.svn" change into my osxbuild.sh here and it appears to work, but I realised I'm unable to test it with a proper 1.7 checkout since OS X (Lion) only has 1.6 (I tried checking it out on my FreeBSD box, which has 1.7, only to realise that svn 1.6 likes 1.7 formatted trees as much as 1.7 liked 1.6 ones...), which requires .svn directories in every directory of the source tree. I realise I probably could install 1.7 from brew, but that seems like too much trouble to go to at this point...

Quote

I am curious to see exactly what you mean by this. I made the decision not to include the frameworks themselves because I had doubts about file size and architecture conflicts, but in checking I now see the 4 MB Apple/libs folder with ".a" files of ogg, vorbis, and SDLmain, which you referenced above. Regardless, if we were to include them I would set it up so there is a separate "Frameworks" directory in Apple/ and the Makefile constructs a full .app bundle.


Basically, you keep a set of .app shells in Apple/bundles into which I inserted a Frameworks dir with the relevant SDL frameworks already there so whenever they were copied by the build script the resultant complete .apps would be ready to go, frameworks and all. The problem I kept having was that the zip file at the end would keep blowing out to 30MB+. This was caused by the symlinks being "followed", with the linked files were being copied instead of the symlinks. After several unsuccessful attempts to solve this by fiddling with the parameters supplied to the zip program in osxbuild.sh I realised the shells are copied out of Apple/build and that stage too was set up to follow symlinks. Adding -y to the zip parameters and -PR (the man page didn't list -r as being valid, but it was working so I assume theres simply no case sensitivity on the parameter, but I decided to err on the side of caution and go with what the man page said) to the cp parameters in Makefile sorted it all out with the final zip files down to 8MB or so. (you can see what I did through the diffs I posted before, but I realise it may not have been entirely clear exactly *why* I was doing that)

A more efficient way of handling this would probably to have them in one place as you suggest (probably zipped, as I don't know how practical it is to maintain symlinks over SVN) and have them copied into the shells when you're staging them them during the build. However, that's a level of Makefile tweaks that's way beyond my expertise so I went with the simplest solution that worked.

edit: Turns out this was easier than I thought: all I had to do was zip the frameworks up, throw the zip into Apple/ and then modify Makefile to unzip them after the shells were copied to the root. I'm not entirely sure about how efficient this is, since from what I can tell, this section gets executed every time the source is compiled meaning it happens twice for each binary (eDuke32 and Mapster32) on each run (x86 and x86_64), but I have absolutely no idea how to rig it so it only happens once and the existing builds seem fine with it so I'll leave it as-is. I also took the opportunity here to add the -q switch to both the unzip lines here and the final archive stage to remove some of the clutter from the output.

Quote

This is strange. Under Snow Leopard I have had no problems simply unpacking the frameworks from the ".dmg" files from the links on the wiki page I wrote into "EDuke32.app/Contents/Frameworks" (for example) and running it without any modification to the source. Without them in place the program will not start with the error I documented on the wiki page.


Yeah, I have no idea wth is going on there either. Everything that I found suggested that, when compiled with @rpath, .app/Contents/Frameworks is one of the directories that's automatically searched, but for some reason SL would prefer System/Frameworks (or whichever directory the frameworks were in when you compile I assume). The install_name_tool kludges help to a point, but then it's the frameworks that can't reference themselves properly. It's almost certainly the result of something I'm doing wrong, I just have no idea what that may be...

This post has been edited by LSDNinja: 29 February 2012 - 10:42 PM

1

User is offline   Hendricks266 

  • EDuke32 Senior Developer
  • 5,365

  #65

For a non-programmer you did a pretty good job of achieving your goals! :rolleyes: I see what you mean about these not being patches per se. Adding includes to support HomeBrew libvpx is trivial, as is adding a check for ifeq(PLATFORM,"DARWIN") to change supc++ to stdc++.

I have only been a Windows user for all my life, so dealing with symlinks and all that jazz makes my eyes bug out. If you look at the SVN log, I forgot to tell the cp commands to recurse directories simply because I didn't know I needed to. In theory I could run the commands necessary to extract the DMG then zip it up well, and the commands to extract them to the correct place in the Makefile, but I would likely get a multitude of switches wrong.

As for PowerPC support, I think we would all be chasing our tails in circles trying to reconcile different versions of Xcode and different versions of OS X... my mind spins at the thought, considering I have never owned a Mac, not to mention testing a program on both a rather outdated model and a cutting edge model simultaneously. We should change the libs from PPC/x86 to x86/x86_64 immediately and mull over backwards compatibility later. I feel confident in saying that the number of x86_64 users is more than the number of PPC users.

View PostLSDNinja, on 29 February 2012 - 09:54 PM, said:

You freely admit in synthesis.sh that this approach is "ugly" so perhaps this can be the incentive for finding a better way?

I didn't write synthesis.sh, Plagman did. :D

Anyway, I think checking for a ".svn" folder is redundant anyway since we are doing nothing more complicated than grabbing the revision number. Both "svn info" and "git svn info" work at any subdirectory level of the repository (even with SVN using a 1.7-style repo) and both display error messages and change ERRORLEVEL when they are not run from a repository.

C:\>echo %ERRORLEVEL%
0

C:\>svn info
svn: E155007: 'C:\' is not a working copy

C:\>echo %ERRORLEVEL%
1

C:\>git svn info
fatal: Not a git repository (or any of the parent directories): .git
Already at toplevel, but .git not found
 at C:\Program Files\Git/libexec/git-core/git-svn line 281

C:\>echo %ERRORLEVEL%
128


As it stands, synthesis.sh uses grep to find the revision, so this should not be a big obstacle.
0

User is offline   Helixhorned 

  • EDuke32 Senior Developer
  • 697

#66

View PostTetsuo, on 29 February 2012 - 01:31 PM, said:

Nothing is being reported no errors in the log regarding savegames or otherwise.... it just doesn't save when I try to save... and I'm very sure permissions to the eduke32 folder in application support are correct and such.

OK, the usual drill then... the new revision prints a more informative message (it reads "G_SavePlayer: failed opening '...' for writing"). What does it say for you?

(o~ Lunatic home: documentation, stand-alone LuaJIT, LunaCON and utilities ~o)
0

User is offline   LSDNinja 

  • 14

#67

View PostHendricks266, on 29 February 2012 - 11:27 PM, said:

For a non-programmer you did a pretty good job of achieving your goals! :rolleyes: I see what you mean about these not being patches per se. Adding includes to support HomeBrew libvpx is trivial, as is adding a check for ifeq(PLATFORM,"DARWIN") to change supc++ to stdc++.


With this in mind, I did a little digging and I believe I've sorted it out: Makefile.shared already sets up platform-specific settings, I just added the STDCPPLIB override to the one for darwin later in the file, reverting the main one at the beginning to the default. Regarding the libraries, I just added additional paths for /usr in addition to the default /opt and that seems to work too.

Quote

I have only been a Windows user for all my life, so dealing with symlinks and all that jazz makes my eyes bug out. If you look at the SVN log, I forgot to tell the cp commands to recurse directories simply because I didn't know I needed to. In theory I could run the commands necessary to extract the DMG then zip it up well, and the commands to extract them to the correct place in the Makefile, but I would likely get a multitude of switches wrong.


This is essentially what I've done, created a "frameworks.zip" file that extracts a complete Frameworks/* directory structure and then telling Makefile to extract it as it sets up the bundles. It seems to be working fine, though I'm concerned as to what effect version mismatches between the framework, the libraries I compiled to make the linker work and whatever libraries are installed from ports, but that's a bridge that hasn't even been built yet...

Quote

As for PowerPC support, I think we would all be chasing our tails in circles trying to reconcile different versions of Xcode and different versions of OS X... my mind spins at the thought, considering I have never owned a Mac, not to mention testing a program on both a rather outdated model and a cutting edge model simultaneously. We should change the libs from PPC/x86 to x86/x86_64 immediately and mull over backwards compatibility later. I feel confident in saying that the number of x86_64 users is more than the number of PPC users.


This is definitely the way things are headed. Lots of software has already abandoned PPC support with more planning to in the future. I can think of a few ways to at least retain the idea of a PPC build for a little bit longer, but without the demand it hardly seems worth it. The fact that no one has really objected to most of Helixhorned's recent builds being Intel-only kind of says it all, really.

Quote

Anyway, I think checking for a ".svn" folder is redundant anyway since we are doing nothing more complicated than grabbing the revision number. Both "svn info" and "git svn info" work at any subdirectory level of the repository (even with SVN using a 1.7-style repo) and both display error messages and change ERRORLEVEL when they are not run from a repository.

C:\>echo %ERRORLEVEL%
0

C:\>svn info
svn: E155007: 'C:\' is not a working copy

C:\>echo %ERRORLEVEL%
1

C:\>git svn info
fatal: Not a git repository (or any of the parent directories): .git
Already at toplevel, but .git not found
 at C:\Program Files\Git/libexec/git-core/git-svn line 281

C:\>echo %ERRORLEVEL%
128


As it stands, synthesis.sh uses grep to find the revision, so this should not be a big obstacle.


While reading this last night, it dawned on me that simply running svn info to grep the revision was what the script used to do. Helixhorned added the directory check somewhere between r2238 and r2252 so as ensure the right command got run regardless of whether you checked the source out through svn or git. In that case it should probably stay, just adapted to refer to a location that's constant in both 1.6 and 1.7 checkouts. I've made the "if -d [ "../../.svn" ] then;" change here, and it seems to be working (I can't be sure since I still have 1.6 .svn folders all over the place), but I'll defer to the "real" programmers on how it gets handled properly.

I've also adapted some code from synthesis.sh to dump and include the SVN changelog. It's a little flaky, because I had to account for not only a situation where you have no previous archives for it to derive the difference from in order to dump the appropriate range from the changelog, but I also had to adapt the earlier changes to account for git as well. I'm not entirely sure any of the git stuff actually works as I'm still using SVN and sourceforge's source control servers have been acting funny forever so I can't check it out to find out :/

Fresh diffs to give you a better idea of what I'm on about:

osxbuild.sh:

Spoiler


Makefile:

Spoiler


Makefile.shared:

Spoiler

1

User is offline   bioman 

  • 2

#68

You should try Linux PPC, EDuke32 compiles like a charm on it. And of course it's still supported, you have access to the most recent versions of applications.
0

User is offline   LSDNinja 

  • 14

#69

View PostLSDNinja, on 28 February 2012 - 01:13 AM, said:

Which brings me to the one thing I haven't quite been able to solve properly and my band-aid solution to which will probably make the real programmers here chuckle: I could;t for the life of me work out how to get the binaries to compile in such a way that they were able to automatically look into the Frameworks folder in the .app bundle so I forced it with install_name_tool after the fact. This seems to work OK under Lion, but Snow Leopard can't wrap its head around it. If anyone knows a more elegant solution, let me know please.


Quote

This is strange. Under Snow Leopard I have had no problems simply unpacking the frameworks from the ".dmg" files from the links on the wiki page I wrote into "EDuke32.app/Contents/Frameworks" (for example) and running it without any modification to the source. Without them in place the program will not start with the error I documented on the wiki page.


View PostLSDNinja, on 29 February 2012 - 09:54 PM, said:

Yeah, I have no idea wth is going on there either. Everything that I found suggested that, when compiled with @rpath, .app/Contents/Frameworks is one of the directories that's automatically searched, but for some reason SL would prefer System/Frameworks (or whichever directory the frameworks were in when you compile I assume). The install_name_tool kludges help to a point, but then it's the frameworks that can't reference themselves properly. It's almost certainly the result of something I'm doing wrong, I just have no idea what that may be...


I think I've made some progress on this, but I've hit something of a wall: Xcode has a setting, "Runpath search paths" that, when set to "@loader_path/../Frameworks", makes everything work right. Behind the scenes, it sets a project variable called "LD_RUNPATH_SEARCH_PATHS". Trouble is, I have absolutely no idea how to translate this to the Makefile setup eDuke uses...
1

User is offline   LSDNinja 

  • 14

#70

SUCCESS!

I realised that Xcode keeps logs of the builds so I went looking in the hope the command line passed to the linker would be in one, but the ones I found were all in binary format. However, one of my other compile jobs had thrown a (non-fatal) linker error and as part of the explanation, printed the entire path being passed to ld, including the magical part: '-Xlinker -rpath -Xlinker "@loader_path/../Frameworks"'. A little bit more digging revealed that I could replace "-Xlinker" with regular "-Wl" prefixes which led me to this in Makefile:

ifeq ($(PLATFORM),DARWIN)
    ifeq (1,$(SDL_FRAMEWORK))
        APPLE_INCLUDE_DIR=$(abspath Apple/include)
        OURCFLAGS += -fno-pic -I$(APPLE_INCLUDE_DIR) -I/Library/Frameworks/SDL.framework/Headers \
                -I/Library/Frameworks/SDL_mixer.framework/Headers
        LIBS += -read_only_relocs suppress -LApple/lib -lvorbisfile -lvorbis -logg -lm \
                -Wl,-framework,SDL -Wl,-framework,SDL_mixer Apple/lib/libSDLmain.a \
                -Wl,-framework,Cocoa -Wl,-framework,Carbon -Wl,-framework,OpenGL \
                -Wl,-framework,CoreMidi -Wl,-framework,AudioUnit \
                -Wl,-framework,AudioToolbox -Wl,-framework,IOKit -Wl,-framework,AGL \
                -Wl,-framework,QuickTime -lm \
                >>-Wl,-rpath -Wl,"@loader_path/../Frameworks"<<
        # We have SDLMain.m from the OSX SDL package in the Apple/ subdir:
        EDITOROBJS+=$(OBJ)/SDLMain.$o
        GAMEOBJS+=$(OBJ)/SDLMain.$o
    else
        OURCFLAGS += -fno-pic -I$(SDLROOT)/include -I$(SDLROOT)/include/SDL
        LIBS += -read_only_relocs suppress -lvorbisfile -lvorbis -logg -lm -lSDL_mixer \
                -Wl,-framework,Cocoa -Wl,-framework,Carbon -Wl,-framework,OpenGL \
                -Wl,-framework,CoreMidi -Wl,-framework,AudioUnit \
                -Wl,-framework,AudioToolbox -Wl,-framework,IOKit -Wl,-framework,AGL \
                -Wl,-framework,QuickTime -lm
    endif
    NASMFLAGS += -f macho
endif


Which not only allows it to work under Lion without the frameworks being present in /Library/Frameworks (they're still necessary to build the source, so I have to keep them around, but it's nice to know the resultant binary is accessing its local copy and doesn't depend on them) , but under Snow Leopard as well. I was a little worried about the latter, as I thought I would have had to find a way to manually set the deployment target. It seemed easy enough: throw MACOSX_DEPLOYMENT_TARGET = 10.6 into Makefile.shared, but with the luck I'm having translating Xcode variables to the greater system, it would have most likely blown up in my face.

I assume that's the best place for them, since those options are only necessary when building the source with the SDL frameworks, but as always, if there's a better location, let me know :)

edit: For my next trick, I'm thinking I might tackle how to make the debug builds conditional on a "debug" command line parameter, but that'll have to wait since I'm too stoked about how, after about 6-7 weeks of hacking around, I finally got this working the way I wanted to, not to mention adding command line parameters is a whole level above what I know about scripting :/

This post has been edited by LSDNinja: 03 March 2012 - 06:11 PM

1

User is offline   Hendricks266 

  • EDuke32 Senior Developer
  • 5,365

  #71

Before I add this I need to know, what do I actually add to the Makefile? Two options:

>>-Wl,-rpath -Wl,"@loader_path/../Frameworks"<<

-Wl,-rpath -Wl,"@loader_path/../Frameworks"


Also, I need you to test that with this added, the game still works with the Frameworks in one of the other locations and not in the app bundle.

View PostLSDNinja, on 03 March 2012 - 06:09 PM, said:

edit: For my next trick, I'm thinking I might tackle how to make the debug builds conditional on a "debug" command line parameter, but that'll have to wait since I'm too stoked about how, after about 6-7 weeks of hacking around, I finally got this working the way I wanted to, not to mention adding command line parameters is a whole level above what I know about scripting :/

If you mean to the binary itself, this is out of the question since it is a fundamentally different build process, if you mean to the app bundle it sounds interesting, if you mean to osxbuild.sh it is unnecessary and should be contained in it like synthesis.sh, and if you mean to the Makefile that doesn't make sense. I don't know why Helix disabled debug builds on OS X, but in theory they should work and would just require more copies of the app bundle.
0

User is offline   LSDNinja 

  • 14

#72

View PostHendricks266, on 03 March 2012 - 06:39 PM, said:

Before I add this I need to know, what do I actually add to the Makefile? Two options:

>>-Wl,-rpath -Wl,"@loader_path/../Frameworks"<<

-Wl,-rpath -Wl,"@loader_path/../Frameworks"


Also, I need you to test that with this added, the game still works with the Frameworks in one of the other locations and not in the app bundle.


The latter, the >><< marks were added to point it out. Sorry for not making that entirely clear. "@executable_path" I think is the better option for 10.5+ than "@loader_path", but everything I found on the subject suggested @loader_path so I went with that. I'll do some more testing and see what happens.

I did a quick test and it seems to work with or without the frameworks being present within the app bundle. I'm not 100% sure how this works, but I believe that /Library/Frameworks and ~/Library/Frameworks (and quite possibly /System/Library/Frameworks) are searched at runtime regardless of any additional parameters you specify and this @rpath, @loader_path and @executable_path business just supplements that.

Quote

If you mean to the binary itself, this is out of the question since it is a fundamentally different build process, if you mean to the app bundle it sounds interesting, if you mean to osxbuild.sh it is unnecessary and should be contained in it like synthesis.sh, and if you mean to the Makefile that doesn't make sense. I don't know why Helix disabled debug builds on OS X, but in theory they should work and would just require more copies of the app bundle.


What I mean is that, as it stands, all the bits to build debug versions are currently commented out. My idea is to instead make them conditional on a command line parameter. It's mostly pointless since debug builds aren't all that useful unless you know what to do with them, especially seeing as how most problems can be sorted through looking at logs and eDuke logs most everything by default (another project I deal with makes full logging dependent on running debug builds, which can be a bit of a pain). I mostly want to do it to see if I can, and hopefully learn something from the experience :)

Chances are high I won't even bother, since the conditionals required to separate and sort out multiple command line parameters in varying order are doing my head in just thinking about them :)
1

User is offline   Hendricks266 

  • EDuke32 Senior Developer
  • 5,365

  #73

The two items on your list I can't complete on my own are the 64-bit libs and including the frameworks. I had a bright idea, though: Since you have to have the frameworks to compile the program, and because we want to include them in the .app bundles, then these two overlap. In theory, we could copy the frameworks from the location specified in the Makefile, or ideally we could include the frameworks in the repository and use them for both purposes without requiring a separate installation. However, the symlinks are still a problem.

As for the libs, I don't know if we should just use yours or build them under some other circumstances. Could you upload them? If they do not have any extra dependencies then they should be fine to use.

View PostLSDNinja, on 03 March 2012 - 06:09 PM, said:

the frameworks being present in /Library/Frameworks (they're still necessary to build the source, so I have to keep them around

I am going to add a variable called APPLE_FRAMEWORKS which you can add to the make invocation to customize this if you want. It has to use absolute paths though.

View PostLSDNinja, on 29 February 2012 - 09:54 PM, said:

(the man page didn't list -r as being valid, but it was working so I assume theres simply no case sensitivity on the parameter, but I decided to err on the side of caution and go with what the man page said)

You are correct, both cases are valid for the parameter.

cp --help said:

-R, -r, --recursive copy directories recursively

0

User is offline   Hendricks266 

  • EDuke32 Senior Developer
  • 5,365

  #74

Quote

-------------------------------------------------- ----------------------
r2396 | hendricks266 | 2012-03-04 03:30:27 -0600 (Sun, 04 Mar 2012) | 2 lines

JFDuke3D port: OS X Startup Window, copied almost verbatim
It needs to have the sound quality box removed and the Game directory box added, possibly among other things.
------------------------------------------------------------------------
r2398 | hendricks266 | 2012-03-04 03:31:37 -0600 (Sun, 04 Mar 2012) | 2 lines

Add APPLE_FRAMEWORKS Makefile variable which can be passed to the make invocation.
ex: make APPLE_FRAMEWORKS=~/Library/Frameworks
------------------------------------------------------------------------
r2399 | hendricks266 | 2012-03-04 03:32:06 -0600 (Sun, 04 Mar 2012) | 1 line

Add an explicit declaration so that Mac OS X binaries look for the Frameworks inside the app bundle before anywhere else.
------------------------------------------------------------------------
r2400 | hendricks266 | 2012-03-04 03:32:33 -0600 (Sun, 04 Mar 2012) | 1 line

Under Mac OS X, override libsupc++ with libstdc++.
------------------------------------------------------------------------
r2401 | hendricks266 | 2012-03-04 03:32:57 -0600 (Sun, 04 Mar 2012) | 1 line

Under Mac OS X, look for libvpx in /usr/local to add support for Homebrew in addition to MacPorts.
------------------------------------------------------------------------
r2402 | hendricks266 | 2012-03-04 03:33:23 -0600 (Sun, 04 Mar 2012) | 6 lines

synthesis.sh:
- Exclude "Apple/lib" rather than "Apple" so that required files are not left out of the tarball.
- Add one to $lastrevision before generating the ChangeLog so that it only includes what is new to an update.
osxbuild.sh:
- Add stronger detection of the SVN revision by adding support for 1.7 (no longer relying on an ".svn" directory) and having a specific fallback in case
build location is neither svn nor git.
- Echo the SVN revision to source/rev.h before the build processes and revert it afterwards.
------------------------------------------------------------------------

I added most of your changes and a few of my own. :)

Things I did not add:
  • I did not have osxbuild.sh generate a ChangeLog. It seemed rather hackish because synthesis is designed to be run exclusively under the circumstances of the Duke4.net server, while osxbuild.sh is for general use (although geared towards Helix). Note that synthesis.sh contains an "svn update" while osxbuild.sh does not.
  • I have not touched any addition of the frameworks to the repository or the relevant code in the Makefile and osxbuild.sh.
  • I didn't bother with the install_name_tool stuff since I think we have it covered.
  • Replacing the PPC/86 libs with 86/64 libs remains a priority.
  • I didn't take out any of the PPC comments just yet.

Also, Rheonie explained to me on IRC that Apple first provided libsupc++ with 10.6 and even that required special parameters to load the 10.6 SDK. So, for now, libstdc++ is a safe bet.

Rhoenie said:

<rhoenie> right now its rather complicated on OSX.. people still have 10.4 and 10.5
<rhoenie> but you cannot compile a binary for these on current 10.7
<rhoenie> and on the other hand: if you build a binary on 10.4 its not said that it will run without crashing on 10.7
<rhoenie> ah.. and powerpc/intel on the 10.4/10.5 setup as well..
<rhoenie> and then there are those 32/64 bit targets :)

Speaking of IRC, it would be great if you could idle in #eduke32 as there is often good programming discussion.
0

User is offline   Tetsuo 

  • 89

#75

View PostHelixhorned, on 01 March 2012 - 04:11 PM, said:

OK, the usual drill then... the new revision prints a more informative message (it reads "G_SavePlayer: failed opening '...' for writing"). What does it say for you?

Just a quick word here... nothing related to "G_Saveplayer:" or saving ever showed up in my log from any build I got. I tried re-downloading it when you posted that and it didn't do anything there either. I wish I was making this up but I'm not. It just doesn't seem to do anything whatsoever when I try to save and when I reopen the game it's like I never saved as the savegame screen is empty. Yet savegames in all my other games work fine.

--Tetsuo

It's funny how the colors of the real world only seem really real when you viddy them on the screen. -- Alex Delarge, A Clockwork Orange
0

User is offline   duke3d 

  • 0

#76

Hi I have a problem with EDuke32 I'm using version 1.4 Universal (Version 2008-06-30) ready to run .App i have to run this one becuse i can't get the 2.0 one to work So anyhow when i run the game i can get music but no sound i have tryed everything i can think of doing like turning of the sound completly and restarting the game again i also tryed installing Openal just to see if that will work but didn't so is there anything i can do to fix this problem

thax Duke3d

This post has been edited by duke3d: 06 March 2012 - 09:06 PM

0

User is offline   Hendricks266 

  • EDuke32 Senior Developer
  • 5,365

  #77

If you are using a PowerPC Mac like earlier in the thread that probably explains why newer versions don't work for you. As for the sound, it is hard to say because you are running a four-year old build. Have you tried compiling it yourself?

This reminds me: we should keep the old PPC/x86 libs in the repository but adjust the Makefile so that they are only used on a PPC Mac. There are two different issues here: Supporting PPC at all, and supporting PPC in official builds.
0

User is offline   duke3d 

  • 0

#78

View PostHendricks266, on 06 March 2012 - 09:50 PM, said:

If you are using a PowerPC Mac like earlier in the thread that probably explains why newer versions don't work for you. As for the sound, it is hard to say because you are running a four-year old build. Have you tried compiling it yourself?

This reminds me: we should keep the old PPC/x86 libs in the repository but adjust the Makefile so that they are only used on a PPC Mac. There are two different issues here: Supporting PPC at all, and supporting PPC in official builds.


what do you mean Keep the old PPC/x86 libs in the repository but adjust the makefile

and no i have'nt tried compiling it myself
0

User is offline   Hendricks266 

  • EDuke32 Senior Developer
  • 5,365

  #79

View Postduke3d, on 07 March 2012 - 11:41 AM, said:

what do you mean Keep the old PPC/x86 libs in the repository but adjust the makefile

That was directed more to the people in the thread who are working on OS X support from the development side.
0

User is offline   LSDNinja 

  • 14

#80

View PostHendricks266, on 06 March 2012 - 09:50 PM, said:

If you are using a PowerPC Mac like earlier in the thread that probably explains why newer versions don't work for you. As for the sound, it is hard to say because you are running a four-year old build. Have you tried compiling it yourself?

This reminds me: we should keep the old PPC/x86 libs in the repository but adjust the Makefile so that they are only used on a PPC Mac. There are two different issues here: Supporting PPC at all, and supporting PPC in official builds.


I just had a quick look into what it'd take to keep maintaining the PowerPC build and it's not pretty... Sidestepping the fact that the code doesn't build under 10.5 (and presumably 10.4 for the same reasons, which I'll get to later) for just a sec, I was able to build a set of three-way universal libraries for libSDL, libogg and libvorbis and after hacking away to uncomment to PPC build directives (I'm a little too thorough and duplicated them for 64-bit PowerPC. I realised that it wouldn't work and commented them out again) it seemed to work until it got to the final linking stage. Turns out the OS X versions of the latest SDL frameworks are Intel-only and while they do supply an SDL.framework that is for PPC, it's meant for 10.4 and therefore, I assume, lacks x86_64 support. Fixing that means going back and rebuilding both frameworks for ppc/i386/x86_64. They supply Xcode projects, but the only way to build them as three-way universal binaries is to use Xcode 3.2 or earlier and I'm only barely starting to get my head around Xcode 4. MacPorts can install framework versions of SDL and SDL_mixer that are compatible with ppc, but they don't seem to be portable and it remains to be seen at this stage whether or not it puts them in a place the linker can access (I'm going to have to reinstall all my ports as 3-way universal to test this as I added ppc half way through and wound up with half and half causing issues later on).

Which brings me now to the other major problem involved in supporting PowerPC: The fact that, as it stands, the code doesn't build under 10.5. A couple of the CFLAGS, -fjump-tables and -Wstrict-overflow=1, aren't supported by the version of GCC Apple ship with Xcode 3.1.4 for Leopard. Not only that, but sdlmusic.c makes a call on the posix_memalign function that isn't implemented prior to 10.6. Both of these seem relatively simple to fix, simply add some Makefile voodoo to sort Darwin 9 and earlier out from 10 and later and use that to disable the offending CFLAGS and make some changes to sdlmusic.c so that it doesn't try and use the posix_memalign function at all under Darwin (some googling seemed to indicate that OS X guarantees 16-byte alignment itself so this should be safe, not that I know what that means or why it's important, heh).

The question here is whether or not any of this is worth it. Originally, I wasn't so sure, but after indulging in this little experiment, I find myself leaning more and more toward 'no'. In any case, Rhoenies last build (20110315) should still support PowerPC and enough of the newer features to keep people still on PowerPC machines happy for a little while longer...

We now return to our regularly scheduled programme :D

View PostHendricks266, on 03 March 2012 - 10:51 PM, said:

The two items on your list I can't complete on my own are the 64-bit libs and including the frameworks. I had a bright idea, though: Since you have to have the frameworks to compile the program, and because we want to include them in the .app bundles, then these two overlap. In theory, we could copy the frameworks from the location specified in the Makefile, or ideally we could include the frameworks in the repository and use them for both purposes without requiring a separate installation. However, the symlinks are still a problem.


As long as you keep them zipped in the repository (and have the Makefile/osxbuild.sh deal with unzipping them) the symlinks shouldn't be a problem. I have an appropriate archive file here, but I've been holding off uploading it since I'm a bit put off by the attachment limit :/

Quote

As for the libs, I don't know if we should just use yours or build them under some other circumstances. Could you upload them? If they do not have any extra dependencies then they should be fine to use.


The ones I have were built under Lion using MacPorts (HomeBrew has no easy way of making things universal), but they seem to work just fine under Snow Leopard. I'm not actually sure if they link under Leopard or not, since other issues affected my ability to compile it. I have these ready for upload to, but I'm just unsure as to where I should upload them to...

Quote

I am going to add a variable called APPLE_FRAMEWORKS which you can add to the make invocation to customize this if you want. It has to use absolute paths though.


I'm not entirely sure it's as simple as this since none of my attempts to relocate the frameworks out of /Library/Frameworks were successful. However, this may be the result of my attempts to back port your variable system to my r2394 tree since Helixhorned's configuration dialogue import doesn't build for me so I'm stuck having away with and older tree. I know it's possible as I've seen it done in Xcode projects, but once again it's a matter of translating what Xcode does back to regular linker commands.

Quote

You are correct, both cases are valid for the parameter.


That's for GNU cp. Mac OS X uses BSD for which some of the swathes are a little different. Notably, cp -r is supported for historical reasons but implies cp -RL which causes symlinks to be followed which isn't what you want. cp -R implies cp -RP by default, which preserves symlinks. It's a little nitpick thing I'm kind of embarrassed to bring up considering how accommodating you've been so far, but this is the safest way of dealing with things.

Quote

Things I did not add:
  • I did not have osxbuild.sh generate a ChangeLog. It seemed rather hackish because synthesis is designed to be run exclusively under the circumstances of the Duke4.net server, while osxbuild.sh is for general use (although geared towards Helix). Note that synthesis.sh contains an "svn update" while osxbuild.sh does not.


The Changelog thing was mostly for my benefit as well as the future possibility of regular automated OS X builds. I'm perfectly happy to maintain it here if you don't want to add it upstream, but I still think it's worth reconsidering if you're ever in a position to automate the OS X builds. :)

Quote

  • I have not touched any addition of the frameworks to the repository or the relevant code in the Makefile and osxbuild.sh.


I think a way needs to be found to make these portable as well before you think about adding them to the repository, especially now that you seem to be having second thoughts about dropping PowerPC support (which will need special versions of the frameworks). As I said before, I have ready to go versions of what's needed here if you only want to support Intel, you just need to make a firm decision on the future of PowerPC support.

Quote

  • I didn't bother with the install_name_tool stuff since I think we have it covered.


Yeah, they were only ever a kludge to make the binaries "portable" and even then it wasn't 100% effective. I'd actually taken them out of my script the day or so before I made my earlier post they were unnecessary, to kind of force myself to find a better solution.

Quote

  • Replacing the PPC/86 libs with 86/64 libs remains a priority.
  • I didn't take out any of the PPC comments just yet.


Again, I have everything ready to go on this front, I just need a firm word on how you want to proceed. I can even do more testing with my three-way universal versions (to see if they link properly under Lion) if that's the path you want to go down.

Finally, I have to report a couple of bugs with the script/Makefiles as they ethan now: In your new version control detection code, you accidentally compared one against the variable 'ref' which meant it broke the git detection. Someone came along and tried to fix it so both comparisons are now against 'ref' and both don't work. Changing them back to what I think is the correct variable 'rev' makes it work right:

rev=`svn info | grep Revision | awk '{ print $2 }'`
vc=svn
if [ -z "$rev" ]; then
    vc=git
    rev=`git svn info | grep 'Revision' | awk '{ print $2 }'`
fi

if [ -n "$rev" ]; then
    # throw the svn revision into a header.  this is ugly.
    echo "const char *s_buildRev = \"r$rev\";" > source/rev.h
else
    rev=unknown
    vc=none
fi


instead of:

rev=`svn info | grep Revision | awk '{ print $2 }'`
vc=svn
if [ -z "$ref" ]; then
    vc=git
    rev=`git svn info | grep 'Revision' | awk '{ print $2 }'`
fi

if [ -n "$ref" ]; then
    # throw the svn revision into a header.  this is ugly.
    echo "const char *s_buildRev = \"r$rev\";" > source/rev.h
else
    rev=unknown
    vc=none
fi


Secondly, when you added the -rpath and @installname line to the linker flags to Makefile, you forgot a trailing \ on the Quicktime line above it, so the line is broken instead of merged:

ifeq ($(PLATFORM),DARWIN)
    OURCFLAGS += -fno-pic -I$(abspath Apple) -I$(abspath Apple/include)
    ifeq (1,$(SDL_FRAMEWORK))
        OURCFLAGS += -I$(APPLE_FRAMEWORKS)/SDL.framework/Headers \
                -I$(APPLE_FRAMEWORKS)/SDL_mixer.framework/Headers
        LIBS += -read_only_relocs suppress -LApple/lib -lvorbisfile -lvorbis -logg -lm \
                -Wl,-framework,SDL -Wl,-framework,SDL_mixer Apple/lib/libSDLmain.a \
                -Wl,-framework,Cocoa -Wl,-framework,Carbon -Wl,-framework,OpenGL \
                -Wl,-framework,CoreMidi -Wl,-framework,AudioUnit \
                -Wl,-framework,AudioToolbox -Wl,-framework,IOKit -Wl,-framework,AGL \
                -Wl,-framework,QuickTime -lm \  # pointing this out here since it's 'blink and you miss it'.
                -Wl,-rpath -Wl,"@loader_path/../Frameworks"
        # We have SDLMain.m from the OSX SDL package in the Apple/ subdir:
        EDITOROBJS+=$(OBJ)/SDLMain.$o
        GAMEOBJS+=$(OBJ)/SDLMain.$o
    else
        OURCFLAGS += -I$(SDLROOT)/include -I$(SDLROOT)/include/SDL
        LIBS += -read_only_relocs suppress -lvorbisfile -lvorbis -logg -lm -lSDL_mixer \
                -Wl,-framework,Cocoa -Wl,-framework,Carbon -Wl,-framework,OpenGL \
                -Wl,-framework,CoreMidi -Wl,-framework,AudioUnit \
                -Wl,-framework,AudioToolbox -Wl,-framework,IOKit -Wl,-framework,AGL \
                -Wl,-framework,QuickTime -lm
    endif
    EDITOROBJS+=$(OBJ)/GrpFile.game.$o $(OBJ)/GameListSource.game.$o $(OBJ)/StartupWinController.game.$o
    GAMEOBJS+=$(OBJ)/GrpFile.game.$o $(OBJ)/GameListSource.game.$o $(OBJ)/StartupWinController.game.$o
    NASMFLAGS += -f macho
endif


instead of:

ifeq ($(PLATFORM),DARWIN)
    OURCFLAGS += -fno-pic -I$(abspath Apple) -I$(abspath Apple/include)
    ifeq (1,$(SDL_FRAMEWORK))
        OURCFLAGS += -I$(APPLE_FRAMEWORKS)/SDL.framework/Headers \
                -I$(APPLE_FRAMEWORKS)/SDL_mixer.framework/Headers
        LIBS += -read_only_relocs suppress -LApple/lib -lvorbisfile -lvorbis -logg -lm \
                -Wl,-framework,SDL -Wl,-framework,SDL_mixer Apple/lib/libSDLmain.a \
                -Wl,-framework,Cocoa -Wl,-framework,Carbon -Wl,-framework,OpenGL \
                -Wl,-framework,CoreMidi -Wl,-framework,AudioUnit \
                -Wl,-framework,AudioToolbox -Wl,-framework,IOKit -Wl,-framework,AGL \
                -Wl,-framework,QuickTime -lm
                -Wl,-rpath -Wl,"@loader_path/../Frameworks"
        # We have SDLMain.m from the OSX SDL package in the Apple/ subdir:
        EDITOROBJS+=$(OBJ)/SDLMain.$o
        GAMEOBJS+=$(OBJ)/SDLMain.$o
    else
        OURCFLAGS += -I$(SDLROOT)/include -I$(SDLROOT)/include/SDL
        LIBS += -read_only_relocs suppress -lvorbisfile -lvorbis -logg -lm -lSDL_mixer \
                -Wl,-framework,Cocoa -Wl,-framework,Carbon -Wl,-framework,OpenGL \
                -Wl,-framework,CoreMidi -Wl,-framework,AudioUnit \
                -Wl,-framework,AudioToolbox -Wl,-framework,IOKit -Wl,-framework,AGL \
                -Wl,-framework,QuickTime -lm
    endif
    EDITOROBJS+=$(OBJ)/GrpFile.game.$o $(OBJ)/GameListSource.game.$o $(OBJ)/StartupWinController.game.$o
    GAMEOBJS+=$(OBJ)/GrpFile.game.$o $(OBJ)/GameListSource.game.$o $(OBJ)/StartupWinController.game.$o
    NASMFLAGS += -f macho
endif


Other than that, it all seems to work, I just can't really test it because it doesn't build (and I can't work out how to disable the configuration dialogue again).

Apologies if I sound a little curt in my replies, I've been working on this off and on for nearly a week and am still not entirely happy with how it sounds. If you want me to elaborate on anything, just ask :)
1

User is offline   Hendricks266 

  • EDuke32 Senior Developer
  • 5,365

  #81

View PostLSDNinja, on 07 March 2012 - 06:05 PM, said:

Which brings me now to the other major problem involved in supporting PowerPC: The fact that, as it stands, the code doesn't build under 10.5. A couple of the CFLAGS, -fjump-tables and -Wstrict-overflow=1, aren't supported by the version of GCC Apple ship with Xcode 3.1.4 for Leopard. Not only that, but sdlmusic.c makes a call on the posix_memalign function that isn't implemented prior to 10.6. Both of these seem relatively simple to fix, simply add some Makefile voodoo to sort Darwin 9 and earlier out from 10 and later and use that to disable the offending CFLAGS and make some changes to sdlmusic.c so that it doesn't try and use the posix_memalign function at all under Darwin (some googling seemed to indicate that OS X guarantees 16-byte alignment itself so this should be safe, not that I know what that means or why it's important, heh).

In theory this should be easy to deal with, provided I can find some way to get the OS X version into the makefile. Since you have Macs at your disposal, could you provide me with sample outputs of the uname command on different versions and with different switches? (In particular, -a and -v.) The Makefile already uses uname to detect the OS so the version should be simple, I hope.

View PostLSDNinja, on 07 March 2012 - 06:05 PM, said:

As long as you keep them zipped in the repository (and have the Makefile/osxbuild.sh deal with unzipping them) the symlinks shouldn't be a problem. I have an appropriate archive file here, but I've been holding off uploading it since I'm a bit put off by the attachment limit :/

The ones I have were built under Lion using MacPorts (HomeBrew has no easy way of making things universal), but they seem to work just fine under Snow Leopard. I'm not actually sure if they link under Leopard or not, since other issues affected my ability to compile it. I have these ready for upload to, but I'm just unsure as to where I should upload them to...

If you already have this stuff ready to go (even lacking PPC), it could not hurt if you could upload it even if I don't necessarily add it just yet. Try Mediafire.com.

View PostLSDNinja, on 07 March 2012 - 06:05 PM, said:

I think a way needs to be found to make these portable as well before you think about adding them to the repository, especially now that you seem to be having second thoughts about dropping PowerPC support (which will need special versions of the frameworks). As I said before, I have ready to go versions of what's needed here if you only want to support Intel, you just need to make a firm decision on the future of PowerPC support.

Again, I have everything ready to go on this front, I just need a firm word on how you want to proceed. I can even do more testing with my three-way universal versions (to see if they link properly under Lion) if that's the path you want to go down.

I think we should try our hardest to have universal PPC/x86/x86_64 libraries since changing those to x86/64 only is the only thing that could break PPC support even more than it already is.

For the frameworks, it would be nice to keep PowerPC support, but if it is overwhelming we could do without it. If you are unable to compile the current versions for PPC there is also a significant back-catalog we could utilize.

http://www.libsdl.org/release/
http://www.libsdl.or..._mixer/release/

View PostLSDNinja, on 07 March 2012 - 06:05 PM, said:

However, this may be the result of my attempts to back port your variable system to my r2394 tree since Helixhorned's configuration dialogue import doesn't build for me so I'm stuck having away with and older tree.

That was my commit actually. I guess it didn't build and that's what I was afraid of. That's what I get for developing blind, so to speak! Could you provide the details of the build errors so I can try and sort it out? In the meantime I will add a Makefile option to disable/enable the OS X startup window.

View PostLSDNinja, on 07 March 2012 - 06:05 PM, said:

That's for GNU cp. Mac OS X uses BSD for which some of the swathes are a little different. Notably, cp -r is supported for historical reasons but implies cp -RL which causes symlinks to be followed which isn't what you want. cp -R implies cp -RP by default, which preserves symlinks. It's a little nitpick thing I'm kind of embarrassed to bring up considering how accommodating you've been so far, but this is the safest way of dealing with things.

Don't be embarrassed at all! I learned something today. Every nitpick is valuable when programming.

View PostLSDNinja, on 07 March 2012 - 06:05 PM, said:

The Changelog thing was mostly for my benefit as well as the future possibility of regular automated OS X builds. I'm perfectly happy to maintain it here if you don't want to add it upstream, but I still think it's worth reconsidering if you're ever in a position to automate the OS X builds. :)

If we are in a position to automate OS X builds, it would be better done with a setup like synthesis.sh which handles SVN updating itself and does not rely on the version numbers of zip files to keep track. That was my main problem with the changelog: since osxbuild.sh only contains instructions to build right here right now without concern for version numbers, it was hackish to do it that way.

View PostLSDNinja, on 07 March 2012 - 06:05 PM, said:

Finally, I have to report a couple of bugs with the script/Makefiles as they ethan now: In your new version control detection code, you accidentally compared one against the variable 'ref' which meant it broke the git detection. Someone came along and tried to fix it so both comparisons are now against 'ref' and both don't work. Changing them back to what I think is the correct variable 'rev' makes it work right:

Secondly, when you added the -rpath and @installname line to the linker flags to Makefile, you forgot a trailing \ on the Quicktime line above it, so the line is broken instead of merged:

Oh, this is embarrassing. I will have it fixed ASAP.

View PostLSDNinja, on 07 March 2012 - 06:05 PM, said:

Apologies if I sound a little curt in my replies, I've been working on this off and on for nearly a week and am still not entirely happy with how it sounds. If you want me to elaborate on anything, just ask :)

Rest assured! I see absolutely zero problems with any of your posts, and you have been incredibly helpful both in your attention to detail and willingness to test out different things. In general, programming requires frank discussions of problems, solutions, suggestions, and criticisms, so fire away!
0

User is offline   Hendricks266 

  • EDuke32 Senior Developer
  • 5,365

  #82

Quote

-------------------------------------------------- ----------------------
r2425 | hendricks266 | 2012-03-08 00:06:00 -0600 (Thu, 08 Mar 2012) | 1 line

Fix OSX-related typos in Makefile and osxbuild.sh.
------------------------------------------------------------------------
r2426 | hendricks266 | 2012-03-08 00:07:10 -0600 (Thu, 08 Mar 2012) | 1 line

Add "OSX_STARTUPWINDOW" Makefile variable to toggle the OS X startup window. Off by default.
------------------------------------------------------------------------

Hopefully this should fix the problems.
0

User is offline   Helixhorned 

  • EDuke32 Senior Developer
  • 697

#83

Startup-window-enabled + PPC builds below me. That build might be slightly broken, in particular the resolution selector for Mapster32, and that you start out with red jeans :) (might be a hint that struct user_defs is interpreted differently from objc/C sources).

(o~ Lunatic home: documentation, stand-alone LuaJIT, LunaCON and utilities ~o)
1

User is offline   LSDNinja 

  • 14

#84

View PostHendricks266, on 07 March 2012 - 06:47 PM, said:

In theory this should be easy to deal with, provided I can find some way to get the OS X version into the makefile. Since you have Macs at your disposal, could you provide me with sample outputs of the uname command on different versions and with different switches? (In particular, -a and -v.) The Makefile already uses uname to detect the OS so the version should be simple, I hope.


On my Mini, the outputs for those uname switches are:

uname -a said:

Darwin Silky-Doll.local 11.3.0 Darwin Kernel Version 11.3.0: Thu Jan 12 18:47:41 PST 2012; root:xnu-1699.24.23~1/RELEASE_X86_64 x86_64


and

uname -v said:

Darwin Kernel Version 11.3.0: Thu Jan 12 18:47:41 PST 2012; root:xnu-1699.24.23~1/RELEASE_X86_64


Of more relevance though, I suspect, is uname -r:

uname -r said:

11.3.0


which gives you just the operating system release. The way it breaks down for OS X is that the first number represents the Darwin major version, in this case, 11 is Lion. Snow Leopard is 10, Leopard is 9 and when it's released, Mountain Lion should be 12, and the second represents the patch level, which is 3 here because I'm running 10.7.3. I honestly have no idea what the third number is for, or even if it's ever been used for anything in a version of OS X. With some cut-fu it should be possible to isolate just the first number which, when combined with an ifeq ($(PLATFORM),DARWIN), should give you the ability to isolate specific versions of Darwin/OS X:

Quote

$ uname -r | cut -d . -f 1
11


Maybe use that as the basis for a DARWINSUBPLATFORM (probably a bit long-winded, maybe just a DARWIN9 boolean...) variable to disable the offending CFLAGS/functions...

Quote

If you already have this stuff ready to go (even lacking PPC), it could not hurt if you could upload it even if I don't necessarily add it just yet. Try Mediafire.com.


I'd actually forgotten about Mediafire. Here goes:

http://www.mediafire...1bxvhmmdlwm4inc

Those are the the newer, three-way universal, versions of the five libraries in the Apple/lib directory. I had to compile them under Snow Leopard, but they appear to link just fine under Lion. Leopard, which is the important one here, I still can't test since as far as I can tell, the source still won't build under it.

Quote

I think we should try our hardest to have universal PPC/x86/x86_64 libraries since changing those to x86/64 only is the only thing that could break PPC support even more than it already is.

For the frameworks, it would be nice to keep PowerPC support, but if it is overwhelming we could do without it. If you are unable to compile the current versions for PPC there is also a significant back-catalog we could utilize.

http://www.libsdl.org/release/
http://www.libsdl.or..._mixer/release/


The two major problems with using older releases are the possibility of a version mismatch with the libraries pulled in from Apple/lib as well as older versions potentially not implementing something eDuke requires. Another problem is how to swing in the right versions of the frameworks on a per-architecture basis as I still haven't succeeded in relocating the (build-time) frameworks out of /Library/Frameworks despite trying every combination I could think of of linker and compiler flags. It gets a few levels down in the tree and suddenly can't find the headers. This happens whether I specify the path in its entirety, or try and fudge it by defining APPLE_FRAMEWORKS with abspath and it always breaks when compiling jaudiolib/src/driver_sdl.c and build/src/sdlayer.c claiming that it can't find "SDL/SDL.h" or some such. It doesn't even work when you use a path outside the tree (even one level down from /Library/Frameworks fails). The only way it works 100% reliably is if the frameworks are in /Library/Frameworks and I can't for the life of me work out why.

Quote

If we are in a position to automate OS X builds, it would be better done with a setup like synthesis.sh which handles SVN updating itself and does not rely on the version numbers of zip files to keep track. That was my main problem with the changelog: since osxbuild.sh only contains instructions to build right here right now without concern for version numbers, it was hackish to do it that way.


As near as I can tell though, synthesis.sh does an svn update first to bring it's own tree up to date with head and then uses the filename of the last snapshot to determine not only if it has to do a new build, but also generate the changelog down the line. I pretty much lifted the line to generate the last revision verbatim from synthesis.sh, only modifying to suit the different filename conventions between the synthesis builds and the OS X builds. The other code is probably a little hackish, but that was added in a hurry in response to certain potential issues that cropped up like what to do if there were no builds to work back from (I didn't want it dumping the *entire* changelog) or differences in version control systems. By studying synthesis.sh more closely, I can probably come up with something more elegant, but I think I'll put it on the back burner for now.

(I only hit the cliff notes here since everything else seems to have been sorted in the time it took me to write this up :))

(I also could have sworn the .app cp -r's in Makefile were transformed in cp -PR's, but they may have just been svn merging your changes with mine and not telling me. Either that, or I didn't notice when it did. Grr...)
1

User is offline   LSDNinja 

  • 14

#85

View PostHelixhorned, on 08 March 2012 - 01:33 PM, said:

Startup-window-enabled + PPC builds below me. That build might be slightly broken, in particular the resolution selector for Mapster32, and that you start out with red jeans :) (might be a hint that struct user_defs is interpreted differently from objc/C sources).


Slight problem here is that it still doesn't run on 10.5, which it needs to in order to be of any use for PowerPC folks. This probably presents the strongest case for dropping PowerPC support, since maintaining PowerPC supports also means maintaining 10.5 support. I think I caught the three blockers for 10.5 support, I just lack the know-how to do much about them. There's also the problem of testing. Despite being correctly identified as "Application (Universal)", the option to "Open using Rosetta" is greyed out, indicating the possibility that the PPC side of things doesn't work 100%. Without proper PowerPC hardware and toolchains, testing is almost impossible.

Another issue here too is that Lion has no PowerPC support at all, the SDKs and toolchain support are completely absent from Xcode 4, meaning that osxbuild.sh errors out quite spectacularly when you reach that part of the script. It shouldn't be too difficult to either make the PPC build conditional on PPC support in the hardware (uname -m or uname -p should be able to help out there, but I have no way of checking for sure) or even split the PPC build out into its own version of osxbuild.sh, but the more of these special exceptions that have to be made in order to support PowerPC and 10.5, the less it becomes worth it to bother, especially when no one is in a position to properly test any resulting builds.

Finally, how did you build the frameworks necessary to enable ppc support? I have had limited success thus far in trying to build them with Xcode, but with MacPorts and a couple of symlinks, it built fine (albeit without the ability to support 10.5). My problem with using MacPorts to do it is the resulting frameworks aren't portable, which creates problems for distribution. At the same time though, even if I can get SDL_Mixer to compile successfully as a universal framework, getting the build to see it outside of /Library/Frameworks is a whole other problem...
1

User is offline   Hendricks266 

  • EDuke32 Senior Developer
  • 5,365

  #86

Quote

-------------------------------------------------- ----------------------
r2432 | hendricks266 | 2012-03-09 01:43:49 -0600 (Fri, 09 Mar 2012) | 1 line

OS X: fix build under Leopard/Xcode 3.1.4
------------------------------------------------------------------------
r2433 | hendricks266 | 2012-03-09 01:45:55 -0600 (Fri, 09 Mar 2012) | 1 line

OS X: new universal x86/x86_64/PPC libraries provided by LSDNinja
------------------------------------------------------------------------
r2434 | hendricks266 | 2012-03-09 01:57:00 -0600 (Fri, 09 Mar 2012) | 1 line

OS X: Since the posix_memalign function causes problems when running on 10.5, not just building, I am making this more "risky/daring" change because OS X guarantees 16 byte alignment so it should be safe.
------------------------------------------------------------------------

This should solve some more stuff but knowing my track record I probably broke something again.

I made r2434 sort of last minute (it revises r2432) but I am sleepy so I hope I correctly interpreted your statement that 10.5 does not run --> posix_memalign must be disabled for all OS X builds because it does not exist on 10.5.
0

User is offline   Hendricks266 

  • EDuke32 Senior Developer
  • 5,365

  #87

View PostLSDNinja, on 08 March 2012 - 10:48 PM, said:

Another issue here too is that Lion has no PowerPC support at all, the SDKs and toolchain support are completely absent from Xcode 4, meaning that osxbuild.sh errors out quite spectacularly when you reach that part of the script. It shouldn't be too difficult to either make the PPC build conditional on PPC support in the hardware (uname -m or uname -p should be able to help out there, but I have no way of checking for sure) or even split the PPC build out into its own version of osxbuild.sh, but the more of these special exceptions that have to be made in order to support PowerPC and 10.5, the less it becomes worth it to bother, especially when no one is in a position to properly test any resulting builds.

It is not too much of an imposition to do that although it could get slightly ugly when the different architectures are mentioned simultaneously on the same line. By the same token, what is the lower bound that osxbuild.sh should support? 10.4? 10.5?

View PostLSDNinja, on 08 March 2012 - 10:48 PM, said:

At the same time though, even if I can get SDL_Mixer to compile successfully as a universal framework, getting the build to see it outside of /Library/Frameworks is a whole other problem...

This may actually be a problem of whether the includes use <> or "". Here is a quick grep of all the SDL-related includes in the source:

build/include/sdl_inc.h:#  include <SDL/SDL.h>
build/include/sdl_inc.h:#  include <SDL_mixer/SDL_mixer.h>
build/src/sdlayer.c:#include <SDL/SDL_events.h>
source/jaudiolib/src/driver_sdl.c:#include <SDL/SDL.h>
source/jaudiolib/src/driver_sdl.c:# include <SDL_mixer/SDL_mixer.h>
source/jaudiolib/src/driver_sdl.c:# include <SDL/SDL_mixer.h>
source/jaudiolib/src/driver_sdl.c:#include <SDL/SDL_thread.h>
Apple/SDLMain.m:#include "SDL.h"
Apple/SDLMain.m:#include "SDLMain.h"
build/include/sdl_inc.h:#  include "SDL.h"
build/include/sdl_inc.h:#  include "SDL_mixer.h"
build/src/misc/makesdlkeytrans.c:#include "SDL/SDL.h"


Try changing them all to be consistently one or the other, and one of the combinations just might work. If so, I will have a new commit to make.

EDIT: Note that a special "SDLMain.h" exists in Apple/ so watch out. I really need some sleep.
0

User is offline   Helixhorned 

  • EDuke32 Senior Developer
  • 697

#88

View PostLSDNinja, on 08 March 2012 - 10:48 PM, said:

Finally, how did you build the frameworks necessary to enable ppc support?

I have no idea TBH, it just works for me. Doing some checks with the "file" command, I have the SDL ones in /Library/Frameworks (installed a long time ago, probably), and the Vorbis libs in our Apple/ tree contain PPC objects.

View PostHendricks266, on 08 March 2012 - 11:48 PM, said:

r2434 | hendricks266 | 2012-03-09 01:57:00 -0600 (Fri, 09 Mar 2012) | 1 line

OS X: Since the posix_memalign function causes problems when running on 10.5, not just building, I am making this more "risky/daring" change because OS X guarantees 16 byte alignment so it should be safe.

By the way, that code is there because I'm paranoid about running arbitrary commands from the main program. It saves the $EDUKE32_MUSIC_CMD string in the allocated block, and makes the page (hence memalign) read-only. :)

(o~ Lunatic home: documentation, stand-alone LuaJIT, LunaCON and utilities ~o)
0

User is offline   Hendricks266 

  • EDuke32 Senior Developer
  • 5,365

  #89

I went to edit osxbuild.sh to prevent PowerPC from being built under 10.7 Lion, but I ended up raping the thing.

Quote

---------------------------------------------------------------- --------
r2437 | hendricks266 | 2012-03-10 03:45:18 -0600 (Sat, 10 Mar 2012) | 6 lines

Thoroughly revised osxbuild.sh, featuring:
- Conditional disabling of the build for each architecture
- Conditional enabling of debug building
- Detection of the OS X version, disabling incompatible builds and establishing a minimum version
- Fail-safe assembly of fat binaries and the archive (each item is checked first)
- Lovely factored 'for' loops and parameter expansion
------------------------------------------------------------------------

I set 10.4 Tiger as the minimum version required to build at all. Is this correct?
0

User is offline   LSDNinja 

  • 14

#90

OK, following the last lot of changes it now appears to compile, link and run under 10.5. On Intel at least. I have no idea if the PowerPC build works or not since it crashes Rosetta (not a good sign, but also no indication that it'll crash on actual hardware, either. The PPC Mapster seems to work under Rosetta though, which seems unusual) and I don't have a PPC Mac to test it on. I have a G5 that I may be able to drag out of mothballs, but it's at my parents place and I have no idea when I'll be able to get back there

A couple of bugs: Hendricks' changes to detect and account for Darwin 9 mostly seem to work, but -Wstrict-overflow=1 is still getting set. I suspect that might be because Makefile.common (where this is supposed to be set up) is being processed before Makefile.shared (where the platform-specific overrides are set up), but I'm not really sure since there's also ifeq($(PLATFORM))'s in .shared as well...

The bad news though is that one of the libraries threw undefined symbols at link-time meaning I had to swing in a set I compiled under Leopard, which work fine there. I also tested them under Lion just to make sure and they work fine there too. Here's the link if you want those:

http://www.mediafire...9abzv7532ac98s3

View PostHendricks266, on 09 March 2012 - 12:17 AM, said:

This may actually be a problem of whether the includes use <> or "". Here is a quick grep of all the SDL-related includes in the source:

build/include/sdl_inc.h:#  include <SDL/SDL.h>
build/include/sdl_inc.h:#  include <SDL_mixer/SDL_mixer.h>
build/src/sdlayer.c:#include <SDL/SDL_events.h>
source/jaudiolib/src/driver_sdl.c:#include <SDL/SDL.h>
source/jaudiolib/src/driver_sdl.c:# include <SDL_mixer/SDL_mixer.h>
source/jaudiolib/src/driver_sdl.c:# include <SDL/SDL_mixer.h>
source/jaudiolib/src/driver_sdl.c:#include <SDL/SDL_thread.h>
Apple/SDLMain.m:#include "SDL.h"
Apple/SDLMain.m:#include "SDLMain.h"
build/include/sdl_inc.h:#  include "SDL.h"
build/include/sdl_inc.h:#  include "SDL_mixer.h"
build/src/misc/makesdlkeytrans.c:#include "SDL/SDL.h"


Try changing them all to be consistently one or the other, and one of the combinations just might work. If so, I will have a new commit to make.

EDIT: Note that a special "SDLMain.h" exists in Apple/ so watch out. I really need some sleep.


I went through and changed them all the "", which seems to work, only now I'm getting a new error:

Apple/SDLMain.m:17: error: cannot find interface declaration for ‘NSApplication’
Failed building obj/SDLMain.o from Apple/SDLMain.m!
make: *** [obj/SDLMain.o] Error 1
make: *** Waiting for unfinished jobs....


...which I think is what you were telling me to watch out for :)

Also, is the "" or <> convention compiler-specific? I can't shake the feeling that this may be why libvorbis isn't compiling right for me under Leopard meaning that fixing this and making these changes across the board will mean breaking 10.5 support again...


edit: turns out this was something else entirely and changing the includes had no discernible effect. I've tried a whole bunch of different things, but it's almost like something, somewhere is hard-coded to look for the headers in /Library/Frameworks, but there's nothing like that in the Makefiles. I'm reasonably certain I have the variables set up right, since when I inadvertently forgot to change APPLE_FRAMEWORKS in Makefile.common SDLMain.m complained it couldn't find SDL.h (because I left it at /Library/Frameworks and I'd removed them from there to avoid any confusion), but was perfectly happy when I had it at $(abspath Apple/Frameworks)...

View PostHendricks266, on 10 March 2012 - 02:12 AM, said:

I went to edit osxbuild.sh to prevent PowerPC from being built under 10.7 Lion, but I ended up raping the thing.

I set 10.4 Tiger as the minimum version required to build at all. Is this correct?


I had a similar idea, only I was thinking of using the architecture of the build machine (somehow derived from uname) to determine which of the builds to do since the thought occurred to me that it really isn't necessary to have to script work to output a completely universal binary as PowerPC users are unlikely to want the Intel build and likewise, Intel users aren't likely to want the PowerPC build. There's the possibility of a situation in which a person has multiple Macs of different architectures in their house, but that's an extreme corner case I suspect and, given the limited portability of the binaries at this point, they're probably better off setting up the build environment and compiling the source on each machine individually. Your solution seems more elegant than anything I would have come up with.

A couple of suggestions I would make though is first to add "ARCH='-arch x86_64'" to the 64-bit make invocation since I noticed under Leopard that, even though it was capable of building and running the 64-bit version, it didn't do so by default the way Snow Leopard and Lion seem to, instead building the i386 version twice causing lipo to get its panties in a bunch later on when it encountered two binaries with the same arch. Secondly, I'd probably change the version detection conditionals for at the very least Snow Leopard to be >= since everyone running Snow Leopard has an x86/x86_64 machine meaning the PPC build is probably a waste of time for them too.

As far as 10.4 goes, I'm kind of striking out. I had to disable several more compiler/linker flags (-fstack-protector, -map, the eduke32.memmap business, the path/@loader_path line and maybe one or two others I'd need to do another few runs to find out) to even get it to compile and even though it seems to compile, it errors out when you try and execute it:

dyld: unknown external relocation type
Trace/BPT error


I have know idea what any of that means or even where to begin to look to fix it. It's possible we've hit a wall and 10.5 is as low as we can go :/

edit: spotted another bug in the new osxbuild.sh: when it lists the command line parameters you forgot to escape the pipe symbol when listing the debug parameter. Adding another \ clears it right up:

echo usage: osxbuild [onlyzip] [noppc] [no86] [no64] [--debug=\<0\|1\>]


This post has been edited by LSDNinja: 10 March 2012 - 10:01 PM

1

Share this topic:


  • 7 Pages +
  • 1
  • 2
  • 3
  • 4
  • 5
  • Last »
  • You cannot start a new topic
  • You cannot reply to this topic


All copyrights and trademarks are property of their respective owners and all comments are owned by their posters. Yes, our forum uses cookies. © 2004-2017 Duke4.net and Voidpoint, LLC

Enter your sign in name and password


Sign in options