Summary: | toolchain changes /dev/null to a file | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | David Wood <jbevren> |
Component: | [OLD] Core system | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED FIXED | ||
Severity: | major | CC: | hppa, mips |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | MIPS | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
David Wood
2005-01-28 05:30:27 UTC
Uh, I mean 666 /dev/null in my chmod's :-X procps isnt the real issue ... it just comes up with it because it runs something like `gcc -o /dev/null` when testing compiler flags our toolchain is the real problem ... here's a way to test: $ echo "int main() { return(0); }" > test.c $ gcc -o /dev/null test.c you will either get an ugly error message and lose /dev/null, or you'll get no output vapier: I can't reproduce that on x86_64 + devfsd or i686 + udev. i know, but i can easily reproduce on my hppa / mips boxes ok, solar grabbed a patch from mainline to fix binutils' ld which is now part of binutils-2.15.92.0.2-r8 ... so that fixed ld from eating /dev/null however, gcc's collect2 would still unlink the output file, so i wrote a small patch based upon the binutils one: http://viewcvs.gentoo.org/src/patchsets/gcc/3.4.3.20050110/gentoo/00_all_gcc_unlink_if_ordinary.patch?root=gentoo tested on my hppa and it no longer unlink's /dev/null ... so i'm adding this patch to our gcc-3.3.5.2005xxxx and our gcc-3.4.3.2005xxxx |