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

Jump to content

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

Building EDuke32 on Mac OS X

#151

View PostHendricks266, on 21 March 2012 - 09:29 AM, said:

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


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


Fixed my original very clean to make it one word. Sorry about that.

You're onto something. The x86 and x64 builds of the tools now compile. They toss minor warnings but it does work and it also now copies into /opt/local/bin/ of my MacPorts install! :)

Snipplet of the warning I got:

Spoiler


Looks like a few errors and warnings here and there, but most tools do build properly into fat binaries. I tested kgroup and it works fine - and fast.

I changed build/Makefile about line 61 to:

UTILLIBS=$(ARCH)  # -lpthread
UTILADDOBJS=
ifneq (0,$(NEDMALLOC))
    UTILADDOBJS+= $(OBJ)/nedmalloc.$o
endif


This post has been edited by Kraigose: 21 March 2012 - 10:38 AM

1

User is offline   Helixhorned 

  • EDuke32 Senior Developer

#152

Oops, my current build doesn't have a PPC version because of this:

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


I guess this still means that it's untested?...
0

User is offline   Hendricks266 

  • Weaponized Autism

  #153

View PostHelixhorned, on 21 March 2012 - 12:39 PM, said:

Oops, my current build doesn't have a PPC version because of this:

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


I guess this still means that it's untested?...

Here is the explanation:

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


Since the command-line arguments are parsed after this, you can override it by launching with `osxbuild.sh --buildppc=1`.

This post has been edited by Hendricks266: 21 March 2012 - 01:12 PM

0

User is offline   Hendricks266 

  • Weaponized Autism

  #154

View PostKraigose, on 21 March 2012 - 10:36 AM, said:

You're onto something. The x86 and x64 builds of the tools now compile. They toss minor warnings but it does work and it also now copies into /opt/local/bin/ of my MacPorts install! :)

Very nice. The UTILLIBS placement was just a convenient spot so that you would not have to be C/Ping $(ARCH) all over the place. The Makefiles need a proper $(LDFLAGS) and I'll add that when I'm home. I'll take a closer look at the warnings then too.

This post has been edited by Hendricks266: 21 March 2012 - 01:33 PM

0

User is offline   LSDNinja 

#155

To add to the good news, I can now confirm the PowerPC build works. I just built 2510 on the G5 and it comes up brilliantly. I still have to test if a build compiled under Snow Leopard is backward compatible with Leo on the G5, but this is progress.

edit: Oh, and thanks for reminding me I still have to get those revised build directions up :)

This post has been edited by LSDNinja: 21 March 2012 - 04:33 PM

0

User is offline   LSDNinja 

#156

View PostHendricks266, on 21 March 2012 - 07:56 AM, said:

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.


Fairly sure:

Spoiler


I just ran all those commands as I was typing this up and, apart from where I tab-completed the gnu.obj directory, it's all there. make cleanutils will successfully clean that stuff out (provided you're in the build/ dir of course) but veryclean (btw, the reason this keeps getting split up into two words is the autocorrect feature in Lion) won't.

This post has been edited by LSDNinja: 21 March 2012 - 04:44 PM

0

User is offline   TerminX 

  • el fundador

  #157

LSDNinja, do you have a SourceForge account? It has been proposed to give you svn commit access for the sake of maintaining OS X support, and after some consideration I've decided to allow it. So, if you don't already have one, please create a SourceForge account and I'll add you as a project member.
0

User is offline   Tetsuo 

#158

View PostLSDNinja, on 21 March 2012 - 04:44 PM, said:

btw, the reason this keeps getting split up into two words is the autocorrect feature in Lion


You can shut that off. http://osxdaily.com/...-mac-os-x-lion/
0

#159

View PostTetsuo, on 22 March 2012 - 03:19 AM, said:



This is something that was bugging me to no end yet I wondered how to fix it. Thank you for pointing this out, it'll save me a bundle of time. It got annoying having to go back and correct the autocorrect.
0

User is offline   Hendricks266 

  • Weaponized Autism

  #160

My new commits should fix some stuff so give them a try.

