Help
Duke4.net
DNF #1
Duke 3D #1
duke3d, on 19 July 2011 - 01:12 PM, said:
the computer is a G5
Is that a PowerPC-based Mac? The builds provided are for x86 Macs.
Building EDuke32 on Mac OS X
- Weaponized Autism
-
#31 Posted 19 July 2011 - 02:30 PM
Is that a PowerPC-based Mac? The builds provided are for x86 Macs.
#32 Posted 20 July 2011 - 08:40 AM
Ya It's a Power PC. is there a ready to run app of Eduke32 for power pc
This post has been edited by duke3d: 20 July 2011 - 09:05 AM
#34 Posted 04 August 2011 - 03:05 PM
[that one dose not work even if i put the Duke 3d.grp in the same folder as the app
- Weaponized Autism
-
#35 Posted 04 August 2011 - 05:11 PM
Does it even start up? If so, can you give us your eduke32.log?
- EDuke32 Developer
-
#37 Posted 06 August 2011 - 03:11 AM
Huh? I thought I built it without any startup windows... You just 'cd' to the Duke3D directory and start ./eduke32 from there, then post the output.
#38 Posted 06 August 2011 - 06:28 PM
When you launch an executable directly like that it pops up the terminal and in there it shows the text that happens when it launches.... so if they set it up wrong it'll just open show an error (pretty much flashing all the stuff that shows up in the eduke32 log file) and close. The only way to not have a terminal window pop up every time you launch an executable directly that way would be to turn it into a proper mac .app application. It has nothing to do with built in startup windows.
To be perfectly honest with you just having the executable files loose like that is not the proper way to do it on OS X. The way rhoenie does it with the .app stuff is the proper way. Done the proper way you don't have to run it from the terminal or have the terminal launch whenever you double click on the executable file. You can download the universal .app file from rheonie's web site and replace the executables inside with the latest ones from here to have an updated version though btw. A .app file is just a folder with a special directory structure and some miscellaneous support files to launch that executable file as a proper mac app.
In order to do this you right click on the .app file and choose "show package contents* then navigate through /contents/MacOS/ and replace the executable files there with the new ones. Rheonie just never made one that directly launches mapster rather than eduke32 and last time I checked mapster is looking for some Mac UI files that aren't available. But to just get eduke32 up and running it works fine.
Also on the Mac it's best to put the grp files, the HRP files, etc. into your /Users/*User*/Library/Application Support/eDuke32/ folder.
Again here's the link for rheonie's site who has the .app stuff available.
http://www.spam-filt...eduke32_on_os_x
@duke3d you may also want to check out the builds there in general and get the .app versions and test those as at least one of them may work.
To be perfectly honest with you just having the executable files loose like that is not the proper way to do it on OS X. The way rhoenie does it with the .app stuff is the proper way. Done the proper way you don't have to run it from the terminal or have the terminal launch whenever you double click on the executable file. You can download the universal .app file from rheonie's web site and replace the executables inside with the latest ones from here to have an updated version though btw. A .app file is just a folder with a special directory structure and some miscellaneous support files to launch that executable file as a proper mac app.
In order to do this you right click on the .app file and choose "show package contents* then navigate through /contents/MacOS/ and replace the executable files there with the new ones. Rheonie just never made one that directly launches mapster rather than eduke32 and last time I checked mapster is looking for some Mac UI files that aren't available. But to just get eduke32 up and running it works fine.
Also on the Mac it's best to put the grp files, the HRP files, etc. into your /Users/*User*/Library/Application Support/eDuke32/ folder.
Again here's the link for rheonie's site who has the .app stuff available.
http://www.spam-filt...eduke32_on_os_x
@duke3d you may also want to check out the builds there in general and get the .app versions and test those as at least one of them may work.
This post has been edited by Tetsuo: 06 August 2011 - 06:47 PM
#39 Posted 10 August 2011 - 12:56 PM
[i try'd the ready to run App for OS X 10.4 tiger I open the App it brings up the console and then I have to Force quit becuse it go's unresponsive
#40 Posted 10 August 2011 - 01:01 PM
It shouldn't bring up the "console" (I'm guessing you mean terminal) unless you went inside the package and ran the executable directly.
#41 Posted 10 August 2011 - 07:05 PM
it shows the console and then at the top of the console theres two bottons they are called Configuration and the other one is Messages and thats when it becoms unresponsive.
#42 Posted 10 August 2011 - 10:55 PM
Sounds like a bizarre bug especially considering that window (the configuration window with the log.. that's not a console) is disabled in eDuke32 for Mac. I'm still thinking perhaps you have your files in the wrong place it's trying to find a certain file.. like the duke3d.grp file an when it doesn't find it it's hanging.... but it's been a long time since I've ran eDuke32 on a PowerPC mac so I don't really know what's going on just going by what you are saying. There should be a log file in the same folder you placed the eDuke32 app file in which should say what is going on.
This post has been edited by Tetsuo: 10 August 2011 - 10:58 PM
- EDuke32 Developer
-
#44 Posted 11 August 2011 - 02:16 PM
So, what executable are you using? I don't know what patches rhonie applied to the base code, so I can't give any support on his build. I know that my "raw binaries" are not the OSX way to do it, but for the sake of pinning down the problem, it might be worthwhile to start with a bare version: there's one less potential failing place.
Here are step-by-step instructions to get my compilation running:
And please, be more verbose with your bug reporting.
Here are step-by-step instructions to get my compilation running:
- extract the eduke32 binary to a directory of your choice, say, ~/duke ('~' denotes the home directory)
- The directory ~/Library/Application Support/EDuke32 must contain DUKE3D.GRP
- open a terminal program like 'Terminal' (on my Snow Leopard, it's under Applications->Utilities)
- enter "cd ~/duke" and then "./eduke32" (without the quotes)
- Now, there should appear some output from the game on the console. When it finishes, copy (Command-C) and paste (Command-V) the output into either a 'spoiler' or 'code' tag here, or on some website made for that purpose like pastebin.
And please, be more verbose with your bug reporting.
#45 Posted 11 August 2011 - 06:58 PM
Yeah he just says "I tried with duke32.grp" but doesn't say where he put it or anything like that. For all we know he just put it in the same folder as the .app file or raw binary. BTW whether you use the .app file or raw binary you have to put the .grp file in the ~/Library/Application Support/EDuke32 folder (or the root folder of the .app file as in /eduke32.app/) It's probably not caused by the .app file as he was having the same problem with the raw binary as well it seems.
This post has been edited by Tetsuo: 11 August 2011 - 07:05 PM
#46 Posted 12 August 2011 - 09:15 PM
[ok i put the biniery only app of Eduke32 in applicansions folder and put duke3d.grp in the liberary/app support/Eduke32 folder how do you get the HRP to work with this app
is there something I missing here
I tryed doing that samething with that ready to run app but it still go's unresponsive
please help
thanks Duke3d
is there something I missing here
I tryed doing that samething with that ready to run app but it still go's unresponsive
please help
thanks Duke3d
This post has been edited by duke3d: 12 August 2011 - 09:15 PM
#47 Posted 14 August 2011 - 10:41 PM
Just in case any of you developers get the impression that the problem I was talking about that was happening for me with the graphics earlier in this post is resolved by my not talking about it much lately I have to remind you that it's still happening. It's even happening in OS 10.7 Lion. Is there something I can do to help diagnose this from a testing point of view? That's practically the only problem I'm having with eDuke32. It doesn't seem to print anything to the log when the problem happens so I was wondering what extra I could do.
This post has been edited by Tetsuo: 14 August 2011 - 10:48 PM
- EDuke32 Developer
-
#48 Posted 15 September 2011 - 01:19 PM
Bumper! Here's EDuke32 revision 2027 for OS X. Careful with classic mode, the TROR test map crashes for me.
Edit 20150218: made URL invalid.
Edit 20150218: made URL invalid.
#49 Posted 15 September 2011 - 08:00 PM
Works great, full screen and everything... works good in a .app file too. Best version yet.
#50 Posted 16 September 2011 - 06:42 AM
Helixhorned, on 15 September 2011 - 01:19 PM, said:
Bumper! Here's EDuke32 revision 2027 for OS X. Careful with classic mode, the TROR test map crashes for me.
Helixhorned and Tetsuo, thanks for working to produce an updated Mac build.
regards
[Edit by Helixhorned 2015-02-18: made URL in quote invalid.]
- Weaponized Autism
-
#51 Posted 16 September 2011 - 06:53 AM
It works great, but you may want to make an app and bundle the SDL and SDL-mixer frameworks with it.
#52 Posted 27 November 2011 - 08:48 PM
Hello everyone,
First, thanks for all the great work with eDuke. I'm really glad that there is finally a Mac client so that I can relive the glory days. I am trying to get HelixHorned's latest build to work, but I keep receiving errors.
I have macports installed and do have both SDL.framework and SDL_mixer.framework in /Library/Frameworks.
It was mentioned earlier in this thread that Helix normally puts SDLMain.m and SDLMain.h in the root eduke32 directory. I did a search and was able to find SDL_main.h, but couldn't find any variation of that with the .m extension. I copied SDL_main.h to the root eduke32 directory, and just for good measure, also copied the entire SDL_mixer.framework and SDL.framework directories to the eduke32 directory. That didn't work, and during my futile attempts to figure out how to make it work, I noticed the error mentioned @executable_path/../Frameworks/SDL....., so I made a Frameworks directory with both SDL_mixer.framework and SDL.framework in it, and put that in the directory above the eduke one due to the "../"
Unfortunately, none of these attempts have succeeded, so I decided to post here. I hope this is still an active thread. Here is the error message from trying to run eduke:
Any suggestions you have would be very welcome. The idea of an app with the frameworks bundled into it was great, but I'd be happy to test other ideas to get it working this way.
First, thanks for all the great work with eDuke. I'm really glad that there is finally a Mac client so that I can relive the glory days. I am trying to get HelixHorned's latest build to work, but I keep receiving errors.
I have macports installed and do have both SDL.framework and SDL_mixer.framework in /Library/Frameworks.
It was mentioned earlier in this thread that Helix normally puts SDLMain.m and SDLMain.h in the root eduke32 directory. I did a search and was able to find SDL_main.h, but couldn't find any variation of that with the .m extension. I copied SDL_main.h to the root eduke32 directory, and just for good measure, also copied the entire SDL_mixer.framework and SDL.framework directories to the eduke32 directory. That didn't work, and during my futile attempts to figure out how to make it work, I noticed the error mentioned @executable_path/../Frameworks/SDL....., so I made a Frameworks directory with both SDL_mixer.framework and SDL.framework in it, and put that in the directory above the eduke one due to the "../"
Unfortunately, none of these attempts have succeeded, so I decided to post here. I hope this is still an active thread. Here is the error message from trying to run eduke:
X:~ user$ /Applications/eDuke32/eduke32 ; exit; dyld: Library not loaded: @executable_path/../Frameworks/SDL.framework/Versions/A/SDL Referenced from: /Applications/eDuke32/eduke32 Reason: no suitable image found. Did find: /Library/Frameworks/SDL.framework/Versions/A/SDL: no matching architecture in universal wrapper Trace/BPT trap logout [Process completed]
Any suggestions you have would be very welcome. The idea of an app with the frameworks bundled into it was great, but I'd be happy to test other ideas to get it working this way.
- Weaponized Autism
-
#53 Posted 27 November 2011 - 09:10 PM
Tman, on 27 November 2011 - 08:48 PM, said:
I noticed the error mentioned @executable_path/../Frameworks/SDL....., so I made a Frameworks directory with both SDL_mixer.framework and SDL.framework in it, and put that in the directory above the eduke one due to the "../"
This needs to be inside the .app bundle. EDuke32.app/Frameworks/SDL....... However, it should work if you put it in /Library/Frameworks/ and ~/Library/Frameworks/ (or something similar, I don't know Macs that well).
#54 Posted 28 November 2011 - 11:01 AM
Hello Hendricks,
Thank you for the speedy reply.
The file I downloaded from Helix's signature is not an app bundle, it is instead just the two UNIX executables for eduke32 and mapster32. I do also have the binary from the eDuke on OSX webpage, listed as Version 2011-03-15.
I copied that app bundle and replaced the eduke32 and mapster32 executables inside of it with the two from Helix's signature and tried running again, but that gave me the same error. I then tried to follow your advice and copied the two frameworks into the app bundle, both in app/Contents/Resources/ and in app/Contents/. app/Contents/ would be the directory above the two executables. Even with this, I received a similar error, although this one now acknowledges that the frameworks are there.
I have had MacPorts for a while, so I decided to get the latest version of it, but that still didn't help. For some reason, I then decided to go straight to the source and download the latest versions of SDL and SDL_mixer directly from the SDL website itself. I then created a fresh combined version of eDuke (the OS X binary from the OS X eDuke website and the new executables from Helix's signature) and put the two new SDL versions into a Frameworks directory inside Contents. The game now runs and doesn't give any errors! Thanks for your help, Hendricks.
The game now runs very well single player, and that is exciting. I am trying to get multiplayer working now, but am having some difficulties. I have two identical installs (as in, I copied the newly created app bundle outlined above directly to the second computer, and both use the same duke.rts and duke3d.grp files) to try to reduce problems. I start the first using -server, and it loads fine, and then I use -connect <ip of server> on the second computer and it joins properly as well. All is good in Duke World for a few minutes, but then the client invariably crashes unexpectedly. The server keeps running just fine, and I'm actually able to have the client rejoin the in-progress game, however crashing in the middle of a Duke match isn't really fair to the crash-ee.
One of the pre-crash symptoms sometimes is that the client will "jiggle" for a few seconds and then appear (to itself) to be hovering approximately one duke-height above the ground. However, the server still sees the client walking on the ground, and the client can pick items up by floating above them (server views this as client walking over them). After that, the client crashes. It sometimes even crashes without the height-errors.
Since I ran both server and client using command line arguments, Terminal is still open when the client crashes. It displays "WARNING: SE23 i<0!" numerous times and then quits. Other than the timidity errors which don't bother me (sound works just fine after changing to 8-bit instead of 16-bit), there isn't anything unusual in the log. There are no unusual entries whatsoever in the server's log or Terminal window.
For reference, all of these tests have been on E1L1: Hollywood Holocaust, with monsters present on "Damn, I'm Good" difficulty. Both client and server are able to blow enemies up together for a few minutes (with everything registering properly on both screens) before the client crashes.
I understand that the MP aspects of eDuke are a work in progress. Have there been any advances on this front recently, or is it still a back-burner issue?
Thanks again for your help.
Thank you for the speedy reply.
The file I downloaded from Helix's signature is not an app bundle, it is instead just the two UNIX executables for eduke32 and mapster32. I do also have the binary from the eDuke on OSX webpage, listed as Version 2011-03-15.
I copied that app bundle and replaced the eduke32 and mapster32 executables inside of it with the two from Helix's signature and tried running again, but that gave me the same error. I then tried to follow your advice and copied the two frameworks into the app bundle, both in app/Contents/Resources/ and in app/Contents/. app/Contents/ would be the directory above the two executables. Even with this, I received a similar error, although this one now acknowledges that the frameworks are there.
X:~ user$ /Applications/eDuke32/EDuke32.app/Contents/MacOS/eduke32 ; exit; dyld: Library not loaded: @executable_path/../Frameworks/SDL.framework/Versions/A/SDL Referenced from: /Applications/eDuke32/EDuke32.app/Contents/MacOS/eduke32 Reason: no suitable image found. Did find: /Applications/eDuke32/EDuke32.app/Contents/MacOS/../Frameworks/SDL.framework/ Versions/A/SDL: no matching architecture in universal wrapper /Applications/eDuke32/EDuke32.app/Contents/MacOS/../Frameworks/SDL.framework/ Versions/A/SDL: no matching architecture in universal wrapper /Library/Frameworks/SDL.framework/Versions/A/SDL: no matching architecture in universal wrapper Trace/BPT trap logout [Process completed]
I have had MacPorts for a while, so I decided to get the latest version of it, but that still didn't help. For some reason, I then decided to go straight to the source and download the latest versions of SDL and SDL_mixer directly from the SDL website itself. I then created a fresh combined version of eDuke (the OS X binary from the OS X eDuke website and the new executables from Helix's signature) and put the two new SDL versions into a Frameworks directory inside Contents. The game now runs and doesn't give any errors! Thanks for your help, Hendricks.
The game now runs very well single player, and that is exciting. I am trying to get multiplayer working now, but am having some difficulties. I have two identical installs (as in, I copied the newly created app bundle outlined above directly to the second computer, and both use the same duke.rts and duke3d.grp files) to try to reduce problems. I start the first using -server, and it loads fine, and then I use -connect <ip of server> on the second computer and it joins properly as well. All is good in Duke World for a few minutes, but then the client invariably crashes unexpectedly. The server keeps running just fine, and I'm actually able to have the client rejoin the in-progress game, however crashing in the middle of a Duke match isn't really fair to the crash-ee.
One of the pre-crash symptoms sometimes is that the client will "jiggle" for a few seconds and then appear (to itself) to be hovering approximately one duke-height above the ground. However, the server still sees the client walking on the ground, and the client can pick items up by floating above them (server views this as client walking over them). After that, the client crashes. It sometimes even crashes without the height-errors.
Since I ran both server and client using command line arguments, Terminal is still open when the client crashes. It displays "WARNING: SE23 i<0!" numerous times and then quits. Other than the timidity errors which don't bother me (sound works just fine after changing to 8-bit instead of 16-bit), there isn't anything unusual in the log. There are no unusual entries whatsoever in the server's log or Terminal window.
For reference, all of these tests have been on E1L1: Hollywood Holocaust, with monsters present on "Damn, I'm Good" difficulty. Both client and server are able to blow enemies up together for a few minutes (with everything registering properly on both screens) before the client crashes.
I understand that the MP aspects of eDuke are a work in progress. Have there been any advances on this front recently, or is it still a back-burner issue?
Thanks again for your help.
- Weaponized Autism
-
#55 Posted 28 November 2011 - 04:33 PM
I'm glad to help!
The multiplayer issues you are experiencing are unfortunately just the fault of the MP code as it stands today, regardless of platform.
Likewise, "WARNING: SE23 i<0!" is simply the fault of the original maps having their swinging doors constructed improperly so they clip through other sectors when they are not supposed to. (#23 on this page)
The multiplayer issues you are experiencing are unfortunately just the fault of the MP code as it stands today, regardless of platform.
Likewise, "WARNING: SE23 i<0!" is simply the fault of the original maps having their swinging doors constructed improperly so they clip through other sectors when they are not supposed to. (#23 on this page)
- Weaponized Autism
-
#56 Posted 24 February 2012 - 08:00 PM
I have been working on this lately.
If all goes well this should be fixed, as I have incorporated .app bundles based on rhoenie's bundles into the SVN and build process. I made a proper EDuke32 icon for it as well.
I also have been working on a new Building EDuke32 on Mac OS X wiki page. Please contribute if you have something to add.
Ideally, if everything is sorted out, Helix's builds should get more exposure on the main site and Dukeworld. Perhaps we could look into running a Mac OS X virtual machine on the server in which to run synthesis cronjobs.
------------------------------------------------------------------------ r2384 | hendricks266 | 2012-02-24 20:59:13 -0600 (Fri, 24 Feb 2012) | 1 line add Mac OS X .app bundles to repository ------------------------------------------------------------------------ r2385 | hendricks266 | 2012-02-24 20:59:51 -0600 (Fri, 24 Feb 2012) | 1 line The Mac OS X build process will now automatically copy the .app bundles to "./" and move the binaries into them. ------------------------------------------------------------------------ r2386 | hendricks266 | 2012-02-24 21:31:20 -0600 (Fri, 24 Feb 2012) | 1 line Update "osxbuild.sh" to reflect implementation of .app bundles on Mac OS X. ------------------------------------------------------------------------
Tetsuo, on 06 August 2011 - 06:28 PM, said:
To be perfectly honest with you just having the executable files loose like that is not the proper way to do it on OS X. The way rhoenie does it with the .app stuff is the proper way.
If all goes well this should be fixed, as I have incorporated .app bundles based on rhoenie's bundles into the SVN and build process. I made a proper EDuke32 icon for it as well.
I also have been working on a new Building EDuke32 on Mac OS X wiki page. Please contribute if you have something to add.
Ideally, if everything is sorted out, Helix's builds should get more exposure on the main site and Dukeworld. Perhaps we could look into running a Mac OS X virtual machine on the server in which to run synthesis cronjobs.
#58 Posted 28 February 2012 - 01:13 AM
I've been hacking away at my own set of change for the past month or so, but have been wrestling with the idea of releasing them. I figure now is as good a time as any.
I had to compile a new set of libs for the Apple/lib directory since the originals were ppc/i386 which was causing the 64-bit build to not link properly. The new ones are i386/x86_64. The downside is no more PowerPC support, but Apple no longer support it and I don't think it's even possible to compile PPC binaries in Xcode 4 under Lion anyway (at least not without screwing around to get Xcode 3 present with the older SDKs...).
I had to change the path for libvpx in the main Makefile because it assumes you're using MacPorts (which live in /opt/local) when I use HomeBrew (/usr/local)
The last major thing I had to do in order to get the sources to even build was change the STDPPLIB variable in build/Makefile.shared from -lsupc++ to -lstdc++. The comments say it's supposed to be overridden, but it didn't seem to be.
From there it's mostly been cosmetic stuff, like adapting the part of the synthesis.sh script that dumped the SVN revision into source/rev.h to osxbuild.sh and removing all the PowerPC build lines since they were commented out, PPC builds are unsupported and it was causing issues toward the end when it came to creating the fat binaries.
I also made some slight changes to how the .app bundles get build to facilitate the inclusion of the relevant SDL frameworks (which I dumped in the .app shells in Apple/bundles). They're full of symlinks which required some changes to command line parameters in certain files in order to have them copied over properly. The other change I made here was telling the final zip stage to exclude all the .svn folders when it build the final .app.
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.
Anyway, here are patch diffs of all my changes:
osxbuild.sh:
Makefile:
build/Makefile.shared:
Also, any chance this thread can be stickied or something so we can keep all this discussion in the one thread and not have to keep digging for it?
I had to compile a new set of libs for the Apple/lib directory since the originals were ppc/i386 which was causing the 64-bit build to not link properly. The new ones are i386/x86_64. The downside is no more PowerPC support, but Apple no longer support it and I don't think it's even possible to compile PPC binaries in Xcode 4 under Lion anyway (at least not without screwing around to get Xcode 3 present with the older SDKs...).
I had to change the path for libvpx in the main Makefile because it assumes you're using MacPorts (which live in /opt/local) when I use HomeBrew (/usr/local)
The last major thing I had to do in order to get the sources to even build was change the STDPPLIB variable in build/Makefile.shared from -lsupc++ to -lstdc++. The comments say it's supposed to be overridden, but it didn't seem to be.
From there it's mostly been cosmetic stuff, like adapting the part of the synthesis.sh script that dumped the SVN revision into source/rev.h to osxbuild.sh and removing all the PowerPC build lines since they were commented out, PPC builds are unsupported and it was causing issues toward the end when it came to creating the fat binaries.
I also made some slight changes to how the .app bundles get build to facilitate the inclusion of the relevant SDL frameworks (which I dumped in the .app shells in Apple/bundles). They're full of symlinks which required some changes to command line parameters in certain files in order to have them copied over properly. The other change I made here was telling the final zip stage to exclude all the .svn folders when it build the final .app.
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.
Anyway, here are patch diffs of all my changes:
osxbuild.sh:
Spoiler
Makefile:
Spoiler
build/Makefile.shared:
Spoiler
Also, any chance this thread can be stickied or something so we can keep all this discussion in the one thread and not have to keep digging for it?
- Weaponized Autism
-
#59 Posted 28 February 2012 - 05:21 PM
It would be best for me to leave any actual changes to Helix since I'm a noob without a Mac with which I can compile. 
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.
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.
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 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.
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.
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.
LSDNinja, on 28 February 2012 - 01:13 AM, said:
I've been hacking away at my own set of change for the past month or so, but have been wrestling with the idea of releasing them. I figure now is as good a time as any.
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.
LSDNinja, on 28 February 2012 - 01:13 AM, said:
I had to compile a new set of libs for the Apple/lib directory since the originals were ppc/i386 which was causing the 64-bit build to not link properly. The new ones are i386/x86_64. The downside is no more PowerPC support, but Apple no longer support it and I don't think it's even possible to compile PPC binaries in Xcode 4 under Lion anyway (at least not without screwing around to get Xcode 3 present with the older SDKs...).
[...]
removing all the PowerPC build lines since they were commented out, PPC builds are unsupported and it was causing issues toward the end when it came to creating the fat binaries.
[...]
removing all the PowerPC build lines since they were commented out, PPC builds are unsupported and it was causing issues toward the end when it came to creating the fat binaries.
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.
LSDNinja, on 28 February 2012 - 01:13 AM, said:
I had to change the path for libvpx in the main Makefile because it assumes you're using MacPorts (which live in /opt/local) when I use HomeBrew (/usr/local)
The last major thing I had to do in order to get the sources to even build was change the STDPPLIB variable in build/Makefile.shared from -lsupc++ to -lstdc++. The comments say it's supposed to be overridden, but it didn't seem to be.
The last major thing I had to do in order to get the sources to even build was change the STDPPLIB variable in build/Makefile.shared from -lsupc++ to -lstdc++. The comments say it's supposed to be overridden, but it didn't seem to be.
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.
LSDNinja, on 28 February 2012 - 01:13 AM, said:
From there it's mostly been cosmetic stuff, like adapting the part of the synthesis.sh script that dumped the SVN revision into source/rev.h to osxbuild.sh
[...]
The other change I made here was telling the final zip stage to exclude all the .svn folders when it build the final .app.
[...]
The other change I made here was telling the final zip stage to exclude all the .svn folders when it build the final .app.
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.
LSDNinja, on 28 February 2012 - 01:13 AM, said:
I also made some slight changes to how the .app bundles get build to facilitate the inclusion of the relevant SDL frameworks (which I dumped in the .app shells in Apple/bundles). They're full of symlinks which required some changes to command line parameters in certain files in order to have them copied over properly.
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.
LSDNinja, 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.
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.
This post has been edited by Hendricks266: 28 February 2012 - 05:26 PM
- EDuke32 Developer
-
#60 Posted 29 February 2012 - 07:45 AM
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.
