Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 515694 - sys-devel/clang: clang disagrees with gcc on default ABI in some of the mips profiles
Summary: sys-devel/clang: clang disagrees with gcc on default ABI in some of the mips ...
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Development (show other bugs)
Hardware: All Linux
: Normal critical (vote)
Assignee: MIPS Porters
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-06-29 19:52 UTC by Michał Górny
Modified: 2018-03-29 08:34 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2014-06-29 19:52:09 UTC
Long story short:

1. we pass --with-abi= to gcc to set the default ABI for compiler,

2. instead, clang has hardcoded default ABI matching CHOST: n64 for mips64* and o32 for mips*.

Of course, proper build can be forced with -mabi=. However, this makes sense only for multilib ebuilds. Non-multilib are going to use whatever CC/CXX user set, so if user sets 'clang', it may build a different ABI than 'gcc'.


Possible solutions:

1. support only profiles that have matching ABIs (I guess you don't like that),

2. change clang defaults (NeedPatch),

3. make clang choose mips ABI based on tool prefix (won't work with plain 'clang', requires changing CHOST of default ABI, NeedPatch),

4. replace all of 'clang' and '$CHOST-clang' with wrapper that add proper -mabi= (relatively easy to do yet a bit unclean, and requires adding ${ABI}_CFLAGS for each ABI).
Comment 1 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2016-10-02 07:58:39 UTC
Hmm, I missed the most useful option:

5. Fix the mips profiles to be sane.
Comment 2 Joshua Kinard gentoo-dev 2016-11-05 23:05:40 UTC
(In reply to Michał Górny from comment #1)
> Hmm, I missed the most useful option:
> 
> 5. Fix the mips profiles to be sane.

I am somewhat puzzled as to what is broken with the profiles for mips.  We're not hacking around anything.  The existing CHOST values have been that way for years.

o32: mips[el]-unknown-linux-gnu
n32: mips[el]64-unknown-linux-gnu + -mabi=n32
n64: mips[el]64-unknown-linux-gnu + -mabi=64

There's some more archaic ABIs out there, such as o64 and eabi, but we don't use them.

Purportedly, there's a newer/ish CHOST for n32 called mips[el]64-unknown-linux-gnuabin32, but no one I know of has done extensive testing of it to see which packages actually recognize it.  These are all for glibc only, too.  uclibc and musl have their own endings, and I don't think either have a dedicated n32 CHOST value like -gnuabin32.

Keep in mind we've got a pretty complex mix of variables with MIPS platforms.  IMHO, I think the bug here is with clang, as their mips support is no where near as feature-complete as gcc's.
Comment 3 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2016-11-06 00:07:38 UTC
No, the bug is that you force default ABI at compile-time of gcc, and expect everything to randomly guess what you wanted there. It's nowhere suitable for cross, and I don't really see adding another magical configuration option to workaround CHOST values that are broken by design and make ABI unpredictable.
Comment 4 Mart Raudsepp gentoo-dev 2017-03-10 17:58:08 UTC
(In reply to Michał Górny from comment #1)
> Hmm, I missed the most useful option:
> 
> 5. Fix the mips profiles to be sane.

What would we have to do for this exactly, which changes, do you know?
Comment 5 Matt Turner gentoo-dev 2017-03-10 17:59:44 UTC
(In reply to Michał Górny from comment #0)
> Long story short:
> 
> 1. we pass --with-abi= to gcc to set the default ABI for compiler,
> 
> 2. instead, clang has hardcoded default ABI matching CHOST: n64 for mips64*
> and o32 for mips*.

There's a 3rd ABI, which is the one we use primary: n32. What is the CHOST for that?

> Of course, proper build can be forced with -mabi=. However, this makes sense
> only for multilib ebuilds. Non-multilib are going to use whatever CC/CXX
> user set, so if user sets 'clang', it may build a different ABI than 'gcc'.

Right, and we set --with-abi=n32 for n32 stages.

> Possible solutions:
> 
> 1. support only profiles that have matching ABIs (I guess you don't like
> that),

Seems like that would preclude multilib?

> 2. change clang defaults (NeedPatch),
> 
> 3. make clang choose mips ABI based on tool prefix (won't work with plain
> 'clang', requires changing CHOST of default ABI, NeedPatch),
> 
> 4. replace all of 'clang' and '$CHOST-clang' with wrapper that add proper
> -mabi= (relatively easy to do yet a bit unclean, and requires adding
> ${ABI}_CFLAGS for each ABI).

These three seem like options we should consider last.

(In reply to Michał Górny from comment #1)
> Hmm, I missed the most useful option:
> 
> 5. Fix the mips profiles to be sane.

What do you mean? What do you suggest?
Comment 6 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2017-03-10 18:13:23 UTC
(In reply to Matt Turner from comment #5)
> (In reply to Michał Górny from comment #0)
> > Long story short:
> > 
> > 1. we pass --with-abi= to gcc to set the default ABI for compiler,
> > 
> > 2. instead, clang has hardcoded default ABI matching CHOST: n64 for mips64*
> > and o32 for mips*.
> 
> There's a 3rd ABI, which is the one we use primary: n32. What is the CHOST
> for that?

clang doesn't have n32 triple at the moment. I was planning to add support for it once we are able to actually use it.

> > Possible solutions:
> > 
> > 1. support only profiles that have matching ABIs (I guess you don't like
> > that),
> 
> Seems like that would preclude multilib?

Exactly the opposite. I think that by this step I meant having clang supported only on those profiles where CHOST for each ABI matches one supported for clang, i.e. CHOST_n64 == mips64*, CHOST_o32 == mips-*, CHOST_n32 == mips64-*n32. We'd effectively kill clang support on the non-multilib profiles that don't guarantee that.

> (In reply to Michał Górny from comment #1)
> > Hmm, I missed the most useful option:
> > 
> > 5. Fix the mips profiles to be sane.
> 
> What do you mean? What do you suggest?

Something along the following:

mips64/n32/make.defaults:CHOST="mips64-unknown-linux-gnu"
mipsel/mips64el/n32/make.defaults:CHOST="mips64el-unknown-linux-gnu"

->

mips64/n32/make.defaults:CHOST="mips64-unknown-linux-gnun32"
mipsel/mips64el/n32/make.defaults:CHOST="mips64el-unknown-linux-gnun32"

Note that I've only done a quick grep, so I might've missed some profile. But these two are the major offenders.

Not that I have any clue how to safely change CHOST on a profile. You'd probably have to introduce a new profile, and require explicit action from users.
Comment 7 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2017-11-29 16:44:30 UTC
Ping. Could we get this done for 17.0 profiles?
Comment 8 Sergei Trofimovich gentoo-dev 2017-12-07 22:15:22 UTC
TL;DR:
  I don't think mips profiles are in any way wrong or deviate from gcc upstream defaults.
  If you need parity then you need to agree on CHOST meaning in gcc and llvm/clang upstreams
  for both n32 (gentoo's n32) and 64 (gentoo's n64) ABIs. Both seem to mismatch.

Longer version:

This bug seems to imply that GCC being configured as
    ./configure --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=mips64-unknown-linux-gnu
targets to something other than N32 ABI. It does not.

N32 ABI is the default:
    $ ../gcc/configure --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=mips64-unknown-linux-gnu
    $ make
    $ ./gcc/xgcc -B./gcc/ -dM -E - </dev/null | fgrep ABI
    #define __GXX_ABI_VERSION 1012
    #define _MIPS_SIM _ABIN32
    #define _ABIN32 2

Upstream default comes from here:
    https://github.com/gcc-mirror/gcc/blob/master/gcc/config.gcc#L2134

Thus gcc (default=n32) and clang (default=64 as asserted by comment #1, I didn't check)
already disagree on CHOST=mips64-unknown-linux-gnu ABI meaning and it needs to be fixed
upstream(s) first.

You might notice gcc/config.gcc has no CHOST at all assigned for
    default_mips_abi=64
and no CHOST assigned for
    MIPS_ABI_DEFAULT=ABI_64

Thus if you need CHOST parity for ABI=64 you would need to propose something
to gcc (and perhaps glibc and binutils) upstream to settle on canonical
64-bit CHOST.

Here is the full list of mips ABIs gcc knows about:
    https://github.com/gcc-mirror/gcc/blob/master/gcc/config.gcc#L4613

    case ${default_mips_abi} in
        32)   tm_defines="$tm_defines MIPS_ABI_DEFAULT=ABI_32" ;;
        o64)  tm_defines="$tm_defines MIPS_ABI_DEFAULT=ABI_O64" ;;
        n32)  tm_defines="$tm_defines MIPS_ABI_DEFAULT=ABI_N32" ;;
        64)   tm_defines="$tm_defines MIPS_ABI_DEFAULT=ABI_64" ;;
        eabi) tm_defines="$tm_defines MIPS_ABI_DEFAULT=ABI_EABI" ;;
    esac

The ABI assignment and default mapping happens in the same file:
    https://github.com/gcc-mirror/gcc/blob/master/gcc/config.gcc#L2099
Comment 9 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2017-12-07 22:36:54 UTC
TL;WR: you're wrong.
Comment 10 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2017-12-07 22:39:59 UTC
In other words, you could spend less time trying to prove wrong is right, and more time fixing it. But as far as I'm concerned, this can just block clang keywording forever and I can direct all the users to you so that they can learn that there's a higher purpose in not being able to use the software they like -- it helps one person believe yet another partial stupid incompatible customization of Gentoo is valid!
Comment 11 Sergei Trofimovich gentoo-dev 2017-12-07 23:39:24 UTC
(In reply to Michał Górny from comment #10)
> In other words, you could spend less time trying to prove wrong is right,
> and more time fixing it.

I proved nothing. I merely stated the facts to get the understanding of problem at hand because it's absolutely not obvious from the bug. It has no linked bugs and has a few claims that imply gentoo does something that deviates from upstream.

Please be more specific what is 'it' here. I'll also post here relevant snippet from IRC:

> 22:40:43 < mgorny> the mips team already agreed the profiles need fixing

If it did I do not see the agreement here in the bug. You have proposed here
5 solutions. Which one(s?) did mips team agree to apply in your understanding? Who did agree so I would get some context from them.

This bug did not state where actual deviation takes place so I had to do spelunking to understand which profiles are affected so far. Now I need to do the same for clang :)

You did not state the end goal on how consistent end state should look like across gcc/clang and other distros.
Comment 12 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2017-12-08 07:37:58 UTC
#c6 states exactly what needs to be changed.

https://wiki.debian.org/Multiarch/Tuples

It should consistently be:

CHOST_o32="mips[el]-unknown-linux-gnu"
CHOST_n32="mips64[el]-unknown-linux-gnuabin32"
CHOST_n64="mips64[el]-unknown-linux-gnuabi64"


Those profiles need to be changed to use safe CHOST for o32:

arch/mips/mipsel/mips64el/multilib/o32/make.defaults:CHOST_o32="mips64el-unknown-linux-gnu"
arch/mips/mipsel/mips64el/multilib/make.defaults:CHOST_o32="mips64el-unknown-linux-gnu"
arch/mips/mips64/multilib/o32/make.defaults:CHOST_o32="mips64-unknown-linux-gnu"
arch/mips/mips64/multilib/make.defaults:CHOST_o32="mips64-unknown-linux-gnu"

i.e. they need to have 'mips64' changed to just 'mips'.


Those profiles need to be changed to use valid CHOST for n32:

arch/mips/mipsel/mips64el/n32/make.defaults:CHOST_n32="mips64el-unknown-linux-gnu"
arch/mips/mipsel/mips64el/multilib/n32/make.defaults:CHOST_n32="mips64el-unknown-linux-gnu"
arch/mips/mipsel/mips64el/multilib/make.defaults:CHOST_n32="mips64el-unknown-linux-gnu"
arch/mips/mips64/n32/make.defaults:CHOST_n32="mips64-unknown-linux-gnu"
arch/mips/mips64/multilib/n32/make.defaults:CHOST_n32="mips64-unknown-linux-gnu"
arch/mips/mips64/multilib/make.defaults:CHOST_n32="mips64-unknown-linux-gnu"

They all need to have 'abin32' appended.


For consistency, it would be also nice to change those:

arch/mips/mipsel/mips64el/n64/make.defaults:CHOST_n64="mips64el-unknown-linux-gnu"
arch/mips/mipsel/mips64el/multilib/n64/make.defaults:CHOST_n64="mips64el-unknown-linux-gnu"
arch/mips/mipsel/mips64el/multilib/make.defaults:CHOST_n64="mips64el-unknown-linux-gnu"
arch/mips/mips64/n64/make.defaults:CHOST_n64="mips64-unknown-linux-gnu"
arch/mips/mips64/multilib/n64/make.defaults:CHOST_n64="mips64-unknown-linux-gnu"
arch/mips/mips64/multilib/make.defaults:CHOST_n64="mips64-unknown-linux-gnu"

...and append 'abi64' consistently to them.
Comment 13 Sergei Trofimovich gentoo-dev 2017-12-08 09:22:03 UTC
> Now I need to do the same for clang

Clang on the other side has no "triple" (as they call tuple) that defaults to n32 ABI.
Their targets are only o32 and n64:

https://github.com/llvm-mirror/clang/blob/3edd9221b28c4a229ae5e211a367f6988c12e879/lib/Driver/ToolChains/Arch/Mips.cpp#L86

  if (ABIName.empty() &&
      (Triple.getVendor() == llvm::Triple::MipsTechnologies ||
       Triple.getVendor() == llvm::Triple::ImaginationTechnologies)) {
    ABIName = llvm::StringSwitch<const char *>(CPUName)
                  .Case("mips1", "o32")
                  .Case("mips2", "o32")
                  .Case("mips3", "n64")
                  .Case("mips4", "n64")
                  .Case("mips5", "n64")
                  .Case("mips32", "o32")
                  .Case("mips32r2", "o32")
                  .Case("mips32r3", "o32")
                  .Case("mips32r5", "o32")
                  .Case("mips32r6", "o32")
                  .Case("mips64", "n64")
                  .Case("mips64r2", "n64")
                  .Case("mips64r3", "n64")
                  .Case("mips64r5", "n64")
                  .Case("mips64r6", "n64")
                  .Case("octeon", "n64")
                  .Case("p5600", "o32")
                  .Default("");
  }

CPUName is an <arch> part of <arch>-<vendor>-<os>-<abi> triple.

Thus today CHOST does not really matter for n32/n64 cases. None of them work. Both upstreams need to be taught about new CHOST tuples to have common ground.

Thus proposed change in #c12 will not improve anything neither for gcc nor for clang users unless the relevant bits will be fixed in the compiler.

Preparing CHOST upfront makes sense provided both gcc and clang upstreams commit on changing the meaning of "new" triplets. It's surprising to see lack of support of proposed triplets in both upstreams even when those are used in debian for a while. Why is that?

Technically any of compilers can change meaning of any CHOST they support. Practically though it will be a breakage for users that will observe ABI change once CHOST changes. Hence why I stress the details of what compiler already use to understand the scope of impact for them and for us now and in the future.

This morning's vanilla gcc still does not understand gnuabi64 and we would need to deviate from upstream's ABI:

    $ ../gcc/configure --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=mips64-unknown-linux-gnuabi64
    $ make
    $ ./gcc/xgcc -B./gcc/ -dM -E - </dev/null | fgrep ABI
    #define __GXX_ABI_VERSION 1012
    #define _MIPS_SIM _ABIN32
    #define _ABIN32 2
Comment 14 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2017-12-08 11:40:54 UTC
Because there is no point in me preparing patches for upst when Gentoo randomly changes CHOST for no reason other than "we can"
Comment 15 Sergei Trofimovich gentoo-dev 2017-12-08 22:48:32 UTC
(In reply to Michał Górny from comment #14)
> Because there is no point in me preparing patches for upst when Gentoo
> randomly changes CHOST for no reason other than "we can"

[once again] Did file a bug about the discrepancy across gcc/clang
to either of upstreams and whether they are aware of the difference?

1. I don't think Gentoo changes CHOST frequently (or at all)

   Unless you refer to
     https://github.com/gentoo/gentoo-gitmig-20150809-draft/commit/9b41ef4f185ac29066749e1bab2cdd314d3023a5
   which has no mention of either: mips@ approving it, any bugs, context or a change.

   Say, this clearly does not work today (3 years passed) in Gentoo's clang:
   $ clang -target mips64-unknown-linux-gnuabin32 -E a.c -dM - </dev/null | fgrep -i abi
   #define _ABI64 3

2. In my opinion Gentoo should adopt upstream definition and interpretation of tuple (whatever definition it is) and help upstreams reconcile tuple definitions.

   Whether one particular tuple (say, mips64-unknown-linux-gnuabi64) it interpreted the same across different upstreams is remaining to be seen.

   Otherwise no matter which obscure enough tuple Gentoo picks it will differ for gcc/clang and we would have to alter their default interpretation using downstream patches.
Comment 16 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2017-12-09 00:39:34 UTC
And in my opinion, I do not care beyond getting clang to work. GCC has a hack, we've been happy to use it through all these years, I don't care. Clang is fully triplet-based, so start using sane triplets.

Or for a start, you could start using one triplet to mean the same thing instead of using two different triplets for the same thing depending on whether it's default or not. Which is what this was about before you started diverging the topic.
Comment 17 Sergei Trofimovich gentoo-dev 2017-12-10 11:19:17 UTC
I'll try to summarise then.

= The problem =
  For 3 ABIs mips needs 3 different CHOSTs to make multilib work.
  Otherwise (I guess) multilib ${CHOST}-wrappers mean something incorrect.

  Example:
    if we have 'mips64-unknown-linux-gnu-curl-config --libs'
    it always returns the same -L/usr/lib<something> path for two different ABIs  that share CHOST (wrong).

  Gentoo partially mitigates ${CHOST}-wrapped being not correct by passing
  proper CFLAGS_${abi} / LDFLAGS_${abi} (and friends) to make ebuilds work.
  It sort of works for gcc but does not work for other ${CHOST}-wrapped binaries.

= Possible solutions =

It does not matter much which exact CHOST values we pick because gcc/clang upstreams disagree on any value we pick for n32/n64.

Two CHOSTs were ok (arguably, except being used for n64 ABI as well):
  - mips-unknown-linux-gnu (o32, OK)
  - mips64-unknown-linux-gnu (n32, contentious)
The third is missing:
  - ?? (n64, missing)

   AFAIU it does not matter which one we pick as none work the same on clang/gcc right now.

Note: none of proposed changes below should change code generation by the toolchains. They only affect file names on disk.

== Action 0 : settle on tuple meanings in Gentoo ==
   mips@ needs to decide which tuples they want to chose as canonical CHOST for ABI and document them as such. Worth considering actions below WRT impact.

== Action 1 (seemingly uncontroversial): settle on n64 tuple and change profiles ==
  Steal debian's
  - mips64[el]-unknown-linux-gnuabi64 (n64)

  Profiles affected (multilib and native):
    mips64/multilib/make.defaults:CHOST="mips64-unknown-linux-gnu"
    mips64/n64/make.defaults:CHOST="mips64-unknown-linux-gnu"
    mips64/make.defaults:CHOST="mips64-unknown-linux-gnu"

    mipsel/mips64el/multilib/make.defaults:CHOST="mips64el-unknown-linux-gnu"
    mipsel/mips64el/n64/make.defaults:CHOST="mips64el-unknown-linux-gnu"
    mipsel/mips64el/make.defaults:CHOST="mips64el-unknown-linux-gnu"

  Consequence: users will have to suffer profile switch. Is n64 used much? Looks like not much. Perhaps could be changed straight away.

== Action 2 (more contentious): settle on n32 tuple and change profiles ==
 === Option 1: revert mips64[el]-unknown-linux-gnuabin32 -> mips64-unknown-linux-gnu ===

  Profiles affected (multilib only):
    mips64/multilib/n64/make.defaults:CHOST_n32="mips64-unknown-linux-gnuabin32"
    mips64/multilib/o32/make.defaults:CHOST_n32="mips64-unknown-linux-gnuabin32"

    mipsel/mips64el/multilib/n64/make.defaults:CHOST_n32="mips64el-unknown-linux-gnuabin32"
    mipsel/mips64el/multilib/o32/make.defaults:CHOST_n32="mips64el-unknown-linux-gnuabin32"

    This should not brick users' systems because it's used only in two profiles for non-default ABI. Rebuilding affected packages should keep system alive.

 === Option 2: finish mips64-unknown-linux-gnu -> mips64[el]-unknown-linux-gnuabin32 ===

  Profiles affected:
    mips64/multilib/make.defaults:CHOST="mips64-unknown-linux-gnu"
    mips64/n32/make.defaults:CHOST="mips64-unknown-linux-gnu"
    mips64/make.defaults:CHOST="mips64-unknown-linux-gnu"

    mipsel/mips64el/multilib/make.defaults:CHOST="mips64el-unknown-linux-gnu"
    mipsel/mips64el/n32/make.defaults:CHOST="mips64el-unknown-linux-gnu"
    mipsel/mips64el/make.defaults:CHOST="mips64el-unknown-linux-gnu"

= The related problems brought up here (don't require action) =

- (as topic states) gcc and clang do not agree on ABI.

  Yes they don't and it's not Gentoo's fault but how two compilers understand tuples. Changing just CHOST* values won't fix ABI mismatch for any tuple. Gentoo will need to apply changes downstream anyway.

- mips64-unknown-linux-gnu<->mips64-unknown-linux-gnuabin32 CHOST changes

  Changing this CHOST value brings nothing except causing users the hurdle to switch from one to another. At least today. mips64-unknown-linux-gnuabin32 could be better long-term when the tuple will be understood by both upstreams (if ever).
Comment 18 Sergei Trofimovich gentoo-dev 2017-12-10 11:23:20 UTC
If I were to choose I'd pick:

> == Action 0 : settle on tuple meanings in Gentoo ==
- mips-unknown-linux-gnu (o32)
- mips64[el]-unknown-linux-gnu (n32, follow gcc and existing non-multilib)
- mips64[el]-unknown-linux-gnuabi64 (n64)

> == Action 1 (seemingly uncontroversial): settle on n64 tuple and change
> profiles ==
>   Steal debian's
>   - mips64[el]-unknown-linux-gnuabi64 (n64)

and apply the changes to existing profiles right away.

> == Action 2 (more contentious): settle on n32 tuple and change profiles ==
>  === Option 1: revert mips64[el]-unknown-linux-gnuabin32 ->
> mips64-unknown-linux-gnu ===

and apply the changes to existing profiles right away.
Comment 19 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2017-12-10 12:16:28 UTC
(In reply to Sergei Trofimovich from comment #17)

> = The related problems brought up here (don't require action) =
> 
> - (as topic states) gcc and clang do not agree on ABI.
> 
>   Yes they don't and it's not Gentoo's fault but how two compilers
> understand tuples. Changing just CHOST* values won't fix ABI mismatch for
> any tuple. Gentoo will need to apply changes downstream anyway.

Bullshit. I will push clang changes upstream. As long as they are harmless and don't break other distributions using clang, that is.

> - mips64-unknown-linux-gnu<->mips64-unknown-linux-gnuabin32 CHOST changes
> 
>   Changing this CHOST value brings nothing except causing users the hurdle
> to switch from one to another. At least today.
> mips64-unknown-linux-gnuabin32 could be better long-term when the tuple will
> be understood by both upstreams (if ever).

Except the latter tuple is *unique* and guaranteed to be safe. The former ends up as ugly Gentoo patch not to break compatibility with other distributions which use it for something else.