This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH - ping] Don't unlink /dev/null on darwin

"Peter O'Gorman" <> writes:

> Anyway, although I'm sure Geoffrey will pop in on this thread at
> some point and say "shut up already, I fixed as", I feel I must get
> rid of that -o /dev/null and need to find a way to do so that you
> agree with :)
> I ran your patch by the way, and still lost /dev/null (hey, at least
> mine worked!), I guess that MAKECMDGOALS was not being set properly in
> the calling Makefile.

Odd.  Er, you *do* understand that this doesn't provide any protection
when running the build itself as root, just when running 'make
install'?  Also, which 'make' have you got?

> You seem to be worried about parallel recursive builds, I don't think
> your scenario is actually possible, however, would putting a $$ into
> the output file name make you less nervous? The temporary file should
> always be going into the builddir, I am about to run a test with a
> non-writable source dir to verify that that is true.

Naming the output file something$$.o would go a long way to mitigate
my concerns about parallel make...

Just to observe, this

> 1) $gcc_compile -v -help | grep '\-fvisibility=.*hidden'

won't work, and this

> 3) Have a gcc option to check for valid flags without creating any
>    output (or requiring input).

would be nice but is not feasible; to be sure that the compile will
fail you have to provide input which actually uses the feature being
tested.  Also we need to probe the assembler too, which is why we
can't use -S and trust gcc to get the "don't delete /dev/null" thing


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]