[erlang-bugs] 64-bit compile fails on Snow Leopard

Dan Gudmundsson dgud@REDACTED
Fri Oct 2 09:52:15 CEST 2009


We are aware of the problem, but have no machines that will boot with a 64-bit kernel,
and can't test it.

We will try to fix it in the next release.

/Dan

Ryan Graham wrote:
> My Mac died last night, but I downloaded the latest source (R13B02-1)
> onto my Linux box at work...
> 
> $ grep -Inr "TMPSYS" ./
> ./erts/configure.in:268:TMPSYS=`uname -s`-`uname -m`
> ./erts/configure.in:290:        if test X"$TMPSYS" '!=' X"Darwin-i386"; then
> ./erts/configure:2782:TMPSYS=`uname -s`-`uname -m`
> ./erts/configure:2806:  if test X"$TMPSYS" '!=' X"Darwin-i386"; then
> ./configure.in:210:TMPSYS=`uname -s`-`uname -m`
> ./configure.in:222:     if test X"$TMPSYS" '!=' X"Darwin-i386"; then
> ./configure.in:230:elif test X"$TMPSYS" '=' X"Darwin-i386"; then
> ./configure:2691:TMPSYS=`uname -s`-`uname -m`
> ./configure:2705:       if test X"$TMPSYS" '!=' X"Darwin-i386"; then
> ./configure:2715:elif test X"$TMPSYS" '=' X"Darwin-i386"; then
> 
> The configure scripts only allow the --enable-darwin-64bit switch if
> you are running on the 32-bit kernel.
> 
> As your outputs show, if you boot up into the 64-bit kernel, `uname
> -m` spits out x86_64 which results in the $TMPSYS being the string
> "Darwin-x86_64", which the script fails to match against
> "Darwin-i386". As a result, it prints out an error:
> 
> "$as_me:$LINENO: error: --enable-darwin-64bit only supported on x86 host"
> 
> ~Ryan
> 
> On Wed, Sep 30, 2009 at 10:17 PM, Dmitri Sosnik <dimavs@REDACTED> wrote:
>> I am already booted with x64 kernel and conf.log says:
>>
>> uname -m = x86_64
>> uname -r = 10.0.0
>> uname -s = Darwin
>> uname -v = Darwin Kernel Version 10.0.0: Fri Jul 31 22:46:25 PDT 2009;
>> root:xnu-1456.1.25~1/RELEASE_X86_64
>>
>> /usr/bin/uname -p = i386
>> /bin/uname -X     = unknown
>>
>> /bin/arch              = unknown
>> /usr/bin/arch -k       = unknown
>> /usr/convex/getsysinfo = unknown
>> hostinfo               = Mach kernel version:
>>     Darwin Kernel Version 10.0.0: Fri Jul 31 22:46:25 PDT 2009;
>> root:xnu-1456.1.25~1/RELEASE_X86_64
>>
>> configure:1358: checking build system type
>> configure:1376: result: i386-apple-darwin10.0.0
>> configure:1384: checking host system type
>> configure:1398: result: i386-apple-darwin10.0.0
>>
>>
>>
>> Cheers,
>> D
>>
>>
>> On 01/10/2009, at 2:20 PM, Ryan Graham wrote:
>>
>>> Reboot and hold down the 6 and 4 keys on your keyboard. If your mac has a
>>> new enough CPU, it will boot up with the 64-bit kernel instead of the
>>> standard 32-bit kernel. The bug I'm reporting wouldn't typically be seen in
>>> normal use, but it is still wrong to assume non-i386 means ppc, which is
>>> what the check is probably there for.
>>>
>>> ~Ryan
>>>
>>> On 2009-09-30, at 6:33 PM, Dmitri Sosnik <dimavs@REDACTED> wrote:
>>>
>>>> I have no idea about autoconf, but I've checked logs and it looks like
>>>> autoconf is using "uname -p" to get host architecture. Snow Leopard x64
>>>> returns i386 here.
>>>>
>>>> Cheers,
>>>> D
>>>>
>>>>
>>>>
>>>> On 01/10/2009, at 6:01 AM, Ryan Graham wrote:
>>>>
>>>>> That's what I was trying to point out. It fails on the configure
>>>>> because it is looking for Darwin-i386 in the output from uname. The
>>>>> same check is done for each submodule as well. It should be a trivial
>>>>> fix, I just didn't have the time to make a patch for it.
>>>>>
>>>>> ~Ryan
>>>>>
>>>>> On Wed, Sep 30, 2009 at 2:04 AM, Dmitri Sosnik <dimavs@REDACTED> wrote:
>>>>>> Thanks!
>>>>>>
>>>>>> But I've realised that it's an another problem. Configure detects wrong
>>>>>> architecture:
>>>>>>
>>>>>> checking build system type... i386-apple-darwin10.0.0
>>>>>> checking host system type... i386-apple-darwin10.0.0
>>>>>>
>>>>>> $uname -a
>>>>>> Darwin DMBP.local 10.0.0 Darwin Kernel Version 10.0.0: Fri Jul 31
>>>>>> 22:46:25
>>>>>> PDT 2009; root:xnu-1456.1.25~1/RELEASE_X86_64 x86_64
>>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>> D
>>>>>>
>>>>>> On 30/09/2009, at 6:41 PM, Kostis Sagonas wrote:
>>>>>>
>>>>>>> Dmitri Sosnik wrote:
>>>>>>>> Yep, the same for me. I think the reason is broken wxWidgets library.
>>>>>>>> According to http://wiki.wxwidgets.org/Development:_wxMac wxWidgets
>>>>>>>> 2.8 is
>>>>>>>> Carbon based and Carbon is only 32 bit. wxWidgets 2.9 is Cocoa based,
>>>>>>>> but
>>>>>>>> there is no stable release for it.
>>>>>>>> Anyway, can we disable wxWidgets? I've tried with
>>>>>>>> --disable-wxwidgets,
>>>>>>>> but it didn't work
>>>>>>> After the 'configure' and before the 'make' you can avoid building any
>>>>>>> library directory you do not want by placing a file named SKIP in it.
>>>>>>> In
>>>>>>> this case, the following command will do the trick:
>>>>>>>
>>>>>>>     touch lib/wx/SKIP
>>>>>>>
>>>>>>> Kostis
>>>>>>>
>>>>>>> ________________________________________________________________
>>>>>>> erlang-bugs mailing list. See http://www.erlang.org/faq.html
>>>>>>> erlang-bugs (at) erlang.org
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> http://rmgraham.blogspot.com
>>>>> http://twitter.com/rmgraham
>>
> 
> 
> 


More information about the erlang-bugs mailing list