Opened 11 years ago

Closed 11 years ago

#21516 closed update (fixed)

dosbox 0.73 update

Reported by: sava.chankov@… Owned by: macports-tickets@…
Priority: Normal Milestone:
Component: ports Version: 1.8.0
Keywords: haspatch Cc: ryandesign (Ryan Schmidt), domiman@…
Port: dosbox

Description

Update dosbox to 0.73. Apply with patch -R -p3 in ports/emulators/dosbox

Attachments (5)

dosbox-0.73.patch (4.7 KB) - added by sava.chankov@… 11 years ago.
dosbox-0.73-ryandesign.diff (1.4 KB) - added by ryandesign (Ryan Schmidt) 11 years ago.
dosbox-universal-ppc-i386.txt (74.9 KB) - added by ryandesign (Ryan Schmidt) 11 years ago.
dosbox-universal-i386-ppc.patch (1010 bytes) - added by sava.chankov@… 11 years ago.
dosbox-no-zlib-dep.patch (861 bytes) - added by sava.chankov@… 11 years ago.

Download all attachments as: .zip

Change History (29)

Changed 11 years ago by sava.chankov@…

Attachment: dosbox-0.73.patch added

comment:1 Changed 11 years ago by jmroot (Joshua Root)

Keywords: haspatch added

comment:2 in reply to:  description Changed 11 years ago by ryandesign (Ryan Schmidt)

Cc: ryandesign@… added

We like for changes to do one logical thing at a time. In particular, we want whitespace changes separated from functional changes.

I have committed some whitespace changes in r58063 and your updated descriptions in r58064. We'll want at least two more commits, one to remove the "universal_variant no" and one to update to 0.73. On Snow Leopard, I'm given to believe that libsdl-devel is currently preferred to libsdl, so the dependency should be rewritten in a way that both could satisfy (both in dosbox and libsdl_sound). But these changes will have to wait until I can get dosbox's dependencies to build on Snow Leopard, or until I try the whole thing on Leopard.

comment:3 Changed 11 years ago by ryandesign (Ryan Schmidt)

Attached is a diff of the remaining proposed changes from your patch that I have not yet committed.

Why does your patch cause the NEWS file to no longer be installed?

Changed 11 years ago by ryandesign (Ryan Schmidt)

Attachment: dosbox-0.73-ryandesign.diff added

comment:4 in reply to:  3 ; Changed 11 years ago by sava.chankov@…

Replying to ryandesign@…:

Why does your patch cause the NEWS file to no longer be installed?

Because it's doesn't differ from ChangeLog since 0.55

comment:5 in reply to:  4 Changed 11 years ago by ryandesign (Ryan Schmidt)

Replying to sava.chankov@…:

Replying to ryandesign@…:

Why does your patch cause the NEWS file to no longer be installed?

Because it's doesn't differ from ChangeLog since 0.55

Sounds like a good reason to me. :)

comment:6 Changed 11 years ago by ryandesign (Ryan Schmidt)

