From owner-freebsd-ports@FreeBSD.ORG Sat Mar 29 14:27:22 2014 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 698FE5C9; Sat, 29 Mar 2014 14:27:22 +0000 (UTC) Received: from smtpout6.timeweb.ru (smtpout6.timeweb.ru [92.53.117.39]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 196AD7DF; Sat, 29 Mar 2014 14:27:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=amdmi3.ru; s=dkim; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=8RriKjKT1X7h0DWoN5b3uwOWsq3zwejHgtuyZ8W4zZA=; b=DyiC9oFhykcmEIBjMQ291G26YSTNCR/AZfIb1F2qsebtDDPQjVhv41WvnrPOn6U5mOZgXkGCTI8/Lxc6EDw438cXNmtltLoZo0xFhxzTeVQkEufF0reTzoWpfPyUqEyP8K8UcjTf8UOEvzyHq4LCrlGL65bw53xfUXzzX1+6xt0=; Received: from [213.148.20.85] (helo=hive.panopticon) by smtp.timeweb.ru with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1WTuEA-0007Ec-CB; Sat, 29 Mar 2014 18:27:18 +0400 Received: from hades.panopticon (hades.panopticon [192.168.0.32]) by hive.panopticon (Postfix) with ESMTP id DF313E7B; Sat, 29 Mar 2014 18:27:17 +0400 (MSK) Received: by hades.panopticon (Postfix, from userid 1000) id D0CE8252E9; Sat, 29 Mar 2014 18:27:17 +0400 (MSK) Date: Sat, 29 Mar 2014 18:27:17 +0400 From: Dmitry Marakasov To: Dimitry Andric Subject: Re: HEAD clang failures due to unknown arguments Message-ID: <20140329142717.GJ73879@hades.panopticon> References: <20140329044342.GG73879@hades.panopticon> <73F477CA-6AF4-4217-AC81-730A5DED11D5@FreeBSD.org> <20140329124652.GH73879@hades.panopticon> <14D047DD-EE2F-4512-BC18-518B693CCD6B@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <14D047DD-EE2F-4512-BC18-518B693CCD6B@FreeBSD.org> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Mar 2014 14:27:22 -0000 * Dimitry Andric (dim@FreeBSD.org) wrote: > > I've just removed them and it worked. Or is there a reason for rpath to > > system lib directory? > > It seems that -rpath is sometimes used gratuitously, indeed. Though it > can sometimes be necessary, if shared libraries are installed into > non-standard places, e.g. /usr/local/lib/myapp/libmyapp.so. That I know. Just wanted to make sure that it's not really needed for /usr/local/lib > Also, not all systems have had /usr/local/lib in their default dynamic > linker path. And I'm also not sure what happens if you attempt to set > $LOCALBASE to something other than /usr/local/lib. :-) > > I tried that once, and I was not really happy with the results... You should've probably just added YOUR_LOCALBASE/lib into ldconfig_paths. I've had a jail in my tinderbox which used completely custom PREFIX and LOCALBASE to catch hardcoded /usr/local's - it worked fine and built almost all software (which it hadn't I've fixed). > > What I plan to do is: > > > > --- > > USES+= compiler:env > > > > .include > > > > post-patch: > > .if ${COMPILER_TYPE} == "clang" > > @${REINPLACE_CMD} -e 's|-fwhole-program||' ${WRKSRC}/CMakeLists.txt > > .endif > > --- > > > > but what if next version of clang learns of this key? > > In this particular case, it will probably never support it. There are > many options which a very specific to gcc (mostly for its optimizer), > which make no sense for clang. Again, my question is not tied to any spedific option. If gcc had -fwhole-program and clang had -fclang-whole-program, there should be a convenient way to do this. Making upstream do conditional checks is a good thing, but if that was possible in all cases, we wouldn't have any patches in the ports tree. In real world, unfortunately, ports tree is mostly patches. > > I'd like to have > > something like > > > > .if ! ${COMPILER_SUPPORTED_ARGUMENTS:M-fwhole-program} > > @${REINPLACE_CMD} -e 's|-fwhole-program||' ${WRKSRC}/CMakeLists.txt > > .endif > > > > .if ${COMPILER_SUPPORTED_ARGUMENTS:M-malign-double} > > CXXFLAGS+= -malign-double > > .endif > > Now you are encoding the work of CMake and autoconf into the ports > infrastructure? I am not sure if that is the proper way. However, I > seem to remember there was also an effort to provide "global" autoconf > and CMake preconfiguration, maybe this type of compiler-specific > knowledge thing could be folded into that? I don't see another way. For example, -R stuff comes from libiconv and gettext: --- LTLIBICONV="${LTLIBICONV}${LTLIBICONV:+ }-R$found_dir" --- LTLIBINTL="${LTLIBINTL}${LTLIBINTL:+ }-R$found_dir" --- To fix that, first we need to fix macros containing these lines, next wait for new versions to be released, next wait for everybody to use these versions. That's years for maintained software while there's also unmaintained, and for that we need a way to deal with this in ports. So dealing with that in ports, just checking ${COMPILER_TYPE} is not future-proof, so we need something better, as I suggested. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru