[ewg] libibverbs not compiling against RHEL6.6

[Doug Ledford]

On 05/16/2016 12:36 PM, Steve Wise wrote:
> 
> 
>> -----Original Message-----
>> From: Doug Ledford [mailto:dledford at redhat.com]
>> Sent: Monday, May 16, 2016 11:27 AM
>> To: Steve Wise; ewg at lists.openfabrics.org
>> Subject: Re: libibverbs not compiling against RHEL6.6
>>
>> On 05/16/2016 12:09 PM, Steve Wise wrote:
>>> See: http://bugs.openfabrics.org/bugzilla/show_bug.cgi?id=2598
>>>
>>> Looks like some compilation problem against RHEL6.6.  Who should own
>>> this?  It is assigned to Doug Ledford, but I'm not sure he's the correct
>>> person?
>>
>> I'm not, but I can tell you what the problem is.  Upstream versions of
>> multiple packages like to instill rpath settings in libraries so they
>> can have both devel and production libraries on the same box.  The
>> problem is that rpath can cause unexpected behaviors.  Things like
>> Distro X releases security update to library A used by app M.  But,
>> because app M uses rpath to find it's library as library B, the update
>> has no effect.  The user thinks they are secure, when in fact, they are
>> not.  So, in general rpath laden libraries and applications are
>> considered a strong security risk by distros as they can silently
>> prevent security updates from taking effect.  For this reason, the Red
>> Hat packaged version of rpmbuild includes checks for rpath and throws
>> errors when it is found.  You either have to turn that security check
>> off in rpm, or you have to modify the libibverbs package not to use
>> rpath in its final files.
>>
>> Here's a couple options to solve the issue.
>>
>> In the %build section of the rpm spec file:
>> 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
>> make %{?_smp_mflags} CFLAGS="$CFLAGS -fno-strict-aliasing"
>>
>> In the %install section of the rpm spec file:
>> # kill rpaths
>> chrpath -d %{buildroot}%{_bindir}/*
>>
> 
> Thanks Doug.  So this would be a change to the spec.in file included in the libibverbs package?  

No.  You should have your own spec file for building packages.  The spec
file in the rpm itself is a good starting point, but it generally should
be modified to suit the particular OS you are building on.  We (meaning
Red Hat) keep our spec files separate from our tarballs and build our
packages from the combination.  OFED should do the same thing.
Otherwise you run into issues like this and rebuilding an upstream
release to solve an OFED build issue doesn't make much sense.

-- 
Doug Ledford <dledford at redhat.com>
              GPG KeyID: 0E572FDD


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 884 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openfabrics.org/pipermail/ewg/attachments/20160516/e1902a5f/attachment.sig>