Regarding removal of "universal_variant no". I assume you did this because the comment said it was added because libsdl was not universal, and it is now. I have done some testing on Leopard now and cannot get dosbox to build universal. In a MacPorts prefix where universal_archs is x86_64/i386, I could not build libsdl (#20235). Then I tried in a new MacPorts prefix with universal_archs set to ppc/i386, and couldn't build speex (#21537). Installing speex-devel got me past that, but dosbox itself failed with what looks like assembly language errors:

core_dyn_x86/../../fpu/fpu_instructions_x86.h: In function 'void FPU_FLD_F32(PhysPt, Bitu)':
core_dyn_x86/../../fpu/fpu_instructions_x86.h:1136: error: unknown register name 'eax' in 'asm'
core_dyn_x86/../../fpu/fpu_instructions_x86.h: In function 'void FPU_FLD_F32_EA(PhysPt)':
core_dyn_x86/../../fpu/fpu_instructions_x86.h:1141: error: unknown register name 'eax' in 'asm'

I'll attach the full debug log.

Were you in fact able to build dosbox universal? If so, with what OS and Xcode version, on what Mac, with what set of architectures in universal_archs?

Changed 11 years ago by ryandesign (Ryan Schmidt)

comment:7 Changed 11 years ago by ryandesign (Ryan Schmidt)

Well, my tests were with dosbox 0.72. Let me try again with 0.73.

comment:8 Changed 11 years ago by ryandesign (Ryan Schmidt)

Ok, the issue persists with 0.73.

comment:9 Changed 11 years ago by ryandesign (Ryan Schmidt)

I updated dosbox to 0.73, took out the NEWS File, and removed the patches in r58073. From your patch that just leaves the universal issue.

Changed 11 years ago by sava.chankov@…

Changed 11 years ago by sava.chankov@…

Attachment: dosbox-no-zlib-dep.patch added

comment:10 Changed 11 years ago by sava.chankov@…

Although #20235 was closed today, I couldn't get libdl 1.2.14 to compile 64 bit. I provide a patch for i386 ppc universal variant - it built on Core 2 Duo. I've got the feeling that configure arguments for platform powerpc should be the same as variant universal, because the FPU code is newly added to 0.73 - however I don't have access to an old Mac with PowerPC and can't test it. Besides, why doesn't MacPorts consider platform declarations when building universal binary for that platform?

The other patch I attached removes zlib as dependency - it's actually dependency of libpng.

comment:11 in reply to:  10 ; Changed 11 years ago by ryandesign (Ryan Schmidt)

Replying to sava.chankov@…:

I provide a patch for i386 ppc universal variant - it built on Core 2 Duo.

But your patch would disable the FPU and dynamic x86 stuff even in the Intel portion of a universal binary. We should either disable it always, even on non-universal builds, or presumably this code is useful, so we should enable it always on Intel, even in a universal binary.

I've got the feeling that configure arguments for platform powerpc should be the same as variant universal, because the FPU code is newly added to 0.73 - however I don't have access to an old Mac with PowerPC and can't test it.

I can test it on my Power Mac G4.

Besides, why doesn't MacPorts consider platform declarations when building universal binary for that platform?

Well, it just doesn't. "platform powerpc" is executed when building on powerpc, regardless what architectures the build is going to be for, and similarly with "platform i386". Universal builds happen all at once -- there aren't separate configure and build phases that get run for each architecture. Unless you use the muniversal portgroup. Then they are run separately, and you do have the chance to pass separate arguments for each architecture. So maybe using muniversal is the way we should go with the dosbox port.

The other patch I attached removes zlib as dependency - it's actually dependency of libpng.

Sounds good; changed in r58183.

comment:12 in reply to:  11 Changed 11 years ago by sava.chankov@…

Replying to ryandesign@…:

Replying to sava.chankov@…: But your patch would disable the FPU and dynamic x86 stuff even in the Intel portion of a universal binary. We should either disable it always, even on non-universal builds, or presumably this code is useful, so we should enable it always on Intel, even in a universal binary.

Yes, it should be enabled on Intel, disabled only on PowerPC. I couldn't find any documentation how to pass different configure args for every arch using muniversal group. Do you know how to do it?

I've got the feeling that configure arguments for platform powerpc should be the same as variant universal, because the FPU code is newly added to 0.73 - however I don't have access to an old Mac with PowerPC and can't test it.

I can test it on my Power Mac G4.

Please, test it.

comment:13 Changed 11 years ago by ryandesign (Ryan Schmidt)

The powerpc platform variant seems to be completely unnecessary; dosbox figures out on its own that it shouldn't enable the FPU or dynamic x86 bits when building on PowerPC.

Have not tested universal yet.

comment:14 in reply to:  13 Changed 11 years ago by ryandesign (Ryan Schmidt)

Replying to ryandesign@…:

The powerpc platform variant seems to be completely unnecessary

Removed in r58322.

comment:15 Changed 11 years ago by domiman@…

For Dosbox on Snow Leopard it would be much more usefull if you could choose a variant that builds 32-bit and keeps FPU and dynamic x86 enabled. Does libsdl_sound build for you? I'm still stuck at physfs...

comment:16 Changed 11 years ago by domiman@…

with the current portfile dosbox 0.73 compiles fine, BUT opposed to the official OS X release, the macports build has severe stability issues. A simple benchmark (search the vogons forums for pcpbench) makes Dosbox crash with a segmentation fault. This is not good.

comment:17 in reply to:  15 Changed 11 years ago by ryandesign (Ryan Schmidt)

Replying to domiman@…:

For Dosbox on Snow Leopard it would be much more usefull if you could choose a variant that builds 32-bit and keeps FPU and dynamic x86 enabled.

Are you saying FPU and dynamic x86 are automatically disabled when building 64-bit?

It is not MacPorts custom to provide variants to build for different architectures. But you can set build_arch to i386 in macports.conf if you want to build i386.

Does libsdl_sound build for you? I'm still stuck at physfs...

No problem building physfs here. If you're unable to, please file a ticket.

No problem building dosbox on Snow Leopard, except that I'm building universal, and dependency speex doesn't build universal, so I had to use speex-devel instead, which is recommended anyway at this point, since the developers of speex no longer recommend using their latest stable release.

comment:18 in reply to:  16 Changed 11 years ago by ryandesign (Ryan Schmidt)

Replying to domiman@…:

with the current portfile dosbox 0.73 compiles fine, BUT opposed to the official OS X release, the macports build has severe stability issues. A simple benchmark (search the vogons forums for pcpbench) makes Dosbox crash with a segmentation fault. This is not good.

Ok. Why is this? We are just compiling the source they provide. If their source causes such crashes, they should fix their source.

comment:19 Changed 11 years ago by nerdling (Jeremy L)

But do they provide 64-bit binaries? Sounds like they simply provide 32-bit, avoiding the issue.

$ file /Volumes/DOSBox 0.73/DOSBox.app/Contents/MacOSDOSBox 
DOSBox: Mach-O universal binary with 4 architectures
DOSBox (for architecture ppc750):	Mach-O executable ppc
DOSBox (for architecture ppc7450):	Mach-O executable ppc
DOSBox (for architecture ppc970):	Mach-O executable ppc
DOSBox (for architecture i386):	Mach-O executable i386

comment:20 Changed 11 years ago by domiman@…

Cc: domiman@… added

Cc Me!

comment:21 Changed 11 years ago by domiman@…

sorry, I wasn't Cc'ed so I missed the answers. I think the crashes are because some parts of their emulation is not yet fit to be built on 64-bit and is therefore automatically disabled when you built Dosbox in 64-bit and therefore crashes when in the emulation the core gets selected automatically (core=auto is default since 0.73).

And since they provide only 32-bit version they avoid the issue.

So far the issue remains, that when Dosbox is built in 64-bit it is unstable.

Before I report that issue with it crashing to the Dosbox devs, can you tell me what to do to manually compile the dosbox CVS in 32-bit? The normal procedure to build it on my own I know (autogen, configure, make), I just don't know how to make it build in 32-bit.

comment:22 in reply to:  21 Changed 11 years ago by nerdling (Jeremy L)

Replying to domiman@…:

Before I report that issue with it crashing to the Dosbox devs, can you tell me what to do to manually compile the dosbox CVS in 32-bit? The normal procedure to build it on my own I know (autogen, configure, make), I just don't know how to make it build in 32-bit.

You might try adding configure.build_arch i386 to the portfile you want to be 32-bit.

comment:23 Changed 11 years ago by domiman@…

I kind of resolved this with the Dosbox developers. As we tested their dynamic CPU core is not compatible with 64bit OS X (works on 64bit Linux), so for a 64bit port of Dosbox you'd need to pass --disable-dynamic-core to ./configure. This would prevent the crash but without dynamic core Dosbox is much slower, especially in the "newer" build games like Blood (in a DOS benchmark the socre with dynamic core is 50, the score without is 3.5). So my recommendation is to build it in 32bit (just like you do for other ports that have problems in 64bit, like Wine). In 32bit I have no problems with Dosbox, both with the 0.73 release sources or actual SVN of Dosbox.

comment:24 Changed 11 years ago by ryandesign (Ryan Schmidt)

Resolution: fixed
Status: newclosed

Forced 32-bit in r61050. Thanks for researching that.

Note: See TracTickets for help on using tickets.