Re: Arch maintainers: new approach for crti.o and crtn.o

[David Miller <davem at davemloft dot net>]

From: "Joseph S. Myers" <joseph@codesourcery.com>
Date: Fri, 10 Feb 2012 21:41:53 +0000 (UTC)

> On Fri, 10 Feb 2012, David Miller wrote:
> 
>> Is there any particular reason you hid the ASFLAGS stuff exclusively
>> into the backwards compat case?  I guess it's to deal with the "defs.h"
>> dependency which doesn't exist when crt{i,n}.S are provided by the
>> architecture.
> 
> In general I think an improvement with the new scheme is that you avoid 
> special makefile rules for these targets (instead they can be built the 
> same way as other objects) and such a special rule is where the 
> $(ASFLAGS-.os) was.  As noted, CPPFLAGS can be used to get these options 
> in - although adding support for $(ASFLAGS-$(<F)) would be cleaner - but I 
> think it's better for architectures to end up setting such a variable if 
> needed for these targets (just as various architectures previously set 
> special options when building initfini.c) than to have a special makefile 
> rule with custom commands.

I'm not so sure I buy this, this puts the burdon on the wrong side
of the equation.

Using the $(ASFLAGS-.os) variable is perfect for this kind of
situation, where you have foo.o files built from assembler files that
need to be PIC.

All these other schemes being described put the burdon on the target
maintainer to keep track of exactly which object files fall into this
category.  And that is very error prone.  It took me hours to figure
out where I'd need to hook in all the various cases in the Sparc
Makefile fragments, including NPTL.

And then tomorrow if, for example, someone changes nptl/pt-crtn.o to
be named just plain nptl/crtn.o, all the targets have to adjust their
Makefile chunks again.

That doesn't make any sense to me, and again it seems extremely error
prone.

Whereas the $(ASFLAGS-.os) solution requires only the person making
generic glibc changes to get this specification right.