[Mingw-cross-env-list] Trying to use x86_64-w64-mingw32.static-g++ -fprofile-generate (inhibit_libc, bug 1665)

[Scott Douglass]

Hi,

I've built x86_64-w64-mingw32.static and I'm trying to use x86_64-w64-mingw32.static-g++ -fprofile-generate and I get link errors:

...

> x86_64-w64-mingw32.static-g++ -o hello -fprofile-generate hello.cpp

/tmp/cci0CedL.o:hello.cpp:(.text+0x1a): undefined reference to `__gcov_indirect_call_profiler_v2'

/tmp/cci0CedL.o:hello.cpp:(.text+0x46): undefined reference to `__gcov_time_profiler'

...

I believe this is probably the same problem as this issue:  https://github.com/mxe/mxe/issues/1665

I've examined logs/gcc_x86_64-w64-mingw32.static and I see that during the building of libgcov.a

  INHIBIT_LIBC_CFLAGS=-Dinhibit_libc

is being used.  This causes most of libgcov to be built as stubs and is leading to the link errors.

gcc/configure winds up setting inhibit_libs=true although it looks like it tries not to:

First it notices were configuring a cross-compiler (and sets CROSS="-DCROSS_DIRECTORY_STRUCTURE"), then it notice $target matches *-*-mingw* and sets with_headers=yes and just a bit later sets target_header_dir=$with_headers (i.e. target_header_dir=yes).  But 'yes' isn't a very good directory name and $target_header_dir/stdio.h (i.e. 'yes/stdio.h') doesn't exist so it sets inhibit_libc=true.

To work-around this I have tried:

1.  Adding '--with-build-sysroot=<abs-path-to-mxe>' to gcc_CONFIGURE_OPTS; this doesn't change the setting of inhibit_libc=true

2.  (instead) Adding '--with-sysroot=<abs-path-to-mxe>' to gcc_CONFIGURE_OPTS; now we do not get inhibit_libc set, but the build fails with the message

The directory that should contain system headers does not exist:

  <abs-path-to-mxe>/mingw/include 

The "/mingw/include" is coming from config.gcc which is setting native_system_header_dir=/mingw/include, but I haven't figured out why yet.

Any suggestions on how to get a build without 'inhibit_libc'?  Would you expect it to work by default?

Thanks.

According to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854368 Debian has fixed/worked-around this problem, but I don't understand what their change was.