[Scons-users] Directing scons to link a local install of a library instead of system version

[Mats Wichmann]

On 6/4/25 09:05, Olumide via Scons-users wrote:
> Dear List,
> 
> I have an obsolete system installation of a library (yaml-cpp) on an RPM 
> Linux for which I do not have admin permissions. This library is a 
> dependency for a some custom code that I am writing for a framework 
> (gem5) that uses the scons build system.
> 
> I have downloaded, compiled and locally installed an up-to-date version 
> of the library (yaml-cpp). The problem is that I cannot convince scons 
> to use the local installed version of the library (yaml-cpp) while 
> building the (gem5) framework.
> 
> My SConscipt file contains the line
> 
> env.Append(LIBS=['yaml-cpp'])
> 
> I think this is why scons picks up the system installation of the 
> library instead of the locally-installed version.
> 
> One of the unsuccessful approaches that I have tried is
> 
> scons CPPPATH=~/.local/include/ LIBPATH=~/.local/lib64/
> 
> Where the up-to-date version of the library is installed to `~/.local`. 
> (I prefer solutions that do not require modifying the SConscript file, 
> e.g.)
> 
> The following command shows that the obsolete library is still linked.
> 
>   ldd ../gem5/build/NULL/gem5.opt
>          linux-vdso.so.1 (0x00007fff15dcf000)
>          libpython3.12.so.1.0 => /lib64/libpython3.12.so.1.0 
> (0x00007ff13f000000)
>          libz.so.1 => /lib64/libz.so.1 (0x00007ff13f895000)
>          libtcmalloc_minimal.so.4 => /lib64/libtcmalloc_minimal.so.4 
> (0x00007ff13f6b8000)
>          libprotobuf.so.25 => /lib64/libprotobuf.so.25 (0x00007ff13ec00000)
>          libhdf5.so.200 => /lib64/libhdf5.so.200 (0x00007ff13e800000)
>          libhdf5_cpp.so.200 => /lib64/libhdf5_cpp.so.200 
> (0x00007ff13ef87000)
>          libyaml-cpp.so.0.6 => /lib64/libyaml-cpp.so.0.6 
> (0x00007ff13e7b0000)  <--- OBSOLETE LIB
>          libpng16.so.16 => /lib64/libpng16.so.16 (0x00007ff13e779000)
>          libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007ff13e400000)
>          libm.so.6 => /lib64/libm.so.6 (0x00007ff13e69e000)
>          libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007ff13ef6c000)
>          libc.so.6 => /lib64/libc.so.6 (0x00007ff13e000000)
>          /lib64/ld-linux-x86-64.so.2 (0x00007ff13f8c4000)
>          libsz.so.2 => /lib64/libsz.so.2 (0x00007ff13ef60000)
> 
> Regards,
> 
> - Olumide
I left a comment on the Stack Overflow version of this, will say 
something similar here:

Showing a link line would be good, we can't see what it's trying to do, 
just the result.

Tricks like passing parameters on the command line work, but you do have 
to add logic in the sconscript to read those, so:

scons CPPPATH=~/.local/include/ LIBPATH=~/.local/lib64/

those two are sure to be currently ignored. You could change those names 
and do something like:

if ARGUMENTS.get('EXTRA_LIBPATH'):
     env.Prepend(LIBPATH=ARGUMENTS.get('EXTRA_LIBPATH'))

(that's just an outline, you'll probably want to think about your 
implementation a bit more).

If you're on a Linux system, you'll also need to arrange for the 
alternate library to be found at runtime, which will mean setting the 
RPATH variable.