basedir spec and plugins

[Thiago Macieira]

Simon McVittie wrote:
>On Tue, 30 Jun 2009 at 04:08:26 -0300, Thiago Macieira wrote:
>> We'll need an architecture key, which is composed by the host OS plus
>> at least the processor main type.
>
>Multiarch http://lackof.org/taggart/hacking/multiarch/ addresses this by
>taking the CPU and OS (or CPU and kernel+OS) from
> config.guess/config.sub, i.e.
>
>`/usr/share/misc/config.guess | cut -d - -f 1,3-`:
>> 	i386-linux
>> 	x86-64-linux
>
>i386-linux-gnu, x86_64-linux-gnu

What's the "gnu" part good for? The important thing here is the kernel ABI 
and the processor. (This is not a discussion of "Linux" vs "GNU/Linux")

Unless there's a i386-linux-uclibc that we have to consider...

>> 	ia64-linux-32le
>> 	ia64-linux-64le
>> 	ia64-linux-32be
>> 	ia64-linux-64be
>
>ia64-linux-gnu (is the word size/endianness differentiation really
> necessary, or is there one endianness and word size that, in practice,
> everyone uses? If you really need to distinguish, talk to
> config-patches at gnu.org, without which software that uses autotools
> probably won't compile for the "other" configurations anyway)

Everyone seems to use 64-bit little endian. But the kernel still has the 
ability to talk to 32-bit processes and big endian ones.

>> 	ia64-hpux-32 (subtypes g++ and aCC)
>> 	ia64-hpux-64 (subtypes g++ and aCC)
>
>Again, config.guess doesn't seem to distinguish: does nobody actually
> use one of these configurations?

In this case, they do. Both 32- and 64-bit libraries are installed in the 
HP-UXi box I have available. They are standard from HP. To make matters 
worse, the PA-RISC binaries are also installed.

I don't think config.guess needs to know the difference, since it's just a 
compiler switch away. The entire library stack is replaced by that switch 
and it's transparent to the application being compiled.

However, for our case here, we need to know the difference, because we need 
to know where to place the libraries/plugins.

And I don't think config.guess is working properly on HP-UXi. If I look at 
the /usr/local/lib where a few packages were installed, I see a 32-bit 
(only) gstreamer and a 64-bit (only) OpenSSL. The 32-bit OpenSSL is in 
/usr/local/lib/hpux32.

By the way, I've just realised pkg-config doesn't work properly either. 
This probably explains some of the faults I have been seeing...

>> 	sparc-solaris-32 (subtypes g++ and CC)
>> 	sparc-solaris-64 (subtypes g++ and CC)
>> 	sparc-linux-32
>> 	sparc-linux-64
>
>sparc-solarisN, sparc-linux-gnu, sparc64-linux-gnu.
>
>It might be worth asking the proposers of multiarch how their work
> relates to C++ compiler ABIs; in principle you could have
> sparc-solaris3-g++3 and sparc-solaris3-suncc, I suppose.

I don't think they do. Reading the webpage you posted the link to, it 
looks like they're only looking at solving the Linux/FHS problem.

I don't think they're interested more "exotic Unix" flavours or C++ ABI 
issues.

We can argue as well that we don't want to solve that problem either. If 
it works for the free operating systems (where GCC seems to be the rule), 
we can be happy.

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/xdg/attachments/20090630/f0325012/attachment.pgp