Closed brettviren closed 2 months ago
Oops, --libdir
is special to waf
already which results in library installs going to a "double absolute" path. One can already force a lib dir name with --libdir
. What is needed is to force lib/
by default unless user uses --libdir
.
Hi @brettviren, my observations on this:
1, previously the default was lib64
on sl7 container and gpvm
2, the ups building script seems to be able to largely adapt to both: https://cdcvs.fnal.gov/redmine/projects/build-framework/repository/wirecell-ssi-build/revisions/master/entry/ups/wirecell.table#L180
Also I have a question: with https://github.com/WireCell/wire-cell-toolkit/commit/313ec048a090e2fb4228a95b2a9ff159b9f7ce4b, the default is now "lib", right? Do we want to propagate this to the ups system?
@HaiwangYu Yes, the default is to install libs into lib/
. If UPS is okay with that, I suggest letting it use that default. If there is a problem a non-standard location can be set with --libdir
.
In some cases a
./wcb install
places libraries inand in others in
I would expect always the former and never the latter but in any case, I'd expect the same behavior on the same OS. However, we see some hosts installing in one and others in the other.
The issue appears to be ultimately due to Waf's
Util.lib64()
function. On 64bitplatform.architecture
, it will return"64"
if/usr/lib64
exists but/usr/lib32
does not. Otherwise, it returns""
.What is "right"?
FHS 3.0 says
/lib
holds libraries needed to boot./lib<qual>
MAY be an architecture variant.Debian supports "multi arch" which is not a simple dichotomy of 32 vs 64 bits. It uses a trio like
x86_64-linux-gnu
to distinguish. It supplies a/lib64
that contains only a single symlink to the dynamic loader in order to satisfy some ABI standard. Debian also implemented a "merged-/usr" feature which combines all common directories in/
and/usr
into/usr
and thus/lib64
is now seen as a symlink to/usr/lib64
. Then, some packages, eglibc6-i386
populate/usr/lib32
.Redhat likes to use
lib64/
and has used it traditionally in their attempt to support merely a 32 and 64 bit dichotomy. I don't find must info outside of their paywalled docs.All in all it seems
Util.lib64()
makes a bad guess.It would be good to control this in WCT.
Apparently, this can be forced with something like the following in a
wscript
:Perhaps added along with a command line option to set it to something else.