flag-o-matic.eclass contains: test-flag-PROG() { local comp=$1 local flags="$2" [[ -z ${comp} || -z ${flags} ]] && \ return 1 local PROG=$(tc-get${comp}) ${PROG} ${flags} -S -o /dev/null -xc /dev/null \ > /dev/null 2>&1 } ... which will likely fail on any platform which doesn't use GCC. On IRIX, in particular, the native MIPSpro compiler suite tools: * Have no -S option; * Have no -xc option; * Will produce an error if invoked without any actual source to compile. This function should be rewritten to pass a stub program to the compiler, as 'configure' scripts do.
Let's see a patch that works and it will be considered for inclusion and possibly pushed upstream to gentoo-x86, although they probably won't buy it.
this does not work on windows too (of course :)). since now i didn't have any time to look into it, and even though there is some occasional error output (everytime the function is called), everything still seems to work ok.
It's not possible to compile dev-lang/python-2.5 on IRIX with this code in place: the python ebuild contains: append-ldflags -L. ... which then falls through to test-flag-PROG in flag-o-matic.eclass, which then fails because the compiler invokation is fubar. This then means that the python build isn't able to link against its own libraries, and the whole thing breaks completely. I've just had a play with the IRIX compiler, and even it's intelligent enough that even 'cc -o /dev/null' fails with: ld32: ERROR 143: I/O error (output file invalid): output ignored ld32: INFO 152: Output file removed because of error. ... so it looks as if the only solution is something along the lines of: test-flag-PROG() { local comp=$1 local flags="$2" [[ -z ${comp} || -z ${flags} ]] && \ return 1 local PROG=$(tc-get${comp}) cat >flag-o-matic_test.c <<FOMEOF int main( void ) { return 0; } FOMEOF ${PROG} ${flags} -c flag-o-matic_test.c \ -o flag-o-matic_test > /dev/null 2>&1 && \ rm flag-o-matic_test > /dev/null 2>&1 } ... which should still be a valid test, as if the compiler exits successfully then there will be an executable to remove, and if it doesn't then 'rm' will also fail. It's a shame that it's not possible to pipe code to the compiler... The compiler flags '-S', '-xc', and specifying /dev/null as the output file are all GNU-specific or, at least, not portable.
(In reply to comment #2) > this does not work on windows too (of course :)). since now i didn't have any > time to look into it, and even though there is some occasional error output > (everytime the function is called), everything still seems to work ok. ohw. wait. i guess on windows it would work for basic things (like the -L. you mentioned). i guess the problems i'm seeing is just unsupported flags beeing tested for. (or maybe something completely different, since the compiler ignores unknown flags...)
do you export CC=something? on IRIX? does tc-getCC on IRIX return something with "gcc" in it?
CC is exported as having value 'cc', and I'm assuming that tc-getCC doesn't contain anything including 'gcc' as gcc doesn't exist on this system, and so you'd expect wide-spread build failures if it did! (Additionally, "$CC $CFLAGS $LDFLAGS" doesn't happen to contain 'gcc' embedded within another string) Note that MIPSpro compiler options make liberal use of colons, so any sed recipe using ':' as a separator will likely break in non-obvious ways...
can't the mipspro wrapper solve this problem somehow?
Hmm - not easily, I don't think. I've just noticed that '-xc' is actually (probably) valid, yet the wrapper doesn't handle it. '-x c' is the form suggested by the MIPSpro and GCC documentation, and this would work. The compiler does support '-xc', though. Additionally, I was wrong when I filed this bug, and the '-S' option is fully supported - my bad. The problem lies in the fact that MIPSpro will refuse to produce output when given no input, outputting: ld32: FATAL 10 : Unable to open output file /dev/null: input file with same name ... otherwise, the output is: ld32: FATAL 11 : Object file format error (test): file is empty. If an empty file (which isn't /dev/null) is used. So it would be possible to parse the supplied command line for "/dev/null", replace the input with a mktemp'd temporary file containing a stub program to be inserted, and then compile this instead writing to another temporary file... ... or run the wrapper's internal check*flags routine and output the result if "/dev/null" is a parameter (which could be fragile - what else might this break?) ... or the (still non-portable, despite my oversights above) test could be changed to something more portable, as suggested in Comment #3 ;) I have a vested interest here - but surely the latter option makes most sense, because it doesn't rely on the behaviour of one particular compiler implementaion?
This is a problem on Solaris with Sun LD as well: > gcc -I../gnulib -c -o /dev/null -xc /dev/null /usr/ccs/bin/as: File exists /usr/ccs/bin/as: error: cannot open output file "/dev/null" Hence all flags are being rejected.
This change works for me, let's hope it's enough Index: flag-o-matic.eclass =================================================================== --- flag-o-matic.eclass (revision 60184) +++ flag-o-matic.eclass (working copy) @@ -424,9 +424,14 @@ [[ -z ${comp} || -z ${flags} ]] && return 1 # use -c so we can test the assembler as well + # don't use -o /dev/null: /usr/ccs/bin/as: File exists (Sun LD) + # don't use /dev/null as input: -xc flag needs not to exist #254120 + local src=${T}/tf-${comp}-${SECONDS}.c + echo "main() {}" > "${src}" local PROG=$(tc-get${comp}) - ${PROG} ${flags} -c -o /dev/null -xc /dev/null \ + ${PROG} ${flags} -c -o "${src}.o" "${src}" \ > /dev/null 2>&1 + rm -f "${src}"{,.o} } # @FUNCTION: test-flag-CC
