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

Jump to content

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

Building EDuke32 on Mac OS X

User is offline   Tetsuo 

#121 Posted 18 March 2012 - 03:06 AM

Yup it did it's now building the same as it was before.. also I have started building it in my under my user account rather than a super user account and as indicated before that's working fine as well.
0

User is offline   Acid0057 

#122 Posted 18 March 2012 - 01:52 PM

 LSDNinja, on 16 March 2012 - 07:51 PM, said:

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.



Thanks LSDNinja for the followup. I've done the xcode print and it did come back with the /Applications/Xcode.app/Contents/Developer directory. So it seems okay on my end but still errors out the same way on the newest build 2494.

EDIT: I just tried Helix's latest build and it works fine.

This post has been edited by Acid0057: 18 March 2012 - 02:57 PM

0

User is offline   LSDNinja 

#123 Posted 18 March 2012 - 04:31 PM

The problem isn't with eDuke32. Not exactly, anyway. The 32-bit build currently has a bug that causes it to crash, yes, but the 64-bit build should be fine, it's just not building on your system because MacPorts is refusing to build libvpx for some reason. There's a bunch of bug reports on it on the MacPorts trac, they claim the issue has been fixed. Try running:

sudo port selfupdate
sudo port clean libvpx
sudo port install libvpx


followed by trying osxbuild.sh again and see if that helps. Meanwhile, I'll re-install a fresh copy of Xcode 4.3.1 on my MacBook and see if I can't reproduce this issue.
0

User is offline   SanyaWaffles 

#124 Posted 19 March 2012 - 10:03 AM

 LSDNinja, on 18 March 2012 - 04:31 PM, said:

The problem isn't with eDuke32. Not exactly, anyway. The 32-bit build currently has a bug that causes it to crash, yes, but the 64-bit build should be fine, it's just not building on your system because MacPorts is refusing to build libvpx for some reason. There's a bunch of bug reports on it on the MacPorts trac, they claim the issue has been fixed. Try running:

sudo port selfupdate
sudo port clean libvpx
sudo port install libvpx


followed by trying osxbuild.sh again and see if that helps. Meanwhile, I'll re-install a fresh copy of Xcode 4.3.1 on my MacBook and see if I can't reproduce this issue.


I recently obtained an iMac and for native building this fixed the problems I was having. For some reason my Xcode wasn't found (switching the Xcode path fixed it) and applying these commands fixed it. Before it kept crashing for me on startup, regardless of 32 or 64 bit binaries.

I had a question, not sure if this is appropriate to ask it in this thread - but how does on build the build tools included in the SVN (like transpal came in handy on Windows) - the

--tools=1


argument isn't working for some reason. no binaries are being built for transpal or the like.
0

User is offline   Acid0057 

#125 Posted 19 March 2012 - 11:05 AM

 LSDNinja, on 18 March 2012 - 04:31 PM, said:

The problem isn't with eDuke32. Not exactly, anyway. The 32-bit build currently has a bug that causes it to crash, yes, but the 64-bit build should be fine, it's just not building on your system because MacPorts is refusing to build libvpx for some reason. There's a bunch of bug reports on it on the MacPorts trac, they claim the issue has been fixed. Try running:

sudo port selfupdate
sudo port clean libvpx
sudo port install libvpx


followed by trying osxbuild.sh again and see if that helps. Meanwhile, I'll re-install a fresh copy of Xcode 4.3.1 on my MacBook and see if I can't reproduce this issue.


Those Commands got it working just fine LSDNinja. Thnaks for your help! I just build r2502. Now that I know its working I'm trying to get the HRP working with the polymer render. I have polymer_hrp.zip and polymer_upd.zip and eduke32_mus.zip all in the same folder (~/Library/Application Support/Eduke32/) as my Atomic Edition DUKE3D.GRP and DUKE3D.RTS. Why aren't the HRP models or the updated music playing?
0

User is offline   LeoD 

  • Duke4.net topic/3513

