I would like to hear reports of building and running linuxbios on ubuntu and FC6.
The background is that ubuntu and, perhaps, fc6, set some options on the gcc pass that make no sense on a bios build. This is a guess. The result is a non-working linuxbios on those machines. It is believed the issue is some sort of stack protection flag that gets set.
So, if you have a working linuxbios, and an fc6 or ubuntu handy, I'd like to hear about your success or failure in building and running linuxbios.
This has been seen on OLPC, but nowhere else; it may be related to special needs of the OLPC.
thanks
ron
ron minnich wrote:
The background is that ubuntu and, perhaps, fc6, set some options on the gcc pass that make no sense on a bios build. This is a guess. The result is a non-working linuxbios on those machines. It is believed the issue is some sort of stack protection flag that gets set.
So, if you have a working linuxbios, and an fc6 or ubuntu handy, I'd like to hear about your success or failure in building and running linuxbios.
Ron, I think Linuxbios build will fail on recent Ubuntu dists. When I encounterd the problem the other developers here at OLPC said "oh yeah, it won't build on ubuntu."
I have the build working on my kubuntu laptop. Ubuntu enables the gcc stack protector. So when you build you get
linuxbios_ram.o: In function `number': vtxprintf.c:(.text+0x271a): undefined reference to `__stack_chk_fail' linuxbios_ram.o: In function `report_resource_stored': (.text+0x3aca): undefined reference to `__stack_chk_fail' linuxbios_ram.o: In function `cpu_initialize': (.text+0x875c): undefined reference to `__stack_chk_fail' collect2: ld returned 1 exit status
The fix is to add -fno-stack-protector into the CFLAGS. I'm currently doing it manually. What we need to know is how to detect when its active.
As for FC6 we would really like to hear from others who are building on FC6
The fix is to add -fno-stack-protector into the CFLAGS. I'm currently doing it manually. What we need to know is how to detect when its active.
You don't have to detect when it's active; you can just always disable it -- well that is, you first have to check if your GCC version supports it at all, it will bail on the command line flag otherwise.
If you really want to see what flags are active, compile a (dummy) file to an assembler file using -fverbose-asm, and it will tell you.
Segher
Segher Boessenkool wrote:
You don't have to detect when it's active; you can just always disable it -- well that is, you first have to check if your GCC version supports it at all, it will bail on the command line flag otherwise.
Thats what I meant. You have to know when to use the disable flag.
You don't have to detect when it's active; you can just always disable it -- well that is, you first have to check if your GCC version supports it at all, it will bail on the command line flag otherwise.
Thats what I meant. You have to know when to use the disable flag.
So you should just try it out somewhere in your build system -- gcc -fno-stack-protector -S -xc - < /dev/null -o /dev/null or something similar, grab the return code -- and that's all you need to do.
Maybe FC6 and/or Ubuntu will change their bad bad ways, but there are so many of those systems out in the field already, lots of projects have to protect themselves against this crap now. Sigh.
Segher
On 1/23/07, Segher Boessenkool segher@kernel.crashing.org wrote:
So you should just try it out somewhere in your build system -- gcc -fno-stack-protector -S -xc - < /dev/null -o /dev/null or something similar, grab the return code -- and that's all you need to do.
we'd always managed to avoid this kind of ugliness, but I guess we have no choice.
What's going to get interesting is when the form that this test takes gets broken by the various distros :-)
Some expert person want to try out a fix? If not, I guess I will.
ron
So you should just try it out somewhere in your build system -- gcc -fno-stack-protector -S -xc - < /dev/null -o /dev/null or something similar, grab the return code -- and that's all you need to do.
we'd always managed to avoid this kind of ugliness, but I guess we have no choice.
Indeed. This hurts many more projects btw, not just us.
What's going to get interesting is when the form that this test takes gets broken by the various distros :-)
The test isn't distro-specific; but I'm sure *some* distro (Gentoo? ;-) ) will break it.
Some expert person want to try out a fix? If not, I guess I will.
With Kbuild it's really easy (just copy the one-liner from the Linux kernel code); but for v2, you'll need to do a little more work (but you can use the same mechanism, of course -- copy on of the cc-option macros and you're fine).
Segher
Hi Guys,
I still monitor a lot of what is going on on the LinuxBIOS list. I am now doing a lot of work on ARM and MIPS stuff, in which environments a cross-compilation is required ... well also, in most of my embedded x86 stuff I maintain I now also use a cross-compilation toolchain so that I can use uClibc.
Maybe it would be an idea to create a very simple LinuxBIOS toolchain system where from a small SVN download, one can have a clean build environment using a pseudo cross-compile environment with a clean compiler per the 'latest' LinuxBIOS suggestion.
I personally use either Buildroot or another really interesting environment called openwrt (which has a really neat build environment aimed at the low-cost broadcom chip-based router environment), but essentially with these environments, one does an SVN checkout which downloads a series of scripts and makefiles, and from that a make creates a completely new toolchain from the specified known sources.
The really great thing about this is that one then has a KNOWN toolchain and all compiles are done with this KNOWN toolchain. Removes a whole lot of crap from the entire build environment, and, it generally works on ANY Linux platform - sure, there are some issues on OSX etc, but it does sure make a clean Linux build environment.
This may be a resolution to the screwed toolchains supplied in certain distros. I personally stopped using ANY flavour of redhat about 5 years ago when they released 7.1 with totally screwed beta compilers, which just broke everything. Since then I have used SuSE and have mostly never looked back. I have never used any RH or Fedora distro since then, purely because I have no idea what they will incorporate in the next release. At least by using the core code, one has a bit of security in knowing what one is dealing with .... ever tried to tell RH that they introduced a bug in the compiler toolchain??? I think it would probably have fallen on deaf ears. I must also point out that since 7.1, RedHat have insisted on creating their own 'patched' versions of GCC which may work for them, but for generic sources, there are frequently issues. (Especially when cross-compiling).
Just my tuppence!
Hamish
ron minnich wrote:
On 1/23/07, Segher Boessenkool segher@kernel.crashing.org wrote:
So you should just try it out somewhere in your build system -- gcc -fno-stack-protector -S -xc - < /dev/null -o /dev/null or something similar, grab the return code -- and that's all you need to do.
we'd always managed to avoid this kind of ugliness, but I guess we have no choice.
What's going to get interesting is when the form that this test takes gets broken by the various distros :-)
Some expert person want to try out a fix? If not, I guess I will.
ron
Maybe it would be an idea to create a very simple LinuxBIOS toolchain system where from a small SVN download, one can have a clean build environment using a pseudo cross-compile environment with a clean compiler per the 'latest' LinuxBIOS suggestion.
Building a cross-compilation toolchain on a fast machine takes about 10 minutes, while building LinuxBIOS should take about 2 seconds.
Also, you might *want* to use a "non-default" toolchain.
I personally use either Buildroot or another really interesting environment called openwrt (which has a really neat build environment aimed at the low-cost broadcom chip-based router environment), but essentially with these environments, one does an SVN checkout which downloads a series of scripts and makefiles, and from that a make creates a completely new toolchain from the specified known sources.
You might want to check out Dan Kegel's excellent "crosstool".
The really great thing about this is that one then has a KNOWN toolchain and all compiles are done with this KNOWN toolchain. Removes a whole lot of crap from the entire build environment, and, it generally works on ANY Linux platform - sure, there are some issues on OSX etc, but it does sure make a clean Linux build environment.
I regularly build the Linux kernel on OSX -- all it takes are some fixes to Linux itself, none toolchain related -- and certainly no fixes to the toolchain itself.
This may be a resolution to the screwed toolchains supplied in certain distros.
That much is true, but it's a really heavy-handed solution.
An option might be to include a script to build (and install) a toolchain as an optional preparation step for building LB.
I personally stopped using ANY flavour of redhat about 5 years ago when they released 7.1 with totally screwed beta compilers, which just broke everything.
"2.96". Yeah I still feel the pain.
ever tried to tell RH that they introduced a bug in the compiler toolchain??? I think it would probably have fallen on deaf ears.
You should have tried though.
Segher
Segher Boessenkool wrote:
Building a cross-compilation toolchain on a fast machine takes about 10 minutes, while building LinuxBIOS should take about 2 seconds.
Sure, but it can also take weeks to figure out that your toolchain is actually at fault.
Also, you might *want* to use a "non-default" toolchain.
If you want to use a non-default toolchain, you should be in a position to decide how to deviate from the defaults, in which case, changing the toolchain build options should be really simple if you are at that level of expertise.
You might want to check out Dan Kegel's excellent "crosstool".
Have used that extensively, and found it to be very good under certain circumstances, however, targeting new platforms already catered for by Buildroot and openwrt, it makes no sense since the toolchains are already in place.
I regularly build the Linux kernel on OSX -- all it takes are some fixes to Linux itself, none toolchain related -- and certainly no fixes to the toolchain itself.
I am a newbie to OSX, so it is probably just growing pains! Nevertheless, I think OSX is really cool!
This may be a resolution to the screwed toolchains supplied in certain distros.
That much is true, but it's a really heavy-handed solution.
I think a solution nevertheless for people who are battling with broken toolchains - certainly this should not be a mandatory part of the build, but an option provided for those battling.
An option might be to include a script to build (and install) a toolchain as an optional preparation step for building LB.
Totally agree.
ever tried to tell RH that they introduced a bug in the compiler toolchain??? I think it would probably have fallen on deaf ears.
You should have tried though.
I did frequently, and it fell on deaf ears - so much so that one of my corporate clients moved away from RH to SuSE.
Segher
Hamish
Building a cross-compilation toolchain on a fast machine takes about 10 minutes, while building LinuxBIOS should take about 2 seconds.
Sure, but it can also take weeks to figure out that your toolchain is actually at fault
That's not my point -- it would be a huge regression (in compile time) to include a toolchain build into the LB default build.
Also, you might *want* to use a "non-default" toolchain.
If you want to use a non-default toolchain, you should be in a position to decide how to deviate from the defaults, in which case, changing the toolchain build options should be really simple if you are at that level of expertise.
No, it's a lot easier to do if you don't have to deal with the mechanics of an automated toolchain build thing at the same time.
You might want to check out Dan Kegel's excellent "crosstool".
Have used that extensively, and found it to be very good under certain circumstances, however, targeting new platforms already catered for by Buildroot and openwrt, it makes no sense since the toolchains are already in place.
Note though that both those systems *use* crosstool under the covers AFAIK.
I regularly build the Linux kernel on OSX -- all it takes are some fixes to Linux itself, none toolchain related -- and certainly no fixes to the toolchain itself.
I am a newbie to OSX, so it is probably just growing pains! Nevertheless, I think OSX is really cool!
Heh. Try to build the Linux kernel on it. Hey, I think battle scars are really cool, too! :-)
This may be a resolution to the screwed toolchains supplied in certain distros.
That much is true, but it's a really heavy-handed solution.
I think a solution nevertheless for people who are battling with broken toolchains - certainly this should not be a mandatory part of the build, but an option provided for those battling.
An option might be to include a script to build (and install) a toolchain as an optional preparation step for building LB.
Totally agree.
The best option probably is to feature something about this really prominently really early in the build instructions.
ever tried to tell RH that they introduced a bug in the compiler toolchain??? I think it would probably have fallen on deaf ears.
You should have tried though.
I did frequently, and it fell on deaf ears - so much so that one of my corporate clients moved away from RH to SuSE.
You tried in their bugzilla? Wow.
In the case at hand -- the SSP thing -- I certainly can see why they want to enable this stuff by default ("protecting their not-all-that-knowledgeable customers against stack overrun vulnerabilities"), but IMNSHO it's the wrong way to go about it, and that's without the consideration that SSP doesn't really help at all (except against total morons).
Segher
Segher Boessenkool wrote:
Building a cross-compilation toolchain on a fast machine takes about 10 minutes, while building LinuxBIOS should take about 2 seconds.
Sure, but it can also take weeks to figure out that your toolchain is actually at fault
Or a 30-second post to the mailing list, or to search the archives. Perhaps we should add this to the wiki as a known issue?
I completely agree (and yes, I'm sure I agree this time). The machine I usually build on is a 1ghz P3, and LB takes long enough to build as it is (a couple minutes, usually), I don't really care for it to be any longer, especially if I'm just randomly poking around to see if I get things to work.
Could we perhaps parse the output of "gcc -v" before compiling, looking for "ubuntu" or "fedora" (or whatever those fedora guys add onto the version name)? Then offer a warning that the compiler may be broken with respect to linuxbios.
BTW, if you still want/need it, here's the error log compiled under Ubuntu 6.10 x64, with ubuntu's gcc 4.1.2:
gcc -m32 -nostdlib -nostartfiles -static -o linuxbios_ram -T /home/amp/LinuxBIOSv2/src/config/linuxbios_ram.ld linuxbios_ram.o linuxbios_ram.o: In function `number': vtxprintf.c:(.text+0x547e): undefined reference to `__stack_chk_fail' linuxbios_ram.o: In function `report_resource_stored': (.text+0x66e6): undefined reference to `__stack_chk_fail' linuxbios_ram.o: In function `init_processor_name': (.text+0x77fe): undefined reference to `__stack_chk_fail' linuxbios_ram.o: In function `amdk8_set_resources': northbridge.c:(.text+0xa965): undefined reference to `__stack_chk_fail' linuxbios_ram.o: In function `cpu_initialize': (.text+0x14c3b): undefined reference to `__stack_chk_fail' collect2: ld returned 1 exit status make[1]: *** [linuxbios_ram] Error 1 make[1]: Leaving directory `/home/amp/LinuxBIOSv2/targets/tyan/s2892/s2892/normal'
with 3.3.6, also from the repos, it's a bit different: gcc -m32 -nostdlib -nostartfiles -static -o linuxbios_ram -T /home/amp/LinuxBIOSv2/src/config/linuxbios_ram.ld linuxbios_ram.o linuxbios_ram.o: In function `idiv_long': (.text+0x11cb7): undefined reference to `__divdi3' linuxbios_ram.o: In function `idiv_long': (.text+0x11ccd): undefined reference to `__moddi3' linuxbios_ram.o: In function `div_long': (.text+0x11e1c): undefined reference to `__udivdi3' linuxbios_ram.o: In function `div_long': (.text+0x11e32): undefined reference to `__umoddi3' collect2: ld returned 1 exit status
I don't know if 64 bit could be causing any additional errors, but this seems very similar to what I get on my 32-bit laptop.
-Corey
The toolchain would only build once, not every time linuxbios is rebuilt.
-----Original Message----- From: linuxbios-bounces@linuxbios.org [mailto:linuxbios-bounces@linuxbios.org] On Behalf Of Corey Osgood Sent: Wednesday, January 24, 2007 10:14 PM To: Segher Boessenkool Cc: Hamish Guthrie; ron minnich; LinuxBIOS Subject: Re: [LinuxBIOS] help from ubuntu and FC6 experts
Segher Boessenkool wrote:
Building a cross-compilation toolchain on a fast machine takes about 10 minutes, while building LinuxBIOS should take about 2 seconds.
Sure, but it can also take weeks to figure out that your toolchain is actually at fault
Or a 30-second post to the mailing list, or to search the archives. Perhaps we should add this to the wiki as a known issue?
I completely agree (and yes, I'm sure I agree this time). The machine I usually build on is a 1ghz P3, and LB takes long enough to build as it is (a couple minutes, usually), I don't really care for it to be any longer, especially if I'm just randomly poking around to see if I get things to work.
Could we perhaps parse the output of "gcc -v" before compiling, looking for "ubuntu" or "fedora" (or whatever those fedora guys add onto the version name)? Then offer a warning that the compiler may be broken with
respect to linuxbios.
BTW, if you still want/need it, here's the error log compiled under Ubuntu 6.10 x64, with ubuntu's gcc 4.1.2:
gcc -m32 -nostdlib -nostartfiles -static -o linuxbios_ram -T /home/amp/LinuxBIOSv2/src/config/linuxbios_ram.ld linuxbios_ram.o linuxbios_ram.o: In function `number': vtxprintf.c:(.text+0x547e): undefined reference to `__stack_chk_fail' linuxbios_ram.o: In function `report_resource_stored': (.text+0x66e6): undefined reference to `__stack_chk_fail' linuxbios_ram.o: In function `init_processor_name': (.text+0x77fe): undefined reference to `__stack_chk_fail' linuxbios_ram.o: In function `amdk8_set_resources': northbridge.c:(.text+0xa965): undefined reference to `__stack_chk_fail' linuxbios_ram.o: In function `cpu_initialize': (.text+0x14c3b): undefined reference to `__stack_chk_fail' collect2: ld returned 1 exit status make[1]: *** [linuxbios_ram] Error 1 make[1]: Leaving directory `/home/amp/LinuxBIOSv2/targets/tyan/s2892/s2892/normal'
with 3.3.6, also from the repos, it's a bit different: gcc -m32 -nostdlib -nostartfiles -static -o linuxbios_ram -T /home/amp/LinuxBIOSv2/src/config/linuxbios_ram.ld linuxbios_ram.o linuxbios_ram.o: In function `idiv_long': (.text+0x11cb7): undefined reference to `__divdi3' linuxbios_ram.o: In function `idiv_long': (.text+0x11ccd): undefined reference to `__moddi3' linuxbios_ram.o: In function `div_long': (.text+0x11e1c): undefined reference to `__udivdi3' linuxbios_ram.o: In function `div_long': (.text+0x11e32): undefined reference to `__umoddi3' collect2: ld returned 1 exit status
I don't know if 64 bit could be causing any additional errors, but this seems very similar to what I get on my 32-bit laptop.
-Corey
bear in mind that many people, given a linuxbios that would not build on system x.y.z, assumed the problem was linuxbios -- even when it was not. In fact, it has rarely been linuxbios, but has in fact been a particular distro or toolchain. How do you answer the following: "I can build a kernel on this distro just fine, why can't I build linuxbios"?
I think it would be nice if somebody could show us the -fturn-off-this-switch approach and how to put it into the linuxbios build process, and detect that on whatever gcc we're using the turn-off-this-switch does not exist, but can be automagically worked around.
But I would also be extremely grateful to anyone who can show us how to set up linuxbios with the 'use this toolchain' as an option. I think, given the number of distros and the strange ways they are breaking our build process, we have to have this option available to users.
thanks
ron
On Thu, 25 Jan 2007, Corey Osgood wrote: [..]
BTW, if you still want/need it, here's the error log compiled under Ubuntu 6.10 x64, with ubuntu's gcc 4.1.2:
According to the gcc home page gcc-4.1.2 will be released any day now.
Russ
Russ Whitaker wrote:
On Thu, 25 Jan 2007, Corey Osgood wrote: [..]
BTW, if you still want/need it, here's the error log compiled under Ubuntu 6.10 x64, with ubuntu's gcc 4.1.2:
According to the gcc home page gcc-4.1.2 will be released any day now.
Russ
It's a prerelease, but I guess officially it would still be 4.1.1: $ gcc -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-checking=release x86_64-linux-gnu Thread model: posix gcc version 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)
Segher Boessenkool wrote:
gcc -m32 -nostdlib -nostartfiles -static -o linuxbios_ram -T /home/amp/LinuxBIOSv2/src/config/linuxbios_ram.ld linuxbios_ram.o linuxbios_ram.o: In function `idiv_long': (.text+0x11cb7): undefined reference to `__divdi3' linuxbios_ram.o: In function `idiv_long': (.text+0x11ccd): undefined reference to `__moddi3' linuxbios_ram.o: In function `div_long': (.text+0x11e1c): undefined reference to `__udivdi3' linuxbios_ram.o: In function `div_long': (.text+0x11e32): undefined reference to `__umoddi3' collect2: ld returned 1 exit status
with 3.3.6, also from the repos, it's a bit different:
That's different, [i]div_long is asking for a 64-bit division, which isn't a native instruction but implemented by the GCC support lib (libgcc), and you're explicitly building without it.
I've done nothing different than with any other build, except change the symlinks in /usr/bin to point to gcc-3.3, etc (ubuntu doesn't have any gcc-config style setup for easy changing of gcc versions). It could be I just missed something, but I didn't pass any extra options to make.
-Corey
P.S. Sorry for the gross mis-quote in my previous post
Hi,
On Thu, Jan 25, 2007 at 03:40:07PM -0500, Corey Osgood wrote:
I've done nothing different than with any other build, except change the symlinks in /usr/bin to point to gcc-3.3, etc (ubuntu doesn't have any gcc-config style setup for easy changing of gcc versions).
Didn't they take 'update-alternatives' from Debian into Ubuntu? Try 'update-alternatives cc' which should allow you to set the default C compiler.
Uwe.
I think what we need is a step in buildtarget that probes the C compiler and sets options correctly.
I will try to look at this tomorrow; I'm installing ubuntu on a system I have at home.
ron
* ron minnich rminnich@gmail.com [070202 03:16]:
I think what we need is a step in buildtarget that probes the C compiler and sets options correctly.
abuild does something like this already. So far it does not probe for supported compiler flags but for the available cross compilers.
We could hop up abuild to generally become the configure and build tool for LinuxBIOS v2.
Could we perhaps parse the output of "gcc -v" before compiling, looking for "ubuntu" or "fedora" (or whatever those fedora guys add onto the version name)? Then offer a warning that the compiler may be broken with respect to linuxbios.
It's just as easy to add the -fno-stack-protector flag if the compiler supports it.
gcc -m32 -nostdlib -nostartfiles -static -o linuxbios_ram -T /home/ amp/LinuxBIOSv2/src/config/linuxbios_ram.ld linuxbios_ram.o linuxbios_ram.o: In function `number': vtxprintf.c:(.text+0x547e): undefined reference to `__stack_chk_fail' linuxbios_ram.o: In function `report_resource_stored': (.text+0x66e6): undefined reference to `__stack_chk_fail' linuxbios_ram.o: In function `init_processor_name': (.text+0x77fe): undefined reference to `__stack_chk_fail' linuxbios_ram.o: In function `amdk8_set_resources': northbridge.c:(.text+0xa965): undefined reference to `__stack_chk_fail' linuxbios_ram.o: In function `cpu_initialize': (.text+0x14c3b): undefined reference to `__stack_chk_fail' collect2: ld returned 1 exit status make[1]: *** [linuxbios_ram] Error 1 make[1]: Leaving directory `/home/amp/LinuxBIOSv2/targets/tyan/ s2892/s2892/normal'
That's the failure at hand yes.
with 3.3.6, also from the repos, it's a bit different: gcc -m32 -nostdlib -nostartfiles -static -o linuxbios_ram -T /home/ amp/LinuxBIOSv2/src/config/linuxbios_ram.ld linuxbios_ram.o linuxbios_ram.o: In function `idiv_long': (.text+0x11cb7): undefined reference to `__divdi3' linuxbios_ram.o: In function `idiv_long': (.text+0x11ccd): undefined reference to `__moddi3' linuxbios_ram.o: In function `div_long': (.text+0x11e1c): undefined reference to `__udivdi3' linuxbios_ram.o: In function `div_long': (.text+0x11e32): undefined reference to `__umoddi3' collect2: ld returned 1 exit status
That's different, [i]div_long is asking for a 64-bit division, which isn't a native instruction but implemented by the GCC support lib (libgcc), and you're explicitly building without it.
Segher
Hi,
On Thu, Jan 25, 2007 at 08:01:24PM +0100, Segher Boessenkool wrote:
Could we perhaps parse the output of "gcc -v" before compiling, looking for "ubuntu" or "fedora" (or whatever those fedora guys add onto the version name)? Then offer a warning that the compiler may be broken with respect to linuxbios.
It's just as easy to add the -fno-stack-protector flag if the compiler supports it.
Yes. Checking for "Fedora" or "Ubuntu" is the wrong approach. We should check whether the compiler actually supports feature xyz, not whether we're on a certain platform.
Uwe.
ron minnich wrote:
I would like to hear reports of building and running linuxbios on ubuntu and FC6.
I use ubuntu 6.10 on my desktop, and it always fails to compile somewhere along the line, both with gcc 4.1 and 3.3 from the ubuntu repositories. The box that I usually compile on runs Gentoo 2006.1, which works perfectly.
-Corey
On 1/23/07, Corey Osgood corey_osgood@verizon.net wrote:
ron minnich wrote:
I would like to hear reports of building and running linuxbios on ubuntu and FC6.
I use ubuntu 6.10 on my desktop, and it always fails to compile somewhere along the line, both with gcc 4.1 and 3.3 from the ubuntu repositories. The box that I usually compile on runs Gentoo 2006.1, which works perfectly.
send me the failing output, ok?
I assume we don't want the stack protection code in.
ron
The background is that ubuntu and, perhaps, fc6, set some options on the gcc pass that make no sense on a bios build. This is a guess. The result is a non-working linuxbios on those machines. It is believed the issue is some sort of stack protection flag that gets set.
Yeah, at least FC6 does that, and it should be reported as a bug to them (or as a serious misfeature at least) -- by default enabling some options that FSF GCC won't allow you to enable by default (for a good reason) cannot be helpful.
Does LinuxBIOS build with -ffreestanding? If you don't, that's a bug for you too -- if you do, and that option does not disable SSP, that's a GCC bug -- either a mainline GCC one, or one in FC6, depending on how they enable it by default.
Segher
Segher Boessenkool wrote:
Does LinuxBIOS build with -ffreestanding? If you don't, that's a bug for you too -- if you do, and that option does not disable SSP, that's a GCC bug -- either a mainline GCC one, or one in FC6, depending on how they enable it by default.
We do not (at least as far as I can tell) and I just tested and -ffreestanding did not help.
Does LinuxBIOS build with -ffreestanding? If you don't, that's a bug for you too -- if you do, and that option does not disable SSP, that's a GCC bug -- either a mainline GCC one, or one in FC6, depending on how they enable it by default.
We do not (at least as far as I can tell)
Bug! Bug! ;-)
and I just tested and -ffreestanding did not help.
I'll go see what the larger GCC community thinks about this -- I'd say it's a bug. Well I'll go check tomorrow :-)
Segher
Does LinuxBIOS build with -ffreestanding? If you don't, that's a bug for you too -- if you do, and that option does not disable SSP, that's a GCC bug -- either a mainline GCC one, or one in FC6, depending on how they enable it by default.
We do not (at least as far as I can tell)
Bug! Bug! ;-)
and I just tested and -ffreestanding did not help.
I'll go see what the larger GCC community thinks about this -- I'd say it's a bug. Well I'll go check tomorrow :-)
The outcome is that -ffreestanding shouldn't disable SSP, as it can be useful for freestanding systems too -- they'll just have to provide the necessary library functions themselves.
Segher
On 01/23/2007 12:20 PM, ron minnich wrote:
I would like to hear reports of building and running linuxbios on ubuntu and FC6.
I've just built working linuxbios. A lot of warnings; no errors.
~>uname -a Linux xd1000 2.6.18-1.2869.fc6 #1 SMP Wed Dec 20 14:51:34 EST 2006 x86_64 x86_64 x86_64 GNU/Linux ~>gcc --version gcc (GCC) 4.1.1 20070105 (Red Hat 4.1.1-51)
Roman
-
Clay Jones -
Corey Osgood -
Hamish Guthrie -
Richard Smith -
Roman Kononov -
ron minnich -
Russ Whitaker -
Segher Boessenkool -
Stefan Reinauer -
Uwe Hermann