Hello everybody!
I have run into rpath issue when creating rpm for hwloc (you might want to check package review ticket at https://bugzilla.redhat.com/show_bug.cgi?id=606498)
rpath is added by libtool. Libraries are getting installed into /usr/lib64 but libtool does not recognize this as default library location on 64-bit system.
One solution was to add "/usr/lib64" directory into /etc/ld.so.conf.
Practical solution to get rpm was to add sed -i 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g' libtool sed -i 's|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' libtool into the %configure stage in rpm specs.
I would like to get rid of these sed lines.
For me it seems either that libtool is buggy or "/usr/lib64" directory is missing in /etc/ld.so.conf.
I (together with upstream) would highly appreciate any feedback on it.
Thanks Jirka
On 06/21/2010 04:38 PM, Jirka Hladky wrote:
Hello everybody!
I have run into rpath issue when creating rpm for hwloc (you might want to check package review ticket at https://bugzilla.redhat.com/show_bug.cgi?id=606498)
rpath is added by libtool. Libraries are getting installed into /usr/lib64 but libtool does not recognize this as default library location on 64-bit system.
One solution was to add "/usr/lib64" directory into /etc/ld.so.conf.
Practical solution to get rpm was to add sed -i 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g' libtool sed -i 's|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' libtool into the %configure stage in rpm specs.
I would like to get rid of these sed lines.
For me it seems either that libtool is buggy or "/usr/lib64" directory is missing in /etc/ld.so.conf.
I (together with upstream) would highly appreciate any feedback on it.
I think (although I admit that I am not an expert here) that if the source uses a current version of libtool, it will just DTRT. I'm guessing it was libtoolized with one of the older versions.
You might try overriding the bundled copy by passing "LIBTOOL=/usr/bin/libtool" with every make invocation, which sometimes just works. I wouldn't recommend this in practice (as you'd then have BuildRequires: libtool >= some.version), but it will give you an idea of whether I'm right or not.
More often than not, there are other necessary changes to be made to the autotooling in the sources to use the newer libtool, and I'm not the one to help you with how to make those. :/
hth,
~spot
Tom "spot" Callaway wrote, at 06/22/2010 07:20 AM +9:00:
On 06/21/2010 04:38 PM, Jirka Hladky wrote:
Hello everybody!
I have run into rpath issue when creating rpm for hwloc (you might want to check package review ticket at https://bugzilla.redhat.com/show_bug.cgi?id=606498)
rpath is added by libtool. Libraries are getting installed into /usr/lib64 but libtool does not recognize this as default library location on 64-bit system.
One solution was to add "/usr/lib64" directory into /etc/ld.so.conf.
Practical solution to get rpm was to add sed -i 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g' libtool sed -i 's|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' libtool into the %configure stage in rpm specs.
I would like to get rid of these sed lines.
For me it seems either that libtool is buggy or "/usr/lib64" directory is missing in /etc/ld.so.conf.
I (together with upstream) would highly appreciate any feedback on it.
I think (although I admit that I am not an expert here) that if the source uses a current version of libtool, it will just DTRT. I'm guessing it was libtoolized with one of the older versions.
You might try overriding the bundled copy by passing "LIBTOOL=/usr/bin/libtool" with every make invocation, which sometimes just works. I wouldn't recommend this in practice (as you'd then have BuildRequires: libtool>= some.version), but it will give you an idea of whether I'm right or not.
More often than not, there are other necessary changes to be made to the autotooling in the sources to use the newer libtool, and I'm not the one to help you with how to make those. :/
hth,
~spot
Well, actually the upstream libtool (Fedora uses 2.2.6a) does not take care of /usr/lib64 for rpath (and this seems the same for the latest 2.2.8). What I usually say is that: ---------- - Usually the reason that unneeded rpath /usr/lib64 is added to the rebuilt binary is that the upstream developer uses libtool which does not take special care of /usr/lib64 for sys_lib_dlsearch_path_spec, while Fedora's libtool take care of this by adding a patch. See the below patch:
http://cvs.fedoraproject.org/viewvc/rpms/libtool/devel/libtool-2.2.6a-rpath....
So actually for most cases, the case that rpath /usr/lib64 is added (only for 64 bits arch) can be avoided by ------------------------------------------------------------------------ sed -i.libdir_syssearch -e \ '/sys_lib_dlsearch_path_spec/s|/usr/lib |/usr/lib /usr/lib64 /lib /lib64 |' \ configure ------------------------------------------------------------------------ i.e. just add the needed paths to sys_lib_dlsearch_path_spec in configure (note that libtool in the build directory is generated by configure) before calling %configure. - You can alternatively do "autoreconf -fi", however calling autotools is not recommended unless unavoidable. ----------
So it is highly possible that if the upstream does not use Fedora (i.e. does not use patched libtool) rpath /usr/lib64 appears on Fedora. And I just confirmed that this method works for this package (hwloc).
Regards, Mamoru
On 06/22/2010 08:36 AM, Mamoru Tasaka wrote:
So it is highly possible that if the upstream does not use Fedora (i.e. does not use patched libtool) rpath /usr/lib64 appears on Fedora.
Does anybody know why that patch [1] hasn't made it into upstream libtool? It looks pretty unobtrusive to me.
It's pretty silly to have to use sed magic for almost every library which bundles libtool, when all it really takes is for upstream to pick up a small patch and wait until it has propagated to other distros.
[1] http://cvs.fedoraproject.org/viewvc/rpms/libtool/devel/libtool-2.2.6a-rpath....
On 06/22/2010 08:34 AM, Kalev Lember wrote:
On 06/22/2010 08:36 AM, Mamoru Tasaka wrote:
So it is highly possible that if the upstream does not use Fedora (i.e. does not use patched libtool) rpath /usr/lib64 appears on Fedora.
Does anybody know why that patch [1] hasn't made it into upstream libtool?
I don't know - Has anybody ever submitted it upstream?
It looks pretty unobtrusive to me.
Well, it's I have to disagree. It's more a hack but a proper solution.
Ralf
On Tuesday, June 22, 2010 07:36:01 am Mamoru Tasaka wrote:
Tom "spot" Callaway wrote, at 06/22/2010 07:20 AM +9:00:
On 06/21/2010 04:38 PM, Jirka Hladky wrote:
Hello everybody!
I have run into rpath issue when creating rpm for hwloc (you might want to check package review ticket at https://bugzilla.redhat.com/show_bug.cgi?id=606498)
rpath is added by libtool. Libraries are getting installed into /usr/lib64 but libtool does not recognize this as default library location on 64-bit system.
One solution was to add "/usr/lib64" directory into /etc/ld.so.conf.
Practical solution to get rpm was to add sed -i 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g' libtool sed -i 's|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' libtool into the %configure stage in rpm specs.
I would like to get rid of these sed lines.
For me it seems either that libtool is buggy or "/usr/lib64" directory is missing in /etc/ld.so.conf.
I (together with upstream) would highly appreciate any feedback on it.
I think (although I admit that I am not an expert here) that if the source uses a current version of libtool, it will just DTRT. I'm guessing it was libtoolized with one of the older versions.
You might try overriding the bundled copy by passing "LIBTOOL=/usr/bin/libtool" with every make invocation, which sometimes just works. I wouldn't recommend this in practice (as you'd then have BuildRequires: libtool>= some.version), but it will give you an idea of whether I'm right or not.
More often than not, there are other necessary changes to be made to the autotooling in the sources to use the newer libtool, and I'm not the one to help you with how to make those. :/
hth,
~spot
Well, actually the upstream libtool (Fedora uses 2.2.6a) does not take care of /usr/lib64 for rpath (and this seems the same for the latest 2.2.8). What I usually say is that:
- Usually the reason that unneeded rpath /usr/lib64 is added to the rebuilt binary is that the upstream developer uses libtool which does not take special care of /usr/lib64 for sys_lib_dlsearch_path_spec, while Fedora's libtool take care of this by adding a patch. See the below patch:http://cvs.fedoraproject.org/viewvc/rpms/libtool/devel/libtool-2.2.6a-rpat h.patch?content-type=text%2Fplain&view=co
So actually for most cases, the case that rpath /usr/lib64 is added (only for 64 bits arch) can be avoided by
sed -i.libdir_syssearch -e \ '/sys_lib_dlsearch_path_spec/s|/usr/lib |/usr/lib /usr/lib64 /lib /lib64 |' \ configure
i.e. just add the needed paths to sys_lib_dlsearch_path_spec in configure (note that libtool in the build directory is generated by configure) before calling %configure. - You can alternatively do "autoreconf -fi", however callingautotools is not recommended unless unavoidable.
So it is highly possible that if the upstream does not use Fedora (i.e. does not use patched libtool) rpath /usr/lib64 appears on Fedora. And I just confirmed that this method works for this package (hwloc).
Regards, Mamoru -- packaging mailing list packaging@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging
Hi Mamoru,
thanks a lot for the explanation! You are indeed right and your solution is working!
Thanks Jirka
On Tue, 22 Jun 2010 14:36:01 +0900, Mamoru Tasaka wrote:
So actually for most cases, the case that rpath /usr/lib64 is added (only for 64 bits arch) can be avoided by
sed -i.libdir_syssearch -e \ '/sys_lib_dlsearch_path_spec/s|/usr/lib |/usr/lib /usr/lib64 /lib /lib64 |' \ configure
i.e. just add the needed paths to sys_lib_dlsearch_path_spec in configure (note that libtool in the build directory is generated by configure) before calling %configure. - You can alternatively do "autoreconf -fi", however calling autotools is not recommended unless unavoidable.
To continue an old thread: is there any plan to update the current packaging guidelines?
http://fedoraproject.org/wiki/Packaging/Guidelines#Beware_of_Rpath
I've been using the DIE_RPATH_DIE hack for one of my packages, vala, for a long time, but today when working on an update for it I decided to try and get its compiler test suite working; it turns out that the only reason it's been failing all along was that the DIE_RPATH_DIE solution made it impossible to run the tests against an uninstalled copy of libvala, because, as you can guess, it requires using rpath.
Adding /usr/lib and /usr/lib64 to the bundled libtool solved the problem nicely.
Regards,
On Tuesday, June 22, 2010 12:20:40 am Tom "spot" Callaway wrote:
On 06/21/2010 04:38 PM, Jirka Hladky wrote:
Hello everybody!
I have run into rpath issue when creating rpm for hwloc (you might want to check package review ticket at https://bugzilla.redhat.com/show_bug.cgi?id=606498)
rpath is added by libtool. Libraries are getting installed into /usr/lib64 but libtool does not recognize this as default library location on 64-bit system.
One solution was to add "/usr/lib64" directory into /etc/ld.so.conf.
Practical solution to get rpm was to add sed -i 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g' libtool sed -i 's|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' libtool into the %configure stage in rpm specs.
I would like to get rid of these sed lines.
For me it seems either that libtool is buggy or "/usr/lib64" directory is missing in /etc/ld.so.conf.
I (together with upstream) would highly appreciate any feedback on it.
I think (although I admit that I am not an expert here) that if the source uses a current version of libtool, it will just DTRT. I'm guessing it was libtoolized with one of the older versions.
You might try overriding the bundled copy by passing "LIBTOOL=/usr/bin/libtool" with every make invocation, which sometimes just works. I wouldn't recommend this in practice (as you'd then have BuildRequires: libtool >= some.version), but it will give you an idea of whether I'm right or not.
More often than not, there are other necessary changes to be made to the autotooling in the sources to use the newer libtool, and I'm not the one to help you with how to make those. :/
hth,
~spot
Hi Tom,
I gave it a try ===================================================== export LIBTOOL=/usr/bin/libtool
./configure --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu -- target=x86_64-redhat-linux-gnu --program-prefix= --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec -- localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man -- infodir=/usr/share/info
$make
$chrpath utils/.libs/lstopo utils/.libs/lstopo: RPATH=/usr/lib64 =====================================================
but it didn't help.
Mamoru is right. His solution is working!
Thanks a lot! Jirka
packaging@lists.fedoraproject.org
-
Jirka Hladky -
Kalev Lember -
Mamoru Tasaka -
Michel Alexandre Salim -
Ralf Corsepius -
Tom Callaway