#126 Posted 19 March 2012 - 04:25 PM

 Acid0057, on 19 March 2012 - 11:05 AM, said:

Those Commands got it working just fine LSDNinja. Thnaks for your help! I just build r2502. Now that I know its working I'm trying to get the HRP working with the polymer render. I have polymer_hrp.zip and polymer_upd.zip and eduke32_mus.zip all in the same folder (~/Library/Application Support/Eduke32/) as my Atomic Edition DUKE3D.GRP and DUKE3D.RTS. Why aren't the HRP models or the updated music playing?
Someone needs to tell EDuke32 to use them ofc. Create the folder ~/Library/Application Support/Eduke32/autoload. Put your ZIPs into that. Rename eduke32_mus.zip to polymer_mus.zip. Check Enable "autoload" folder on startup, or put NoAutoLoad = 0 into your eduke32.cfg.
0

User is online   Hendricks266 

  • Weaponized Autism

  #127 Posted 19 March 2012 - 05:37 PM

 Kraigose, on 19 March 2012 - 10:03 AM, said:

I had a question, not sure if this is appropriate to ask it in this thread - but how does on build the build tools included in the SVN (like transpal came in handy on Windows) - the

--tools=1


argument isn't working for some reason. no binaries are being built for transpal or the like.

They are built in the build/ subdirectory.
0

User is offline   LSDNinja 

#128 Posted 19 March 2012 - 05:39 PM

Older builds required all that stuff to be in ~/Library/Application Support/eDuke32, but newer ones let you put it all in the same directory as the binaries. There's no enable autoload or polymer checkboxes on the Mac version of the startup dialog (yet), so you have to do all that stuff in the config file. I was going to cover all that once I knew the main part of the revised build directions worked :wub:

 Kraigose, on 19 March 2012 - 10:03 AM, said:

I had a question, not sure if this is appropriate to ask it in this thread - but how does on build the build tools included in the SVN (like transpal came in handy on Windows) - the

--tools=1


argument isn't working for some reason. no binaries are being built for transpal or the like.


Last time I checked (a few days ago), that command went through all the motions, but nothing seemed to get built. I raised it earlier, but Hendricks must of missed it :)

edit: I had my G5 taken out of mothballs over the weekend, so I'm in the process of testing the PowerPC build to confirm it works on actual PowerPC hardware.

edit2: I also reinstalled Lion/Xcode/MacPorts from scratch on the MacBook last night and, apart from having to run xcode-select to change the path to the .app version of Xcode and re-run the ports sync, I wasn't able for reproduce the issue Acid0057 was having. It must have been just a bug in the port file that they fixed upstream.

This post has been edited by LSDNinja: 19 March 2012 - 05:46 PM

0

User is online   Hendricks266 

  • Weaponized Autism

  #129 Posted 19 March 2012 - 08:11 PM

 LSDNinja, on 19 March 2012 - 05:39 PM, said:

Last time I checked (a few days ago), that command went through all the motions, but nothing seemed to get built. I raised it earlier, but Hendricks must of missed it :)

I thought you were saying that the builds were disappearing when copied to the MacPorts and Homebrew directories. Are you sure they are not in "build/"?
0

User is offline   LSDNinja 

#130 Posted 19 March 2012 - 08:14 PM

 Hendricks266, on 19 March 2012 - 08:11 PM, said:

I thought you were saying that the builds were disappearing when copied to the MacPorts and Homebrew directories. Are you sure they are not in "build/"?


I had a look, all that was there were the object files. It's really strange since, for all intents and purposes, it looks like they all build and link properly, but they just... disappear somewhere between when they get built and when the script tries to copy them to $prefix/bin...
0

User is online   Hendricks266 

  • Weaponized Autism

  #131 Posted 19 March 2012 - 08:21 PM

Could you try adding a "ls $utils" before the copying but after that variable is constructed? It may work for you to have a Finder window open in "build/" as the tools are being built to see what is happening.

This post has been edited by Hendricks266: 19 March 2012 - 08:21 PM

0

User is offline   LSDNinja 

