From owner-freebsd-ports@FreeBSD.ORG Mon Sep 21 06:59:38 2009 Return-Path: Delivered-To: freebsd-ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9FCE1065676 for ; Mon, 21 Sep 2009 06:59:38 +0000 (UTC) (envelope-from bf1783@googlemail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by mx1.freebsd.org (Postfix) with ESMTP id 3BA618FC0A for ; Mon, 21 Sep 2009 06:59:37 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id 4so701691eyf.9 for ; Sun, 20 Sep 2009 23:59:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=tYDvpRBlEgSxbaG8MdVrncTecDKQIFoJmxps/yNx2nQ=; b=b3fABNqYc05jqNe2jmzoKp9cRpM5fq+MlDRHU5jLxXVqN7uGXsWynFeXImmFFBsiZo AE5jhpcC9CCttjMXEKY1PlwZxW586+yIQi7UIkvZBzQJtArDVBV53iCK8CcxtA84X1OT IzSp93n2FiIWU3oDXVPkc4sL5k/JgmYukkI64= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=dPaYg5ksdjFw9i8wqBeN4GOuW2LdLHN2WHIWX/twqm/JCTVovXEPswB2eTioIOv/Ix 9cLRdN73wiHEEQPSUHebI4Ev5df6e6PwzwwKO0hQIbFbwF+DJevSGlg6neUlFN/qzEQj 0WKUD+Cdahvqs1tadxQ8yhP5rQi8oE9XsW/Jk= MIME-Version: 1.0 Received: by 10.216.7.210 with SMTP id 60mr1133464wep.126.1253516377135; Sun, 20 Sep 2009 23:59:37 -0700 (PDT) Date: Mon, 21 Sep 2009 06:59:37 +0000 Message-ID: From: "b. f." To: freebsd-ports@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1 Cc: gerald@pfeifer.com Subject: Re: Need to use some library path before /usr/lib X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 06:59:38 -0000 Gerald Pfeifer wrote: >On Thu, 17 Sep 2009, Jason J. Hellenthal wrote: >> Something like the following. >> >> [/usr/local/bin/] >> libstdc++.so /usr/local/lib/gcc44/libstdc++.so >> libstdc++.so.6 /usr/local/lib/gcc44/libstdc++.so.6 > >That looks quite nice, and I was going to use that, alas I cannot >seem to make it work. Is it possible that libmap.conf does not work >when the name on the left-hand side is the same as on the right-hand >side? It must be an exact (i.e., per-binary file) constraint, unless we enforce the requirement that all ports that have binaries in the directory are compiled with the same compiler. There is no way that I can see to do this in the current Ports framework without separate PREFIXes and LOCALBASEes, which would result in undesired redundancies. And I don't think that all ports respect non-default PREFIXes and LOCALBASEes, although there is ongoing work in this direction. However, if exact constraints are used throughout this file, I wonder if performance will suffer as the size of libmap.conf grows much larger. I suspect the answer to this problem does not involve libmap.conf, at least in it's current form. One of the advantages of the current Ports framework is that, within limits, different compilers may be used for different ports. I don't think that users want to give up the ability to define CC. Even if they did, we're still stuck with shared objects from the base system that depend upon the libraries of the base system compiler. (As an aside, NetBSD just brought the latest binutils into their base system, and DragonFly has imported gcc 4.4. Why is it that these projects, that have similar licensing goals, have made a pragmatic choice to use select GPLv3 code, at least until BSD-licensed equivalents are available, and we haven't?) > >> Now for a port running (octave as example) have that port spam libmap.conf >> with the proper configuration for just that port the same way perl does to >> make.conf. > >That might work, though it looks like a lot of work. It occurs to me >we really need to set this globally. See above. >That is one of the implications >those that always pushed for having ports use a distinct compiler may >have missed. That, or using -rpath. > >Loren, how would we best have GCC automatically add > -rpath=/usr/local/lib/gcc44 >to every invocation? Presumably spec magic? Probably, because not every port uses or respects LDFLAGS and CFLAGS. (Some of them don't even respect CC.) But what about those ports that invoke the linker directly, not through the compiler? There will have to be a big LDFLAGS cleanup. Also, will changing -rpath be sufficient? I doubt it: we may have to clean up linking statements in ports, and probably rename some libraries, so that no objects are linked that in turn require different and incompatible shared libraries with the same name. (In that sense, this thread is probably misnamed.) b.