-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[build] Fixed support for --libddir under Ubuntu #7094
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,5 +1,13 @@ | ||
%global _sbindir /sbin | ||
%global _libdir /%{_lib} | ||
|
||
# Set the default libdir directory based on distribution. | ||
%if %{undefined _libdir} | ||
%if 0%{?fedora} >= 17 || 0%{?rhel} >= 7 || 0%{?centos} >= 7 | ||
%global _libdir /%{_lib} | ||
%else | ||
%global _libdir /lib | ||
%endif | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thanks for the PR! One comment. I believe you're going to have to add There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Actually, never mind. The There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, exactly, it's automatically added, so no need to add it |
||
%endif | ||
|
||
# Set the default udev directory based on distribution. | ||
%if %{undefined _udevdir} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@albundy83 so I think adding a way to override the default libdir is entirely reasonable. But it's not clear to me why this doesn't already default to the right values on Ubuntu. If you take a look at the
/usr/lib/rpm/macros
file from Ubuntu 16.04 you'll see that both_lib
and_libdir
are defined correctly for the distribution. Do you know where exactly it's getting the wrong default values from?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this, I did not even know that this file exists :)
I will check on my side.
By the way, when I saw the content of this file, it seems that
libdir
default is more/usr/lib
but according to this for exemple:https://packages.ubuntu.com/bionic/amd64/libzfs2linux/filelist
libdir
is defined in/lib
so it seems correct to leave it to/lib
no ?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Traditionally the packaging defines
_prefix
to be/
so it should default to/lib
. Incidentally, if you look down a few lines you'll also see where the%configure
macro gets defined.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, here an update about rpm macros files:
So, it should work, but when running
strace rpm --eval '%{_lib}'
, we saw (I shorten the output):And later:
And the file
/usr/lib/rpm/platform/x86_64-linux/macros
contain the following entries:So it explains why I fallback to
/lib64
by default and not/lib
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That makes sense. Then the root cause is that the
/usr/lib/rpm/platform/x86_64-linux/macros
provided by Debian/Ubuntu is incorrect and specifies the wrong install location for x86_64. Then how about thisnote: I'm presuming it's set correctly for other arches. This is primarily due to a difference in the way that Debian and Redhat respectively decided to handle the multiarch/multilib issue.
This way it should just do the right thing. One possible concern / advantage is that the updated libraries will now be correctly installed in the same location as the distribution provided ones.
@loli10K can we get your thoughts on this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is from an armhf Debian8 install:
Unless i am mistaking the contents of those platform files they seem wrong and i agree this seems a bug in Debian/Ubuntu-provided macros.
I can probably do more testing to see how the change in
zfs-build.m4
, which looks good to me, plays with "native" Debian packaging this weekend.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure that defining
lib
tolib/x86_64-linux-gnu
is the correct value, it should belib
no ?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here the way Debian package it:
https://packages.debian.org/sid/amd64/libzfs2linux/filelist
and for Ubuntu:
https://packages.ubuntu.com/bionic/amd64/libzfs2linux/filelist
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So I opted to put them in
lib/x86_64-linux-gnu
since that's where all the other shared libraries are installed. I'm not sure why they opted to put the zfs libraries underlib
, it looks to me like a mistake since they are the only ones installed there.