#132 Posted 19 March 2012 - 08:44 PM

It already tries to list the tools it's built as far as I can tell, all I get here is a string of "file or directory not found" messages:

Spoiler


Is there somewhere else you want me to put the ls command?
0

User is online   Hendricks266 

  • Weaponized Autism

  #133 Posted 19 March 2012 - 08:47 PM

(Has rhoenie gotten in touch with giving you remote SSH access to a PPC Mac Mini with Leopard 10.5 Server? That is what I am using to test right now.)

I think I have it. Try removing the "-j 3" command from the make invocation and the tools should build. If you could, try removing it from all 12 invocations (meaning, including the main build) and see if there are any adverse effects.

Helixhorned, do you remember why you originally added it?

This post has been edited by Hendricks266: 19 March 2012 - 08:55 PM

0

User is offline   LSDNinja 

#134 Posted 19 March 2012 - 08:49 PM

I just tried building everything on my G5 and ended up with the same hanging issue as I did with Rosetta using ppc builds built on the MacBook. At this point I think that means we can mostly rule out any kind of cross-compilation/translation issue which means I'm at a loss as to where to go next. The weird part here though is Mapster seems fine, I would have thought that'd be crashing too since it shares a lot of the same code with the main eDuke engine... I even went looking for the possibility that master is somehow getting compiled with a slightly different set of flags to eduke, but came up empty. Of course, that doesn't mean it's not, only that I can't read the Makefiles well enough to tell where, if anywhere, the flags are changing... Unless anyone else has some ideas I can try, I think we're at another of those points where he have to re-evaluate our decision to persist with ppc support... I built a debug version (I think I've figured out what's going on here: a combination of the debug builds being built before the release ones and the lipo-fu at the end of the script is throwing the timestamps off. I'll go back and see if I can't get any more meaningful data from the x86 build as well) and didn't see anything particularly helpful:

Spoiler

0

User is online   Hendricks266 

  • Weaponized Autism

  #135 Posted 19 March 2012 - 08:54 PM

(See my above post if you haven't already.)

After the program crashes in GDB, could you run the bt command to print a backtrace? It doesn't look like you did this.
0

User is offline   LSDNinja 

#136 Posted 19 March 2012 - 09:08 PM

 Hendricks266, on 19 March 2012 - 08:47 PM, said:

(Has rhoenie gotten in touch with giving you remote SSH access to a PPC Mac Mini with Leopard 10.5 Server? That is what I am using to test right now.)


I don't believe he has, but I have the PMG5 here now so I'm not sure it's hugely important.

Quote

I think I have it. Try removing the "-j 3" command from the make invocation and the tools should build. If you could, try removing it from all 12 invocations (meaning, including the main build) and see if there are any adverse effects.

Helixhorned, do you remember why you originally added it?


That seemed to get it building, but I don't think make veryclean gets rid of the object files for the build tools so now I'm getting a bunch of cross-architectural short circuits when you cross from the x86_64 versions over to the x86 versions.

 Hendricks266, on 19 March 2012 - 08:54 PM, said:

(See my above post if you haven't already.)

After the program crashes in GDB, could you run the bt command to print a backtrace? It doesn't look like you did this.


Oops, I hadn't read far enough down in the tutorial to realise I had to :)

I'll go back and do that, but does it matter if the program doesn't actually crash? Can I Ctrl-C to stop it and then run bt/backtrace to get what it was doing the moment before I stopped it?

This is all I get if I do that:

Spoiler

0

User is online   Hendricks266 

  • Weaponized Autism

  #137 Posted 19 March 2012 - 09:48 PM

 LSDNinja, on 19 March 2012 - 09:08 PM, said:

That seemed to get it building, but I don't think make veryclean gets rid of the object files for the build tools so now I'm getting a bunch of cross-architectural short circuits when you cross from the x86_64 versions over to the x86 versions.

I don't know what this problem is, but make veryclean is (probably?) not at fault. When I try it, it compiles correctly for PPC but not the first two.

 LSDNinja, on 19 March 2012 - 09:08 PM, said:

I'll go back and do that, but does it matter if the program doesn't actually crash? Can I Ctrl-C to stop it and then run bt/backtrace to get what it was doing the moment before I stopped it?

I don't think interrupting the program and then executing a backtrace is helpful. (Then again, I don't know exactly what is going on.) Does it print anything if you backtrace after the program has terminated other than "No stack."? If there is no stack... then this is really confusing.

This post has been edited by Hendricks266: 19 March 2012 - 10:04 PM

0

User is offline   Plagman 

  • Former VP of Media Operations

#138 Posted 19 March 2012 - 09:57 PM

If you're experiencing a lockup, you can definitely interrupt it in gdb and get a backtrace to see what it's doing. You should get several samples as it could be spinning in a pretty wide loop.
0

User is offline   LSDNinja 

#139 Posted 20 March 2012 - 12:35 AM

 Hendricks266, on 19 March 2012 - 09:48 PM, said:

I don't know what this problem is, but make veryclean is (probably?) not at fault. When I try it, it compiles correctly for PPC but not the first two.


The problem I'm getting is that, with -j 3 removed from all the buildutils make invocations, it'll build the x86_64 versions just fine, but when it moves on to the x86 versions I get all kinds of linking errors:

Spoiler


That's interesting, now it's throwing "undefined symbol" errors before it's got to the i386 build, much like it was before...

Quote

I don't think interrupting the program and then executing a backtrace is helpful. (Then again, I don't know exactly what is going on.) Does it print anything if you backtrace after the program has terminated other than "No stack."? If there is no stack... then this is really confusing.


