This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc 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: Move sysdeps/x86_64/Implies to sysdeps/x86_64/64


From: "Joseph S. Myers" <joseph@codesourcery.com>
Date: Thu, 22 Mar 2012 22:28:53 +0000 (UTC)

> On Thu, 22 Mar 2012, Roland McGrath wrote:
> 
>> I definitely want other people to give opinions about this before we decide
>> what to do.
> 
> I find the finer points of Implies ordering rather confusing, but one 
> thing that would be in favour of any enhancement to the scheme would be if 
> it avoids the need for such files as 
> sysdeps/unix/sysv/linux/powerpc/powerpc32/power7/Implies (which says
> 
> powerpc/powerpc32/power7/fpu
> powerpc/powerpc32/power7
> 
> ) - I'm not sure exactly what ordering issue that is addressing, but it 
> would be good to have a clear explanation for both that and the present 
> x32 issue (actually saying what the salient difference is between two 
> orderings, and what files that difference matters for).

All of those things are probably dealing with the same issue Sparc has
to contend with, which is that if you need compat routines built for
an earlier ABI where "long double" == "double" then you have to play
games to get the cpu sysdep directories in the sysdep list before
ldbl-opt.

As an aside, if I spent a few months reworking glibc's build system
such that it didn't generate thousands of prefix rules every directory
traversal (and thus result in combinatorial explosion inside of GNU
make) how receptive would people be to this?

It just really irks me that more than %60 of my build time is spent
processing rules inside of GNU Make, rather than compiling or running
test cases.


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