Short: The ebuild uses an obsolete CYGPORTS commit from gcc-6.4.0. This is the one for gcc-7.3.0 : https://github.com/cygwinports/gcc/commit/d83e3d1ac0a9adfacdf120f013870472e8e712c3 Reproducible: Always Steps to Reproduce: 1. Enter Gentoo Prefix on Cygwin 2. emerge -1u sys-devel/gcc Actual Results: Prepare stage fails on wrong/obsolete patches from cygports. Expected Results: Prepare succeeds I'll post a diff of my local ebuild after testing the most current cygports commit.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/proj/prefix.git/commit/?id=41934e526d01bd534e6f22cbb8a5dd496224eedc commit 41934e526d01bd534e6f22cbb8a5dd496224eedc Author: Fabian Groffen <grobian@gentoo.org> AuthorDate: 2018-06-08 13:06:29 +0000 Commit: Fabian Groffen <grobian@gentoo.org> CommitDate: 2018-06-08 13:06:29 +0000 sys-devel/gcc: update Cygwin patch commit, thanks Sven Eden Bug: https://bugs.gentoo.org/657594 Package-Manager: Portage-2.3.40.1-prefix, Repoman-2.3.9 sys-devel/gcc/Manifest | 1 + sys-devel/gcc/gcc-7.3.0-r3.ebuild | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-)
I've updated the hash already, since the old one was faulty nevertheless. I'll await your findings before closing this bug. Thanks!
Wow, that was fast! Currently I get -------- configure: error: in `/build/portage/sys-devel/gcc-7.3.0-r4/work/build/x86_64-pc-cygwin/libgomp': configure: error: C compiler cannot create executables See `config.log' for more details. -------- So I'll need a while to find out what's going on. However, I think that this is a different issue. This bug is about the old patches not applying. And that was fixed. :-)
hmmm, what stage is that in? Is it using the "host" compiler (whatever you have emerged before 7.3, 5.3?) or xgcc? I've simply renamed this bug, let's try to triage the process here. :)
(In reply to Sven Eden from comment #3) > So I'll need a while to find out what's going on. *meh*. When building with USE="ssp", the libssp test fails. I am trying now with USE="-ssp"
The current compiler is gcc-6.4.0
Created attachment 535304 [details] build/x86_64-pc-cygwin/libgomp/config.log Damn. The build still fails in: "Configuring stage 1 in x86_64-pc-cygwin/libgomp" And it is the same error: "cannot find -lssp_nonshared" Why, if SSP should be disabled? Configuration log is attached.
When I look at the gcc.cygport file, I can see that they have --disable-ssp set. Further there are these lines in src_compile() : -------- # use built-in SSP with Cygwin 2.10 # FIXME: --disable-libssp should suffice in GCC 8 export gcc_cv_libc_provides_ssp=yes -------- I will try this when I am back in office on Monday. Maybe disabling/masking USE="ssp" and adding that export on cygwin is enough.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=be6dbc5a9d2052338d58e0a6ea2d69cf118ecec1 commit be6dbc5a9d2052338d58e0a6ea2d69cf118ecec1 Author: Michael Haubenwallner <haubi@gentoo.org> AuthorDate: 2018-06-08 18:27:34 +0000 Commit: Michael Haubenwallner <haubi@gentoo.org> CommitDate: 2018-06-08 18:29:25 +0000 profiles/cygwin/p.use: disable ssp for all gcc versions Bug: https://bugs.gentoo.org/657594 profiles/prefix/windows/cygwin/package.use | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
With my recent changes it built. But postinst fails with: -------- cp: cannot stat '//gentoo/usr/share/gcc-data/x86_64-pc-cygwin/7.3.0/fixlafiles.awk': No such file or directory * ERROR: sys-devel/gcc-7.3.0-r4::local_overlay failed (postinst phase): * (no error message) * * Call stack: * ebuild.sh, line 124: Called __call-ebuildshell 'pkg_postinst' * ebuild.sh, line 552: Called pkg_postinst * environment, line 3069: Called toolchain_pkg_postinst * environment, line 4384: Called die * The specific snippet of code: * cp "${ROOT}${DATAPATH}"/fixlafiles.awk "${EROOT}"usr/share/gcc-data/ || die; -------- Weird thing, because: -------- $ ls -lh /gentoo/usr/share/gcc-data/x86_64-pc-cygwin/7.3.0/*.awk -rw-r--r-- 1 SEden Domain Users 8,5K 11. Jun 14:19 /gentoo/usr/share/gcc-data/x86_64-pc-cygwin/7.3.0/fixlafiles.awk --------
Created attachment 535646 [details, diff] Fix gcc-7.3.0-r3.ebuild for cygwin Although I had this postinst issue, gcc seems to have been merged just fine. I have synced my ebuild with the portage tree version and am re-emerging now. Until then, the uploaded patch fixes the libgomp issue.
// probably means \\ on cygwin, which means remote fileshare, am I right? haubi's fixes probably take care of the ssp disabling.
(In reply to Fabian Groffen from comment #12) > // probably means \\ on cygwin, which means remote fileshare, am I right? > > haubi's fixes probably take care of the ssp disabling. Sorry, but you are wrong. There is neither a remote filesystem within my setup, nor does Cygwin understand any '\\' addresses. Honestly I have no idea why there are two slashes. ..oh wait... In toolchain.eclass it reads: -------- cp "${ROOT}${DATAPATH}"/fixlafiles.awk ... -------- ROOT is just "/" and DATAPATH is starting with a "/". So that's in order. However, Michael disabled the ssp USE flag on all gcc versions on Cygwin, but that is not enough. The build system will automatically try to build its own libgomp unless told to explicitly use the system provided ssp. (See comment from cygport) When I tried my fix the configure output even had a text in it telling me that, among various other parts, libgomp will not be built, and this time it worked. I am now on gcc-7.3.0 :-)
(In reply to Sven Eden from comment #13) > When I tried my fix the configure output even had a text in it telling me > that, among various other parts, libgomp will not be built, and this time it > worked. That was wrong of course. The exact text is: -------- *** This configuration is not supported in the following subdirectories: zlib target-libgo gnattools gotools target-libada target-libhsail-rt target-libffi target-libobjc target-libcilkrts target-liboffloadmic target-libsanitizer target-libvtv target-libmpx target-libssp (Any other directories should still work fine.) -------- and that was completely irrelevant. However, the build succeeds, only the error in postinst is a bit irritating. I have investigated a bit further: * The double slash comes from using ${ROOT}${DATAPATH}, as the latter has $EPREFIX, which begins with a slash. ROOT is only the slash, so this is seemingly in order. * However, if I copy the command, I get: -------- $ cp //gentoo/usr/share/gcc-data/x86_64-pc-cygwin/7.3.0/fixlafiles.awk /gentoo/usr/share/gcc-data/ cp: cannot stat '//gentoo/usr/share/gcc-data/x86_64-pc-cygwin/7.3.0/fixlafiles.awk': No such file or directory -------- With a single slash it works. * Now if I use the cygpath command to make a windows path from the double slashed variant, it returns a double backslashed path, which _is_ a network path. * But taking that network path converting back to unix with the cygpath command, I get the original path with a single slash. I think that is a problem with Cygwin, and I should report this as a bug. -=-However-=- : The previous gcc versions merged just fine, so where does this error come from? I wanted to use 'git blame' on the toolchain.eclass, to see whether postinst was changed recently, but I am on webrsync, so no git info for me. :-(
Yep, its definitely Cygwins fault: Every GNU/Linux system: $ stat -c "%2n %f %i" / // / 41ed 48976645948727610 // 41ed 48976645948727610 Cygwin: $ stat -c "%2n %f %i" / // / 41ed 4222124652325260 // 416d 18014896789143535314 I am sending a mail to their mailing list, lets see what they have to say. In the meantime: How can we ensure that paths do not begin with double slashes on Cygwin? I am completely at sea with this...
Hrmpf. I found this commit: https://github.com/gentoo/gentoo/commit/bf1a95b7af6073408aa5a3d40931df67d59f8d2c It "fixed" the path from ${ROOT}/${DATAPATH} (leading to /// -> working fine) to the now problematic ${ROOT}${DATAPATH} (leading to // -> not working) And wherever I look, ROOT is meant to be '/' and EPREFIX is meant to start with a slash. Actually I haven't found a situation where ROOT can be something else, but I bet there is a damn good reason for its existence.
(In reply to Sven Eden from comment #15) > Yep, its definitely Cygwins fault: Well, yes and no: They won't "fix" it. Cygwin is known to distinguish "/" from "//", as in "//" to be used as "//server.name/sambashare/", much like Windows itself does "\\server.name\sambashare\". However, "/." is equal to "/./.", "///.": $ for x in // /./ ///; do echo "/ equal to $x: " $(test / -ef $x && echo yes || echo no); done / equal to //: no / equal to /./: yes / equal to ///: yes > In the meantime: How can we ensure that paths do not begin with double > slashes on Cygwin? I am completely at sea with this... Although it is preferred to ensure one single leading slash: When this was hard, I have worked around using one of the above, like ROOT="/./"
(In reply to Sven Eden from comment #16) > And wherever I look, ROOT is meant to be '/' and EPREFIX is meant to start > with a slash. Actually I haven't found a situation where ROOT can be > something else, but I bet there is a damn good reason for its existence. Things get more sophisticated recently, because EAPI 7 defines all those ROOT+D variables to _not_ have the trailing slash any more. To be EAPI agnostic, ROOT+D variables need to be used like this now: - rm -rf "${ED}"usr/share/{man,info} - rm -rf "${ED%/}"/usr/share/{man,info}
(In reply to Michael Haubenwallner from comment #18) > - rm -rf "${ED}"usr/share/{man,info} > - rm -rf "${ED%/}"/usr/share/{man,info} this should read - rm -rf "${ED}"usr/share/{man,info} + rm -rf "${ED%/}"/usr/share/{man,info}
Created attachment 535692 [details, diff] Possible fix for toolchain.eclass (In reply to Michael Haubenwallner from comment #19) > (In reply to Michael Haubenwallner from comment #18) > > > - rm -rf "${ED}"usr/share/{man,info} > > - rm -rf "${ED%/}"/usr/share/{man,info} > > this should read > > - rm -rf "${ED}"usr/share/{man,info} > + rm -rf "${ED%/}"/usr/share/{man,info} First, sorry for thinking you where wrong. I only saw the "\\" and didn't realize that that would be the windows path Cygwin would transform "//" into. Well, if I understand you correctly, an update to the toolchain.eclass like the patch I attached would fix the issue?
That change looks good to me. The eclass still lives in prefix iirc, so can easily be applied.
(In reply to Sven Eden from comment #20) > First, sorry for thinking you where wrong. I only saw the "\\" and didn't > realize that that would be the windows path Cygwin would transform "//" into. Did have a hard time too realizing these subtleties with Cygwin ;) > Well, if I understand you correctly, an update to the toolchain.eclass like > the patch I attached would fix the issue? Basically yes, except that the same should be done with EROOT as well: - ${EROOT}usr/ + ${EROOT%/}/usr/ However, given that we still have toolchain.eclass in prefix-overlay, I'd wonder how much is/will be done in Gentoo mainline toolchain.eclass here for EAPI 7. But why isn't this a problem with gcc-6.4.0 already?
@haubi: I (very) recently synced the eclasses, so the diffs should be accurate (as in, Prefix diffs only)
Just an update: With the patches for the ebuild and toolchain.eclass, I managed to eventually see: -------- >>> sys-devel/gcc-7.3.0-r4 merged. -------- But I am not quite there, yet. Something is still fishy: -------- * Switching native-compiler to x86_64-pc-cygwin-7.3.0 ... * Updating LTO plugin symlink in /./gentoo/usr/x86_64-pc-cygwin/binutils-bin/lib/bfd-plugins [ ok ] * Running 'fix_libtool_files.sh 7.3.0' /build/portage/._unmerge_/sys-devel/gcc-7.3.0-r4/temp/environment: line 4421: fix_libtool_files.sh: command not found >>> Original instance of package unmerged safely. -------- I'll re-prepare gcc-7.3 and see whats at that line. fix_libtool_files.sh is definitely in $PATH.
(In reply to Sven Eden from comment #24) > I'll re-prepare gcc-7.3 and see whats at that line. fix_libtool_files.sh is > definitely in $PATH. Or I just look into /gentoo/var/db/pkg/sys-devel/gcc-7.3.0-r4/environment.bz2 ... PATH is set to $BINPATH, which is $EPREFIX/usr/x86_64-pc-cygwin/gcc-bin/7.3.0 - and there is no fix_libtool_files.sh there.
The update of mpfr triggered a rebuild of gcc-7.3, and this time the merge ended up with: -------- * Switching native-compiler to x86_64-pc-cygwin-7.3.0 ... * Updating LTO plugin symlink in /./gentoo/usr/x86_64-pc-cygwin/binutils-bin/lib/bfd-plugins * Running 'fix_libtool_files.sh 7.3.0' Scanning libtool files for hardcoded gcc library paths... * [1/2] Scanning /gentoo/lib ... * [2/2] Scanning /gentoo/usr/lib ... >>> Original instance of package unmerged safely. -------- So I do not know why fix_libtool_files.sh wasn't found on my first try, but this time it worked correctly. So my patches fix the issue for me.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/proj/prefix.git/commit/?id=3c6d544bad8c84e6f627fdf5a2e54fd269040de4 commit 3c6d544bad8c84e6f627fdf5a2e54fd269040de4 Author: Fabian Groffen <grobian@gentoo.org> AuthorDate: 2021-01-10 19:51:29 +0000 Commit: Fabian Groffen <grobian@gentoo.org> CommitDate: 2021-01-10 19:51:29 +0000 sys-devel/gcc-7.4.0: add fix for Cygwin, bug #657594 Closes: https://bugs.gentoo.org/657594 Package-Manager: Portage-3.0.12.0.2-prefix, Repoman-3.0.2 Signed-off-by: Fabian Groffen <grobian@gentoo.org> sys-devel/gcc/gcc-7.4.0.ebuild | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
