> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Bernhard Fischer > Sent: den 3 juni 2008 10:29 > To: Bernd Schmidt > Cc: uClibc > Subject: Re: [RFC] build system replacement > > 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.
Something along what gcc's -MP option does? > I'll think about this some more, but perhaps somebody has an > opinion or an idea.. :) //Peter _______________________________________________ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc