From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 13 06:11:47 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 07DC01065672 for ; Sun, 13 Jun 2010 06:11:47 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id B03378FC1B for ; Sun, 13 Jun 2010 06:11:46 +0000 (UTC) Received: by vws20 with SMTP id 20so2882717vws.13 for ; Sat, 12 Jun 2010 23:11:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=eLhE7+T9bLsC5p3c/ExCrhZKsWFNNBLrQ+Kmmg3wOSo=; b=PCyZ2BtFSOLL8e1JQQhevuwJcGqcTJSOl5WqyloE1Ks5LX48dd0uSoJhmA2PyHPbI1 LQ7569VYzELENaGNcI30fvaZCopoOr2RT+tE06Ow/pARBvLqDYa+LzS41mP7gvTAGg71 5OlTcacdzznT3+FFdwdBSdZGK8f4HkhFPj8Uo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=iTCIYDUL84wHWDGH11/1rQ2A4cmq3vOuS5pUNhjyiDI25OrQYK2E0FzcePDuRwCKqP PCA+f8INka5CccFb+CbeY4BJZBmOHYOgKszQHd1X+K8EcHhors9Z7KONT7bTQ5sNOcLU J0TSqLg3KgdXsMOLp6NQ+TYhAAuRLNf4WCW0g= MIME-Version: 1.0 Received: by 10.224.65.152 with SMTP id j24mr1341224qai.52.1276409505713; Sat, 12 Jun 2010 23:11:45 -0700 (PDT) Received: by 10.229.233.74 with HTTP; Sat, 12 Jun 2010 23:11:45 -0700 (PDT) Date: Sat, 12 Jun 2010 23:11:45 -0700 Message-ID: From: Garrett Cooper To: FreeBSD-Hackers Content-Type: text/plain; charset=ISO-8859-1 Subject: Resolving lib build dependencies in src a non-race condition prone way? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jun 2010 06:11:47 -0000 I might be completely missing the boat as to what needs to be done here, but the current code in Makefile.inc1, and lib/Makefile appears very race condition prone: >From Makefile.inc1: _prebuild_libs= ${_kerberos5_lib_libasn1} ${_kerberos5_lib_libheimntlm} \ ${_kerberos5_lib_libhx509} ${_kerberos5_lib_libkrb5} \ ${_kerberos5_lib_libroken} \ lib/libbz2 lib/libcom_err lib/libcrypt \ lib/libexpat \ ${_lib_libgssapi} ${_lib_libipx} \ lib/libkiconv lib/libkvm lib/libmd \ lib/ncurses/ncurses lib/ncurses/ncursesw \ lib/libopie lib/libpam ${_lib_libthr} \ lib/libradius lib/libsbuf lib/libtacplus \ lib/libutil ${_lib_libypclnt} lib/libz lib/msun \ ${_secure_lib_libcrypto} ${_secure_lib_libssh} \ ${_secure_lib_libssl} >From lib/Makefile: SUBDIR_ORDERED= ${_csu} \ libc \ libbsm \ libauditd \ libcom_err \ libcrypt \ libelf \ libkvm \ msun \ libmd \ ncurses \ ${_libnetgraph} \ libradius \ librpcsvc \ libsbuf \ libtacplus \ libutil \ ${_libypclnt} SUBDIR= ${SUBDIR_ORDERED} \ libalias \ libarchive \ ${_libatm} \ Note that if in Makefile.inc1 I place a library like libarchive, then the process will fall over in itself (this is the case in my perforce branch today) trying to fulfill prerequisites (libbz2, liblzma, libz). If I place the dependencies in SUBDIR_ORDERED in lib/Makefile, then I risk bringing in a race condition where a high enough -j value will cause the build to fail as well. The other thing that's curious is instead of building in the logic to build the prerequisite libraries in the leaf Makefiles, make just currently fails as follows: ===> lib/libpkg (all) make: don't know how to make /usr/obj/scratch/freebsd/perforce/pkg_install-enhancements/tmp/usr/lib/libarchive.a. Stop I was wondering why the DPADD code wasn't properly building prerequisites beforehand, but it appears that the only code that defines the targets are the respective lib Makefiles themselves. So, to just confirm this: Is there a race condition issue that's currently handled by explicit manual ordering of the targets? - If yes, could it be fixed by adding in bits to link back the lib make invocations at Makefile.inc1, or similar, i.e.: LIBARCHIVE_SRCDIR= lib/libarchive ${LIBARCHIVE}: .for i in depend obj all install ${MAKE} -C ${SRCDIR}${LIBARCHIVE_SRCDIR} $i .endfor ? (I realize that using the variable ${SRCDIR} won't function in all contexts, so it probably be something like ${TOP_SRCDIR}, keeping parity with an autotools-like paradigm -- but the name doesn't really matter too much right now). - If no, what am I doing wrong? Thanks, -Garrett