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

 
 

bug #27775: Does not compile on OS X 10.6

Submitted by:  None
Submitted on:  Wed 21 Oct 2009 08:50:59 PM UTC  
 
Category: InstallSeverity: 3 - Normal
Status: Need InfoPrivacy: Public
Assigned to: Christian Mauduit <ufoot>Open/Closed: Open

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

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>
Project AdministratorIn charge of this item.
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:

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>
Project AdministratorIn charge of this item.
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 File(s):
   
   
Comment:
   

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

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed 21 Oct 2009 09:30:07 PM UTCufootStatusNone=>Need Info
      Assigned toNone=>ufoot
    Wed 21 Oct 2009 08:50:59 PM UTCNoneAttached File-=>Added crash.txt, #18923

    Back to the top


    Powered by Savane 3.1-cleanup