Also, try building "make makesdlkeytrans". It sounds like a pretty useless tool but I'm curious to see if it works.
0

#161

View PostHendricks266, on 23 March 2012 - 12:25 PM, said:

My new commits should fix some stuff so give them a try.

Also, try building "make makesdlkeytrans". It sounds like a pretty useless tool but I'm curious to see if it works.


Around line #163 in build/Makefile, I had to change

                    -Wl,-framework,SDL -Wl,-framework,SDL_mixer Apple/lib/libSDLmain.a


to

                    -Wl,-framework,SDL -Wl,-framework,SDL_mixer ../Apple/lib/libSDLmain.a


Or it would toss errors. After that it works well.

And doing "make makesdlkeytrans" works but I'm not sure what it does.

This post has been edited by Kraigose: 23 March 2012 - 03:41 PM

0

User is offline   Hendricks266 

  • Weaponized Autism

  #162

View PostKraigose, on 23 March 2012 - 03:37 PM, said:

After that it works well.

And doing "make makesdlkeytrans" works but I'm not sure what it does.

Glad to hear it. I'll fix that error from my quick 'n' dirty edit to add SDL libs to the tools so that makesdlkeytrans would build soon.
0

User is offline   Hendricks266 

  • Weaponized Autism

  #163

Should be fixed now.
0

#164

View PostHendricks266, on 24 March 2012 - 12:34 AM, said:

Should be fixed now.


The latest build attempts on my part are prohibiting me from building eDuke32/Mapster32 itself.

I'm getting this error:

ld: warning: directory not found for option '-L/usr/local/lib'
ld: library not found for -lssp
collect2: ld returned 1 exit status
Failed linking executable eduke32!


EDIT: For clarification, the tools themselves seem to build okay aside this little line:

buildtools: Creating fat binaries.
./osxbuild.sh: line 161: kextract.debug: command not found
buildtools: Installing to MacPorts search path.


This post has been edited by Kraigose: 24 March 2012 - 07:52 AM

0

User is offline   Helixhorned 

  • EDuke32 Senior Developer

#165

View PostKraigose, on 24 March 2012 - 07:51 AM, said:

The latest build attempts on my part are prohibiting me from building eDuke32/Mapster32 itself.

I'm getting this error:

ld: warning: directory not found for option '-L/usr/local/lib'
ld: library not found for -lssp
collect2: ld returned 1 exit status
Failed linking executable eduke32!



r2525 commit log said:

Make "LIBS+= $(L_SSP) -Wl,--enable-auto-import" conditional to Windows.

0

#166

This latest commit fixed the building of eDuke32 and Mapster32 itself it seems :) Thanks for the quick fix, Hendricks266 (for the original fixes) and Helixhorned (for fixing the linker error).
0

User is offline   LSDNinja 

#167

There's still a minor issue: At about line 162-163 of the script you generate a list of the compiled tools to pass on to lipo in order to create universal binaries:

    echo buildtools: Creating fat binaries.
    utils=`make printutils` `EXESUFFIX_OVERRIDE=.debug make printutils`


The problem is that that fails if you aren't doing a debug build. I've managed to fix that by explicitly checking for the debug option and changing the way the utils variable gets created as a result, but I'm not sure what, if anything, that'll break down the road:

    echo buildtools: Creating fat binaries.
    if [ $builddebug == 1 ]; then
        utils=`make printutils` `EXESUFFIX_OVERRIDE=.debug make printutils`
    else
        utils=`make printutils`
    fi


Which brings me to my next point:

View PostTX, on 21 March 2012 - 07:10 PM, said:

LSDNinja, do you have a SourceForge account? It has been proposed to give you svn commit access for the sake of maintaining OS X support, and after some consideration I've decided to allow it. So, if you don't already have one, please create a SourceForge account and I'll add you as a project member.


I'm... not quite sure how I feel about that. I don't know what else I can really contribute since my expertise begins and ends at relatively minor script hacks, anything code-related and I'm completely out of my depth :/ The other major reason why I'm uneasy about being given such responsibility is because I only have the most basic understanding of what I'm messing with here and it makes me feel a little better to be able to have anything I come up with peer reviewed before it gets committed in case a better solution exists. In any case, my sourceforge.net account is admiral_lsd if you still want to add it.

