Libraries installed at wrong place about mhvtl

[gonzoleeman]

Mark, it's not you. :)

The code to detect whether or not /usr/lib or /usr/lib64 should be used is flawed. It checks for "lib64$" in /etc/ld.so.conf or /etc/ld.so.d/*.conf. But that's not right. On my openSUSE Leap 15 system, the only "lib64" at the end of a line is "/usr/local/lib64". Here's the whole file /etc/ld.so.conf:

/usr/local/lib64
/usr/local/lib
include /etc/ld.so.conf.d/*.conf
# /lib64, /lib, /usr/lib64 and /usr/lib gets added
# automatically by ldconfig after parsing this file.
# So, they do not need to be listed.

So "lib64" doesn't even have to be in /etc/ld.so.conf for a system to use /lib64 and /usr/lib64.

Perhaps a better way to detect if "/usr/lib64" should be the installation destination is to check the output of "ldconfig -p"? For example: "ldconfig -p | fgrep -q /usr/lib64"?

What do you think @markh794

[gonzoleeman]

First note: you can work around this, when building/installing, by setting LIBDIR=/usr/lib64 on the "make" command line.

I'm investigating how the different distros handle this (using a subset, of course), and I have two version of Ubuntu, and they are quite strange, with regard to 64-bit library locations.In Ubuntu 16.04, there is a /lib64 with just one library in it, and no /usr/lib64. And no mention of /lib64 in /etc/ld.so.conf*. Instead, they use /usr/lib/x86_64-linux-gnu and /lib/x86_64-linux-gnu! Bizarre. And it looks like 18.10 is the same.

Looking at CentOS 7.6, I see there is a /usr/lib64, and a /lib64 which is symlink to /usr/lib64. The only "lib64" I see in /etc/ld.so.conf* is "/usr/lib64/libmysql"! And if I grep the output of "ldconfig -p" for "/usr/lib64", again, the only one I see is for libmysql! But if I grep for "lib64", there are ton of them.

My conclusion: it is very hard to make a build system that is going to work on every distribution, partly because there is no standard location for libraries, and there is no standard way to find out where this particular Linux (whatever it is) names such directories if they use them at all. :(

Note that as a person that supports lots of packages for a living, this is true of many packages. That's generally why the "%build" target in RPM SPEC files general does more than just "make".

Of course @markh794 owns the package so can approach this however he wishes, but as to your original question @sviscapi , I'd suggest just passing in "LIBDIR" in your case.

[haniffm]

@sviscapi I've tested the currently latest commit in vagrant with centos7.6 which seems to work fine. I've created a PR here: #45