What if it's PowerPC, ARM, SPARC, etc?
It will run the 32 bit version.
There aren't any bitcoin builds for those platforms anyway so the point is moot.
BTW, this is the new request https://github.com/bitcoin/bitcoin/pull/107
Topic: Linux packages should have an autodetect 32/64 bit using bash (Read 2966 times)
It will run the 32 bit version.
There aren't any bitcoin builds for those platforms anyway so the point is moot.
BTW, this is the new request https://github.com/bitcoin/bitcoin/pull/107
What if it's PowerPC, ARM, SPARC, etc?
Pull request is here, https://github.com/bitcoin/bitcoin/pull/104
February 27, 2011, 10:36:55 AM
Auto-detection would be a good thing if it is foolproof, but otherwise it adds more problems than it solves.
You're right.A 64bit kernel can run the 64bit bitcoin excutable as well as the 32bit one, whereas a 32bit kernel can only run the 32bit binary. So I gather it would be safe to run the 64bit version if ‘uname -m’ explicitly says ‘x86_64’, and run the 32bit version in all other cases. Am I correct?
Cheers,
Yes. Agreed.
February 27, 2011, 09:58:43 AM
/proc/cpuinfo is probably your best source of information about your processor.
Which part of the information are you specifically referring to? And aren't we more interested in the kernel than in the hardware?Cheers,
February 27, 2011, 09:49:57 AM
/proc/cpuinfo is probably your best source of information about your processor.
February 27, 2011, 09:49:11 AM
Auto-detection would be a good thing if it is foolproof, but otherwise it adds more problems than it solves.
You're right.A 64bit kernel can run the 64bit bitcoin excutable as well as the 32bit one, whereas a 32bit kernel can only run the 32bit binary. So I gather it would be safe to run the 64bit version if ‘uname -m’ explicitly says ‘x86_64’, and run the 32bit version in all other cases. Am I correct?
Cheers,
February 27, 2011, 09:43:44 AM
You must have misunderstood & I wasn't clear enough:
The CPU is 64 bit.
The kernel is compiled for 32 bit.
uname -m displays i686. If uname -m showed the hardware arch then it would display x86_64, no? Therefore I conclude that uname -m is displaying the machine hardware type as compiled into the kernel, not detected from proc.
The CPU is 64 bit.
The kernel is compiled for 32 bit.
uname -m displays i686. If uname -m showed the hardware arch then it would display x86_64, no? Therefore I conclude that uname -m is displaying the machine hardware type as compiled into the kernel, not detected from proc.
I think I understood you correctly. When I referred to ribuck I just meant to say that the above answered his question, not that his assumption was correct.
Quote
I'm inclined to think that uname -m is simply reporting back the compiled flags inside the kernel.
Me too. So can't we conclude that if we wish to run a version of bitcoin that has the same ‘bitlength’ as the running Linux kernel, then ‘uname -m’ is a valid way of getting the required information?
(I'm not sure ‘we’ always want that, though: On a Core 2 Duo machine I get appr. 1000 khash/sec with a 64bit 1-threaded jgarzik miner using the cryptopp algorithm (the fastest algorithm available in the 64bit version), whereas I get an extra 50+ khash/sec using the cryoptopp_asm32 algorithm with the 32bit version of the same miner, so surely I want to run the 32bit version in order to get a few extra millicents.)
Cheers,
February 27, 2011, 09:30:28 AM
I conclude that uname -m is displaying the machine hardware type as compiled into the kernel
The "man uname" command says that -m means "print the machine hardware name", but maybe uname -m is actually printing the last part of the kernel version string as displayed by uname -r.
I'm currently running 64-bit Fedora, and this is what I see:
uname -r
2.6.35.11-83.fc14.x86_64
uname -m
x86_64
Auto-detection would be a good thing if it is foolproof, but otherwise it adds more problems than it solves.
February 27, 2011, 09:09:20 AM
No, because if it was the other way around then uname -m would show 64 bit on the 32bit version of Ubuntu.
I don't think you'll be able to run a 64bit version of Linux on a 32bit machine, whereas you can run a 32bit version of Linux on a 64bit machine without any problems whatsoever.Cheers,
You must have misunderstood & I wasn't clear enough:
The CPU is 64 bit.
The kernel is compiled for 32 bit.
uname -m displays i686. If uname -m showed the hardware arch then it would display x86_64, no? Therefore I conclude that uname -m is displaying the machine hardware type as compiled into the kernel, not detected from proc.
Quote from: random forum on google
all methods above are wrong. If the system was installed with 32bit OS the result will always be 32 unless it has a 64bit Linux running.
The correct way to do is:
cat /proc/cpuinfo
and look for flag “lm” in the flags: column. If it’s there then it’s 64bit CPU no matter Intel or AMD.
The correct way to do is:
cat /proc/cpuinfo
and look for flag “lm” in the flags: column. If it’s there then it’s 64bit CPU no matter Intel or AMD.
I'm inclined to think that uname -m is simply reporting back the compiled flags inside the kernel.
Here is the terminal output on this dual processor system:
Quote
x@l:~$ cat /proc/cpuinfo | grep flags
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm tpr_shadow vnmi flexpriority
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm tpr_shadow vnmi flexpriority
x@l:~$ uname -m
i686
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm tpr_shadow vnmi flexpriority
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm tpr_shadow vnmi flexpriority
x@l:~$ uname -m
i686
Note the presence of lm (64bit CPU) but reporting of i686 from uname.
February 27, 2011, 08:29:34 AM
My sister has been using bitcoin, and because of the long startup/multiple executables she was just going into every directory under bin and opening all the binaries repeatedly until it bitcoin opens. She assumed it was because bitcoin is broken. This script would also alleviate that problem.
No, because if it was the other way around then uname -m would show 64 bit on the 32bit version of Ubuntu.
I don't think you'll be able to run a 64bit version of Linux on a 32bit machine, whereas you can run a 32bit version of Linux on a 64bit machine without any problems whatsoever.Cheers,
I'm on a computer with a 64bit processor but 32bit Ubuntu. uname -m shows i686
That answers ribuck's question, doesn't it?Cheers,
No, because if it was the other way around then uname -m would show 64 bit on the 32bit version of Ubuntu.
To know the default used architecture on debian based distrib :
Code:
dpkg --print-architecture
I'm on a computer with a 64bit processor but 32bit Ubuntu. uname -m shows i686
That answers ribuck's question, doesn't it?Cheers,
1) check hardware
Code:
# cat /proc/cpuinfo
2) check used kernelCode:
# file /sbin/init
Is that platform agnostic? AFAIK aren't some distros replacing the classic init runlevel?
I'm on a computer with a 64bit processor but 32bit Ubuntu. uname -m shows i686
1) check hardware
Code:
# cat /proc/cpuinfo
2) check used kernelCode:
# file /sbin/init
If gcc is installed, perhaps you could look for the _LP64 preprocessor symbol (a.k.a. “longs and pointers are 64 bits”) and act accordingly, e.g.:
Cheers,
Code:
#!/bin/sh
WORKING_DIR=$(basename "${0}")
gcc -dM -E - exec "${WORKING_DIR}"/bin/64/bitcoin "${@}"
}
exec "${WORKING_DIR}"/bin/32/bitcoin "${@}"
# eof
WORKING_DIR=$(basename "${0}")
gcc -dM -E - exec "${WORKING_DIR}"/bin/64/bitcoin "${@}"
}
exec "${WORKING_DIR}"/bin/32/bitcoin "${@}"
# eof
Cheers,
Doesn't "uname -m" only give you the hardware type? Until recently, I was running 32-bit Fedora on 64-bit hardware.
bitcoin.linux
Idea came to me after a user on IRC was having trouble running bitcoin (didn't know their arch nor how to navigate in console nor about bitcoin/bitcoind distinction).
My sister has been using bitcoin, and because of the long startup/multiple executables she was just going into every directory under bin and opening all the binaries repeatedly until it bitcoin opens. She assumed it was because bitcoin is broken. This script would also alleviate that problem.
Code:
#!/bin/bash
MACHINE_TYPE=`uname -m`
WORKING_DIR=`basename $0`
if [ ${MACHINE_TYPE} == 'x86_64' ]; then
# run 64-bit bitcoin here
$WORKING_DIR/bin/64/bitcoin
else
# run 32-bit bitcoin here
$WORKING_DIR/bin/32/bitcoin
fi
MACHINE_TYPE=`uname -m`
WORKING_DIR=`basename $0`
if [ ${MACHINE_TYPE} == 'x86_64' ]; then
# run 64-bit bitcoin here
$WORKING_DIR/bin/64/bitcoin
else
# run 32-bit bitcoin here
$WORKING_DIR/bin/32/bitcoin
fi
Idea came to me after a user on IRC was having trouble running bitcoin (didn't know their arch nor how to navigate in console nor about bitcoin/bitcoind distinction).
My sister has been using bitcoin, and because of the long startup/multiple executables she was just going into every directory under bin and opening all the binaries repeatedly until it bitcoin opens. She assumed it was because bitcoin is broken. This script would also alleviate that problem.
Jump to: