Re: Use of lang/gcc*'s g++* via the likes of USE_GCC=11:build+ in ports when a -Wl,-rpath=/usr/local/lib/gcc* is required: How?

On Sun, Apr 17, 2022 at 07:21:11PM -0700, Mark Millard wrote:
> I'll use g++11 as an example here. By no means is the issue
> limited to g++11 . Also, the general issue is not limited
> to the specifics of the other aspects of the example I report
> below.
> 
> 
> EXAMPLE PROBLEM:
> 
> FreeBSD's /lib/libgcc_s.so.1 is insufficient for what aarch64
> g++11 code generation expects to be provided. Programs can be
> built but end up with notices that start with:
> 
> ld-elf.so.1: /lib/libgcc_s.so.1: version GCC_4.5.0 required by
> . . . not found
> 
> Sometimes the ". . ." is /usr/local/lib/gcc11/libstdc++.so.6 .
> Other times it does not get that far because the program
> itself has the issue before shared libraries are bound. A
> simple 6 line program on aarch64 can show the issue:
> 

You're best bet is to have small shell scripts.  For gfortran
testing with it built in my home directory, I have

% cat ~/bin/gfcx 
#! /bin/sh
DIR=`id -P kargl | sed 's/\:/\ /g' | awk '{print $9}'`
export DIR

LD_LIBRARY_PATH=$DIR/work/lib
export LD_LIBRARY_PATH

LD_RUN_PATH=$DIR/work/lib
export LD_RUN_PATH

$DIR/work/bin/gfortran -fno-backtrace $@


You'll need to figure out how to get the build to use your 
scripts.

PS:  When clang/llvm was imported into FreeBSD, /lib/libgcc_s.so.1
should have been renamed to libllvm_s_so.1.  Usurping a well-known
name from a well-known open-source compiler is simply stupid.
-- 
Steve