Prev: Logs and dumps for kernel panics to collect and analyze?
Next: resize a lvm volume on a raid1
From: Artist on 6 Mar 2010 19:18
On my x86_64 server with a newly installed Debian 5 I did this sequence
of installation commands:

apt-get install gcc
apt-get install gawk
apt-get install make
apt-get install locate
updatedb
wget http://monkey.org/~provos/libevent-1.4.13-stable.tar.gz
tar zxvf libevent-1.4.13-stable.tar.gz
cd libevent-1.4.13-stable
../configure
make && make install

I thought I would automatically get an installation that took full
advantage of the 64 bit architecture. But looking in the directory
/var/cache/archives I see most of the files end in i386.deb. So now I am
not sure. Is this what I should see if the full benefit if the x86_64
architecture is to be had?

--
If you desire to respond directly remove the "sj." from the domain name
part of my email address. It is a spam jammer.
From: Darren Salt on 6 Mar 2010 19:54
I demand that Artist may or may not have written...

> On my x86_64 server with a newly installed Debian 5 I did this sequence
> of installation commands:

> apt-get install gcc
[snip; local install of libevent-1.4.13-stable]

That's in backports. You should get it from there instead of building it
yourself; see http://packages.debian.org/source/lenny-backports/libevent (and
follow the "backports" link) for details.

(And were it not in backports, you should install build-essential, use dget
to fetch the .dsc of the version in testing (it'll fetch the rest of the
source automatically), "dpkg-source -x" the .dsc to unpack the source, then
"debuild binary" to build it. Then dpkg (as root) to install it. Best to stay
within the package management system wherever you reasonably can.)

> I thought I would automatically get an installation that took full
> advantage of the 64 bit architecture.

That's not determined by adding packages.

> But looking in the directory /var/cache/apt/archives I see most of the
> files end in i386.deb. So now I am not sure. Is this what I should see if
> the full benefit if the x86_64 architecture is to be had?

Not really. You can cross-compile for amd64 and even run the resulting
binaries, but your installation is i386. (However, you can at least run an
amd64 kernel.)

You might want to throw that away and do a full re-install, targetting amd64.

It's possible, but somewhat involved, to "migrate" it to amd64. This requires
use of dpkg --get-selections, preserving /etc, /var/cache/debconf and
probably a few other bits and pieces, doing a base install, chrooting into
it, using dpkg --set-selections, restoring all of what you preserved except
/etc, installing the packages according to the selections (aptitude in UI
mode is ideal), then (selectively?) restoring /etc. You do need to know your
way around a Debian system to some extent to be able to get away with this
kind of installation hack, though, and I've probably omitted something
extremely important. Let's just say that it may, potentially, become Very
Interesting.

