[OPEN-ILS-DEV] Packaging Update

[Ben Webb]

On 7 July 2011 21:38, Dan Scott <dan at coffeecode.net> wrote:
> On Sun, Jul 3, 2011 at 1:32 PM, Ben Webb <bjwebb67 at googlemail.com> wrote:
> <snip>
>> The issue with the build process that I'm currently trying to tackle
>> is that of rpath. Distributions, fedora especially[5], frown upon the
>> usage of rpath hardcoded library paths (to the point of build tools
>> refusing to build packages). However, by default Evergreen and OpenSRF
>> use these rather heavily for their own libraries. Is this a concious
>> decision that has been made, or just something autotools defaults to?
>> Whereabouts in the build process does this get decided? Currently for
>> fedora I am manually replacing rpath with ld.so.conf.d after build,
>> but it would be nicer to do it 'right' during the build process.
>
> On this matter, I think it's primarily because that's a default of
> autotools (see http://sourceware.org/autobook/autobook/autobook_88.html
> for the autotools counter argument). If you have the time to teach
> autotools not to add rpath in the first place, and can confirm that
> the non-rpath'ed approach works, please go for it; packaging needs
> should trump autotools conventions, methinks. There's always "chrpath
> -d" if all else fails.

I couldn't see any obvious way of disabling it nicely through
autotools, so I tried patching libtool as suggested by some of the
fedora documentation. For the most part (ie. everything but the apache
modules) this is successful in removing the rpath links. However only
some parts of the opensrf codebase seem to use the dynamic ld
information correctly, and starting the c modules fails. Until I work
out how to have these loaded properly dynamically, I will return the
fedora packages to using rpath. Apparently it is somewhat acceptable
to have packes using rpath internally, but since evergreen-ils and
opensrf are two seperate packages, I feel this only partially applies.

Regards,
Ben