basedir spec and plugins
thiago at kde.org
Tue Jun 30 14:11:32 PDT 2009
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-`:
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-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
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-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
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
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/xdg/attachments/20090630/f0325012/attachment.pgp
More information about the xdg