Re: Help with rpath issue

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 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
> --
> packaging mailing list
> packaging@xxxxxxxxxxxxxxxxxxxxxxx
> 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
--
packaging mailing list
packaging@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/packaging


[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite Forum]     [KDE Users]

  Powered by Linux