What I pasted before is what I got when I ctrl-C'd and then ran backtrace. The problem is that it doesn't exactly crash as such, it just gets hung up at that point after it posts the message saying "Initialised 24.0M cache". Now, every build I've ever ran (Windows, Linux, OSX. Hell, I think even the original DOS version had a similar delay iirc) has had a slight delay at that point, but this is the first time I've run into a situation where it doesn't continue.

 Plagman, on 19 March 2012 - 09:57 PM, said:

If you're experiencing a lockup, you can definitely interrupt it in gdb and get a backtrace to see what it's doing. You should get several samples as it could be spinning in a pretty wide loop.


I'll definitely give that a shot, but it'll probably be a day or two before I can get back to it :/
0

User is offline   Acid0057 

#140 Posted 20 March 2012 - 07:40 AM

 LSDNinja, on 19 March 2012 - 05:39 PM, said:

Older builds required all that stuff to be in ~/Library/Application Support/eDuke32, but newer ones let you put it all in the same directory as the binaries. There's no enable autoload or polymer checkboxes on the Mac version of the startup dialog (yet), so you have to do all that stuff in the config file. I was going to cover all that once I knew the main part of the revised build directions worked :)


I had to modify two parts in the eduke32.cfg to get the HRP working. First all my HRP files are in ~/Library/Application Support/eDuke32/autoload/
Then I had to change "NoAutoLoad" to 0 and "Polymer" to 1 as you said above LSDNinja. I'm working with rev 2502 and it runs awesome and looks great on my MacBookPro. Thanks for all your help.

Also if anybody wants it here's the output zip with no PPC support of the latest build http://dl.dropbox.co...32-osx-2502.zip
0

User is online   Hendricks266 

  • Weaponized Autism

  #141 Posted 20 March 2012 - 09:22 AM

Helix has a new triple-universal build in his signature: http://www.kutin.de/...32-osx-2502.zip
0

User is offline   Helixhorned 

  • EDuke32 Developer

#142 Posted 20 March 2012 - 10:04 AM

 Hendricks266, on 19 March 2012 - 08:47 PM, said:

I think I have it. Try removing the "-j 3" command from the make invocation and the tools should build. If you could, try removing it from all 12 invocations (meaning, including the main build) and see if there are any adverse effects.

Helixhorned, do you remember why you originally added it?

