From owner-svn-ports-all@freebsd.org Mon Apr 24 08:50:22 2017 Return-Path: Delivered-To: svn-ports-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3F0AED4D3DD; Mon, 24 Apr 2017 08:50:22 +0000 (UTC) (envelope-from danfe@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1A0DF1993; Mon, 24 Apr 2017 08:50:22 +0000 (UTC) (envelope-from danfe@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id v3O8oL1P065336; Mon, 24 Apr 2017 08:50:21 GMT (envelope-from danfe@FreeBSD.org) Received: (from danfe@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id v3O8oLTE065335; Mon, 24 Apr 2017 08:50:21 GMT (envelope-from danfe@FreeBSD.org) Message-Id: <201704240850.v3O8oLTE065335@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: danfe set sender to danfe@FreeBSD.org using -f From: Alexey Dokuchaev Date: Mon, 24 Apr 2017 08:50:21 +0000 (UTC) To: ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org Subject: svn commit: r439270 - head/databases/libcouchbase/files X-SVN-Group: ports-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-ports-all@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for the ports tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 08:50:22 -0000 Author: danfe Date: Mon Apr 24 08:50:21 2017 New Revision: 439270 URL: https://svnweb.freebsd.org/changeset/ports/439270 Log: databases/libcouchbase: tentatively attempt to unbreak parallel builds. The problem was not immediately obvious to me: after eliminating dtrace(1) output filename clash and forcibly serializing two normally concurrent in parallel mode linking stages, the problem did not go away. In fact, while the port was building seemingly fine in a single-thread (unsafe) mode, the messages "No probe sites found for declared provider" were still sometimes present in the log, as well as "target object (...) already exists. Please remove the target object and rebuild all the source objects if you wish to run the DTrace". Running dtrace(1) via truss(1) revealed something odd: it was opening the substrate object files in read-write mode! Further tests and studying its code (/usr/src/cddl/contrib/opensolaris/lib/libdtrace/common/dt_link.c; see process_obj() and dt_modtext() functions) had confirmed that it is not idempotent, and under certain circumstances would actually modify object files passed to it. Address the problem in the following ways: 1) append PID number to the output file name to reduce the chances of clash; 2) most importantly, copy the object files to a temporary location before allowing dtrace(1) to mess with them. This is rather ugly and far from robust solution; however, even that the port does not break in single-thread build mode for some reason, dtrace(1) rightfully generates errors (ir)regardless. Ultimately, I'd rather see dtrace(1) fixed properly instead so this work-around could be dropped. Added: head/databases/libcouchbase/files/patch-cmake_dtrace-instr-link.pl (contents, props changed) Added: head/databases/libcouchbase/files/patch-cmake_dtrace-instr-link.pl ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ head/databases/libcouchbase/files/patch-cmake_dtrace-instr-link.pl Mon Apr 24 08:50:21 2017 (r439270) @@ -0,0 +1,51 @@ +--- cmake/dtrace-instr-link.pl.orig 2016-08-05 21:38:44 UTC ++++ cmake/dtrace-instr-link.pl +@@ -3,7 +3,7 @@ use strict; + use warnings; + use Digest::MD5 qw(md5_hex); + +-my $HDR = "** $0:"; ++my $HDR = "** $0 ($$):"; + $\="\n"; + + my $DT_SRC = shift @ARGV; +@@ -16,23 +16,36 @@ if (!scalar @O_FILES) { + exec($CMD,@ARGV); + } + ++# Copy .o files to a temporary location before DTrace messes with them ++chomp(my $tmpdir = `mktemp -d -t $$`); ++if (system("tar cf - @O_FILES | tar xf - -C $tmpdir") != 0) { ++ system("rm -rf $tmpdir"); ++ exit(1); ++} ++ + my $ss = join('_', @O_FILES); + my $hexstr = md5_hex($ss); + +-my $INSTRUMENTED = "generated/probes_${hexstr}.o"; ++# From now, we work with files in the temporary location, update @ARGV ++map { $_ =~ s,.+\.o$,$tmpdir/$&, } @ARGV; ++ ++my $INSTRUMENTED = "generated/probes_${hexstr}_$$.o"; + # Run DTrace instrumentation. Assuming running from build directory: + my @args = ( + 'dtrace', '-C', '-G', + '-s', $DT_SRC, + '-o', $INSTRUMENTED, +- @O_FILES); ++ grep { $_ =~ /\.o$/ } @ARGV); + + print "$HDR: Creating instrumented DTrace object: @args"; + if (system(@args) != 0) { ++ system("rm -rf $tmpdir"); + exit(1); + } + + unshift @ARGV, $CMD; + push @ARGV, $INSTRUMENTED; + print "$HDR: Linking with instrumented DTrace object: @ARGV"; +-exit(system(@ARGV)); ++my $rc = system(@ARGV); ++system("rm -rf $tmpdir"); ++exit($rc);