GNOME Bugzilla – Bug 709238
jhbuild needs help working out whether to use lib64 or lib by default
Last modified: 2021-05-17 15:58:33 UTC
defaults.jhbuilrc has this comment to explain problem: # whether to install to lib64 directories? Currently this will default to # True on Linux AMD64, PPC64 or S390x systems, and False everywhere else. # Patches accepted to fix the default for other architectures.
Created attachment 256228 [details] [review] test which libraries to use The previous test only worked on certain archs this one should be a more reliable way to determine whether to use lib64 or not Bug https://bugzilla.gnome.org/show_bug.cgi?id=709237
The previous code had a check, that worked on mentioned architectures; it is replaced by, nothing? Is your patch missing some part? The addpath() part shouldn't happen in the config file, and the system pkg-config is supposed to look in his directories, so that shouldn't be needed. (The mentioned bug number is wrong)
Created attachment 256247 [details] [review] Determine whether to use lib64 via processor The previous test only worked for certain linux archs. Get information from processor instead Bug https://bugzilla.gnome.org/show_bug.cgi?id=709237
Created attachment 256248 [details] [review] Determine whether to use lib64 via processor
Review of attachment 256228 [details] [review]: Hi, You're replacing code that *sets* use_lib64 with code that merely *reads* use_lib64? How can that work? Is there another patch I'm missing?
Review of attachment 256248 [details] [review]: Hmm, this will affect Windows too now. And why did you drop ppc64/s390x from the list? Note x86_64 doesn't mean "64 bit". Can you explain to me what problem you're solving? Like...did you personally hit an issue? Did someone else you know have a problem?
The platform.processor() tells you the capability of the processor of the machine so it shouldn't matter what os is installed. However, I have no way to test this on a windows/mac at the moment. It's possible to see '64bit' from using platform.architecture() so I am looking at trying to extract that information for this test. e.g. my machine prints ('64bit', 'ELF') Anyway I think this is closer to solving the problem. The problem being: not all computers are running linux, I guess. To be honest, I never really looked at what that code was doing until today and I had just assumed that it was trying to find out what libraries to read from. I had not realised it was setting the value for anything but I know there is a way to do it with the platform library just from looking ( at http://hg.python.org/cpython/file/2.7/Lib/platform.py ). I am just not sure exactly how yet. I am finding hard to believe an addpath() is not needed but if that is true it would be great. I will try it without and see if anything breaks.
(In reply to comment #7) > Anyway I think this is closer to solving the problem. The problem being: not > all computers are running linux, I guess. Well, the archs that are not known will just default to /lib/, and that shouldn't be a problem (I set use_lib64 to False even on my 64bits system, and that works fine). > I am finding hard to believe an addpath() is not needed but if that is true it > would be great. I will try it without and see if anything breaks. From the pkg-config manpage: PKG_CONFIG_PATH A colon-separated (on Windows, semicolon-separated) list of directories to search for .pc files. The default directory will always be searched after searching the path; the default is libdir/pkgconfig:datadir/pkgconfig where libdir is the libdir for pkg-config and datadir is the datadir for pkg-config when it was installed. Seriously, I don't think there's anything to fix here. (unless you wan people building GNOME on arm64 systems to have their jhbuild use /lib64/ by default.)
(In reply to comment #8) > (In reply to comment #7) > > Anyway I think this is closer to solving the problem. The problem being: not > > all computers are running linux, I guess. > > Well, the archs that are not known will just default to /lib/, and that > shouldn't be a problem (I set use_lib64 to False even on my 64bits system, and > that works fine). > > > I am finding hard to believe an addpath() is not needed but if that is true it > > would be great. I will try it without and see if anything breaks. > > From the pkg-config manpage: > > PKG_CONFIG_PATH > A colon-separated (on Windows, semicolon-separated) list of > directories to search for .pc files. > The default directory will always be searched after > searching the path; the default is > libdir/pkgconfig:datadir/pkgconfig where libdir is the libdir for > pkg-config and datadir is the > datadir for pkg-config when it was installed. > > > Seriously, I don't think there's anything to fix here. (unless you wan people > building GNOME on arm64 systems to have their jhbuild use /lib64/ by default.) I have given this some thought and checked my own system with: $ set | grep libdir This turned up $ libdir=/usr/lib On my desktop it doesn't seem to have been set which is curious. If there is no problem, why set use_lib64 at all? Why did someone think to put it there if it is not useful for 64bit architectures... Or something?
Well, it dates back, a long time ago… (git log -S use_lib64), on February 5th 2004 James Henstridge merged his jhbuild-ng branch (that's recorded in commit 7b5f7d). In its embedded ChangeLog, we can read: + * jhbuild/modtypes/tarball.py (Tarball.do_configure): honour + use_lib64 setting. + * jhbuild/commands/bootstrap.py (do_bootstrap): move bootstrap + code into commands subpackage. + (Bootstrap.build): if use_lib64 is true, pass --libdir when + configuring bootstrap packages. + * jhbuild/modtypes/base.py (CVSModule.do_configure): if use_lib64 + is set, then pass --libdir when configuring the package. But it doesn't point to a rationale, so we have to guess here. Probably it was done to mimick what was being done for system libraries, maybe with some perspectives for a bi-arch jhbuild? Anyway it could certainly be removed now, but that would leave existing users with a problem, as new modules would get installed into their lib/ directory, and not next to the previously installed modules, sitting in lib64/.
(In reply to comment #10) > > Anyway it could certainly be removed now, but that would leave existing users > with a problem, as new modules would get installed into their lib/ directory, > and not next to the previously installed modules, sitting in lib64/. Things break if you use lib/ in the jhbuild root on /usr/lib64 systems. I forget exactly what, sorry...I wish I could be more specific.
What I do wonder is why the use_lib64 default can't just be a matter of: return os.access('/lib64', os.X_OK) There are some interesting questions here around the much more recent Debian multiarch stuff. Should we try to mirror that in the jhbuild root too? Right now they get lib64 in the jhbuild root which seems odd.
> return os.access('/lib64', os.X_OK) I thought about it but it wouldn't work the expected way for someone running jhbuild via the linux32 utility. $ python -c 'import os; print os.uname()[-1]' x86_64 $ linux32 python -c 'import os; print os.uname()[-1]' i686 (I know I once had a buildbot using linux32). > There are some interesting questions here around the much more recent Debian > multiarch stuff. Should we try to mirror that in the jhbuild root too? Right > now they get lib64 in the jhbuild root which seems odd. There are other things that makes the jhbuild root different than the system layout on Debian (for example Debian doesn't have libexec), I'd keep it that way, this avoids breaking all those jhbuild installs for little worth.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/jhbuild/-/issues/184.