Just building it in parallel for a little more speed. Should be handled transparently for well-written Makefiles, but removing it shouldn't have any effect on the result either. Maybe you forgot to clean up some old targets, LSDNinja?
0

User is offline   Acid0057 

#143 Posted 20 March 2012 - 10:10 AM

 Hendricks266, on 20 March 2012 - 09:22 AM, said:

Helix has a new triple-universal build in his signature: http://www.kutin.de/...32-osx-2502.zip


Well that works. I'll leave it with Helix since I can't build PPC on my Mac. Thanks again for all the help. I'll keep watching the thread if I can be of any more assistance with the compiling part.
0

User is offline   LSDNinja 

#144 Posted 21 March 2012 - 01:05 AM

 Helixhorned, on 20 March 2012 - 10:04 AM, said:

Just building it in parallel for a little more speed. Should be handled transparently for well-written Makefiles, but removing it shouldn't have any effect on the result either. Maybe you forgot to clean up some old targets, LSDNinja?


I am meticulous about cleaning stuff out in between runs, even stuff I know gets nuked before the build process starts. Anything that's left behind during a build run is stuff that isn't getting cleaned out by the appropriate clean up invocations in the Makefiles.

I think I know what it is. For kicks I ran osxbuild.sh with --tools=1 and --build64=0 to try and force it into building just the x86 versions and it still have me linking errors due to incorrect symbols. That, I assume, is because "-arch x86" or -m32 isn't being properly passed somewhere along the line. That doesn't explain why the x86_64 build is getting undefined symbols...

(make veryclean ignoring the object files for the build tools, while possibly not affecting anything here, is probably still a bug worth squashing as well)

edit running it with --build64=0 also won't make the tools install either, presumably since generateicon is still failing due to undefined symbols which throws off the rest of the build/install phase.

This post has been edited by LSDNinja: 21 March 2012 - 01:08 AM

0

User is offline   SanyaWaffles 

#145 Posted 21 March 2012 - 01:44 AM

An update for clarification: Actually by manually building it by going into the build directory (the one that contains the utilities source) itself and using make, the tools are generated that way, though the --tools=1 still is broken though and thus I'm not sure if I'm making x86_64 compatible builds of the tools.

Spoiler

1

User is offline   LSDNinja 

#146 Posted 21 March 2012 - 01:52 AM

