On 23 September 2016 at 11:42, Heiko Becker <[email protected]> wrote: > On 09/23/16 12:34, Emil Velikov wrote: >> On 23 September 2016 at 08:07, Alan Coopersmith >> <[email protected]> wrote: >>> On 09/23/16 12:05 AM, Emil Velikov wrote: >>>> >>>> On 23 September 2016 at 07:31, Julien Cristau <[email protected]> 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 _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
