[RFC] build system replacement

Bernhard Fischer rep.dot.nop at gmail.com
Tue Jun 3 08:29:15 UTC 2008


On Sun, Jun 01, 2008 at 05:50:41PM +0200, Bernd Schmidt wrote:
> Bernhard Fischer wrote:
>> I hope i improved the situation a bit now (if you use r22158 and later).
>> We honour both all our prerequisites (if your compiler groks what we
>> mean to ask for in our gcc-ism) as well as the used CC and flags.
>> I consider this fixed, issue closed, nothing to see here, please move on
>> (or holler if i broke something) :)
>
> I've done a bit of digging, and found the cause of two problems.
>
> 1. So far, only libc-so-y and libc-a-y are tracked.
> This needs to be extended to handle all the other libraries, including  
> ld.so.
>
> 2. The CFLAGS passed to the compiler have changed in some cases.
> Previously, when compiling ldso/libdl/libdl.c,  $^ used to be  
> "ldso/libdl/libdl.c"; it is now "ldso/libdl/libdl.c FORCE", which means  
> that $(CFLAGS-$(notdir $(^D)) no longer does the right thing: $(notdir  
> $(^D)) is now "libdl .".
>
> There's also $(CFLAGS-$(notdir $<)) in the command line, which doesn't  
> work for this case, since it expands to "ldso/libdl/"; note the prefix  
> "ldso/" and the trailing slash.
>
> We could fix this by using $(<D) instead of $(^D) in the above.  Also,  
> maybe it makes sense to clean up the CFLAGS to always mention the full  
> path without trailing slash.

I see that you already took care of this, many thanks.

We still have a problem, though. Consider HAVE_SHARED set (i.e. ldso is
built) and also some thread variant selected. Build. Turn off
thread-support. make clean && make; bummer.

Suddently there is no rule to make include/bits/pthreadtypes.h (anymore).
We recorded this header as a prereq in the first build, but of course
turning off thread-support breaks this horribly.
A make realclean obviously would bypass this, but either we need
dummy-rules for conditional headers like this or do something else to
drop those now unavailable prerequisites.

I'll think about this some more, but perhaps somebody has an opinion or
an idea..  :)



More information about the uClibc mailing list