https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ Issue: app-editors/mined-2015.25 calls cc directly. Discovered on: amd64 (internal ref: guru_ci) NOTE: As per QA policy, toolchain tools must not be called directly because they can cause issue in cross-compiling and because is not possible use a different CC implementation (like clang). To reproduce, please use sys-devel/gcc-config[-native-symlinks], sys-devel/binutils-config[-native-symlinks].
Created attachment 762972 [details] build.log build log and emerge --info
Error(s) that match a know pattern: make[1]: gcc: No such file or directory
Sorry about the (very) late response time; I didn't realize that there was another issue with this package. Speaking of which, I'm not entirely sure that there still is an issue here. I'm having issues reproducing this error. I've recompiled gcc-config and binutils-config with the -native-symlinks flags (as per the ), but upon recompilation of mined, no errors occured. When I tried to compile the old version of the package (the one that this bug was opened around) that used the provided makefile, I expected an error then. Unfortunately (maybe fortunately, I don't know anymore), none arose. So I can't reproduce the error on the package I know is broken, and I can't reproduce it on the most recent version, either. Is anybody able to reproduce this? Is the package still broken, or did I accidentally fix it?
I got the error: “no C compiler found” from mkmined. After setting CC to my compiler it worked. Maybe you had still some symlinks lying around? It should be enough to temporarily move /usr/bin/gcc to reproduce this. `tc-export CC` from toolchain-funcs.eclass should make it work.
After moving gcc and cc (against better judgement), I was able to reproduce this error. A quick tc-export later, and the problem seems to have been fixed. The commit (2cf5af8e8c422c7f553460fdaf777d88e79da9f9) has been pushed, and I'm just waiting for it to make its way through, now. Finally, a "thank-you" is in order to tastytea for teaching me how to successfully break the package.
(In reply to alex from comment #3) > Sorry about the (very) late response time; I didn't realize that there was > another issue with this package. > > Speaking of which, I'm not entirely sure that there still is an issue here. > I'm having issues reproducing this error. I've recompiled gcc-config and > binutils-config with the -native-symlinks flags (as per the ), but upon > recompilation of mined, no errors occured. > Are you sure it was definitely off? They're forced on in profiles.
(In reply to Sam James from comment #6) > (In reply to alex from comment #3) > > Speaking of which, I'm not entirely sure that there still is an issue here. > > I'm having issues reproducing this error. I've recompiled gcc-config and > > binutils-config with the -native-symlinks flags (as per the ), but upon > > recompilation of mined, no errors occured. > > > > Are you sure it was definitely off? They're forced on in profiles. That didn't even cross my mind. A quick emerge --info of the packages later, and yep, you're right. The flags never made it to the package. In hindsight, I should've checked that earlier. I got a little too confident, I guess. Regardless, the problem's been solved (allowed into the master branch), so I'm going to close this bug as fixed.