View PostTetsuo, on 22 March 2012 - 03:19 AM, said:



To tell the truth, I don't really mind it. It's great for the small typos I make all the time on account of my typing style. The downside is, of course, that you have to be on your toes a bit more in case it corrects something you misspelt on purpose.

Also, another couple of issues I've noticed: When Hendricks changed the conditionals to make 10.5 the minimum supported version and/or disable the powerpc build on Snow Leopard and above, it resulted in the 64-bit build not being disabled on 10.5 (because build64=0 fell into a place that only got executed on <10.5). I think I've fixed that:

if [ `expr $darwinversion \< 9` == 1 ]; then
    echo OS X 10.5 is the minimum requirement for building.
    exit 1
fi
if [ `expr $darwinversion \= 9` == 1 ]; then
    build64=0
fi
if [ `expr $darwinversion \> 9` == 1 ]; then
    buildppc=0
fi


but perhaps someone here has a more elegant solution.

Secondly, I've noticed an odd discrepancy between PowerPC builds compiled on an actual PowerPC Mac and those cross-compiled on an Intel Mac. The cross-compiled builds seem fine, building and linking with no apparent errors and they appear to work when you run them through Rosetta, but transfer them to a PowerPC Mac and they crash. I'll do some more digging with a debug build (it crashes properly meaning an accurate backtrace shouldn't be hard to generate), but it'll probably take some time since debug builds require jumping through a few hoops to get working right.
0

User is offline   Hendricks266 

  • Weaponized Autism

  #168

View PostLSDNinja, on 24 March 2012 - 10:47 PM, said:

There's still a minor issue: At about line 162-163 of the script you generate a list of the compiled tools to pass on to lipo in order to create universal binaries:

    utils=`make printutils` `EXESUFFIX_OVERRIDE=.debug make printutils`

I have fixed that but it is a simple syntax error, and the check for the existence of the debug builds is built into the loop.

View PostLSDNinja, on 24 March 2012 - 10:47 PM, said:

Also, another couple of issues I've noticed: When Hendricks changed the conditionals to make 10.5 the minimum supported version and/or disable the powerpc build on Snow Leopard and above, it resulted in the 64-bit build not being disabled on 10.5 (because build64=0 fell into a place that only got executed on <10.5).

That is a holdover from 10.4, hence its vestigial position above the error and exit. Do you want me to disable 64-bit building on 10.5 even though it is supported?
0

User is offline   LSDNinja 

#169

View PostHendricks266, on 25 March 2012 - 09:09 AM, said:

I have fixed that but it is a simple syntax error, and the check for the existence of the debug builds is built into the loop.


Heh, this is why I probably couldn't be trusted with svn access. I went after the symptom without fully understanding the cause :)

Quote

That is a holdover from 10.4, hence its vestigial position above the error and exit. Do you want me to disable 64-bit building on 10.5 even though it is supported?


My assumption is that the vast majority of people still running Leopard are doing so because they're on PowerPC hardware obsoleted by newer versions of OS X. Disabling the 64-bit build in that situation (as well as disabling the PPC build under Snow Leopard in addition to Lion) avoids the additional hassles of getting libvpx installed into a PowerPC environment. With the additional parameters to enable/disable the various builds (timeout: any chance you can rig one for the tools that builds only the tools? It's probably not hugely important now the tools are building/installing properly, but it was getting annoying there having to Ctrl-C the build every time it was launching into the main build process during testing), anyone who wishes to override the defaults can do so if they wish, and I've accounted for that in my new build directions, but I'm aiming to keep the basic procedure as simple as possible.
0

User is offline   Hendricks266 

  • Weaponized Autism

  #170

It is done!
0

User is offline   LSDNinja 

#171

Awesome. I also finally uploaded the revised build directions. There's still a couple of rough edges, but I think I have the basics mostly covered. Hopefully I haven't screwed up the formatting too much :)
0

#172

