crossdev for MIPS fails on gcc stage1 when hardened is in USE flags (on host)
Steps to Reproduce:
1. Have hardened in host USE flags
2. crossdev -t mips-softfloat-linux-gnu
3. Wait until it hits gcc-stage1
configure: error: *** --enable-esp is not supported on this mips-softfloat-linux-gnu target.
GCC should build.
When I blacklist hardened USE flag for GCC in crossdev script everything builds successfully.
--- /usr/bin/crossdev.old 2011-06-04 21:16:57.272280477 +0200
+++ /usr/bin/crossdev 2011-06-04 21:18:36.631893358 +0200
@@ -173,6 +173,9 @@
+ mips*) GUSE="-hardened" # doesn't work
i'm not copying all of the misc profiles into crossdev
*** Bug 525910 has been marked as a duplicate of this bug. ***
(In reply to Maciej Szmigiero from comment #0)
> crossdev for MIPS fails on gcc stage1 when hardened is in USE flags (on host)
> Reproducible: Always
> Steps to Reproduce:
> 1. Have hardened in host USE flags
> 2. crossdev -t mips-softfloat-linux-gnu
> 3. Wait until it hits gcc-stage1
> Actual Results:
> configure: error: *** --enable-esp is not supported on this
> mips-softfloat-linux-gnu target.
> Expected Results:
> GCC should build.
> When I blacklist hardened USE flag for GCC in crossdev script everything
> builds successfully.
> --- /usr/bin/crossdev.old 2011-06-04 21:16:57.272280477 +0200
> +++ /usr/bin/crossdev 2011-06-04 21:18:36.631893358 +0200
> @@ -173,6 +173,9 @@
> KCAT="dev-util"; KPKG="w32api";
> LCAT="dev-util"; LPKG="mingw-runtime";;
> + mips*) GUSE="-hardened" # doesn't work
> + ;;
Actually this is not true. We are supporting hardened on mips for gcc-4.8 and above. I've been using it for several years. So you patch would be a problem for people wanting hardened mips, like me :)
(In reply to Anthony Basile from comment #4)
> (In reply to Maciej Szmigiero from comment #0)
> > crossdev for MIPS fails on gcc stage1 when hardened is in USE flags (on host)
> Actually this is not true. We are supporting hardened on mips for gcc-4.8
> and above. I've been using it for several years. So you patch would be a
> problem for people wanting hardened mips, like me :)
Might be true now - the above was written 3+ years ago, two major gcc version later it may work out of the box :)
This bug may be fixed for mips-linux-uclibc architecture??
In the bug marked as duplicate, I did not use hardened.
I posted all my log files there, Bug 525910 https://bugs.gentoo.org/show_bug.cgi?id=525910
I don't fully understand the error.
(In reply to Johannes Buchner from comment #7)
if you review the bug summary, this is not specific to hardened or any target
you can workaround it locally with something like:
crossdev --genv 'USE="-sanitize"' ...
How about bare-metal targets (eg avr) for which we doesn't have profiles?
*** Bug 604668 has been marked as a duplicate of this bug. ***
How about you create a package "crossdev-masks" which generates a list of “crossdev-‹target›/‹package› -‹keyword›” settings and installs this list to /etc/portage/package.use/crossdev or something like that?
You may be able to collect some of the data for this list from the official profiles, either during install or when building a release of this package. The latter would make things more reproducible, while the former might be able to work with overlays, too. You could also manually collect keywords which are known to fail on systems that have no profile, e.g. in response to a bug report. You could have the generation process substitute alternate category names for targets that may be identified by different names.
I think you should make crossdev depend on this package, so that people get the list without manual action. If someone starts editing the list, config protection would kick in and require a manual merge upon next upgrade, which I'd consider appropriate. You might also make the list generation part of the crossdev package itself, but that would mean updating the whole package whenever the list of masked flags changes. Not sure how often that would be, so decide for yourself.
You could also have crossdev interact with this list generation. Whenever a new target gets installed, suitable entries would get generated and appended to the file. That would allow e.g. matching the target against wildcards, so you could e.g. mask based on OS no matter the ARCH. The problem here would be getting rid of settings again. When removing a target, you can easily clean all settings for that, but what happens if the profile for some target changes, to now allow a flag that used to be forbidden? Then you should revbump the package, and the installation should generate a new list based on the installed cross compilers, to be presented to the user via regular config file handling tools.
*** Bug 609032 has been marked as a duplicate of this bug. ***
Mark spam comment private.
crossdev got a bunch of filters recently. If that still happens please file a new bug and we'll sort out filters.