I just tried that here and while it does seem to work (and generate x86_64 versions, but that's probably just because x86_64 is the default here), I still get the undefined symbol error in generateicon resulting in the build claiming to fail:

Spoiler


which is what it was doing before Hendricks added the facility to osxbuild.sh

edit: What exactly does this comment do, btw:

http://eduke32.svn.s...n&revision=2503

Will it have any effect on the PowerPC build seeing as, iirc, PPC is big endian?

This post has been edited by LSDNinja: 21 March 2012 - 01:58 AM

0

User is online   Hendricks266 

  • Weaponized Autism

  #147 Posted 21 March 2012 - 07:56 AM

 LSDNinja, on 21 March 2012 - 01:05 AM, said:

That, I assume, is because "-arch x86" or -m32 isn't being properly passed somewhere along the line.

If you manually specify "ARCH='-arch i386'" in osxbuild.sh, does that change anything?

 LSDNinja, on 21 March 2012 - 01:05 AM, said:

(make veryclean ignoring the object files for the build tools, while possibly not affecting anything here, is probably still a bug worth squashing as well)

Are you absolutely sure "make veryclean" leaves behind object files? The rule for it in the Makefile is:

clean:
	-rm -f $(OBJ)/*
	echo -n "" > $(OBJ)/keep.me

cleanutils:
	-rm -f $(UTILS) $(UTILOBJS) $(UTILADDOBJS)

veryclean: clean cleanutils
	-rm -f $(ENGINELIB) $(EDITORLIB)


"veryclean" first invokes "clean" which clears the entire obj.gnu folder.

 LSDNinja, on 21 March 2012 - 01:05 AM, said:

That doesn't explain why the x86_64 build is getting undefined symbols...

 LSDNinja, on 21 March 2012 - 01:05 AM, said:

edit running it with --build64=0 also won't make the tools install either, presumably since generateicon is still failing due to undefined symbols which throws off the rest of the build/install phase.

This puzzles me as well and requires further investigation.

 LSDNinja, on 21 March 2012 - 01:52 AM, said:

edit: What exactly does this comment do, btw:

http://eduke32.svn.s...n&revision=2503

Will it have any effect on the PowerPC build seeing as, iirc, PPC is big endian?

rhoenie was very happy in IRC when he saw that commit, so I assume yes.
0

User is offline   Helixhorned 

  • EDuke32 Developer

#148 Posted 21 March 2012 - 08:43 AM

 LSDNinja, on 21 March 2012 - 01:52 AM, said:

edit: What exactly does this comment do, btw:

http://eduke32.svn.s...n&revision=2503

Will it have any effect on the PowerPC build seeing as, iirc, PPC is big endian?


Among other things, it replaced a hard to read bitwise tweak with the "obvious" code. It was reading a byte into the lowest-addressed byte of an int32 (which is the most significant on big-endian) and then supposedly swapping it into the least-significant byte using this code:
#if defined(__APPLE__) && B_BIG_ENDIAN != 0
    // this is almost as bad as just setting the value to 25 :)
    g_numRealPalettes = ((g_numRealPalettes * 0x80200802ULL) & 0x0884422110ULL) * 0x0101010101ULL >> 32;
#endif

Has anyone actually verified that it does what it claims? I did the mental arithmetic once but am too lazy to do it a second time. Anyway, has the infinite (maybe just very large) loop has gone away? Otherwise it'd be interesting to see a couple more samples of "bt", as Plagman mentioned.
0

User is offline   SanyaWaffles 

#149 Posted 21 March 2012 - 08:56 AM

 Hendricks266, on 21 March 2012 - 07:56 AM, said:

If you manually specify "ARCH='-arch i386'" in osxbuild.sh, does that change anything?


I know the question wasn't directed at me, but I was trying various things this morning - aside one thing all efforts fell to pieces.

  • I tried adding i386 to the ARCH flags manually to the osxbuild.sh file
  • I tried adding it before running the osxbuild.sh file
  • Also tried manually toggling flags in the makefile to see what happened. In short, similar results - complications in the x86_64


The only way to get them to build is by going into build directory and force making:

make veryclean
make utils


Oddly, I do not specify any flags during the process, and aside generateicon, all the tools do build, and I can verify some of them do work properly (the KGROUP/KEXTRACT tools work at least!)

I also notice when building it via the shell file, says the .o files were built for i386 and are incompatible with x86_64.

Spoiler


Which looks like a linker error to me, like something isn't cleaning right between i386 (32-bit) and x86_64 (64-bit) building.

This post has been edited by Kraigose: 21 March 2012 - 09:43 AM

1

User is online   Hendricks266 

  • Weaponized Autism

  #150 Posted 21 March 2012 - 09:29 AM

 Kraigose, on 21 March 2012 - 08:56 AM, said:

make very clean
make utils

That's supposed to be one word, "veryclean".

 Kraigose, on 21 March 2012 - 08:56 AM, said:

I also notice when building it via the shell file, says the .o files were built for i386 and are incompatible with x86_64.

Which looks like a linker error to me, like something isn't cleaning right between i386 (32-bit) and x86_64 (64-bit) building.

Aha! (I think.)
In the Makefiles, I don't see $(ARCH) specified anywhere to the linker, at the very least for the tools. This may or may not be our problem. I'm away from home so I can't see for myself.

Try adding it in various places, both compiler and linker, and see if you get the desired results. Try setting "UTILLIBS=$(ARCH)". It looks like the compiling step gets $(ARCH) via $(OURCFLAGS).

This post has been edited by Hendricks266: 21 March 2012 - 09:33 AM

0

Share this topic:


  • 7 Pages +
  • « First
  • 3
  • 4
  • 5
  • 6
  • 7
  • 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