You need to change the conf or any software that will make dosbox automatically switch core to dynamic will bomb Dosbox.

Will do exactly that. Thank you.

Thank you for your help. I just tried yet another time, fresh svn checkout from the trunk. Same thing.

Now, it is not a big issue to me. I happy with Dosbox 0.74. But if somebody is interested, I can provide further details that might help to reproduce the error. Just tell me what you need and I will post more info.

Here is the compiling info:
http://pastebin.com/tupJhWYp

Ok, I got it partially figured out, thanks to ufo's build log. The hint that gave it away was the beginning of configure, the host and build system.
When I pass "--build=i386-apple-darwin10.5.0 --host=i386-apple-darwin10.5.0" along to configure everything works fine.
My automake cache prevented me from getting my host/build to get screwed up and thus always got a working one. Don't know what changed there. I'll take a look at the changes of the build system to figure this out.

Edit: something in MacPorts automake tools is screwing things up 🙁
So, really not your fault, nor is it Dosbox...

Thank you in advance, Dominus!

it's caused by the autoconf 2.68 of MacPorts. I've written to the MacPorts mailinglist, perhaps they know something. Alternatively I might need to search the autoconf bug tracker if it is a known issue.
So, either you backtrack to the 2.67 version of autoconf via MacPorts or you use the configure options I wrote in the post above.
Backtrack:
check via "port installed" whether you have that installed, MacPorts keeps old versions around if they were installed and you can see that in this list. If you have this, then enter commands "sudo port deactivate autoconf" and "sudo port activate autoconf @2.67_0".
OR if you haven't got it installed then follow the guide https://trac.macports.org/wiki/howto/InstallingOlderPort (tcl is only the example you need autoconf - the right port file for autoconf 2.67 is at https://trac.macports.org/browser/trunk/dport … tfile?rev=70583)

Dominus,

Thank you!!!

In the script I use for building, I simply replaced

./configure

with

./configure --build=i386-apple-darwin10.5.0 --host=i386-apple-darwin10.5.0

and it worked perfectly. "core dynamic" doesn't cause a crash.

Very impressed and grateful.

Thank you Dominus! You have been great help.

Actually you have been of great help, since I overlooked this issue and would have been bitten by it sooner or later as welll. This way I knew to look for something 😉

Ok, finally got it figured out for real!
All my mistake after all. Autoconf is just throwing warnings, I fixed those in a patch, see the patch tracker.

So to compile Dosbox in 32bit and a working dynamic core you need to export ONLY (forget the long export line we used before, there are some optimizations in that but to keep it simple and easier to troubleshoot use this instead):

export CFLAGS='-I/opt/local/include -O2 -arch i386'
export CXXFLAGS=$CFLAGS
export CPPFLAGS=$CXXFLAGS
export LDFLAGS='-L/opt/local/lib -O2 -arch i386'
export CC='/usr/bin/gcc-4.2 -arch i386'
export CXX='/usr/bin/g++-4.2 -arch i386'
export GCOV='/usr/bin/gcov-4.2 -arch i386'

then run ./autogen.sh and ./configure (no need for build/host, in fact better don't use those since they are very specific to Snow Leopard, with lion or leopard this will break).

The reason is that host and build targets were determined by the compiler check, compiler check showed 64bit which lead to configure making the decision to not compile the x86 dynrec core, instead it compiled the alternative 64bit dynrec core. The 64bit dynrec core bombs on OS X.

Again I have no idea how it worked fine for me before... It just did 😀

The 64bit dynrec core bombs on OS X.

gulikoza ported it for 64bit linux, does it crash when building a 64bit OSX executable
or just in your 32bit dosbox+64bit recompiler case??

also crashes a 64bit dosbox binary as I reported already a couple of times here 😀
This (and that the x86 dynrec core is supposed to be faster/better) is the reason why I'm always telling people to compile a 32bit version if they have to.

also crashes a 64bit dosbox binary as I reported already a couple of times here

Sorry for ignoring OSX questions 😉

how dare you?!!!! 😉
(though I have answered this question before, so either you or qbix asked that before - but the vogons search is something I do not exactly get good results from...)

Well no idea how different the ABIs are, could be shitty for parameter passing and things like that
so you'd have to delve a bit deeper into ASM->C things and ABI 64bit details.

yes, that's about the point where I can only follow other people's test advice. I can patch, I can compile, I can figure out some compile stuff but I can't code.

Can't really code that either, you need to find nicely hidden information in the ABI docs
and good recompiler debugging skills on that platform. Well maybe somewhen 😀

sounds like a job for rhoenie 😀

hehe

Dominus's instructions made it possible for me to build a portable copy of SVN under OS X. In case anyone wants to do the same thing, here is a summary of the instructions, all in one place. Remember that all of this is Dominus's work; I've just put it all together in one message.

1. Install MacPorts from http://www.macports.org

2. To make this version of DOSBox portable, and if (like me) you don't need sdl_net or sdl_sound, then install these items only:

1sudo port install libsdl +universal +no_x11
2sudo port install libpng +universal
3sudo port install pkgconfig +universal 

3. Then use a script to automate the whole process of setting environment variables and editing the Makefiles to create a static-linked sdl:

1#!/bin/sh
2
3export CFLAGS='-I/opt/local/include -O2 -arch i386' 
4export CXXFLAGS=$CFLAGS 
5export CPPFLAGS=$CXXFLAGS 
6export LDFLAGS='-L/opt/local/lib -O2 -arch i386' 
7export CC='/usr/bin/gcc-4.2 -arch i386' 
8export CXX='/usr/bin/g++-4.2 -arch i386' 
9export GCOV='/usr/bin/gcov-4.2 -arch i386' 
10
11make clean
12./autogen.sh
13./configure 
14
15sed -i.old -e "s@-L/opt/local/lib -lSDLmain -lSDL -Wl,-framework,Cocoa@-L/opt/local/lib /opt/local/lib/libSDLmain.a /opt/local/lib/libSDL.a -Wl,-framework,OpenGL -Wl,-framework,Cocoa -Wl,-framework,ApplicationServices -Wl,-framework,Carbon -Wl,-framework,AudioToolbox -Wl,-framework,AudioUnit  -Wl,-framework,IOKit@g" -e "s@-lX11@ @g" Makefile
16
17cd src
18
19sed -i.old -e "s@-L/opt/local/lib -lSDLmain -lSDL -Wl,-framework,Cocoa@-L/opt/local/lib /opt/local/lib/libSDLmain.a /opt/local/lib/libSDL.a -Wl,-framework,OpenGL -Wl,-framework,Cocoa -Wl,-framework,ApplicationServices -Wl,-framework,Carbon -Wl,-framework,AudioToolbox -Wl,-framework,AudioUnit  -Wl,-framework,IOKit@g" -e "s@-lX11@ @g" Makefile
20
21cd ..
22make

The two sed commands perform the replacement in the Makefile that Dominus spelled out in another message.

Put this script in the "trunk" folder (or whatever you call the folder that contains the folders "src", "include", "docs", etc.) Make the script executable with the command chmod +x filename. In the terminal, navigate to the folder that contains the script, src, include, docs, etc, and run the script from the terminal to build DOSBox, which will be created in the src folder.

EDIT: Modified to match Dominus's corrections in the next messages, and to spell out what to do with the script.