(That said, a full install followed by copying what you've customised most
into the new /etc will probably do. It's up to you...)

--
| Darren Salt | linux at youmustbejoking | nr. Ashington, | Doon
| using Debian GNU/Linux | or ds ,demon,co,uk | Northumberland | Army
| + http://wiki.debian.org/DebianEeePC/

With clothes the new are best, with friends the old are best.
From: Artist on 6 Mar 2010 20:44
Darren Salt wrote:
> I demand that Artist may or may not have written...
>
>> On my x86_64 server with a newly installed Debian 5 I did this sequence
>> of installation commands:
>
>> apt-get install gcc
> [snip; local install of libevent-1.4.13-stable]
>
> That's in backports. You should get it from there instead of building it
> yourself; see http://packages.debian.org/source/lenny-backports/libevent (and
> follow the "backports" link) for details.
>
> (And were it not in backports, you should install build-essential, use dget
> to fetch the .dsc of the version in testing (it'll fetch the rest of the
> source automatically), "dpkg-source -x" the .dsc to unpack the source, then
> "debuild binary" to build it. Then dpkg (as root) to install it. Best to stay
> within the package management system wherever you reasonably can.)
>
>> I thought I would automatically get an installation that took full
>> advantage of the 64 bit architecture.
>
> That's not determined by adding packages.
>
>> But looking in the directory /var/cache/apt/archives I see most of the
>> files end in i386.deb. So now I am not sure. Is this what I should see if
>> the full benefit if the x86_64 architecture is to be had?
>
> Not really. You can cross-compile for amd64 and even run the resulting
> binaries, but your installation is i386. (However, you can at least run an
> amd64 kernel.)
>
> You might want to throw that away and do a full re-install, targetting amd64.
>
> It's possible, but somewhat involved, to "migrate" it to amd64. This requires
> use of dpkg --get-selections, preserving /etc, /var/cache/debconf and
> probably a few other bits and pieces, doing a base install, chrooting into
> it, using dpkg --set-selections, restoring all of what you preserved except
> /etc, installing the packages according to the selections (aptitude in UI
> mode is ideal), then (selectively?) restoring /etc. You do need to know your
> way around a Debian system to some extent to be able to get away with this
> kind of installation hack, though, and I've probably omitted something
> extremely important. Let's just say that it may, potentially, become Very
> Interesting.
>
> (That said, a full install followed by copying what you've customised most
> into the new /etc will probably do. It's up to you...)
>

Thankyou for your reply. This is a big help. I will remove and reinstall
libevent using the link that you have given.

Does a similar thing need to be done for my installations of gcc, gawk,
make, and locate?

I was mistaken about x86_64. The uname -m command gives i686. But the
gcc -v command shows the default architecture is i486:

debian:/usr/share# uname -v
#1 SMP Wed Feb 10 09:24:17 UTC 2010
debian:/usr/share# gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian
4.3.2-1.1' --with
-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortr
an,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib
--libexecdir=/u
sr/lib --without-included-gettext --enable-threads=posix --enable-nls
--with-gxx
-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3
--enable-clocale=gnu --e
nable-libstdcxx-debug --enable-objc-gc --enable-mpfr
--enable-targets=all --enab
le-cld --enable-checking=release --build=i486-linux-gnu
--host=i486-linux-gnu --
target=i486-linux-gnu
Thread model: posix
gcc version 4.3.2 (Debian 4.3.2-1.1)

Should the target have been i686-linux-gnu if I had the right
configuration for it or the right gcc installed?

--
If you desire to respond directly remove the "sj." from the domain name
part of my email address. It is a spam jammer.
From: Darren Salt on 6 Mar 2010 22:37
I demand that Artist may or may not have written...

> Darren Salt wrote:
>> I demand that Artist may or may not have written...
>>> On my x86_64 server with a newly installed Debian 5 I did this sequence
>>> of installation commands:
>>> apt-get install gcc
>> [snip; local install of libevent-1.4.13-stable]
>> That's in backports. You should get it from there instead of building it
>> yourself; see http://packages.debian.org/source/lenny-backports/libevent
>> (and follow the "backports" link) for details.
>> (And were it not in backports, you should install build-essential, use
>> dget to fetch the .dsc of the version in testing (it'll fetch the rest of
>> the source automatically), "dpkg-source -x" the .dsc to unpack the source,
>> then "debuild binary" to build it. Then dpkg (as root) to install it. Best
>> to stay within the package management system wherever you reasonably can.)

> Thankyou for your reply. This is a big help. I will remove and reinstall
> libevent using the link that you have given.

> Does a similar thing need to be done for my installations of gcc, gawk,
> make, and locate?

I shouldn't think so; but if you've followed the links and are now properly
using backports, then apt will tell you; e.g. "apt-cache policy gcc-4.3".

>>> I thought I would automatically get an installation that took full
>>> advantage of the 64 bit architecture.
>> That's not determined by adding packages.

>>> But looking in the directory /var/cache/apt/archives I see most of the
>>> files end in i386.deb. So now I am not sure. Is this what I should see if
>>> the full benefit if the x86_64 architecture is to be had?

>> Not really. You can cross-compile for amd64 and even run the resulting
>> binaries, but your installation is i386. (However, you can at least run an
>> amd64 kernel.)

>> You might want to throw that away and do a full re-install, targetting
>> amd64.
[snip]

> I was mistaken about x86_64. The uname -m command gives i686.

Kernel. Not particularly relevant, except that that tells me that it only
supports native 32-bit userland.

/proc/cpuinfo is more interesting; particularly the first model name line and
flags line.

> But the gcc -v command shows the default architecture is i486:

> debian:/usr/share# uname -v
> #1 SMP Wed Feb 10 09:24:17 UTC 2010
> debian:/usr/share# gcc -v
> Using built-in specs.
> Target: i486-linux-gnu
[snip]

That's what's expected, given your installation.

> Should the target have been i686-linux-gnu if I had the right configuration
> for it or the right gcc installed?

You need the "-march" option. Probably "-march=i686", though you could tune
it more specifically than that. (The gcc-doc package contains the relevant
info.)

If the CPU is actually x86-64, regardless of whether it's Intel or AMD, then
using the install media for either i386 or amd64 will work; and even if you
stick with your i386 install, you'll be able to install linux-image-*-amd64
(some people want 64-bit kernels but 32-bit userland).

--
| Darren Salt | linux at youmustbejoking | nr. Ashington, | Doon
| using Debian GNU/Linux | or ds ,demon,co,uk | Northumberland | Army
| + http://www.xine-project.org/

You will have many recoverable tape errors.
From: Artist on 6 Mar 2010 23:31
Darren Salt wrote:
> I demand that Artist may or may not have written...
>
>> Darren Salt wrote:
>>> I demand that Artist may or may not have written...
>>>> On my x86_64 server with a newly installed Debian 5 I did this sequence
>>>> of installation commands:
>>>> apt-get install gcc
>>> [snip; local install of libevent-1.4.13-stable]
>>> That's in backports. You should get it from there instead of building it
>>> yourself; see http://packages.debian.org/source/lenny-backports/libevent
>>> (and follow the "backports" link) for details.
>>> (And were it not in backports, you should install build-essential, use
>>> dget to fetch the .dsc of the version in testing (it'll fetch the rest of
>>> the source automatically), "dpkg-source -x" the .dsc to unpack the source,
>>> then "debuild binary" to build it. Then dpkg (as root) to install it. Best
>>> to stay within the package management system wherever you reasonably can.)
>
>> Thankyou for your reply. This is a big help. I will remove and reinstall
>> libevent using the link that you have given.
>
>> Does a similar thing need to be done for my installations of gcc, gawk,
>> make, and locate?
>
> I shouldn't think so; but if you've followed the links and are now properly
> using backports, then apt will tell you; e.g. "apt-cache policy gcc-4.3".
>
>>>> I thought I would automatically get an installation that took full
>>>> advantage of the 64 bit architecture.
>>> That's not determined by adding packages.
>
>>>> But looking in the directory /var/cache/apt/archives I see most of the
>>>> files end in i386.deb. So now I am not sure. Is this what I should see if
>>>> the full benefit if the x86_64 architecture is to be had?
>
>>> Not really. You can cross-compile for amd64 and even run the resulting
>>> binaries, but your installation is i386. (However, you can at least run an
>>> amd64 kernel.)
>
>>> You might want to throw that away and do a full re-install, targetting
>>> amd64.
> [snip]
>
>> I was mistaken about x86_64. The uname -m command gives i686.
>
> Kernel. Not particularly relevant, except that that tells me that it only
> supports native 32-bit userland.
>
> /proc/cpuinfo is more interesting; particularly the first model name line and
> flags line.
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Xeon(R) CPU E5405 @ 2.00GHz
stepping : 10
cpu MHz : 2000.072
cache size : 6144 KB
physical id : 0
siblings : 8
core id : 1
cpu cores : 8
apicid : 1
initial apicid : 1
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu de tsc msr pae cx8 sep cmov pat clflush mmx fxsr sse sse2
ss ht nx constant_tsc pni ssse3 sse4_1
bogomips : 4017.21
clflush size : 64
power management:

I have executed the command:
apt-get remove --purge libevent
From the documentation I understand this was supposed to remove all
files for libevent. But the command:
locate libevent
finds many files for libevent in the directories:
/usr/local/src/libevent-1.4.13-stable/
/usr/local/lib/
Were these supposed to be removed be apt-get? Or should I remove these
manually?
--
If you desire to respond directly remove the "sj." from the domain name
part of my email address. It is a spam jammer.
 |  Next  |  Last
Pages: 1 2 3 4
Prev: Logs and dumps for kernel panics to collect and analyze?
Next: resize a lvm volume on a raid1