64-bit compile fails on Snow Leopard

[Ryan Graham-2]

./configure fails when using --enable-darwin-64bit on Snow Leopard  
when running a 64-bit kernel.

The configure scripts check the output of uname for Darwin-i386 as a  
sanity check but does not accept Darwin-x86_64.

For reference, Snow Leopard can be booted into a 64-bit kernel by  
holding down the '6' and '4' keys during boot up.

~Ryan

________________________________________________________________
erlang-bugs mailing list. See http://www.erlang.org/faq.html
erlang-bugs (at) erlang.org

[dimavs]

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

Cheers,
D


PS My old 13B01 x64 build from Leopard works fine with 64bit kernel of  
Snow Leopard.


On 30/09/2009, at 1:32 PM, Ryan M. Graham wrote:

> ./configure fails when using --enable-darwin-64bit on Snow Leopard  
> when running a 64-bit kernel.
>
> The configure scripts check the output of uname for Darwin-i386 as a  
> sanity check but does not accept Darwin-x86_64.
>
> For reference, Snow Leopard can be booted into a 64-bit kernel by  
> holding down the '6' and '4' keys during boot up.
>
> ~Ryan
>
> ________________________________________________________________
> erlang-bugs mailing list. See http://www.erlang.org/faq.html
> erlang-bugs (at) erlang.org
>

________________________________________________________________
erlang-bugs mailing list. See http://www.erlang.org/faq.html
erlang-bugs (at) erlang.org

[Kostis Sagonas-2]

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

[dimavs]

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
>

________________________________________________________________
erlang-bugs mailing list. See http://www.erlang.org/faq.html
erlang-bugs (at) erlang.org

[Ryan Graham-2]

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@...> 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

________________________________________________________________
erlang-bugs mailing list. See http://www.erlang.org/faq.html
erlang-bugs (at) erlang.org

[dimavs]

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@...>  
> 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

________________________________________________________________
erlang-bugs mailing list. See http://www.erlang.org/faq.html
erlang-bugs (at) erlang.org

[Ryan Graham-2]

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@...> 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@...>  
>> 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
>

________________________________________________________________
erlang-bugs mailing list. See http://www.erlang.org/faq.html
erlang-bugs (at) erlang.org

[dimavs]

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@...> 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@...>  
>>> 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
>>

________________________________________________________________
erlang-bugs mailing list. See http://www.erlang.org/faq.html
erlang-bugs (at) erlang.org

[Ryan Graham-2]

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@...> 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@...> 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@...> 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
>>>
>
>

--
http://rmgraham.blogspot.com
http://twitter.com/rmgraham

________________________________________________________________
erlang-bugs mailing list. See http://www.erlang.org/faq.html
erlang-bugs (at) erlang.org

[Dan Gudmundsson]

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@...> 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@...> 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@...> 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
>>
>
>
>

________________________________________________________________
erlang-bugs mailing list. See http://www.erlang.org/faq.html
erlang-bugs (at) erlang.org

[Winston Smith-6]

On Fri, Oct 2, 2009 at 3:52 AM, Dan Gudmundsson <dgud@...> wrote:
> We are aware of the problem, but have no machines that will boot with a
> 64-bit kernel,
> and can't test it.

I just ran into this, if you are interested I have attached a patch,
it was pretty simple (sorry, I don't know if it's in the right format,
but you should be able to see the changes well enough).

BTW: This was against R13B02-1 sources.

> We will try to fix it in the next release.

I'd be more than happy to test it for you.



________________________________________________________________
erlang-bugs mailing list. See http://www.erlang.org/faq.html
erlang-bugs (at) erlang.org