pkg-config and rpm relocations

[Dan Nicholson]

On Mon, Apr 5, 2010 at 5:37 PM, Kevin Fox <Kevin.Fox at pnl.gov> wrote:
> On Mon, 2010-04-05 at 12:16 -0700, Tollef Fog Heen wrote:
>> ]] Kevin Fox
>>
>> | Option 1, I can just fix up the .pc file in the postinstall rpm hook.
>> | This would work but feels a bit unclean.
>>
>> This would break the checksums that RPM stores and so rpm -V would fail,
>> would it not?
>
> Thats the biggest reason I dislike that idea. It breaks things.
>
>> | Option 2, pkg-config seems to already have some prefix relocation code
>> | in it but its only enabled in Windows. Is there a reason for this?
>> | Would it be acceptable to enable this on linux to follow the RPM
>> | relocation semantics? They are slightly different then whats there
>> | now, but wouldn't be hard to implement. I could probably whip up a
>> | patch for this if someone is interested.
>>
>> I am not yet convinced about relocatable shared libraries being useful
>> and am quite wary of enabling any support for relocating
>> libraries. Rebuilding is usually less work and doesn't cause weird
>> errors.
>
> Its a chicken and the egg problem. Its hard to get shared libraries
> relocatable because the build system gets in the way. The build system
> guys don't want to make the build system handle it well because few
> shared library properly support it.
>
> I am trying to convince some of my coworkers to switch to using
> pkg-config for their current libraries. They have a requirement that
> their libraries are relocatable currently, so they do work already. If I
> can't fix pkg-config, or at least work around it using option 1, then
> the number of users using pkg-config won't grow. I'm willing to submit a
> patch to add the functionality, but I don't want to do so if it wont be
> accepted.
>
>> Please note that I'm not disputing that you can, in some cases, relocate
>> libraries, but you can't always.
>
> This is true. That is why RPM's by default are not relocatable unless
> you tell RPM explicitly in the spec file that the RPM is safe to
> relocate. In my case though, I have relocatable ones I want to support.
>
>> I guess an option might be to allow it with a flag in the .pc file, but
>> again, I'm not convinced relocation is something we necessarily want to
>> support.
>>
>
> So the way relocation is handled in RPM is that you have something like:
> /prefix/lib/libfoo
> /prefix/bin/bar
> /etc/foo.conf
>
> The prefix variable in the rpm is assigned prefix=/prefix.
>
> If you do not relocate, the file tree is as listed above. If you do
> change prefix, /prefix is stripped from the list, making:
> /lib/libfoo
> /bin/bar
> /etc/foo.conf
>
> and then the new prefix is prepended making the final install tree:
> /opt/myrelocation/lib/libfoo
> /opt/myrelocation/bin/bar
> /opt/myrelocation/etc/foo.conf
>
> I think, how I would approach this would be to come up with two new
> variables:
> relocatableroot=/
> relocatableprefix=/usr
>
> If these exist, then the package is relocatable, it should follow the
> RPM semantics. Check to see if the pkgconfig file is relative to the
> relocatableprefix. If it is not, then change relocatableroot to point to
> the correct place, and set relocatableprefix = "". This would
> automatically set any other variable properly that uses those two
> variables. It is fairly simple to write, and leaves it up to people
> writing .pc files to make sure they are relocatable.
>
> How would something like that sound?

You can already do that today just by setting the variables in your
.pc file appropriately.

foo.pc:
relocatableprefix=
prefix=${relocatableprefix}/usr
exec_prefix=${prefix}
includedir=${prefix}/include
libdir=${exec_prefix}/lib

Cflags: -I${includedir}
Libs.private: -L${libdir} -lfoo

In fact, you can probably fake it today with most .pc files just by
using "pkg-config --define-variable=prefix=$relocatableprefix".

$ pkg-config --define-variable=prefix=/foo --libs libssl
-L/foo/lib64 -lssl -lcrypto -ldl -lz

--
Dan