[LinuxBIOS] Infamous __stack_chk_fail problem.

[Stefan Reinauer]

* Peter Stuge <peter at stuge.se> [071203 18:08]:
> On Mon, Dec 03, 2007 at 08:34:00AM -0800, Steve Isaacs wrote:
> > I believe that like it or not if you want LinuxBIOS to be widely
> > accepted it must be able to demonstrate repeatability.
> 
> Excellent point! I agree with you completely.
> 
> We should definately look at automating the build process and even
> build environment, because it is a sensitive component in the build
> process, and we should make LB smart enough to build with a build
> environment other than the one that starts with /usr/bin/gcc.

We already have all this: That's why I developed the LinuxBIOS test
system that started producing binary images at a central point:

http://qa.linuxbios.org/log_test.php?timestamp=20061109-173426&device=epia-m&vendor=via&manual=true

Of course everyone is free to use the same tool chain for all their
builds. But for sure, the result can not be good if we try to build
every software development and testing process out there into linuxbios.
At some point there will always be a special restriction that a
commercial vendor will have to make. Like running on certain svn
revisions, basically forking, rather than staying on HEAD all the time.

> However - I want it to remain optional rather than a requirement,
> so that the entry level stays as low as possible for as many as
> possible.

If someone feels the need for a cross development environment -- there's
crosstool. You can easily build RPMs for all kinds of cross compiler
versions for all kinds of platforms. 

It is an interesting project, and we recommend everyone using LinuxBIOS
in a commercial environment to use it. But that belongs into the
corporate software development process, and not into linuxbios.

Just change your target config.lb to your known good tool chain and
you're fine. 

In addition, as a side note: I have not seen any miscompilations with
any toolchain of (Open)SUSE Linux since 2003 whereas Redhat/Fedora was
troublesome with every second toolchain release. It seems RH/F is quite
a bit more "progressive" when it comes down to toolchains. So if you
want a stable system, you should also take into consideration that
choosing a distribution as experimental as FC8, you will run into such
problems.

Stefan

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: info at coresystems.de  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866