[Scons-users] Force scons to use local libraries over system libraries

[暗黑聖飢魔]

Thank you guys for clarifying that the path is not specified by SCons
itself.

I just double-checked and found where that "-L*/usr/lib*" comes from in
gem5/SConstruct. The command "python-config --ldflags" is executed to obtain
the ldflags needed by python and appended to LINKFLAGS. Prepending our
library path to LINKFLAGS solves our problem.

Hsuan

Mats Wichmann <mats at wichmann.us> 於 2020年8月30日 週日 上午12:47寫道：

> On 8/29/20 8:03 AM, 暗黑聖飢魔 wrote:
> > Hi, is it possible to change the library path search order, so that
> > scons searches a specific path before the system path?
> >
> > We try to build an open source project called gem5, which uses scons as
> > its build system. We need to link gem5 with /*libz 1.2.9*/. The problem
> > is that there is already a /*/usr/lib/libz.so*/, whose version is the
> > incompatible /*1.2.8*/. Unfortunately, we don't have permission to
> > update the system libraries.
> >
> > We have already tried adding the following statement to SConstruct:
> >
> >     main.Prepend(LIBPATH=['/*/path/to/our/libz*/'])
> >
> > but in the build log, we find "/*/path/to/our/libz*/" is still searched
> > after "/*/usr/lib*/":
> ...
> >         -lpthread -lm -lpython2.7 /*-lz*/ -lrt -llz4 ...... -ldrampower
> > -lfputils -liostream3 -lelf -lfdt -lnomali -lpng
> >
> > It seems the "*//usr/lib/*" is specified by scons itself instead of
> > gem5's scons scripts. Is it possible to bring our
> > "/*/path/to/our/libz*/" before that?
>
> it doesn't come from SCons - it's probably put in by the compiler itself.
>
> One way you can solve the link-time problem is instead of giving the
> library name ('z') by itself, to give the path to the library, that way
> you bypass any lookup games: /path/to/our/libz.so.
>
> You actually have two problems to solve here: link-time resolution,
> which you're working on with the above, and run-time resolution.  It
> doesn't help much if you link against the right library version in your
> build, and then at runtime, the older version is still picked up.  If
> your run-time environment is similarly out of your control, you probably
> need to do something with rpath (read up on this in the gcc docs; scons
> has support for rpath fiddling).
>
> In this kind of scenario, where some of the environment is out of your
> control, you're actually better off switching to using a container (e.g.
> Docker), or using something like Flatpak/AppImage/etc. so you can
> actually control the environment the way you need. Those topics are a
> bit beyond the scope of this list, just giving you something to think
> about.
>
>
> _______________________________________________
> Scons-users mailing list
> Scons-users at scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20200830/9728d844/attachment-0001.html>