On Sun, Nov 03, 2002 at 10:02:56AM +0000, Daniel Flickinger wrote: > Sent: Fri, 1 Nov 2002 10:55:33 +0200 by Ruslan: > > The problem is that it is time slice dependent; it only > shows if /usr/include/uuid.h has not been installed from > a prior installworld. > > At this point I am relatively convinced it is a make -j > # issue, eg: one part of the make is ahead of another > from the lack of a specific dependency.
The includes are installed prior to building the libraries. You should be able to verify this by looking at your ourput files. Since both are different phases, they always run serially WRT each other. No -j will ever change that. The first thing we do when we build libraries is to make dependencies. This we *must* do in serial WRT the building, because make(1) reads the dependencies at startup time. So, we have to explicitly rerun make(1) for the actual build in order to have the new dependencies used. After "depend" we actually build. If there's an ordering violation, then why did the make depend work? Also, is uuid.h present in the .depend file? Even if "build" runs before "depend", it's not the dependency info that causes the compiler to actually find libraries. It's only for make(1) to determine ordering. Thus, even if "build" happened before "depend", you'll not see this failure. It either works or the build fails because source files (and the likes) haven't been generated yet. > I wonder whether it is more important to consider the > make synchronization or more rigorous dependencies? I don't think there's a problem in either. You'll have to come up with substantial data that shows some sort of inconsistency before I will open that can of worms. Did you try the rebuilt in a clean source tree already? The reason I ask is because a modified src/Makefile.inc1 is more likely to cause the kind of failures you see than anything else. -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
