[PATCH xbitmaps] Install pkgconfig file into arch-dependent location

[Emil Velikov]

On 23 September 2016 at 11:42, Heiko Becker <heirecka at exherbo.org> wrote:
> On 09/23/16 12:34, Emil Velikov wrote:
>> On 23 September 2016 at 08:07, Alan Coopersmith
>> <alan.coopersmith at oracle.com> wrote:
>>> On 09/23/16 12:05 AM, Emil Velikov wrote:
>>>>
>>>> On 23 September 2016 at 07:31, Julien Cristau <jcristau at debian.org> wrote:
>>>>>
>>>>> On Thu, Sep 22, 2016 at 19:12:13 +0200, Heiko Becker wrote:
>>>>>
>>>>> That seems like it's going backwards, and your commit message doesn't
>>>>> explain why.
>>>>>
>>>> That was my initial thought as well (going backwards). Then again,
>>>> as-is the .pc file is located in a arch _in_ dependant location, which
>>>> causes file conflicts as you have multilib - x86-86 & x86 installed
>>>> for example. In such cases the files have different contents (path)
>>>> which leads to link time issues.
>>>
>>>
>>> How can you have link time issues when there's noting in xbitmaps to
>>> link with?   It's purely xbm files, sometimes abused as C headers.
>>>
>> Ack, you're absolutely correct. I didn't realise that the xbitmaps
>> repo doesn't ship any libraries.
>
> It doesn't, but it provides includes and the includedir gets propagated
> via pkg-config, leading to a build error on a multi-arch layout when
> cross compiling xsetroot.
>
Yes, that's correct. From my [humble] experience - every 32bit build
"clashes" with the 64bit one for everything but the
libraries/executables.

Since everything else (man pages, images, headers) should be
identical, in theory at least, there isn't anything to be concerned
about. Thus some distros do not bundle the 'duplicates' with the 32bit
package.

If things are not the identical, one ought to attempt to resolve that first.

That's my take on it, but I could be very wrong on the topic.
Emil