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

Jump to content

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

Building EDuke32 on Mac OS X

User is offline   LSDNinja 

#91 Posted 10 March 2012 - 11:56 PM

So I went and revisited my changelog code. I'm not sure if I've made it better or worse:

    # Generate Changelog
    lastrevision=`ls -A1 eduke32-osx* | tail -n1 | cut -d- -f3 | cut -d. -f1`
    
    if [ -z $lastrevision ]; then
        let lastrevision=rev-1
    elif [ $lastrevision -lt $rev ]; then
        let lastrevision+=1
    else
        let lastrevision=rev-1
    fi

    if [ "$vc" == "svn" ]; then
            svn log -r $rev:$lastrevision > Changelog.txt
    elif [ "$vc" == "git" ]; then
            git svn log -r $rev:$lastrevision > Changelog.txt
    fi


What it's supposed to do is generate a changelog between the version you're currently building and the one you had before, but in the absence of an existing build or if it's the same as the current version, generate a changelog for the revision just prior. The overall idea being to avoid generating a log that spans back to the dawn of the repo. I'm not happy with having rev-1 in there twice though, I was hoping to have it so it added 1 when lastrevision was less than rev and subtracted one in every other case, but that had issues when lastrevision was null.

edit: Goddammit Hendricks! I had to change HDDs to test Tiger and now I have to change 'em back to test Leopard again! :)

This post has been edited by LSDNinja: 11 March 2012 - 12:03 AM

0

User is offline   LSDNinja 

#92 Posted 11 March 2012 - 12:47 AM

OK, so that last round of changes enabled to source to build and link cleanly under Leopard as far as I can tell. The PowerPC build is still acting a little weird, but without an actual PowerPC Mac to test it on I can't confirm if that's due to a problem with the build itself or some conflict with Rosetta...

The question still remains, however, as to what to do about Tiger. I want to say that that's where the line should be drawn, but our one PowerPC user in this thread is still using it so I don't know...

I should probably take the time to document the PowerPC build process at some point, as it's a little involved, but I should probably wait until I have access to an actual PowerPC Mac so I can sort out what's a cross-compilation issue and what isn't.
0

User is online   Hendricks266 

  • Weaponized Autism

  #93 Posted 11 March 2012 - 12:53 AM

Quote

r2444 | hendricks266 | 2012-03-11 01:11:59 -0600 (Sun, 11 Mar 2012) | 2 lines

- Makefiles: fix handling of "-Wstrict-overflow=1" to fix Leopard 10.5/Xcode 3.1.4 compatibility
- osxbuild.sh: explicitly specify "ARCH='-arch x86_64'" for 64-bit builds
------------------------------------------------------------------------
r2445 | hendricks266 | 2012-03-11 01:15:44 -0600 (Sun, 11 Mar 2012) | 1 line

OS X: another set of new universal x86/x86_64/PPC libraries provided by LSDNinja, this time compiled under Leopard 10.5


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

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...

You are right, so I moved all the handling of -Wstrict-overflow=1 to Makefile.shared.

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

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

Added. It definitely sounds safer to me to have the libs compiled on an older machine because there tends to be more incompatibility working backwards than forwards.

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

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 :)

I really did need some sleep. SDLMain.h is not "special", but rather is tied to SDLMain.m and is not a part of the SDL library at all! It specifically must remain using "".

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

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...

"" and <> are standard to the C preprocessor. I'm not sure to make of the rest of this quote. :)

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

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.

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.

The primary purpose of osxbuild.sh is to serve as the source for a universal binary distribution which, as of now, is Helix's personal builds. If the PPC build is a waste of time for users then they can run "osxbuild.sh noppc" and all will be well. :wub:

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

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 :/

That sounds like a lot to deal with and I have the inclination simply to banish 10.4 from osxbuild.sh without further delay.

EDIT

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

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\>]


Damn! I missed this because I had this post written ~5 hours before I made the commits. Go figure. Oh well, at least it's just cosmetic. I'll fix it in the next go-round, and I'll add your changelog code too for good measure. :D

This post has been edited by Hendricks266: 11 March 2012 - 01:20 AM

0

User is offline   LSDNinja 

#94 Posted 11 March 2012 - 02:20 AM

View PostHendricks266, on 11 March 2012 - 12:53 AM, said:

"" and <> are standard to the C preprocessor. I'm not sure to make of the rest of this quote. :)


