Re: Compiling Linux kernel



Hi, Sven.

On Friday, 25 December 2009 09:53:53 +0100,
Sven Joachim wrote:

Sorry to send this message twice, but I thought that for some reason
it had not arrived at the list. Although it seems that both messages
arrived with a delay of six hours. This can be due to some
moderation of the list?

This list is not moderated, and your messages have a very low
spamassassin score, so they should have arrived immediately. You can
look in the "Received:" headers to see where they spent the time.

It seems that the problem was to the return:

Received: from liszt.debian.org (EHLO liszt.debian.org) [82.195.75.100]
by mx0.gmx.net (mx052) with SMTP; 24 Dec 2009 20:10:35 +0100 <------
Received: from localhost (localhost [127.0.0.1])
by liszt.debian.org (Postfix) with QMQP
id 5547A2D0D8E; Thu, 24 Dec 2009 12:47:49 +0000 (UTC) <------
Received: from localhost (localhost [127.0.0.1])
by liszt.debian.org (Postfix) with ESMTP id CF5AD2D0D5C
for <lists-debian-user@xxxxxxxxxxxxxxxx>; Thu, 24 Dec 2009 12:47:42 +0000 (UTC)
Received: from liszt.debian.org ([127.0.0.1])
by localhost (lists.debian.org [127.0.0.1]) (amavisd-new, port 2525)
with ESMTP id 7OfJDoFZMriA for <lists-debian-user@xxxxxxxxxxxxxxxx>;
Thu, 24 Dec 2009 12:47:35 +0000 (UTC)

Now I'm seeing that the email crosses liszt.debian.org several times,
which draws attention to me.

And why in this case yes we must use these options if running an
amd64 kernel in userland 32 is not necessary to use ARCH=x86_64 in
the invocations of "make" when compiling of the traditional way?

Well, thinking a little more about this subject, the cause by which
this happens perhaps is that when make-kpkg consults the general
architecture of the system, it obtains in (b.1) as in (b.2) that is
i386. For that reason in both cases it is necessary to use
--cross-compile and --arch.

Nevertheless when being used the compilation of the traditional way,
this becomes by outside any own control of Debian and the
architecture that will be used by default is the one of running
kernel.

Is correct this asseveration?

Yes, kernel-package relies on the information dpkg-architecture
provides whereas the kernel Makefile trusts "uname -m" to determine
the architecture. On systems with a 64-bit kernel and 32-bit userland
this gives different information:

,----
| % dpkg-architecture -qDEB_BUILD_ARCH
| i386
| % uname -m
| x86_64
`----

Thanks to all by the contributions. These were very useful.


Regards,
Daniel
--
Fingerprint: BFB3 08D6 B4D1 31B2 72B9 29CE 6696 BF1B 14E6 1D37
Powered by Debian GNU/Linux Lenny - Linux user #188.598

Attachment: signature.asc
Description: Digital signature



Relevant Pages

  • finding actual cpu architecture
    ... architecture of a machine. ... on Opteron, with i686 kernel, 'uname -a' ...
    (comp.os.linux)
  • finding actual architecture
    ... architecture of a machine. ... on Opteron, with i686 kernel, 'uname -a' ...
    (alt.os.linux)
  • finding actual cpu architecture
    ... architecture of a machine. ... on Opteron, with i686 kernel, 'uname -a' ...
    (comp.os.linux.development.system)
  • Re: How to verify the running kernels architecture?
    ... $ yum list installed | grep kernel ... How do I know if the kernel I'm running is the i586 or i686 version? ... uname -m is not useful in this case, because it shows me the machine ... architecture, not the architecture for which the ...
    (Fedora)
  • Re: [PATCH 1/4] Blackfin: arch patch for 2.6.18
    ... to the kernel from the mtd medium, ... architecture if that means that you have to leave holes like setup. ... You seem to have lots of these machine specfic header files in include/asm. ... probably be either 'subarchitecture' or 'platform' in your code. ...
    (Linux-Kernel)