From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd44.google.com (mail-io1-xd44.google.com [IPv6:2607:f8b0:4864:20::d44]) by sourceware.org (Postfix) with ESMTPS id ECA653840C0D for ; Fri, 29 May 2020 17:23:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org ECA653840C0D Received: by mail-io1-xd44.google.com with SMTP id h10so128268iob.10 for ; Fri, 29 May 2020 10:23:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oG4BUdr8Dn6cpjmXU59ONZOqLWLjFNQbv2/rchi+LNU=; b=NmNYWme7MM0ETM6ng5i3MVnzteWk8gOamKKZR04gJa4S14rXHZD0tNotumW/hg9lyu zwxzTkHcqxkHaz9mtgheVtuU6TsR4f0LYMlWr9JDZ9EENBJgqzP5IjdKjcdiJJUDZAN5 iDgdUYlC+Cu2v6kK6sFQgyq4WWJFz8uG8MO6jLaOhbt6nOfEwPd7nugPF+nG1cetxxTK sPjSYSxwSxvMXH6PoRZBPfS907HAiU6giHBiAw1nfmno4hT6vfh4Af2OdbCacydn9d9L woyZE1IvVv29RYhRNOWbgonVQAsg7+rqeHQhD50rgIS8Bj3MR+6M+bAvUVz7gv7xKtb9 1IcA== X-Gm-Message-State: AOAM533FCEI1EvGscKZpm7HU9ooP7UL38aPKa+IJWpICdzGVWWB17Ys4 AUZ8IPypdNQ0GVfp+Tz9i12IyfKvMuwDpE/u5FQ= X-Google-Smtp-Source: ABdhPJx6JSAm4+iiFWmmfIJLx8tA1anccqDLrYtoEVvJ8XpYWSplYV/i6pGl/36qr7n56DAsIjRr37Gc2hu8jigag/8= X-Received: by 2002:a6b:c9cd:: with SMTP id z196mr7590490iof.172.1590772994402; Fri, 29 May 2020 10:23:14 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jonathan Wakely Date: Fri, 29 May 2020 18:23:03 +0100 Message-ID: Subject: Re: multiple installed versions of gcc -- automatically set rpath ?? To: Patrick Herbst Cc: gcc-help Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-help@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-help mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2020 17:23:16 -0000 On Fri, 29 May 2020 at 12:33, Jonathan Wakely wrote: > > On Fri, 29 May 2020 at 04:37, Patrick Herbst via Gcc-help > wrote: > > > > I have the base gcc that came with my distro and i'd like to have the > > option of using a newer version without replacing the older one. > > > > I'd like to install the newer version in a different path, like /opt. > > > > I run into a problem though when compiling with the newer version in > > /opt, it links against the libstdc++ in /opt, but at runtime the > > executable tries to link with the systems version in /usr/lib. > > > > Is there a way to have the gcc in /opt automatically set the rpath > > when linking so that executables can run against the /opt libstdc++? > > > The simplest solution is to just use a shell script/function/alias to > invoke the new GCC and have that automatically add the -Wl,-rpath > flags. For example, I use this bash function: > > GCC () > { > local id=$1; > local version=${id%/*}; > shift; > local dir=$HOME/gcc/${version}; > local lib=lib64; > for arg in "$@"; > do > case $arg in > -m32) > lib=lib > ;; > -m64) > lib=lib64 > ;; > esac; > done; > local libdir=${id/$version/$dir\/$lib}; > local colour=-fdiagnostics-color; > if [[ $version =~ 4.[12345678] ]]; then > colour=''; > fi; > ( set -o pipefail; > LANG=C $dir/bin/g++ -Wall -Wextra -g "${@:--v}" > ${@:+-Wl,-rpath,$libdir} $colour 2>&1 | less -FR ) > } > > so that "GCC N ..." can be used to run ~/gcc/N/bin/g++ and set the > rpath to ~/gcc/N/lib64 or ~/gcc/N/lib as appropriate. Then I haveshell > aliases using that: > > g++14 is aliased to `GCC latest -std=gnu++14' > g++17 is aliased to `GCC latest -std=gnu++17' > > where ~/gcc/latest is a symlink to (currently) ~/gcc/11 > > That shell function is overkill for most people (I have nearly 100 GCC > builds under ~/gcc which is unusual!) but the general idea of a > shortcut to invoke the new compiler with the -Wl,rpath option works > well. > > > You can also use a custom specs file, as shown in the stackoverflow > link Dan Kegel gave (but ignore the answer there about > --with-boost-ldflags as that's wrong). The answer showing how to use a > specs file only works for non-multilib compilers though. If you want > to be able to link both 32-bit and 64-bit code you'll need to make the > link specs smarter, to adjust it based on the presence/absence of the > -m64 or -m32 flags. It looks like this works for the multilib case: --with-specs='%{!static:%{!m32:-Wl,-rpath,/tmp/rpathinst/lib64}%{m32:-Wl,-rpath,/tmp/rpathinst/lib}}' It assumes you know the /tmp/rpathinst prefix in advance, so isn't perfect. I'd like it to be able to find the lib and lib64 dirs relative to the installation dir.