Wanted to let people know that GameListSource.game.m needs all instances of "numgrpfiles" capitalized to "NUMGRPFILES" due to the change here:

Quote

r2543 | helixhorned | 2012-03-26 18:03:40 -0400 (Mon, 26 Mar 2012) | 1 line

Capitalize numgrpfiles macro to NUMGRPFILES.


I tried compiling it before, it wouldn't work unless I did this.
0

User is offline   Helixhorned 

  • EDuke32 Senior Developer

#173

Sorry! That tells me that I need to update my Emacs function I usually use to search all source files and throw *.m in there, too.
0

#174

View PostHelixhorned, on 28 March 2012 - 10:20 AM, said:

Sorry! That tells me that I need to update my Emacs function I usually use to search all source files and throw *.m in there, too.


Okay, cool to know it's being fixed in the main trunk :)

Oh? You use Emacs? I wish I was good with it, Emacs and vi and vim are powerful - too powerful perhaps - for the dabble/up-and-coming coder like myself. The only *nix editor I use, unfortunately, is occasionally nano or pico though for sudo jobs like host file editing or the like.
0

#175

I found something interesting.

The dylibs/Frameworks:

  • SDL
  • SDL_mixer
  • libvorbis/libvorbisfile/libogg


All were in my bundle stored in <bundle>.app/Contents/Frameworks on my local build. I transferred this build to another Mac and it crashed.

I found out the error: these libraries were reading in the MacPorts directory, rather than in the app - which didn't exist.

The bad news is the builds generated are thus, not portable at all... Unless the user has it installed in the proper paths, no dice. The good news is there's a fix: the dylibs and frameworks merely need their paths changed with install_name_tool, a tool that allows the paths to be changed - in this case here's an example for the SDL framework:

install_name_tool -change @rpath/Frameworks/SDL.framework/Versions/A/SDL @executable_path/../Frameworks/SDL.framework/Versions/A/SDL eduke32


and libvorbisfile.dylib is similar:

install_name_tool -change /opt/local/lib/libvorbisfile.3.dylib @executable_path/../Frameworks/libvorbisfile.dylib eduke32


This post has been edited by Kraigose: 20 April 2012 - 05:15 PM

0

User is offline   LSDNinja 

#176

That's normal when you compile the frameworks with MacPorts afaik. MacPorts bodges the frameworks together by compiling all the dependent libraries and symlinking them into a framework shell in it's /opt/local filesystem. It's a massive pain because not only can eDuke not reliably be told to look for frameworks outside /Library/Frameworks at this point, MacPorts is the only thing that is seemingly able to build three-way universal binaries of the relevant frameworks. It's really only PowerPC users that need to worry about this, since Intel users can use the versions provided by libsdl.org which are compiled for bundle-embedding from the get-go.
0

User is offline   Helixhorned 

  • EDuke32 Senior Developer

#177

View PostTetsuo, on 05 March 2012 - 03:23 PM, said:

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

Does the problem still persist? I recently discovered that I made a stupid line-transposition mistake and as a result the error message was never printed. Now (with r3009 from my sig) the printing should work!
0

User is offline   Tetsuo 

#178

Well, now that you've fixed the printing the savegame function is also fixed. So no error to report still because savegames now work. ;)

I've got kind of a request though. Could you make it so the log file goes into the eduke32 folder in application support where the preferences goes rather than in the same folder the eduke32.app file is in? It'd be more neater and kosher that way. The folder where you keep your apps is not the folder to keep log files in.

This post has been edited by Tetsuo: 12 September 2012 - 10:49 PM

0

User is offline   Tetsuo 

#179

I seem to now be having problems with the looping function for songs. When it attempts to loop the song the entire sound system messes up. The log doesn't seem to print any error for that. This is on the same mac as before.. late 2009 model 27 inch iMac with Mountain Lion (10.8.2).

This post has been edited by Tetsuo: 25 November 2012 - 06:29 PM

0

User is offline   Hendricks266 

  • Weaponized Autism

  #180

I'm not sure how to address that. Could it be a problem in libvorbis/libogg?
0

Share this topic:


  • 7 Pages +
  • « First
  • 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