[WIP] [RFC] cross-arm-none-eabi rework

[sirikid]

Why:

• More granular updates — each component of the toolchain can be built and updated separately.
• Extensive use of template system features — less manual work and less mistakes.

Why not:

• Additional points of failure. Possible solution: arm-none-eabi build helper.
• More packages in the repo with strange prefixes — this can confuse newcomers.

Please write your thoughts if you are interested in this package or in cross compilation in general, because I don’t even know if anyone except me needs this rework.

[pullmoll]

This looks good to me and we have not seen updates for quite some time for this target.
IMHO this won't confuse newcomers. They would probably not look for cross* packages at all.
I'm trying to build here and will report (build) problems, if any.

[sirikid]

I built the packages on x86_64-glibc and used them to compile my STM32 project, everything works fine. Binutils build on Trevis. There are problems with fetching newlib tarballs, which can be fixed by using wget instead of curl, but I don't know what is actually happening.

[pullmoll]

I could build the package for x86_64* and i686* so it seems ok, If you say it also works for you then I'd ask @void-linux/pkg-committers if this is ok to merge?

[jnbr]

There is a risk of breaking installations when moving files between packages.
To prevent this, this PR should be merged in two steps, cross-arm-none-eabi-* first and then cross-arm-none-eabi, so that cross-arm-none-eabi has a different timestamp than the remaining packages.

[pullmoll]

@jnbr good point.
@sirikid You should also append nocross=yes to cross-arm-none-eabi/template because we cannot cross compile cross compilers. And also to cross-arm-none-eabi-gcc. It seems that cross-arm-none-eabi-binutils can be cross built.. but I think it's best to make all nocross=yes in the first place.

[sirikid]

Both gcc and binutils should support cross-compiling, their configure scripts support the following flags:

~/w/gcc-8.3.0 $ ./configure --help | grep -e HOST -e BUILD -e TARGET
  --build=BUILD     configure for building on BUILD [guessed]
  --host=HOST       cross-compile to build programs to run on HOST [BUILD]
  --target=TARGET   configure for building compilers for TARGET [HOST]
...

I also want to draw attention to the fact that I build gcc with different options. I did it because I didn't know how to port the existing patch to the new version of gcc.
Existing gcc:

~ $ arm-none-eabi-gcc --print-multi-lib
.;
thumb;@mthumb
fpu;@mfloat-abi=hard
armv6-m;@mthumb@march=armv6s-m
armv7-m;@mthumb@march=armv7-m
armv7e-m;@mthumb@march=armv7e-m
armv7-ar/thumb;@mthumb@march=armv7
armv7e-m/softfp;@mthumb@march=armv7e-m@mfloat-abi=softfp@mfpu=fpv4-sp-d16
armv7e-m/fpu;@mthumb@march=armv7e-m@mfloat-abi=hard@mfpu=fpv4-sp-d16
armv7-ar/thumb/softfp;@mthumb@march=armv7@mfloat-abi=softfp@mfpu=vfpv3-d16
armv7-ar/thumb/fpu;@mthumb@march=armv7@mfloat-abi=hard@mfpu=vfpv3-d16

My:

~ $ arm-none-eabi-gcc --print-multi-lib
.;
arm/v5te/softfp;@marm@march=armv5te+fp@mfloat-abi=softfp
arm/v5te/hard;@marm@march=armv5te+fp@mfloat-abi=hard
thumb/nofp;@mthumb@mfloat-abi=soft
thumb/v7/nofp;@mthumb@march=armv7@mfloat-abi=soft
thumb/v7+fp/softfp;@mthumb@march=armv7+fp@mfloat-abi=softfp
thumb/v7+fp/hard;@mthumb@march=armv7+fp@mfloat-abi=hard
thumb/v6-m/nofp;@mthumb@march=armv6s-m@mfloat-abi=soft
thumb/v7-m/nofp;@mthumb@march=armv7-m@mfloat-abi=soft
thumb/v7e-m/nofp;@mthumb@march=armv7e-m@mfloat-abi=soft
thumb/v7e-m+fp/softfp;@mthumb@march=armv7e-m+fp@mfloat-abi=softfp
thumb/v7e-m+fp/hard;@mthumb@march=armv7e-m+fp@mfloat-abi=hard
thumb/v7e-m+dp/softfp;@mthumb@march=armv7e-m+fp.dp@mfloat-abi=softfp
thumb/v7e-m+dp/hard;@mthumb@march=armv7e-m+fp.dp@mfloat-abi=hard
thumb/v8-m.base/nofp;@mthumb@march=armv8-m.base@mfloat-abi=soft
thumb/v8-m.main/nofp;@mthumb@march=armv8-m.main@mfloat-abi=soft
thumb/v8-m.main+fp/softfp;@mthumb@march=armv8-m.main+fp@mfloat-abi=softfp
thumb/v8-m.main+fp/hard;@mthumb@march=armv8-m.main+fp@mfloat-abi=hard
thumb/v8-m.main+dp/softfp;@mthumb@march=armv8-m.main+fp.dp@mfloat-abi=softfp
thumb/v8-m.main+dp/hard;@mthumb@march=armv8-m.main+fp.dp@mfloat-abi=hard

[sirikid]

I did additional research and I can say that the patch was unnecessary, and everything is fine with multilibs now. The new toolkit supports more processors, and I think this is good.

There are few questions left:

1. Is nocross necessary or convenient? I can postpone cross-compiling to the next version of GCC.
2. Packages now have a lot of conflicts with native ones. Some of the files are not needed and they can be removed, and some can be put into platform-independent packages, for example gcc-doc.
3. cross-arm-none-eabi-{binutils,gcc,newlib} definitely conflict with cross-arm-none-eabi, so at first they should be added with conflicts="cross-arm-none-eabi" and then cross-arm-none-eabi become metapackage and conflicts should be removed, right?

[pullmoll]

1. nocross is (currently) required because the cross builders would fail trying to build some of cross-arm-none-eabi-* packages.
2. Packages or subpackages of this PR should not conflict with packages other than the current cross-arm-none-eabi. If they do, you should see if the conflict is due to arch specific vs. noarch or, if this is not the case, move the result elsewhere, perhaps /usr/lib/cross-arm-none-eabi/* or /usr/share/cross-arm-none-eabi/* depending on if it is code or data.
   3.) Perhaps @jnbr can tell how it should be done. Converting an existing package into a metapackage is not trivial and I'm not sure if the way you describe would work. I fear building the metapackage will fail because of the conflicts... hmm.

[jnbr]

I don't think we need any conflicts= here, the time where these packages conflict is very short and shouldn't affect anyone.

The problem when moving files between packages is, that xbps removes files which it considers obsolete. The mapping beetween files and packages is done via mtime, which broke when SOURCE_DATE_EPOCH was introduced to get reproducible builds.
So cross-arm-none-eabi needs a different timestamp than the other packages. This can be achieved by what I wrote before: merge the new packages first and wait for the builder to finish, then merge the update of cross-arm-none-eabi.

There is no need to change the templates to make this work.

[pullmoll]

So ideally the cross-arm-non-eabi update should go into a separate PR, then this one can be merged in the first step and, after the builders are finished, the 2nd PR can be merged.

[sirikid]

Ok, I think I am done with this.

[pullmoll]

Looks good so you could now create a PR for cross-arm-none-eabi meta package.