The hotplug list is discussing if they can automate the download and
installation of drivers to suit new hardware. Personally I do not
think it is going to work but that is not our problem. The question of
mixing objects compiled with different compilers was raised.
------- Forwarded Message
On Mon, 29 Oct 2001 13:53:40 -0800,
Greg KH <[EMAIL PROTECTED]> wrote:
>On Thu, Oct 18, 2001 at 01:19:47AM +0100, Stamatis Mitrofanis wrote:
>> I agree that a C compiler is a nice thing to have, but no one must be
>> forced to have it (say, end users). If it becomes a "base package",
>> every computer must have it installed and then people will start using
>> it when it's not necessary (huge mess). The best thing to do here is to
>> install the right version of gcc on demand (just as we do for drivers).
>
>And what version of gcc would you install? Different versions for
>different vendor kernels and even releases :)
I have decided to add CONFIG_KBUILD_GCC_VERSION to kbuild 2.5, it
records the values of gcc -b and -V used to build the kernel. The
string is automatically generated and added to the .config, _every_
source file will implicitly depend on that config variable so changing
the compiler will force a complete recompile.
Building the kernel and modules from a mixture of compilers is not a
supported operation.
This is almost true in kbuild 2.5 already. If you compile with 'gcc'
then recompile with 'kgcc' or switch from 'gcc' to 'gcc -V 3.0.1',
everything gets rebuilt because the compiler name and flags are part of
the saved command, any change in a command forces a recompile of the
affected objects. Adding the CONFIG_ variable will document which
compiler was used and catches the pathological case where 'gcc' is used
but it points to different compilers on different days.
Version information for other build utilities will be added as required.
>But I don't keep my kernels in /usr/src/linux, and neither do most
>people. And vendor kernels include a number of different .config files,
>all of them placed in a different file within the .src.rpm. Work with
>the LSB if you want to push for this kind of standardization.
Or the kbuild maintainer ;). LSB does not document down to this level
of detail so I am standardizing where .config and other files go in
2.5. /lib/modules/`uname -r`/{.config,System.map,trees}. kbuild 2.5
is not restricted to a single source tree so the single build symlink
is useless in 2.5, instead the 'trees' file defines the source tree(s)
and the object tree.
------- End of Forwarded Message
_______________________________________________
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel
