bugLiquid War 6 - Bugs: bug #27775, Does not compile on OS X 10.6

 
 

bug #27775: Does not compile on OS X 10.6

Submitter:  None
Submitted:  Wed 21 Oct 2009 08:50:59 PM UTC
   
 
Category:  Install Severity:  3 - Normal
Status:  In Progress Privacy:  Public
Assigned to:  ufoot Open/Closed:  Open
* Mandatory Fields

Add a New Comment Rich Markup
   

Mon 04 May 2015 04:49:30 AM UTC, comment #4: 

I know do have access to a Mac OS X 10.8 machine, should be able to solve this.

Christian Mauduit <ufoot>
Group administrator
Sat 26 Dec 2009 04:29:59 PM UTC, comment #3: 

AFAIK I didn't change anything significant in the autotools chain since 0.0.7beta so even using the tarballs from http://www.ufoot.org/liquidwar/v6/snapshots/ (same as using SCM upstream but saves you the GNU/Arch tax) won't help I guess. Probably this bug should be forwarded to autoconf/automake maintainers since, after all, it's their code that detects an i386 host when it's 64-bit. I suspect LW6 isn't the only project to have this issue, and I'm sure it'll be fixed with time but someone does have to report the bug at some point. I admit I didn't take the time to dig into existing (known) autoconf/automake issues related to OS/X snow leopard and besides, I think I'm not even using the latest autotools chain. What probably happens is that the autotools than ship with LW6 now are simply not snow-leopard aware.

One thing to try would be to re-run the autotools suite, eg type "autoreconf" in the source directoty (on your 64-bit platform) and see what the next ./configure gives.

Have a nice day,

ufoot.

Christian Mauduit <ufoot>
Group administrator
Tue 15 Dec 2009 01:26:44 AM UTC, comment #2: 

I am not the original Anonymous poster, but I've encountered the same problem.

The first three lines of the configure output on my system are:


checking build system type... i386-apple-darwin10.2.0
checking host system type... i386-apple-darwin10.2.0
checking target system type... i386-apple-darwin10.2.0


So it seems it's reporting that it's 32-bit, even though it's compiling for 64.

The LW6_X86 override patch you provided works fine, I have not tried compiling from the SCM yet.

NanoTech <nanotech>
Wed 21 Oct 2009 09:18:24 PM UTC, comment #1: 

Yes, indeed compilation (your log shows it well) is done with DLW6_X86=1 which is bad on a 64-bit platform. I did compile the game on an x86_64 (but it was a GNU/Linux box) and there's no fundamental reason it wouldn't build on Snow Leopard.

Out of curiosity, what is the output of ./configure? It should show, on the very first lines, what is detected as an OS. For instance on Leopard it gives:

----8<------------------------------------------
checking build system type... i386-apple-darwin9.8.0
checking host system type... i386-apple-darwin9.8.0
checking target system type... i386-apple-darwin9.8.0
----8<------------------------------------------

The host system is what is important in our case.

Normally ./configure should detect non-x86 and avoid compiling the assembly file. Here's an excerpt from ./configure.ac in upcoming 0.0.8beta.

----8<------------------------------------------
lw6_x86=no
if test ${host_cpu} = i386 || test ${host_cpu} = i486 || test ${host_cpu} = i586 || test ${host_cpu} = i686 ; then
   lw6_x86=yes
fi
AM_CONDITIONAL(LW6_X86, test x${lw6_x86} = xyes)
LW6_X86_CFLAGS=
if test x${lw6_x86} = xyes ; then
   LW6_X86_CFLAGS="-DLW6_X86=1"
fi
----8<------------------------------------------

As a side note, 0.0.7beta has a bug, which is that it tests target instead of host for that matter. But I'm not sure this is the very problem.

If you simply want to continue your compilation (and track other problems) you can try to just patch and put instead:

----8<------------------------------------------
AM_CONDITIONAL(LW6_X86, false)
LW6_X86_CFLAGS=
----8<------------------------------------------

You'll then have to run autoconf and ./configure again.

Thanks for your feedback and have a nice day.

ufoot.

PS: LW does run faster on x86_64, it has non-negligeable 64-bit operations so even if it memory footprint is well below 4gigs, you can expect good perfs. The x86 assembly code was here to fill a gap and implement spin locks which are missing on Mac OS X. So it happens on Mac OS X it's really interesting to have it. The long term solution (I self-censor the possibility that Apple backports pthread spin support to their OS) would be to code that for x86_64 too. It's not that hard, this file is very small and non-complicated. But it's obviously not my priority now. If LW6_X86 is undefined, spin locks are not used and a standard mutex lock is used instead. In theory it's less efficient for some tasks. In theory.

Christian Mauduit <ufoot>
Group administrator
Wed 21 Oct 2009 08:50:59 PM UTC, original submission:  

The Liquidwar 6 0.0.7beta does not compile on OS X 10.6.1 using MacPorts 1.8.1.  The cause of the failure appears to be in the sys-testandsetx86 file, having to do with inline 32-bit assembly.  10.6 has moved to 64-bit runtime.  The crash log is attached.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #18923:  crash.txt added by None (9KiB - text/plain)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by nanotech (Posted a comment)
  • -email is unavailable- added by ufoot (Posted a comment)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-05-04 ufoot StatusNeed Info In Progress
    2009-10-21 ufoot StatusNone Need Info
        Assigned toNone ufoot
    2009-10-21 None Attached File- Added crash.txt, #18923

    Back to the top

    Powered by Savane 3.13-cf05.
    Corresponding source code