Bug #5299
closed
waf uses a different default LIBDIR in Ubuntu 23.04 and later (lib vs. lib64)
100%
Description
In Ubuntu 23.04 and later, running sudo ./waf install will install libndn-cxx.so and libndn-cxx.pc under /usr/local/lib64 instead of /usr/local/lib as in prior Ubuntu versions. This results in things no longer working out of the box, i.e., users need to manually set LD_LIBRARY_PATH, PKG_CONFIG_PATH, etc. for ndn-cxx to be automatically detected by other packages.
Based on my preliminary investigation, the root cause can be found in the lib64() function in waflib/Utils.py:
def lib64():
"""
Guess the default ``/usr/lib`` extension for 64-bit applications
:return: '64' or ''
:rtype: string
"""
# default settings for /usr/lib
if os.sep == '/':
if platform.architecture()[0] == '64bit':
if os.path.exists('/usr/lib64') and not os.path.exists('/usr/lib32'):
return '64'
return ''
This heuristic seems somewhat fragile to me. Indeed, starting from Ubuntu 23.04, the path /usr/lib64 does exist (EDIT: this is not the key difference, see #note-2) and causes waf to set the default LIBDIR to ${PREFIX}/lib64, which in turn triggers the change in installation behavior described above.
Updated by Davide Pesavento 12 months ago
- Priority changed from High to Normal
starting from Ubuntu 23.04, the path /usr/lib64 does exist
Actually, this isn't the whole story. /usr/lib64 already exists in previous versions (Ubuntu 22.04) and even in Debian 12, but it does not seem to trigger the problematic behavior there.
The key difference turned out to be the presence/absence of /usr/lib32. For some reason, that directory does not exist on my Ubuntu 23.10 system[*], which causes lib64() to return the wrong path suffix. The directory does exist (empty) on Ubuntu 22.04 and 64-bit Debian.
I will check if the issue can be replicated on a fresh installation of 23.10.
[*] IIRC this machine was initially installed as an Ubuntu 22.04 or 22.10 desktop, and then upgraded every ~6 months to each new release (22.10 -> 23.04 -> 23.10). This issue started appearing immediately after upgrading to 23.04.
Updated by Davide Pesavento 11 months ago
- Status changed from New to In Progress
- Assignee set to Davide Pesavento
Updated by Davide Pesavento 10 months ago
- Description updated (diff)
- % Done changed from 0 to 20
This happened again on a fresh install of Debian 12 (amd64). Not sure what changed since my previous test other than using a newer image, but this time /usr/lib32 does not exist and therefore waf decided to install into /usr/local/lib64, which is not a default library search path.
I've also checked the upcoming Ubuntu 24.04 using the ubuntu/noble64 vagrant image (the official image from Canonical, even though it's just a prerelease at this point). /usr/lib64 exists, /usr/lib32 does not.
Updated by Davide Pesavento 10 months ago
- Status changed from In Progress to Closed
- % Done changed from 20 to 100
A workaround has been implemented in our CI scripts. The ndn-cxx documentation already mentions that it may be necessary to add the library installation path to ld.so.conf. I'm closing this issue for now as I'm not planning any further changes in the short term.