Gentoo right now abuses the vendor field for hardfloat triples: arch/arm/armv6j/make.defaults:CHOST="armv6j-hardfloat-linux-gnueabi" arch/arm/armv7a/make.defaults:CHOST="armv7a-hardfloat-linux-gnueabi" default/linux/uclibc/arm/armv6j/make.defaults:CHOST="armv6j-hardfloat-linux-uclibceabi" default/linux/uclibc/arm/armv7a/make.defaults:CHOST="armv7a-hardfloat-linux-uclibceabi" hardened/linux/musl/arm/armv7a/make.defaults:CHOST="armv7a-hardfloat-linux-musleabi" This causes major interoperability issues. After wasting two days trying to figure out proper upstreamable way of adding support for this wheel reinvention into LLVM, I've given up. So please fix our profiles to use standard triples, i.e. **-gnueabihf, **-uclibceabihf, **-musleabihf.
Did you mean tuples?
Actually, I meant 'triplet' per autoconf vocabulary [1]. Not that the name really matters and there is any point in you asking this question when the example is pretty clear. [1]:https://www.gnu.org/software/autoconf/manual/autoconf-2.65/html_node/Specifying-Target-Triplets.html
Right. I assumed you might be introducing a portmanteau of tuple and triplet there. (Obligatory https://xkcd.com/927/ .)
But now the Summary makes even less sense.
Ping. Could we finally get this done as part of 17.0 profile switch, since we're going to require people to rebuild gcc anyway?
As much as I hate being pushed into this by other distros, I suppose it is technically more correct. 17.0 seems like a good opportunity.
I took the plunge and tried this on my main ARM system. I used quickpkg to backup binutils, gcc, and glibc just in case. I then more or less followed this old guide. https://wiki.gentoo.org/wiki/Changing_the_CHOST_variable I simply changed CHOST in make.conf. I didn't need to set CHOST_arm as that never matched in the first place. For the new profile, I believe only the default CHOST needs to change. I didn't need to run binutils-config after emerging binutils as suggested but I did need to run gcc-config after emerging gcc, which isn't mentioned. Until I did this, glibc's src_unpack would die complaining about libgcc_s.so.1. I had to clean up some files in /etc/env.d as described. fix_libtool_files.sh didn't pick up anything because .la files are avoided where possible now. I guess some people may still need to do this step though. I'm not going to rebuild @world but I'll try doing an update to make sure everything is working correctly. I didn't attempt to make the PIE-transition as found in other 17.0 profiles as I'm not sure what changes are needed here. If someone can guide me, I will attempt to do both migrations at the same time on my chroot.
(In reply to James Le Cuirot from comment #7) > I took the plunge and tried this on my main ARM system. I used quickpkg to > backup binutils, gcc, and glibc just in case. I then more or less followed > this old guide. > > https://wiki.gentoo.org/wiki/Changing_the_CHOST_variable > > I simply changed CHOST in make.conf. I didn't need to set CHOST_arm as that > never matched in the first place. For the new profile, I believe only the > default CHOST needs to change. > > I didn't need to run binutils-config after emerging binutils as suggested > but I did need to run gcc-config after emerging gcc, which isn't mentioned. > Until I did this, glibc's src_unpack would die complaining about > libgcc_s.so.1. > > I had to clean up some files in /etc/env.d as described. > > fix_libtool_files.sh didn't pick up anything because .la files are avoided > where possible now. I guess some people may still need to do this step > though. > > I'm not going to rebuild @world but I'll try doing an update to make sure > everything is working correctly. > > I didn't attempt to make the PIE-transition as found in other 17.0 profiles > as I'm not sure what changes are needed here. If someone can guide me, I > will attempt to do both migrations at the same time on my chroot. We'll need a news item. I can write it but since I haven't done the migration, I'm not sure what the steps are. Can you distill the above to short point forms. Also, we have a particular CHOST value in the /17.0/ profiles already. Do we just change it? Will that break systems? As far as catalyst runs go, it should be fine sine the new stages will just pick up the new CHOST from the profiles. But what about someone who has a seasoned system with a CHOST already defined in their make.conf?
(In reply to Anthony Basile from comment #8) > We'll need a news item. I can write it but since I haven't done the > migration, I'm not sure what the steps are. Can you distill the above to > short point forms. At this point, I was just getting a rough idea of what was involved and what issues there may be. I'll get a few points down and see if I (and others) can repeat it. > Also, we have a particular CHOST value in the /17.0/ profiles already. Do > we just change it? Will that break systems? As far as catalyst runs go, it > should be fine sine the new stages will just pick up the new CHOST from the > profiles. But what about someone who has a seasoned system with a CHOST > already defined in their make.conf? I had forgotten that there are arm 17.0 profiles already. I can see that there are hardly any arch-specific differences between the two so this is mainly about PIE. I'm not sure about changing the CHOST in place. Most users probably specify it in their own make.conf but what if they haven't? You wouldn't want this to suddenly change under your feet. That's what news items are for but is that sufficient? Having said all that, the glibc profiles aren't even listed under eselect profile yet (not in profiles.desc) and the non-glibc profiles are listed as experimental so does any of that even matter? As for my progress, I have updated about 40 packages out of 100 so far and have only run into one issue. After about 30 packages, it complained that it could not find gpg-error because it was looking for armv7a-hardfloat-linux-gnueabi-gpg-error-config. There were a bunch of files like this in /usr/bin. I deleted the ones left over by gcc-config as they were unowned. I figured rebuilding the rest would be overkill so I simply renamed them instead. rename -v hardfloat-linux-gnueabi unknown-linux-gnueabihf /usr/bin/*hardfloat-linux-gnueabi* Grepping the whole of bin revealed instances of the old CHOST within some files but using sed here would be dangerous so I thought I'd see how far it would get without fixing that. I immediately saw this warning during configure but it seems harmless and will eventually get flushed out. checking for gpg-error-config... /usr/bin/armv7a-unknown-linux-gnueabihf-gpg-error-config checking for GPG Error - version >= 1.25... yes (1.27) configure: WARNING: *** *** The config script /usr/bin/armv7a-unknown-linux-gnueabihf-gpg-error-config was *** built for armv7a-hardfloat-linux-gnueabi and thus may not match the *** used host armv7a-unknown-linux-gnueabihf. *** You may want to use the configure option --with-gpg-error-prefix *** to specify a matching config script or use $SYSROOT. ***
FYI, 17.0 profiles weren't added to profiles.desc specifically because of this.
(In reply to Michał Górny from comment #10) > FYI, 17.0 profiles weren't added to profiles.desc specifically because of > this. Thanks, that's good to know. World update finished now. I encountered two more problems. I forgot to update the symlinks pointing to the files I'd renamed earlier. I fixed that with: cd /usr/bin find -L * -lname "armv7a-hardfloat-linux-gnueabi-*" -exec ln -snf armv7a-unknown-linux-gnueabihf-{} {} \; irssi failed to build until I had rebuilt Perl. The wiki guide also mentions rebuilding Perl.
The above case was simple enough but doing this together with the PIE migration requires a little more thought. The PIE (17.0) guide says you should upgrade to at least gcc 6.4.0 before switching profile. When I asked dilfridge why, he said it's so that your gcc isn't masked after switching profile but I don't see why that matters. With arm being slow, he said we could skip this step so I did and started with 5.4.0. Similarly, the CHOST change guide says you should rebuild the toolchain with the same versions but this isn't strictly necessary if you're careful. I tried upgrading all three parts. CHOST=armv7a-unknown-linux-gnueabihf OLD_CHOST=armv7a-hardfloat-linux-gnueabi GCC_PV=6.4.0 1. quickpkg sys-devel/binutils sys-devel/gcc sys-libs/glibc (just in case) 2. Switch to the new profile. 3. Update CHOST in /etc/portage/make.conf if not using the default. 4. emerge -1 sys-devel/binutils 5. Remove any old binutils versions if applicable. 6. Ensure the new binutils is selected with binutils-config. 7. emerge -1 sys-devel/gcc 8. Remove any old gcc versions if applicable. 9. Ensure the new gcc is selected with gcc-config. You may need to explicitly select it even if it's already highlighted? 10. find /etc/env.d -name "*${OLD_CHOST}*" -delete && env-update && . /etc/profile 11. emerge -1 sys-libs/glibc 12. emerge -1 sys-devel/binutils 13. emerge -1 sys-devel/libtool 14. /usr/share/gcc-data/${CHOST}/${GCC_PV}/fix_libtool_files.sh ${GCC_PV} --oldarch ${OLD_CHOST} 15. qfile -o /usr/bin/${OLD_CHOST}-* | xargs rm -v 16. cd /usr/bin && find -name "${OLD_CHOST}-*" -exec sh -c "X='{}'; mv -v \"\${X}\" \"\${X/${OLD_CHOST}/${CHOST}}\"" \; 17. cd /usr/bin && find * -lname "${OLD_CHOST}-*" -exec ln -snfv ${CHOST}-{} {} \; 18. emerge -1 dev-lang/perl (if you have it) For a pure PIE migration, you would emerge binutils after gcc, which is why we do it twice here. dilfridge didn't seem sure about why this is necessary but perhaps it's to rebuild libiberty.a with PIE. There aren't any other static libraries in binutils though and I doubt that libiberty is even used that much. At least binutils doesn't take so long to build. Please do scrutinise the above as much as you can. I don't want to break anybody's systems.
(In reply to James Le Cuirot from comment #12) > > Please do scrutinise the above as much as you can. I don't want to break > anybody's systems. God what a mess. I get each step but I'm just not sure what will happen in the wild. For musl and uclibc I can "just do it" in the catalyst stage builds, but on a live system, I'm not sure. I'm going to schedule fixing this for at least uclibc and musl during our spring break in March.
I had some spare cycles and an armv6j musl chroot kicking around so I thought I might test this. Note, I use the armv7a profiles, but override CFLAGS to get my architecture. I got stopped at James' step 11 (obviously emerge -1 musl, not glibc). It fails installing with: .... ./tools/install.sh -D -m 644 include/wctype.h /var/tmp/portage/sys-libs/musl-1.1.18/image//usr/include/wctype.h ./tools/install.sh -D -m 644 include/wordexp.h /var/tmp/portage/sys-libs/musl-1.1.18/image//usr/include/wordexp.h * /var/tmp/portage/sys-apps/sandbox-2.12/work/sandbox-2.12/libsandbox/trace.c:_do_ptrace():75: failure (Function not implemented): * ISE:_do_ptrace: ptrace(PTRACE_TRACEME, ..., 0x00000000, 0x00000000): Function not implemented * ERROR: sys-libs/musl-1.1.18::gentoo failed (install phase): * (no error message) * * Call stack: * ebuild.sh, line 124: Called src_install * environment, line 2257: Called die * The specific snippet of code: * [[ -e "${D}"/lib/ld-musl-${arch}.so.1 ]] || die; * I retried with FEATURES="-sandbox" as well as FEATURES="-usersandbox -userpriv", both have the same outcome. I am doing this within a QEMU chroot, but have never seen this ptrace message in the 3 years this root has been alive.
(In reply to David Flogeras from comment #14) > I am doing this within a QEMU chroot, but have never seen this ptrace > message in the 3 years this root has been alive. This is almost certainly related to the QEMU environment but I don't know why you're only hitting it now.
Note this forum thread. Sounds like it's recently fixed in glibc but perhaps not in musl. https://forums.gentoo.org/viewtopic-p-8148028.html#8148028
I'm not sure if it's the same issue. I was hitting that on my glibc based chroots as described while the same qemu version had no trouble rebuilding musl.
For comparison, I downloaded the 20171112 stage3-armv7a and used the same qemu to rebuild musl (not trying to switch CHOST) and it worked. Note the warning, perhaps that warning has turned into an error somehow? I'm obviously out of my depth here. ... ./tools/install.sh -D -m 644 include/wchar.h /var/tmp/portage/sys-libs/musl-1.1.18/image//usr/include/wchar.h ./tools/install.sh -D -m 644 include/wctype.h /var/tmp/portage/sys-libs/musl-1.1.18/image//usr/include/wctype.h ./tools/install.sh -D -m 644 include/wordexp.h /var/tmp/portage/sys-libs/musl-1.1.18/image//usr/include/wordexp.h * Unable to trace static ELF: /var/tmp/portage/sys-libs/musl-1.1.18/image/usr/lib/libc.so: /var/tmp/portage/sys-libs/musl-1.1.18/image/usr/lib/libc.so >>> Completed installing musl-1.1.18 into /var/tmp/portage/sys-libs/musl-1.1.18/image/
OK, back to the armv6j chroot from comment #14: I managed to get past emerge -1 musl by setting FEATURES="-sandbox -usersandbox -userpriv". Afterwards, I put the sandbox features back to defaults and continued without any issues in the rest of the ~250 packages on this system. Once world was rebuilt, I tried to emerge -1 musl to see if somehow things had changed, but the same issue happened. Finally, I downgraded from sandbox-2.12 (musl overlay) to 2.10-r4 (also musl overlay) and was able to emerge musl cleanly. I noted there was an updated sandbox-2.13 in the musl overlay, so I also gave that a try. It resulted in the same ptrace issues noted before. So it seems that somehow >sandbox-2.10 has a problem with the new CHOST, but not my old CHOST of armv6j-hardfloat-linux-musleabi.
(In reply to David Flogeras from comment #19) > OK, back to the armv6j chroot from comment #14: > > I managed to get past emerge -1 musl by setting FEATURES="-sandbox > -usersandbox -userpriv". > > Afterwards, I put the sandbox features back to defaults and continued > without any issues in the rest of the ~250 packages on this system. > > Once world was rebuilt, I tried to emerge -1 musl to see if somehow things > had changed, but the same issue happened. > > Finally, I downgraded from sandbox-2.12 (musl overlay) to 2.10-r4 (also musl > overlay) and was able to emerge musl cleanly. > > I noted there was an updated sandbox-2.13 in the musl overlay, so I also > gave that a try. It resulted in the same ptrace issues noted before. > > So it seems that somehow >sandbox-2.10 has a problem with the new CHOST, but > not my old CHOST of armv6j-hardfloat-linux-musleabi. Probably worth exploring https://gitweb.gentoo.org/proj/sandbox.git/ . This will most likely need fixing going forward.
After scrutinizing my logs, I see that this system upgraded to sandbox-2.12::musl _after_ the last time I had rebuilt world. It had nothing to do with changing the triplet. sandbox-2.12::musl has since been demoted to ~arm, but I cannot comment if this is why, or other reasons. It all comes down to QEMU is missing ptrace. If you compile the following: #include <sys/ptrace.h> int main() { ptrace( 0,0,0,0 ); } You'll get a qemu: Unsupported syscall: 26 Alternatively, run "sandbox /usr/lib/libc.so" And it seems that sandbox uses ptrace more aggressively since version 2.11. To my untrained eyes, it seems that much of the 2.10->2.11 changes were ptrace related. Clearly nothing to do with this bug, I'll open a new one. Sorry for the noise.
Process worked for changing armv6j-hardfloat-linux-uclibceabi (uclibc-ng) to armv6j-unknown-linux-uclibceabihf. next is armv6j gnueabi
(In reply to David Flogeras from comment #22) > Process worked for changing armv6j-hardfloat-linux-uclibceabi (uclibc-ng) to > armv6j-unknown-linux-uclibceabihf. > > next is armv6j gnueabi Thanks for this! Does this mean we'll shortly have all the libc implementations covered for armv6j ?!
(In reply to Michael Everitt (IRC: veremitz) from comment #23) > (In reply to David Flogeras from comment #22) > > Process worked for changing armv6j-hardfloat-linux-uclibceabi (uclibc-ng) to > > armv6j-unknown-linux-uclibceabihf. > > > > next is armv6j gnueabi > Thanks for this! Does this mean we'll shortly have all the libc > implementations covered for armv6j ?! Thanks, the testing really helps because I have to do this for both uclibc and musl in catalyst for the stages and this is reassuring that it'll actually work.
@veremitz All in good fun :) I'm not sure what all the libc possibilities are, and officially musl isn't even a supported profile for armv6j. (Neither is uclibc probably, but if you look hard there's a profile hidden in profiles/hardened/linux/uclibc/arm/armv6j that doesn't show up in eselect) Either way, mine are armv6j-unknown-linux-uclibceabihf, muslceabihf, and gnueabihf. I do have an armv7a gnu for a cubieboard, but I'd like to wait until 17.0 is there to do that rebuild, since that system has quite a bit more "large" packages. That takes quite a while, and doing two full rebuilds is torture. I think things look good that it should go smoothly. @blueness Full disclosure, musl was gcc-6.4.0 tested transitioning from 13.0->17.0 whilst renaming CHOST uclibc was gcc-6.4.0 simply renaming CHOST (no 17.0 available yet) and to keep things fun, gnueabi I'm both renaming CHOST and upgrading from gcc-5.4.0 -> 6.4.0 (again, staying on the old profile)
armv6j-hardfloat-linux-gnueabi -> armv6j-unknown-linux-gnueabihf went fine too.
Do I get it right that this bug has to be solved so that clang can be used for armv7a-hardfloat?
Okay, so today I tested clang on amd64 and had a blast, so I will jump into this bug to help with testing, therefore copy the existing rootfs from my rpi to an external drive and chroot into it, follow all the steps from #12 and therefore go from CHOST="armv7a-hardfloat-linux-gnueabi" to CHOST="armv7a-unknown-linux-gnueabihf" I'll report back in, ehrr, a week or so? :) I guess that this is going to break the musl rust ebuild from the overlay up to some point at least..
Some time ago (to report https://bugs.gentoo.org/show_bug.cgi?id=595834#c17) I changed CHOST to CHOST="armv7a-unknown-linux-musleabihf" I had to set CHOST_arm as well. Otherwise sys-devel/clang will produce wrong ${CHOST}-clang symlinks.
(In reply to Felix Janda from comment #29) > I had to set CHOST_arm as well. Otherwise sys-devel/clang will produce > wrong ${CHOST}-clang symlinks. Good to know, I don't have clang on the systems I tested.
(In reply to Felix Janda from comment #29) > Some time ago (to report https://bugs.gentoo.org/show_bug.cgi?id=595834#c17) > I changed CHOST to > > CHOST="armv7a-unknown-linux-musleabihf" > > I had to set CHOST_arm as well. Otherwise sys-devel/clang will produce > wrong ${CHOST}-clang symlinks. Did you put CHOST_arm="armv7a-unknown-linux-musleabihf-clang" to /etc/portage/make.conf for this? The guide from #12 doesn't work for me on 13.0 profile, it gives me an error related in a way that gcc does not want to be build against armv7a-unknown-linux-muselabihf, and I don't have a 17.0 profile to choose from. will try again with the guide form here: https://wiki.gentoo.org/wiki/Changing_the_CHOST_variable
Converted my nyan-big Chromebook from armv7a-hardfloat-linux-gnueabi to armv7a-unknown-linux-gnueabihf and enabled PIE for GCC in one go. My procedure was: 1. Make sure the old GCC 4.9.4 from the stage 3 tarball is uninstalled and all traces are removed from /etc/env.d 2. eselect GCC 6.4.0 3. emerge --ask --oneshot sys-devel/libtool 4. Change CHOST variable 5. emerge --ask --oneshot sys-devel/binutils 6. Unmask gcc pie 7. emerge --ask --oneshot gcc 8. emerge --ask --oneshot glibc binutils 9. emerge --emptytree @world Rebuilding @world wasn't quite without issues, but it worked.
(In reply to tt_1 from comment #31) > The guide from #12 doesn't work for me on 13.0 profile, it gives me an error > related in a way that gcc does not want to be build against > armv7a-unknown-linux-muselabihf, and I don't have a 17.0 profile to choose > from. You can't select the 17.0 profile with eselect yet as it's not officially available yet. You have to replace with /etc/portage/make.profile symlink manually. (In reply to takashi from comment #32) > My procedure was: > ... To be honest, that's more or less the same as my procedure but I added additional steps for safety, cleanup (you'll have some old CHOST junk left in /etc/env.d), and avoiding the need to remerge @world, which is something most arm users dread.
Created attachment 523378 [details] gcc build logs Yes, one has to set the symlink by hand to get a 17.0 profile. I followed the instructions from #12, it is just that I already have a working gcc-6.4.0-r1 but with the old profile and *-gnueabi as CHOST. Now it is a 17.0 profile, and CHOST is changed to *-gnueabihf in /etc/portage/make.conf, but I can't emerge gcc with new chost and (*pie) - the relevant logs are attached. propably should be --host=armv7a-hardfloat-linux-gnueabi and --build=armv7a-hardfloat-linux-gnueabihf instead?
(In reply to tt_1 from comment #34) > I followed the instructions from #12, it is just that I already have a > working gcc-6.4.0-r1 but with the old profile and *-gnueabi as CHOST. Now it > is a 17.0 profile, and CHOST is changed to *-gnueabihf in > /etc/portage/make.conf, but I can't emerge gcc with new chost and (*pie) - > the relevant logs are attached. You need to provide config.log, that has the real error message. > propably should be --host=armv7a-hardfloat-linux-gnueabi and > --build=armv7a-hardfloat-linux-gnueabihf instead? I initially thought specifying --build would necessary but seemingly not. Your new CHOST is odd though. You've got hardfloat *and* gnueabihf? Although I would expect it to work anyway, let's not introduce potential for failure.
It seems as if my misstake was to think of arm*-*-*-*hf as armv7a-hardfloat-linux-gnueabihf. crossdev has no problem to build a toolchain with that name, and the first recompile of binutils doesn't mind neither. But on step two, gcc rejects it. With the correct CHOST="armv7a-unknown-linux-gnueabihf" it all works out, but I have to say that some of the commands are a bit difficult to decypher and to verify on your own, with the many brakets and variables, it might be easier to understand if you would give the users one guide with plain written CHOST and OLD_CHOST and to ask them to change the chost to their values. Also it might be a bad idea to reboot during the whole process, as I got this message here: <<< !needed obj /usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/6.4.0/libgcc_s.so.1 <<< !needed sym /usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/6.4.0/libgomp.so.1 <<< !needed obj /usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/6.4.0/libgomp.so.1.0.0 <<< !needed sym /usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/6.4.0/libstdc++.so.6 <<< !needed obj /usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/6.4.0/libstdc++.so.6.0.22 /bin/bash: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory * The ebuild phase 'other' has exited unexpectedly. This type of behavior * is known to be triggered by things such as failed variable assignments * (bug #190128) or bad substitution errors (bug #200313). Normally, before * exiting, bash should have displayed an error message above. If bash did * not produce an error message above, it's possible that the ebuild has * called `exit` when it should have called `die` instead. This behavior * may also be triggered by a corrupt bash binary or a hardware problem * such as memory or cpu malfunction. If the problem is not reproducible or * it appears to occur randomly, then it is likely to be triggered by a * hardware problem. If you suspect a hardware problem then you should try * some basic hardware diagnostics such as memtest. Please do not report * this as a bug unless it is consistently reproducible and you are sure * that your bash binary and hardware are functioning properly. Still, it seemed to have worked, compiling dev-lang/perl as last step. Do I have to rebuild gcc as well on emerge -e world? It would save many hours to not to have to.
I think the CHOST should come from the profile, so just the profile switch should be at the right moment, plus telling to remove their own CHOST from older make.conf's to actually let it happen, imho
(In reply to Mart Raudsepp from comment #37) > I think the CHOST should come from the profile, so just the profile switch > should be at the right moment, plus telling to remove their own CHOST from > older make.conf's to actually let it happen, imho Fair enough but we haven't applied the CHOST change to the profiles yet. :)
I managed to pass the guide from #12 with success, now going to do an emerge -e world. Upon a quick look into /usr/bin, there is still a file called armv7a-hardfloat-linux-gnueabihf-dwp, which is a broken symbolic link to /usr/armv7a-hardfloat-linux-gnueabihf/bin/dwp Also there is still a folder in /usr/armv7a-hardfloat-linux-gnueabi, all subfolders with broken symlinks as well. /etc/env.d/ is clean, however Is it possible to stay on the 13.0 profile, but change the CHOST anyway, and to upgrade later on to the 17.0 profile when it is more stable?
(In reply to tt_1 from comment #39) > I managed to pass the guide from #12 with success, now going to do an emerge > -e world. Upon a quick look into /usr/bin, there is still a file called > armv7a-hardfloat-linux-gnueabihf-dwp, which is a broken symbolic link to > /usr/armv7a-hardfloat-linux-gnueabihf/bin/dwp This symlink is not owned by any package and step #15 should remove it. Obviously make sure you have set OLD_CHOST before you run that! > Also there is still a folder in /usr/armv7a-hardfloat-linux-gnueabi, all > subfolders with broken symlinks as well. If all the toolchain packages you have installed now are for the new CHOST then you can delete this whole directory. > Is it possible to stay on the 13.0 profile, but change the CHOST anyway, and > to upgrade later on to the 17.0 profile when it is more stable? You could but although it's not official yet, I doubt you will face any problems with the 17.0 profile. It's already been thoroughly tested on amd64 and most of the pain is in the migration, which you will have to face regardless.
Finished rebuilding world set, now have working clang :) equery f clang | grep armv7 /usr/lib/llvm/5/bin/armv7a-unknown-linux-gnueabihf-clang /usr/lib/llvm/5/bin/armv7a-unknown-linux-gnueabihf-clang++ /usr/lib/llvm/5/bin/armv7a-unknown-linux-gnueabihf-clang++-5.0 /usr/lib/llvm/5/bin/armv7a-unknown-linux-gnueabihf-clang-5.0 /usr/lib/llvm/5/bin/armv7a-unknown-linux-gnueabihf-clang-cl /usr/lib/llvm/5/bin/armv7a-unknown-linux-gnueabihf-clang-cl-5.0 /usr/lib/llvm/5/bin/armv7a-unknown-linux-gnueabihf-clang-cpp /usr/lib/llvm/5/bin/armv7a-unknown-linux-gnueabihf-clang-cpp-5.0 tested with libpng, it compiles fine, but takes double the time as gcc while super memory efficent at the same time. Will it take a long time to make the 17.0 profile + new chost available? Because I may run into bugs, and I guess maintainers will close it as invalid as long as it's not an official profile. So yeah, guide from #12 worked well for me. I may want to add, that I had gcc-6.4.0-r1 already merged before the profile change. Also python3_6 use flag is still masked, but that seems to be another topic.
Ah, I forgot to mention that I set CHOST_arm="$CHOST" in make.conf for clang, this might be fixable in toolchain.eclass or some other eclass?
(In reply to tt_1 from comment #41) > Will it take a long time to make the 17.0 profile + new chost available? > Because I may run into bugs, and I guess maintainers will close it as > invalid as long as it's not an official profile. It shouldn't be long as the profile changes are trivial and we just need someone, probably blueness, to write the news item. (In reply to tt_1 from comment #42) > Ah, I forgot to mention that I set CHOST_arm="$CHOST" in make.conf for > clang, this might be fixable in toolchain.eclass or some other eclass? We have CHOST_arm="${CHOST}" in profiles/arch/arm/make.defaults but this appears to be the wrong place for it as this results in "arm-unknown-linux-gnu". Would it need to explicitly go in armv6j, armv7a, etc?
No idea how to properly fix CHOST_arm value from within the profile, but as long as it's possible to set the correct value via make.conf I certainly don't care too much. The guide from #12 works just fine for armv7, it can be copied 1:1 into an upcoming news item. I think armv6 passed as well, right?
armv6j worked for me, only issues I had were related to the exotic arches (musl/uclibc) and have nothing to do with this process.
It is possible to compile clang with CHOST="armv7a-unknown-linux-musleabihf", but it needs to be set CHOST_arm="armv7a-unknown-linux-musleabihf" extra, otherwise sys-libs/compiler-rt can't find clang binaries. I forgot that and set the symlinks on my own, but can't build compiler-rt-sanitizers at the moment with this error: /var/tmp/portage/sys-libs/compiler-rt-sanitizers-5.0.1/work/compiler-rt-5.0.1.src/lib/sanitizer_common/sanitizer_platform_limits_posix.cc:1033:1: error: 'assertion_failed__1033' declared as an array with a negative size CHECK_SIZE_AND_OFFSET(dirent, d_ino); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /var/tmp/portage/sys-libs/compiler-rt-sanitizers-5.0.1/work/compiler-rt-5.0.1.src/lib/sanitizer_common/sanitizer_platform_limits_posix.h:1475:3: note: expanded from macro 'CHECK_SIZE_AND_OFFSET' COMPILER_CHECK(sizeof(((__sanitizer_##CLASS *) NULL)->MEMBER) == \ I'll try again with CHOST_arm set in make.conf, and propably open a new bug if I hit it again. Apart from that, I followed instructions from #12 for this musl installation, and it all worked out fine. Clang wasn't part of the world file when I did the emerge -e world after the change in CHOST.
Here are my suggested changes to the profiles. veremitz and blueness, please review. I have fixed up the CHOST_arm issue across all existing profiles and updated CHOST for all 17.0 profiles. I'm assuming that uclibc isn't going to see 17.0. https://github.com/chewi/gentoo/commits/armhf-profiles If you're happy, I'll send these to the mailing list.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=26a471c23be476600eecbc5ae8582eba94b9acfe commit 26a471c23be476600eecbc5ae8582eba94b9acfe Author: James Le Cuirot <chewi@gentoo.org> AuthorDate: 2018-05-04 22:57:30 +0000 Commit: James Le Cuirot <chewi@gentoo.org> CommitDate: 2018-05-17 09:06:28 +0000 profiles: Use *eabihf on arm hardfloat triplets for 17.0 onwards 13.0 is now the exception, which sets it back to the old value. Bug: https://bugs.gentoo.org/602440 profiles/arch/arm/armv6j/make.defaults | 2 +- profiles/arch/arm/armv7a/make.defaults | 2 +- profiles/default/linux/arm/13.0/armv6j/make.defaults | 2 ++ profiles/default/linux/arm/13.0/armv7a/make.defaults | 2 ++ profiles/default/linux/arm/17.0/musl/armv7a/make.defaults | 2 +- 5 files changed, 7 insertions(+), 3 deletions(-)
I've successfully built a stage3 with catalyst, which you can check out at: https://dev.gentoo.org/~chewi/stages/ Following this, I've pushed my profile changes so all that remains is to update profiles.desc. We're just waiting on a guide from blueness. Catalyst should also be updated accordingly.
The guide from #12 is perfectly fine to be copied into a guide or news article.
I am just about to run a glibc->musl switch including profile-17 changes on armv6j, so once this is complete, ad blueness has given his Ack, then we can take the next steps. Will discuss the catalyst changes with dol-sen on the -releng IRC channel.
I have now pushed the new armv6j musl profile and successfully built a stage3 from it. See my URL above.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=914febc477dac68d772a3bc9e3ff48b7c81d6649 commit 914febc477dac68d772a3bc9e3ff48b7c81d6649 Author: James Le Cuirot <chewi@gentoo.org> AuthorDate: 2018-07-09 19:35:01 +0000 Commit: James Le Cuirot <chewi@gentoo.org> CommitDate: 2018-07-09 19:35:01 +0000 Revert "profiles: add arm 17.0 profiles" This reverts commit 8ef566d3672572990664d48595994385df06f535. A news item with a clear migration guide is needed before this is ready for public consumption. Bug: https://bugs.gentoo.org/602440 profiles/profiles.desc | 25 ------------------------- 1 file changed, 25 deletions(-)
Since the news item hasn't been forthcoming and I think my migration guide is a little scary as it stands, I've tried to script it up. Not finished yet but nearly there. It wasn't as hard as I thought it would be. My only concern is that while it's robust, if it does blow up then it's not exactly resumable. You'd have to continue by hand. It's still an improvement, I suppose. Will finish it soon.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/data/gentoo-news.git/commit/?id=eb934b1aed6fe6ed4a7e7cec36422c6e2a083c2a commit eb934b1aed6fe6ed4a7e7cec36422c6e2a083c2a Author: James Le Cuirot <chewi@gentoo.org> AuthorDate: 2018-09-07 21:02:06 +0000 Commit: James Le Cuirot <chewi@gentoo.org> CommitDate: 2018-09-07 21:19:21 +0000 2018-09-07-arm-17-profile-migration: Add news item Bug: https://bugs.gentoo.org/602440 .../2018-09-07-arm-17-profile-migration.en.txt | 59 ++++++++++++++++++++++ 1 file changed, 59 insertions(+)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d561f3dfa943990d5f2417ffd05551e9463d15a8 commit d561f3dfa943990d5f2417ffd05551e9463d15a8 Author: James Le Cuirot <chewi@gentoo.org> AuthorDate: 2018-09-07 21:20:19 +0000 Commit: James Le Cuirot <chewi@gentoo.org> CommitDate: 2018-09-07 21:20:19 +0000 profiles: (Re-)Add arm 17.0 profiles with new *hf tuples See the associated news item for details. Closes: https://bugs.gentoo.org/602440 profiles/profiles.desc | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+)
