When building cross-mingw32/gcc-5.3.0 with USE=fortran, the build dies with an error in libgfortran: /tmp/portage/cross-mingw32/gcc-5.3.0/work/gcc-5.3.0/libgfortran/intrinsics/chmod.c: In function 'chmod_internal': /tmp/portage/cross-mingw32/gcc-5.3.0/work/gcc-5.3.0/libgfortran/intrinsics/chmod.c:109:15: error: implicit declaration of function 'umask' [-Werror=implicit-function-declaration]
Created attachment 419436 [details] emerge --info
Created attachment 419438 [details] gcc-build-logs.tar.bz2
*** Bug 568658 has been marked as a duplicate of this bug. ***
Is any additional information needed to help fix this?
(In reply to Dennis Schridde from comment #4) not really. needs someone to investigate/fix. i don't consider fortran a critical language, so i don't tend to prioritize it.
# cd /var/tmp/portage/cross-mingw32/gcc-5.3.0/work # grep UMASK build/mingw32/libgfortran/config.h #define HAVE_UMASK 1 # grep umask build/mingw32/libgfortran/config.log configure:16544: checking for umask ac_cv_func_umask=yes gcc-5.3.0/libgfortran/configure.ac has umask as part of an AC_CHECK_FUNCS_ONCE list. # grep --binary-files=without-match -r umask /usr/mingw32 /usr/mingw32/usr/include/io.h:/* Should umask be in sys/stat.h and/or sys/types.h instead? */ /usr/mingw32/usr/include/io.h:_CRTIMP int __cdecl __MINGW_NOTHROW _umask (int); /usr/mingw32/usr/include/io.h:_CRTIMP int __cdecl __MINGW_NOTHROW umask (int); # grep -r umask gcc-5.3.0/libgfortran/io/io.h # qfile -v /usr/mingw32/usr/include/io.h cross-mingw32/mingw-runtime-3.20.2 (/usr/mingw32/usr/include/io.h) So the configure check likely sees the header from mingw-runtime, while the compiler sees the one from the gcc source tree. At least that's the most plausible explanation I could find. Can we somehow force configure to not detect that function, without being too hackish?
I managed to build this cross gcc: # ebuild $(equery w cross-mingw32/gcc) unpack # cd /var/tmp/portage/cross-mingw32/gcc-5.3.0/work # patch gcc-5.3.0/libgfortran/config.h.in << EOF --- gcc-5.3.0/libgfortran/config.h.in.orig +++ gcc-5.3.0/libgfortran/config.h.in @@ -841,7 +841,9 @@ #undef HAVE_UINTPTR_T /* Define to 1 if you have the `umask' function. */ +#ifndef _WIN32 #undef HAVE_UMASK +#endif /* Define to 1 if you have the <unistd.h> header file. */ #undef HAVE_UNISTD_H EOF # cd # ebuild $(equery w cross-mingw32/gcc) merge Would such a change to the header be acceptable unconditionally, or would that break builds on Windows? It's only the umask support in fortran, so even if it disables a feature which would otherwise be available on Windows, I personally don't think it's a huge problem. But I might be wrong. If you want to play it safe, find a way for the ebuild to only apply this patch conditionally, or for the patch to only affect cross builds. Or change the declaration of umask in the mingw runtime. Or the name of the io.h header in gcc.
(In reply to Martin von Gagern from comment #7) config.h.in is a generated file that should (cannot) be modified. you should look at the configure script and figure out why the umask test is passing. it should be failing which means HAVE_UMASK would not be defined.
Created attachment 423460 [details, diff] Include <io.h> if it exists I had another look. Perhaps gcc-5.3.0/libgfortran/io/io.h is the wrong place to look. After all, it's in a subdirectory so it shouldn't accidentially shadow the <io.h> provided by mingw-runtime. Looking at the configure script, I see that configure tests whether the given function can be LINKED against. When compiling the conftest code, it provides a (bogus) prototype itself. So at that point we know that there us a umask symbol in the MinGW runtime libs. Then later the compiler complains about implicit declaration of umask, since it's lacking the right header. That's because for some reason the header defining umask in MinGW (and apparently Windows CRT as well) is io.h not sys/stat.h. This patch here SHOULD do just that. Unfortunately I couldn't get the ebuild to regenerate the configure script and config.h.in in the libgfortran directory yet. So the patch contains two hunks to simulate that effect. If you can get a proper reconfig working there, feel free to just remove those two hunks from the file. But even with the two extra hunks included, the build fails during the install phase: mv: cannot stat ‘/var/tmp/portage/cross-mingw32/gcc-5.3.0/image//usr/lib/libcc1*’: No such file or directory * Call stack: * ebuild.sh, line 133: Called src_install * environment, line 3781: Called toolchain_src_install * environment, line 4884: Called gcc_movelibs * environment, line 1985: Called die * The specific snippet of code: * mv "${D}"/usr/$(get_libdir)/libcc1* "${D}${HOSTLIBPATH}" || die; I can't see how this would be related, but it seems to be due to the distinction between lib and lib64 on my system: # ls /var/tmp/portage/cross-mingw32/gcc-5.3.0/image/usr/lib*/libcc1* /var/tmp/portage/cross-mingw32/gcc-5.3.0/image/usr/lib64/libcc1.la /var/tmp/portage/cross-mingw32/gcc-5.3.0/image/usr/lib64/libcc1.so /var/tmp/portage/cross-mingw32/gcc-5.3.0/image/usr/lib64/libcc1.so.0 /var/tmp/portage/cross-mingw32/gcc-5.3.0/image/usr/lib64/libcc1.so.0.0.0
It appears that both issues (io.h - patch provided by Martin, and lib64 - probably solvable using get_libdir) could be fixed. Is there an ETA on when these fixes will appear in the Gentoo tree?
A month later: Vapier, is this somewhere on your to-do list? Is there any possibility to prioritise this higher?
(In reply to Martin von Gagern from comment #9) i just built gcc-5.3.0[fortran] fine w/mingw64-runtime-3.0.0 and 4.0.4. sys/stat.h includes io.h explicitly, so the umask prototype is available via that header. you can see this by running: $ i686-w64-mingw32-gcc -E -include sys/stat.h - <<<'' |& grep umask __attribute__ ((__dllimport__)) int __attribute__((__cdecl__)) _umask(int _Mode) ; int __attribute__((__cdecl__)) umask(int _Mode) ; if you look at umask.c, it has an explicit include: #ifdef HAVE_SYS_STAT_H #include <sys/stat.h> #endif if we look at the config.log for libgfortran on your system, it found it fine: configure:4861: checking for sys/stat.h configure:4861: /tmp/portage/cross-mingw32/gcc-5.3.0/work/build/./gcc/xgcc -B/tmp/portage/cross-mingw32/gcc-5.3.0/work/build/./gcc/ -L/tmp/portage/cross-mingw32/gcc-5.3.0/work/build/mingw32/winsup/mingw -L/tmp/portage/cross-mingw32/gcc-5.3.0/work/build/mingw32/winsup/w32api/lib -isystem /tmp/portage/cross-mingw32/gcc-5.3.0/work/gcc-5.3.0/winsup/mingw/include -isystem /tmp/portage/cross-mingw32/gcc-5.3.0/work/gcc-5.3.0/winsup/w32api/include -B/usr/mingw32/bin/ -B/usr/mingw32/lib/ -isystem /usr/mingw32/include -isystem /usr/mingw32/sys-include -c -g -O2 conftest.c >&5 configure:4861: $? = 0 configure:4861: result: yes so the question becomes: why doesn't sys/stat.h on your side include io.h and/or define umask explicitly ? this bug has nothing to do with lib64 file collisions (although that has been fixed in an independent bug by this point).
(In reply to SpanKY from comment #12) > (In reply to Martin von Gagern from comment #9) > > i just built gcc-5.3.0[fortran] fine w/mingw64-runtime-3.0.0 and 4.0.4. > > sys/stat.h includes io.h explicitly, so the umask prototype is available via > that header. you can see this by running: > $ i686-w64-mingw32-gcc -E -include sys/stat.h - <<<'' |& grep umask I think there is one important difference between the different target triplets involved: * i686-w64-mingw32 builds fine on your side * x86_64-w64-mingw32 builds fine on my side * i686-w32-mingw32 shows the abovementioned error The difference between w32 and w64 appears to be that the former uses dev-util/mingw-runtime, while the latter uses dev-util/mingw64-runtime.
(In reply to Dennis Schridde from comment #13) check the headers as i did. if dev-util/mingw-runtime isn't including things, then it's broken, not gcc.
(In reply to SpanKY from comment #14) > check the headers as i did. if dev-util/mingw-runtime isn't including > things, then it's broken, not gcc. Thanks for the hint. It seems it indeed is not including io.h: # grep -R umask --binary-files=without-match /usr/i686-w32-mingw32/ /usr/i686-w32-mingw32/usr/include/io.h:/* Should umask be in sys/stat.h and/or sys/types.h instead? */ /usr/i686-w32-mingw32/usr/include/io.h:_CRTIMP int __cdecl __MINGW_NOTHROW _umask (int); /usr/i686-w32-mingw32/usr/include/io.h:_CRTIMP int __cdecl __MINGW_NOTHROW umask (int); /usr/i686-w32-mingw32/mingw/include/io.h:/* Should umask be in sys/stat.h and/or sys/types.h instead? */ /usr/i686-w32-mingw32/mingw/include/io.h:_CRTIMP int __cdecl __MINGW_NOTHROW _umask (int); /usr/i686-w32-mingw32/mingw/include/io.h:_CRTIMP int __cdecl __MINGW_NOTHROW umask (int); The summary of this report should probably be changed to: cross-i686-w32-mingw32/mingw-runtime with cross-i686-w32-mingw32/gcc-5.3.0[fortran]: error: implicit declaration of function 'umask'
P.S: Mike is right, man 3p umask says: SYNOPSIS #include <sys/stat.h> mode_t umask(mode_t cmask); Thus including io.h would be wrong.
Hi, There is no reason to use the old mingw project, it is less maintained (if any) compared to mingw-w64 project. The mingw-w64 can produce both i686 and x86_64 binaries.
(In reply to Alon Bar-Lev from comment #17) > Hi, > There is no reason to use the old mingw project, it is less maintained (if > any) compared to mingw-w64 project. > The mingw-w64 can produce both i686 and x86_64 binaries. So you're planning to tree-clean dev-util/mingw-runtime and make sys-devel/crossdev use dev-util/mingw64-runtime in the future?
(In reply to Dennis Schridde from comment #18) sounds like the sensible thing to do
(In reply to SpanKY from comment #19) > sounds like the sensible thing to do Is there something I can do to help fix this?
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c61bbbef5950cf52bf752043efcb7ce68357cb7e commit c61bbbef5950cf52bf752043efcb7ce68357cb7e Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2019-10-20 08:35:26 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2019-10-20 08:41:40 +0000 dev-util/w32api, dev-util/mingw-runtime: drop packages Drop mingw-runtime-based packages. Use mingw64-runtime-based ones instead. Here are example mingw64-based tuples to use: - i686-w64-mingw32 (equivalent of mingw32) - x86_64-w64-mingw32 (equivalent on migw64?) crossdev can be used to recreate new cross-environment. Closes: https://bugs.gentoo.org/584858 Closes: https://bugs.gentoo.org/511492 Closes: https://bugs.gentoo.org/568500 Closes: https://bugs.gentoo.org/574556 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> dev-util/mingw-runtime/Manifest | 4 - .../files/mingw-runtime-3.18-gcc-4.6.patch | 27 ---- .../files/mingw-runtime-3.20-LDBL_MIN_EXP.patch | 145 --------------------- dev-util/mingw-runtime/metadata.xml | 11 -- dev-util/mingw-runtime/mingw-runtime-3.18.ebuild | 76 ----------- dev-util/mingw-runtime/mingw-runtime-3.20.2.ebuild | 77 ----------- dev-util/mingw-runtime/mingw-runtime-3.20.ebuild | 75 ----------- .../mingw-runtime/mingw-runtime-4.0.3.1.ebuild | 82 ------------ dev-util/w32api/Manifest | 2 - dev-util/w32api/metadata.xml | 11 -- dev-util/w32api/w32api-3.17.2.ebuild | 64 --------- dev-util/w32api/w32api-4.0.3.1.ebuild | 66 ---------- profiles/package.mask | 2 - 13 files changed, 642 deletions(-)