It was mostly me drifting off on to another thought :D Basically, the reason I'm having trouble compiling a universal version of SDL_mixer.framework is because libvorbis and libtheora can't seem to find the Ogg headers (which are in /Library/Frameworks/Ogg.framework/Headers) and all the includes there are in the form #include "Ogg/Ogg.h" as well (This same setup that worked under Xcode 4 without issue, only without ppc support, obviously). I was thinking that, since changing the compiler changed the number of warnings/errors that were generated, I was running up against a new/old gcc/something else compiler issue, but if that's not the case then I'm possibly back to square 1 on that front. Seeing as I've so far been unsuccessful in getting the build to look anywhere *but* /Library/Frameworks for the frameworks it needs anyway, it's not really a big deal at this stage.

Quote

The primary purpose of osxbuild.sh is to serve as the source for a universal binary distribution which, as of now, is Helix's personal builds. If the PPC build is a waste of time for users then they can run "osxbuild.sh noppc" and all will be well. :)


What I meant (and what I could have sworn I had there, maybe it was in one of the million older drafts and didn't make the final cut...) was that it's not meant for single-point distribution in the same way synthesis is. At least, not yet anyway. With that in mind, I figured it was safe to assume that most people using it would be to compile the source for their own enjoyment, therefore reducing the need for a fully universal binary and making it easier to separate the PowerPC and Intel builds. Your way is infinitely better than what I was considering since, although it seems more complex, you avoid a lot of the code duplication I was looking at (not to mention get away without having to know what a PowerPC Mac returns for uname -m or uname -p :D). I guess what I was trying top say though was that, if you're going to go Intel-only for Lion, you may as well extend it to Snow Leopard as well since although SL can generate a PowerPC binary, it isn't overly useful since everyone running SL has an x86/x86_64 machine and it's not backward compatible with Leopard. At the same time it doesn't add that much to the build time, only about a minute and a half on my Core 2 Duo MacBook, so it probably doesn't matter...

Quote

That sounds like a lot to deal with and I have the inclination simply to banish 10.4 from osxbuild.sh without further delay.


Yeah, if the build had run after I made all those modifications then *maybe* it may have been worth going another round with platform-specific conditionals, but since it didn't and without anything specific to help nail down exactly where to start looking, it's probably best we quit while we're ahead.

Quote

EDIT

Damn! I missed this because I had this post written ~5 hours before I made the commits. Go figure. Oh well, at least it's just cosmetic. I'll fix it in the next go-round, and I'll add your changelog code too for good measure.


lol, I know exactly what that's like. I've been spending days meticulously crafting posts only to have to rejig them all because someone has replied in the interim XD. To be honest, I only noticed that since I was using the new command line switches to isolate certain builds. I figured the same errors would crop up in both cases so it was pointless to build it twice so I went to isolate the x86_64 build and mucked up the switch (thus leading to the script showing me the syntax info and causing the bug to show itself). It probably would have gone unnoticed forever otherwise XD

edit: Regarding the changelog code, I'm still not fussed if it gets in or not, I only brought it back up again to get some fresh ideas on how to make it look better. I'm still not entirely happy with how it looks or works, but if you think you can clean it up then be my guest :wub:

This post has been edited by LSDNinja: 11 March 2012 - 02:34 AM

0

User is online   Hendricks266 

  • Weaponized Autism

  #95 Posted 11 March 2012 - 12:22 PM

I'll be posting more later, but something that was brought up in IRC is building of the Build tools on OS X, which IIRC can be built by invoking make from the build/ directory. This may require another option in osxbuild.sh to create universals of the tools.

Another issue is seeing if we can have the game compile with LibVPX on x86 and possibly even PPC.

This post has been edited by Hendricks266: 11 March 2012 - 02:10 PM

0

User is offline   LSDNinja 

#96 Posted 11 March 2012 - 05:54 PM

I just enabled USE_LIBVPX on the x86 build here (under Leopard, but I'll do comparison runs under both Snow Leopard and Lion to make sure) and it seemed to work, there were no warnings or errors related to libvpx that I could see, so unless you're disabling it somewhere else it should all be good. PowerPC is going to be difficult since libvpx itself doesn't compile under PowerPC (it fails at the configure stage claiming '--host=powerpc-apple-darwin9.8.0' is an invalid option) so I'm not sure if that's going to be possible...

If by the 'build tools' you mean things like kextract and friends that live in build/src/util then that raises a possible problem of where to actually put them after they're built. Ideally you'd want them in a directory that's on the main search path so you can access them anywhere, but Unix systems, OS X in particular, make that a little difficult. Both MacPorts and Homebrew set up directories you could probably use, but they both use different ones. I suppose you write in some code that detected the presence of either /opt/local/bin (for MacPorts) or /usr/local/bin (for Homebrew) and install them in the relevant location (as well as something to uninstall them afterward if need be), but perhaps I'm over thinking it...
0

User is online   Hendricks266 

  • Weaponized Autism

  #97 Posted 13 March 2012 - 10:44 PM

Quote

r2476 | hendricks266 | 2012-03-14 01:27:45 -0500 (Wed, 14 Mar 2012) | 4 lines

osxbuild.sh: new "tools" parameter builds the Build tools in addition to the full binaries
Makefiles: new features to facilitate above:
- buildtools: "make printutils" is a phony which simply lists all the tools
- $(EXESUFFIX_OVERRIDE)

It would be great if you could look this over and give it a try.
0

User is offline   Acid0057 

#98 Posted 14 March 2012 - 09:08 AM

Hi,

I signed up on the forums because I got a nice new shiny MacBook Pro with a intel i7 which is way better then my 8 year old Windows XP PC. I'd really like to try eduke32 with the HRP on the newest build. I'm having trouble building the app and am a noob on this. Here's what I've done so far:

1. Got current version from subversion through Terminal Command line
2. Downloaded Xcode from App store (Running Mac OS X Lion 10.7.3)
3. Downloaded SDL and SDL_Mixer newest versions and placed them in /Library/Frameworks
4. Got my Duke3d.grp and Duke3d.rts from my GOG purchased version on my mac in ~/Library/Application Support/EDuke32/ along with the HRP zip files, still zipped

I don't understand this direction in the wiki from Building EDuke32 on Mac OS X:

Quote

You need to define the root directory of your SDL installation. Edit the file build/Makefile.shared. In most cases you only have to change SDLROOT to match your setup. For example: if you have MacPorts (aka DarwinPorts) installed then use /opt/local.


Not sure what I should put in the makefile.shared if my SDL installation is in Global: /Library/Frameworks

When I run osxbuild.sh from the terminal I get this output:

adams-mac-wired:eduke32 adam$ ./osxbuild.sh
./osxbuild.sh: line 92: make: command not found
./osxbuild.sh: line 93: make: command not found
x86_64 release build succeeded.
cp: Mapster32.app/Contents/MacOS/mapster32: No such file or directory
cp: EDuke32.app/Contents/MacOS/eduke32: No such file or directory
Reverted 'source/rev.h'
Creating fat binaries.


Not sure what to do at this point and any assistance is appreciated! Thanks!
0

User is offline   Helixhorned 

  • EDuke32 Developer

#99 Posted 14 March 2012 - 09:15 AM

View PostAcid0057, on 14 March 2012 - 09:08 AM, said:

./osxbuild.sh: line 92: make: command not found
./osxbuild.sh: line 93: make: command not found


You need to have the GNU build utilities like 'make' etc. installed. If they don't come with the XCode installation, maybe they're somewhere else on the system DVD?
0

User is offline   LSDNinja 

#100 Posted 14 March 2012 - 09:31 AM

That Makefile.shared stuff on the wiki is obsolete, don't worry about it.

The reason osxbuild.sh can't find make is because Apple no longer include the command line tools in the base Xcode distribution. To get those you first need to have a Developer ID (go to the Mac Dev Centre and click 'Register' in the top right hand corner and follow the steps. If you already have an Apple ID then you can link your developer ID to that. Don't worry, basic dev accounts are free. Once you have that stuff out of the way you need to open Xcode and go into its preferences dialog (Xcode -> Preferences in the menu bar or Command+,) and, in the 'Downloads' tab, click 'Install' next to 'Command Line Tools'. At this point you'll be prompted for the Developer ID you set up earlier. Enter it and your password and it should be on its way.

We're not don yet though. You also need to install MacPorts. Remember to get the Lion version and not the Snow Leopard or Leopard versions. Once that's installed, you then need to edit a couple of it's config files to make sure it builds what's needed correctly. At a terminal prompt, type:

sudo nano /opt/local/etc/macports/variants.conf


When prompted, enter your password and hit enter then add the following to the end of the file:

+universal
+no_x11


Then hold down Ctrl and press X to exit nano. You'll be asked if you want to save the file. Press 'Y'.

Now you have make sure both i386 and x86_64 versions of things are being built by typing

sudo nano /opt/local/etc/macports/macports.conf


enter your password again if prompted and then scroll down until you get to the "universal_archs" line and make sure both i386 and x86_64 are in there.

Finally you need to install the libvpx and pkg-config ports by typing:

sudo port install libvpx pkgconfig


again entering your password if prompted. Once that's all done you should be able to run osxbuild.sh and have it compile cleanly.

edit: I'll clean these up in the not too distant and put them on the wiki, I'm just waiting to get access to my G5 for the PowerPC build directions.

Hendricks: I haven't got around to testing the latest build tools additions will do that sometime later today (Thursday my time).

This post has been edited by LSDNinja: 14 March 2012 - 09:36 AM

1

User is offline   Acid0057 

#101 Posted 14 March 2012 - 12:17 PM

Thanks LSDNinja for the quick reply and help. Those directions sure got me farther then before. The only problem I'm having now is when I try to run the Eduke32.app from the compile I get an error window saying that Eduke32 app quit unexpectedly. Here's the eduke32.log file:

EDuke32 2.0.0devel r2476
Compiled Mar 14 2012 15:54:58
Using /Applications/ for game data
Using /Applications/EDuke32.app/ for game data
Using /Users/adam/Library/Application Support/EDuke32/ for game data
Initializing SDL system interface (compiled against SDL version 1.2.15, found version 1.2.15)
Using "Quartz" video driver


It just ends there. Any thoughts? Oh and when I try to run Eduke again it says that it failed when trying to restore windows do I want to try and restore windows.

This post has been edited by Acid0057: 14 March 2012 - 12:30 PM

0

User is online   Hendricks266 

  • Weaponized Autism

  #102 Posted 14 March 2012 - 05:07 PM

View PostLSDNinja, on 14 March 2012 - 09:31 AM, said:

edit: I'll clean these up in the not too distant and put them on the wiki, I'm just waiting to get access to my G5 for the PowerPC build directions.

Hendricks: I haven't got around to testing the latest build tools additions will do that sometime later today (Thursday my time).

I went ahead and wikified your new instructions because it's better to have to-be-cleaned instructions than old ones that don't work at all.
0

User is offline   LSDNinja 

#103 Posted 14 March 2012 - 07:13 PM

View PostAcid0057, on 14 March 2012 - 12:17 PM, said:

Thanks LSDNinja for the quick reply and help. Those directions sure got me farther then before. The only problem I'm having now is when I try to run the Eduke32.app from the compile I get an error window saying that Eduke32 app quit unexpectedly. Here's the eduke32.log file:

EDuke32 2.0.0devel r2476
Compiled Mar 14 2012 15:54:58
Using /Applications/ for game data
Using /Applications/EDuke32.app/ for game data
Using /Users/adam/Library/Application Support/EDuke32/ for game data
Initializing SDL system interface (compiled against SDL version 1.2.15, found version 1.2.15)
Using "Quartz" video driver


It just ends there. Any thoughts? Oh and when I try to run Eduke again it says that it failed when trying to restore windows do I want to try and restore windows.


Any chance you could paste the report that error message generates? If you paste it here don't forget to wrap it in code and spoiler tags, but a better idea is to use a Pastebin site. I have to admit that I'm at a loss as to what the problem may be though since, if you're getting to the point of having an EDuke32.app that actually runs, then that usually indicates the build environment is sound and it should work... In fact, when I built r2476 just a moment ago I wasn't able to reproduce the problem either. A possible clue is that it's bugging out right around the point that it searches for game data, but there's a specific error message for that from eDuke, it shouldn't be be causing the OS to get involved like that...

View PostHendricks266, on 14 March 2012 - 05:07 PM, said:

I went ahead and wikified your new instructions because it's better to have to-be-cleaned instructions than old ones that don't work at all.


Thanks, I had tried to write some new directions before, but got bogged down in where to start. Having to write down a single specific procedure helped, but there's still a fair bit to go :/

Also, I had a go at building those tools with the new osxbuild.sh changes and the good news is the script itself seems to work, with everything seeming to build (before you updated osxbuild.sh I was having a little trouble with generateicon because a couple of the object files were somehow being built with i386 symbols) and the logic to put them in the right directory afterward appears to function (It found the homebrew directory on my Mini, I'll still need to test it on the setups I have with MacPorts. I suspect you'll have to make some allowance, as jarring as it may be, to use sudo for Homebrew installs since one advantage of brew over MacPorts is it works at user-level, MacPorts needs superuser privs), but they just seem to disappear. I mean, the script goes through all the motions with no apparent build errors, but when it goes to list what it's built at the end, you get nothing but "No such file or directory" messages and the install line fails for similar reasons. Even digging through the build/ section of the source tree reveals nothing except the object files.

This post has been edited by LSDNinja: 14 March 2012 - 07:16 PM

1

User is offline   Tetsuo 

#104 Posted 14 March 2012 - 08:22 PM

I compiled it tonight on my Mac (27 inch Core i5 12GB RAM late 2009 iMac running 10.7.3) and the resulting .app file works fine for me.. about as good as the others that have been posted here. Although the frame rate seems better now for some reason. Anyway, it's easier than ever to compile eduke32 on the mac thanks to you guys. It's pretty neat how it now generates a .app bundle rather than raw binaries! I compiled using a super user but the resulting .app bundle can be run under my normal user account.

This post has been edited by Tetsuo: 14 March 2012 - 08:26 PM

1

User is offline   LSDNinja 

#105 Posted 15 March 2012 - 12:50 AM

Helixhorned made a series of commits not too long ago that optimised a few things, they're probably having flow-on effects to the Mac and Linux builds. The x86_64 build is probably contributing a little as well. Also, while some of the dependencies like the frameworks (Lion requires authentication before you can put stuff in /Library/Frameworks and possibly other directories) and stuff installed through MacPorts requires temporary super user privileges, building the source itself shouldn't. None of the countless test runs I've done over the last few weeks have ever had any trouble associated with building as a regular user.
1

User is online   Hendricks266 

  • Weaponized Autism

  #106 Posted 15 March 2012 - 01:01 AM

View PostLSDNinja, on 15 March 2012 - 12:50 AM, said:

Helixhorned made a series of commits not too long ago that optimised a few things, they're probably having flow-on effects to the Mac and Linux builds.

If you are running a build other than 32-bit x86, these two commits definitely have a positive impact on Classic renderer performance because on those architectures currently we have to build with the C replacements of the ASM code.

Quote

r2405 | helixhorned | 2012-03-04 14:12:30 -0600 (Sun, 04 Mar 2012) | 17 lines

Optimization of C replacements of basic texture mapping functions, part 1

Affected functions: hlineasm4, vlineasm1, mvlineasm1, tvlineasm1.

Optimizations:
- declare all used variables as possibly const-qualified locals in each
function. This removes unnecessary loads from memory in the loops.
- rewrite "for (; cnt>=0; cnt--) {...}" to "cnt++; do {...} while (--cnt);"
in the three last ones (yes, these function iterate cnt+1 times). This
makes them functionally equivalent to the asm versions (madness ensues for
cnt < 0) and allows the compiler to remove one 'test' instruction at the
end of each loop.
- in the translucence function, replace addition by ORing

Observations (system: Core2 Duo Linux x86_64):
With a 1680x1050 window fully covered by the respective type of wall (simple,
masked, trans. masked), fps increases by 3-4 from the baseline of approx. 60.
------------------------------------------------------------------------
r2424 | helixhorned | 2012-03-07 13:42:37 -0600 (Wed, 07 Mar 2012) | 13 lines

Optimizations and tweaks for C replacements of mhline and thline.

Hlines for masked and translucent masked ceiling/floor (sprites).

- apply the --> 'do { ... } while (--cnt)' transformation, making these
functions iterate cnt+1 times like the asm version. This also fixes an
off-by-one issue where sprites or masked ceilings/floors had a one-pixel
non-drawn line to the right.
- This time, only declare-as-local two 'extern' globals (asm1 and asm2).
It seems that I was too eager with "localing" all file-scoped vars earlier.
GCC is able to remove the loads from memory inside the loop by itself, whereas
clang is not. This is not trivial, since it has to prove that the 'screen'
pointer passed to the functions will never alias these globals.

0

User is offline   LSDNinja 

#107 Posted 15 March 2012 - 01:10 AM

View PostHendricks266, on 15 March 2012 - 01:01 AM, said:

If you are running a build other than 32-bit x86, these two commits definitely have a positive impact on Classic renderer performance because on those architectures currently we have to build with the C replacements of the ASM code.


Yeah, those are the ones I was talking about I think, but when you say the classic renderer does that mean you'll see little to no benefit from them on polymer or polymost?

I had a go at cleaning up the build directions on the wiki:

http://pastebin.ca/2128330

I can't say I'm entirely happy with that though. The business with libvpx in a PowerPC or universal environment is a little complicated and I'm not sure I explained it well enough, but I couldn't come up with anything better despite numerous tries. I'll probably have to re-write the MacPorts section and quite possibly even the Frameworks section from scratch, but I'm not sure yet :/
0

User is online   Hendricks266 

  • Weaponized Autism

  #108 Posted 15 March 2012 - 01:24 AM

As far as I know the ASM is only used by the classic renderer.

Your newer directions are up with one or two slight tweaks.
0

User is offline   Acid0057 

#109 Posted 15 March 2012 - 09:54 PM

I'm still getting it stuck at the same spot on my machine.

Here's what I did:

1. deleted the downloaded version off SVN for Eduke32 and got the newest
2. Checked and ran through the updated directions off the wiki.
3. Final builds of Mapster and Eduke fail in the same spot as before.

I'm going to paste in my terminal commands in a spoiler. Maybe there is a clue there somewhere but I'm no programmer so I can't make heads or tails of it.

Spoiler


And here's what my variants.conf looks like:

Spoiler


And my macports.conf as well:

Spoiler


Also does it matter where you download the Eduke32 source? Mine is in /User/Adam/Eduke32

Again any help is much appreciated!

This post has been edited by Acid0057: 15 March 2012 - 09:55 PM

0

User is offline   Tetsuo 

#110 Posted 15 March 2012 - 10:03 PM

Shouldn't matter where you download it. I let mine download to the default place which is in the account you are downloading it from and it compiles and works for me.
0

User is offline   Acid0057 

#111 Posted 15 March 2012 - 10:13 PM

View PostTetsuo, on 15 March 2012 - 10:03 PM, said:

Shouldn't matter where you download it. I let mine download to the default place which is in the account you are downloading it from and it compiles and works for me.

That's good to know. Also in case it helps here's the Mac OS X Error Report Details that I get when trying to run Eduke32.app

Spoiler

0

User is offline   LSDNinja 

#112 Posted 15 March 2012 - 10:13 PM

I went back and had another go at cleaning up the build directions and I think I have something that I'm mostly happy with. The problem, however, is that I make the assumption that only 10.5 has to worry about the PPC build. I know I've brought that up before and that you shot it down, and I was happy to accept that at the time because it didn't seem like that big a deal. I bring it up again though, because while trying to write out these directions I realised that it becomes easier for everyone if we limit the ppc/libvpx mess to the one situation where it's a real problem (creating ppc/x86/x86_64 UBs) and avoid the problem entirely everywhere else. By canning the ppc build on Snow Leopard then PowerPC users only have to deal with ppc and x86, with no need to worry about libvpx and Intel users only have to deal with x86/x86_64, with no need to worry about ppc. This only leaves a tiny amount of overlap among users who still run Leopard on Intel and/or want to create a three way universal binary, which we can deal with through some special notes for people that know what they're rather than walking everybody through a fairly involved procedure for no real benefit. All it'll take is a trivial change in osxbuild.sh:

if [ `expr $darwinversion \>\= 10` == 1 ]; then
    buildppc=0
fi


I won't bring this up again after this, so don't feel as though you have to make the above change to shut me up (I still can't shake the feeling that that's why the changelog code got in, I only brought that up again for ideas on how to improve it). I'll keep a lid on my most recent attempt on the build directions pending your decision :)
0

User is offline   LSDNinja 

#113 Posted 15 March 2012 - 10:19 PM

View PostAcid0057, on 15 March 2012 - 09:54 PM, said:

I'm still getting it stuck at the same spot on my machine.

Here's what I did:

1. deleted the downloaded version off SVN for Eduke32 and got the newest
2. Checked and ran through the updated directions off the wiki.
3. Final builds of Mapster and Eduke fail in the same spot as before.

I'm going to paste in my terminal commands in a spoiler. Maybe there is a clue there somewhere but I'm no programmer so I can't make heads or tails of it.

<snip>

Also does it matter where you download the Eduke32 source? Mine is in /User/Adam/Eduke32

Again any help is much appreciated!


One thing I notice right away is that it's not building libvpx and therefore the x86_64 build is failing. Can you dig out the log file it references (/opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_multimedia_libvpx/ libvpx/main.log) and put that up here? Maybe it'll contain some clues. That said, even without the 64-bit built the x86 build is compiling, linked and being packaged properly so that at least should work, but you never know...

UPDATE: I just forced my copy into 32-bit mode here and that started exhibiting similar crashes to Acid0057. If we can figure out exactly why libvpx isn't building for him then that should get the x86_64 build working and be enough to fix his immediate problem.

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

0

User is online   Hendricks266 

  • Weaponized Autism

  #114 Posted 16 March 2012 - 05:16 AM

View PostLSDNinja, on 15 March 2012 - 10:13 PM, said:

I went back and had another go at cleaning up the build directions and I think I have something that I'm mostly happy with. The problem, however, is that I make the assumption that only 10.5 has to worry about the PPC build. I know I've brought that up before and that you shot it down, and I was happy to accept that at the time because it didn't seem like that big a deal. I bring it up again though, because while trying to write out these directions I realised that it becomes easier for everyone if we limit the ppc/libvpx mess to the one situation where it's a real problem (creating ppc/x86/x86_64 UBs) and avoid the problem entirely everywhere else. By canning the ppc build on Snow Leopard then PowerPC users only have to deal with ppc and x86, with no need to worry about libvpx and Intel users only have to deal with x86/x86_64, with no need to worry about ppc. This only leaves a tiny amount of overlap among users who still run Leopard on Intel and/or want to create a three way universal binary, which we can deal with through some special notes for people that know what they're rather than walking everybody through a fairly involved procedure for no real benefit. All it'll take is a trivial change in osxbuild.sh:

if [ `expr $darwinversion \>\= 10` == 1 ]; then
    buildppc=0
fi


I won't bring this up again after this, so don't feel as though you have to make the above change to shut me up (I still can't shake the feeling that that's why the changelog code got in, I only brought that up again for ideas on how to improve it). I'll keep a lid on my most recent attempt on the build directions pending your decision :)

Sounds good to me, if it will make life easier for everyone, but you may want to include a few quick notes on the subject on the wiki for anyone who wants a full universal. I will add your change, and modify the noppc option to an on/off like --debug so users can force it on Snow Leopard if they want to.

The changelog code got in because it looked good and my objections don't really hold water when it works perfectly well in practice.

View PostLSDNinja, on 15 March 2012 - 10:19 PM, said:

UPDATE: I just forced my copy into 32-bit mode here and that started exhibiting similar crashes to Acid0057. If we can figure out exactly why libvpx isn't building for him then that should get the x86_64 build working and be enough to fix his immediate problem.

Do you think you could run a --debug=1 build with GDB and get a backtrace? (If you can't use GDB, crashing with the debug build might produce more useful output by OS X itself.) It would be immensely helpful.

EDIT: I get errors too when I force Helix's build into 32-bit mode.

This post has been edited by Hendricks266: 16 March 2012 - 05:33 AM

0

User is offline   Acid0057 

#115 Posted 16 March 2012 - 08:17 AM

Guys I really appreciate all your help getting my bugs ironed out here. LSDNinja here's the main.log file from Macports you requested:

Spoiler


I was just curious coming from a Windows background why we can't just have one of us build the app packages and put them up for download? Is there specific dev tools that are required to run the app package?

This post has been edited by Acid0057: 16 March 2012 - 08:59 AM

0

User is online   Hendricks266 

  • Weaponized Autism

  #116 Posted 16 March 2012 - 02:06 PM

View PostAcid0057, on 16 March 2012 - 08:17 AM, said:

I was just curious coming from a Windows background why we can't just have one of us build the app packages and put them up for download? Is there specific dev tools that are required to run the app package?

We can and we have. Check Helixhorned's signature.
0

User is offline   LSDNinja 

#117 Posted 16 March 2012 - 07:51 PM

View PostHendricks266, on 16 March 2012 - 05:16 AM, said:

Sounds good to me, if it will make life easier for everyone, but you may want to include a few quick notes on the subject on the wiki for anyone who wants a full universal. I will add your change, and modify the noppc option to an on/off like --debug so users can force it on Snow Leopard if they want to.


What've done here with the build directions is split them up into separate sections for PowerPC, Intel, steps common to both and included a section for 10.5 users who want to build a universal binary or the 64-bit build on its own. It makes things easier because people can skip through to the sections they need, hopefully without being confused by steps they don't need. Disabling the ppc build by default is good, but if you're going to include the option to enable it, is there any way you can rig it so that it enables all the DARWIN9 stuff (for all three builds, not just ppc) as well? As it is, you only disable the CFLAGS Leopard doesn't support under Leopard, they need to be disabled under Snow Leopard too if the builds are to be backward compatible. While you're at it, could you rig all three builds with similar on/of switches? Part of my revised wiki directions involve how to reenable the x86_64 build on Leopard and it'd be easier to tell people to run a simple command line parameter than to hack the script itself :)

Quote

The changelog code got in because it looked good and my objections don't really hold water when it works perfectly well in practice.


That's reassuring. There's still a couple of areas where it doesn't quite work though, which was what I was looking for help on. I'd love to be able to silence the ls error when it can't find any previous builds (I tried redirecting it to /dev/null with &>, but that resulted in all ls output being redirected, including the string I was looking for) and there's some logic issues when the svn run to determine the revision fails, but I wouldn't consider that a priority since it shouldn't happen in the real world because people will typically use the native version of svn to checkout the source whereas I've been moving working copies around through 3 major versions.

Quote

Do you think you could run a --debug=1 build with GDB and get a backtrace? (If you can't use GDB, crashing with the debug build might produce more useful output by OS X itself.) It would be immensely helpful.

EDIT: I get errors too when I force Helix's build into 32-bit mode.


I'll give this a shot, but I'll confess to having absolutely no clue how to generate such a backtrace. I'll look it up and get back to you :wub:

View PostAcid0057, on 16 March 2012 - 08:17 AM, said:

Guys I really appreciate all your help getting my bugs ironed out here. LSDNinja here's the main.log file from Macports you requested:


The offending line appears to be this:

Spoiler


I looked it up and it seems pretty weird because it's apparently related to Xcode being installed outside of /Developer and that fixing it involves changing developer_dir in macports.conf, but that seems fine in yours... What does 
xcode-select -print-path
say for you on your system? If it says anything other than "/Applications/Xcode.app/Contents/Developer" then try running 
xcode-select -switch /Applications/Xcode.app/Contents/Developer
(you may have to use sudo, not sure) and see if that helps. Even if you ultimately end up using one of Helixhorned's prebuilt binaries, you'd be doing me a massive favour when it comes to revising the build directions. MacPorts actually prompted me to run that xcode-select line not long after I upgraded to Xcode 4.3, but I figured it was because I'd upgraded through 4.2.1 and it wouldn't happen on a brand new install.

edit: I'm having a little trouble generating that backtrace. I compiled eDuke32 with the --debug=1 option (I also used no64 to completely isolate the 32-bit build) and copied the .debug.app into the my eDuke32 install directory, but when I tried to run the binary through gdb it spewed a bunch of errors claiming the object files were more recent than my executable and that it couldn't find something called an OSO file :)

This post has been edited by LSDNinja: 16 March 2012 - 08:28 PM

0

User is online   Hendricks266 

  • Weaponized Autism

  #118 Posted 16 March 2012 - 11:27 PM

Quote

r2487 | hendricks266 | 2012-03-17 02:25:46 -0500 (Sat, 17 Mar 2012) | 4 lines

osxbuild.sh:
- Make all arguments explicit toggles (except for onlyzip).
- Disable PowerPC builds by default on Snow Leopard in addition to Lion.
- Enable Darwin 9 compatibility for all builds whenever PowerPC is enabled.


View PostLSDNinja, on 16 March 2012 - 07:51 PM, said:

edit: I'm having a little trouble generating that backtrace. I compiled eDuke32 with the --debug=1 option (I also used no64 to completely isolate the 32-bit build) and copied the .debug.app into the my eDuke32 install directory, but when I tried to run the binary through gdb it spewed a bunch of errors claiming the object files were more recent than my executable and that it couldn't find something called an OSO file :)

:wub:

Does OS X produce anything more descriptive or informative when you crash with the debug build?
0

User is offline   Tetsuo 

#119 Posted 17 March 2012 - 12:52 AM

Now when I try to build eduke32 I get:

./osxbuild.sh: line 208: OSX_STARTUPWINDOW=1: command not found
x86_64 release build succeeded.
cp: Mapster32.app/Contents/MacOS/mapster32: No such file or directory
cp: EDuke32.app/Contents/MacOS/eduke32: No such file or directory
./osxbuild.sh: line 232: OSX_STARTUPWINDOW=1: command not found
x86 release build succeeded.
cp: Mapster32.app/Contents/MacOS/mapster32: No such file or directory
cp: EDuke32.app/Contents/MacOS/eduke32: No such file or directory
Reverted 'source/rev.h'
Creating fat binaries.

0

User is online   Hendricks266 

  • Weaponized Autism

  #120 Posted 18 March 2012 - 01:11 AM

Quote

r2494 | hendricks266 | 2012-03-18 03:49:22 -0500 (Sun, 18 Mar 2012) | 1 line

osxbuild.sh: Potential fix for the $commonargs bash variable.

Tetsuo, see if this fixes it.

This post has been edited by Hendricks266: 18 March 2012 - 01:12 AM

0

Share this topic:


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

All copyrights and trademarks not owned by Voidpoint, LLC are the sole property of their respective owners. Play Ion Fury! ;) © Voidpoint, LLC

Enter your sign in name and password

Sign in options