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

[Olumide]

The "primary" SConstruct file, https://github.com/gem5/gem5/blob/stable/ 
references/uses CCFLAGS and LINKFLAGS which I have tried to set as follows

scons CCFLAGS="-I/home/me/.local/install/include/" 
LINKFLAGS="-L/home/me/.local/install/lib64/" 
EXTRAS=/home/me/repos/project ...

Where my SConstruct file is in the EXTRAS directory.

However the linker error "/usr/bin/ld: cannot find -lyaml-cpp" persists.

 > ... You could change those names and do something like:
 >
 > if ARGUMENTS.get('EXTRA_LIBPATH'):
 >      env.Prepend(LIBPATH=ARGUMENTS.get('EXTRA_LIBPATH'))

Do you mean I should change LIBPATH to EXTRA_LIBPATH on the command line 
and add those two lines to my SConscript file?

- Olumide


On 04/06/2025 17:24, Mats Wichmann wrote:
> 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.
> 
> 
>