undefined reference to `__imp__cprintf' during build x86_64-w64-mingw32 on Windows

[SuperKogito]

I am trying to build OpenBlas so I can use blas_sgemm() on Windows 10 using x86_64-w64-mingw32. Unfortunately, I keep running across this error, when running the make command. I did not specify any extra arguments.

ar -ru ../../../libopenblas_skylakexp-r0.3.24.a lapacke_cgb_nancheck.o lapacke_cgb_trans.o lapacke_cge_nancheck.o lapacke_cge_trans.o lapacke_cgg_nancheck.o lapacke_cgg_trans.o lapacke_cgt_nancheck.o lapacke_chb_nancheck.o lapacke_chb_trans.o lapacke_che_nancheck.o lapacke_che_trans.o lapacke_chp_nancheck.o lapacke_chp_trans.o lapacke_chs_nancheck.o lapacke_chs_trans.o lapacke_c_nancheck.o lapacke_cpb_nancheck.o lapacke_cpb_trans.o lapacke_cpf_nancheck.o lapacke_cpf_trans.o lapacke_cpo_nancheck.o lapacke_cpo_trans.o lapacke_cpp_nancheck.o lapacke_cpp_trans.o lapacke_cpt_nancheck.o lapacke_csp_nancheck.o lapacke_csp_trans.o lapacke_cst_nancheck.o lapacke_csy_nancheck.o lapacke_csy_trans.o lapacke_ctb_nancheck.o lapacke_ctb_trans.o lapacke_ctf_nancheck.o lapacke_ctf_trans.o lapacke_ctp_nancheck.o lapacke_ctp_trans.o lapacke_ctr_nancheck.o lapacke_ctr_trans.o lapacke_ctz_nancheck.o lapacke_ctz_trans.o lapacke_dgb_nancheck.o lapacke_dgb_trans.o lapacke_dge_nancheck.o lapacke_dge_trans.o lapacke_dgg_nancheck.o lapacke_dgg_trans.o lapacke_dgt_nancheck.o lapacke_dhs_nancheck.o lapacke_dhs_trans.o lapacke_d_nancheck.o lapacke_dpb_nancheck.o lapacke_dpb_trans.o lapacke_dpf_nancheck.o lapacke_dpf_trans.o lapacke_dpo_nancheck.o lapacke_dpo_trans.o lapacke_dpp_nancheck.o lapacke_dpp_trans.o lapacke_dpt_nancheck.o lapacke_dsb_nancheck.o lapacke_dsb_trans.o lapacke_dsp_nancheck.o lapacke_dsp_trans.o lapacke_dst_nancheck.o lapacke_dsy_nancheck.o lapacke_dsy_trans.o lapacke_dtb_nancheck.o lapacke_dtb_trans.o lapacke_dtf_nancheck.o lapacke_dtf_trans.o lapacke_dtp_nancheck.o lapacke_dtp_trans.o lapacke_dtr_nancheck.o lapacke_dtr_trans.o lapacke_dtz_nancheck.o lapacke_dtz_trans.o lapacke_lsame.o lapacke_sgb_nancheck.o lapacke_sgb_trans.o lapacke_sge_nancheck.o lapacke_sge_trans.o lapacke_sgg_nancheck.o lapacke_sgg_trans.o lapacke_sgt_nancheck.o lapacke_shs_nancheck.o lapacke_shs_trans.o lapacke_s_nancheck.o lapacke_spb_nancheck.o lapacke_spb_trans.o lapacke_spf_nancheck.o lapacke_spf_trans.o lapacke_spo_nancheck.o lapacke_spo_trans.o lapacke_spp_nancheck.o lapacke_spp_trans.o lapacke_spt_nancheck.o lapacke_ssb_nancheck.o lapacke_ssb_trans.o lapacke_ssp_nancheck.o lapacke_ssp_trans.o lapacke_sst_nancheck.o lapacke_ssy_nancheck.o lapacke_ssy_trans.o lapacke_stb_nancheck.o lapacke_stb_trans.o lapacke_stf_nancheck.o lapacke_stf_trans.o lapacke_stp_nancheck.o lapacke_stp_trans.o lapacke_str_nancheck.o lapacke_str_trans.o lapacke_stz_nancheck.o lapacke_stz_trans.o lapacke_xerbla.o lapacke_zgb_nancheck.o lapacke_zgb_trans.o lapacke_zge_nancheck.o lapacke_zge_trans.o lapacke_zgg_nancheck.o lapacke_zgg_trans.o lapacke_zgt_nancheck.o lapacke_zhb_nancheck.o lapacke_zhb_trans.o lapacke_zhe_nancheck.o lapacke_zhe_trans.o lapacke_zhp_nancheck.o lapacke_zhp_trans.o lapacke_zhs_nancheck.o lapacke_zhs_trans.o lapacke_z_nancheck.o lapacke_zpb_nancheck.o lapacke_zpb_trans.o lapacke_zpf_nancheck.o lapacke_zpf_trans.o lapacke_zpo_nancheck.o lapacke_zpo_trans.o lapacke_zpp_nancheck.o lapacke_zpp_trans.o lapacke_zpt_nancheck.o lapacke_zsp_nancheck.o lapacke_zsp_trans.o lapacke_zst_nancheck.o lapacke_zsy_nancheck.o lapacke_zsy_trans.o lapacke_ztb_nancheck.o lapacke_ztb_trans.o lapacke_ztf_nancheck.o lapacke_ztf_trans.o lapacke_ztp_nancheck.o lapacke_ztp_trans.o lapacke_ztr_nancheck.o lapacke_ztr_trans.o lapacke_ztz_nancheck.o lapacke_ztz_trans.o lapacke_make_complex_float.o lapacke_make_complex_double.o
ranlib ../../../libopenblas_skylakexp-r0.3.24.a
make[3]: Leaving directory 'D:/Users/superkogito/Desktop/workspace/OpenBLAS-0.3.24/lapack-netlib/LAPACKE/utils'
make[2]: Leaving directory 'D:/Users/superkogito/Desktop/workspace/OpenBLAS-0.3.24/lapack-netlib/LAPACKE'
make[1]: Leaving directory 'D:/Users/superkogito/Desktop/workspace/OpenBLAS-0.3.24/lapack-netlib'
make[1]: Entering directory 'D:/Users/superkogito/Desktop/workspace/OpenBLAS-0.3.24/exports'
make[1]: warning: -j8 forced in makefile: resetting jobserver mode.
./gensymbol win2k    x86_64 dummy 0 0 0 0 0 0 "" "" 1 0 1 1 1 1 > libopenblas.def
cc -O2 -DSMALL_MATRIX_OPT -DMS_ABI -DMAX_STACK_ALLOC=2048 -Wall -m64 -DF_INTERFACE_GFORT -DSMP_SERVER -DNO_WARMUP -DMAX_CPU_NUMBER=8 -DMAX_PARALLEL_NUMBER=1 -DBUILD_SINGLE=1 -DBUILD_DOUBLE=1 -DBUILD_COMPLEX=1 -DBUILD_COMPLEX16=1 -DVERSION=\"0.3.24\" -msse3 -mssse3 -msse4.1 -mavx -mavx2 -march=skylake-avx512 -fno-asynchronous-unwind-tables -mavx2 -UASMNAME -UASMFNAME -UNAME -UCNAME -UCHAR_NAME -UCHAR_CNAME -DASMNAME=dllinit -DASMFNAME=dllinit_ -DNAME=dllinit_ -DCNAME=dllinit -DCHAR_NAME=\"dllinit_\" -DCHAR_CNAME=\"dllinit\" -DNO_AFFINITY -I.. -c -o dllinit.obj -s dllinit.c
ranlib ../libopenblas_skylakexp-r0.3.24.a
cc -O2 -DSMALL_MATRIX_OPT -DMS_ABI -DMAX_STACK_ALLOC=2048 -Wall -m64 -DF_INTERFACE_GFORT -DSMP_SERVER -DNO_WARMUP -DMAX_CPU_NUMBER=8 -DMAX_PARALLEL_NUMBER=1 -DBUILD_SINGLE=1 -DBUILD_DOUBLE=1 -DBUILD_COMPLEX=1 -DBUILD_COMPLEX16=1 -DVERSION=\"0.3.24\" -msse3 -mssse3 -msse4.1 -mavx -mavx2 -march=skylake-avx512 -fno-asynchronous-unwind-tables -mavx2 -UASMNAME -UASMFNAME -UNAME -UCNAME -UCHAR_NAME -UCHAR_CNAME -DASMNAME= -DASMFNAME=_ -DNAME=_ -DCNAME= -DCHAR_NAME=\"_\" -DCHAR_CNAME=\"\" -DNO_AFFINITY -I..  libopenblas.def dllinit.obj \
-shared -o ../libopenblas.dll -Wl,--out-implib,../libopenblas.dll.a \
-Wl,--whole-archive ../libopenblas_skylakexp-r0.3.24.a -Wl,--no-whole-archive -Lc:/programdata/chocolatey/lib/mingw/tools/install/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0 -Lc:/programdata/chocolatey/lib/mingw/tools/install/mingw64/bin/../lib/gcc -Lc:/programdata/chocolatey/lib/mingw/tools/install/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/lib/../lib -Lc:/programdata/chocolatey/lib/mingw/tools/install/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../lib -Lc:/programdata/chocolatey/lib/mingw/tools/install/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/lib -Lc:/programdata/chocolatey/lib/mingw/tools/install/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../..  -lgfortran -lmoldname -lmingwex -lmsvcrt -lquadmath -lm -lmoldname -lmingwex -lmsvcrt -lpthread -lmoldname -lmingwex -lmsvcrt  -defaultlib:advapi32 -lgfortran -defaultlib:advapi32 -lgfortran
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: ../libopenblas_skylakexp-r0.3.24.a(memory.obj):memory.c:(.text+0x6c2): undefined reference to `__imp__cprintf'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: ../libopenblas_skylakexp-r0.3.24.a(memory.obj):memory.c:(.text+0x7f7): undefined reference to `__imp__cprintf'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: ../libopenblas_skylakexp-r0.3.24.a(xerbla.obj):xerbla.c:(.text+0x13): undefined reference to `__imp__cprintf'
collect2.exe: error: ld returned 1 exit status
make[1]: *** [Makefile:124: ../libopenblas.dll] Error 1
make[1]: Leaving directory 'D:/Users/superkogito/Desktop/workspace/OpenBLAS-0.3.24/exports'
make: *** [Makefile:146: shared] Error 2

I already tried make clean and installing the mingw dependencies as mentioned here, but no luck:

• undefined reference to `__imp__cprintf' #658
• Cimpile OpenBLAS 0.2.20 Failed under Windows 10 X64 with msys2  #1306

My GCC version is:

gcc --version
gcc.exe (MinGW-W64 x86_64-ucrt-posix-seh, built by Brecht Sanders) 12.2.0

Any help on how to solve this is appreciated.
Thank you.

[martin-frbg]

did you install the gcc-fortran part(s) of mingw as well ?

[SuperKogito]

Yes as discussed #1306, unless I am missing something.

[martin-frbg]

gfortran dev package looks to be a different version ?

[SuperKogito]

I updated the MinGW installation manager catalogue but no updated/newer version is available. I will remove the dev version and try to build again, although I don't think this should affect my installation since as mentioned #1306

It should skip all fortran components (LAPACK) in absence of compiler and hopefully wrongly set compiler too.

And I already tried the build without the fortran installation and it also failed.
I should mention that I am running this on my work pc which includes some corporate firewall and proxy, can these possibly affect the build process?

[brada4]

Corporate network profile might be on a network share or under aggressive virus control.
Try c:/users/public as stable local filesystem.
Or setting MAKE_NB_JOBS=2 to avoid microbe races on shares

[SuperKogito]

Can you please elaborate on this. I am not sure I understand it

Try c:/users/public as stable local filesystem.

[brada4]

errno 1 is permission denied which means that your admin is better positioned to help. It can be your profile syncing to a file server or antivirus nagging you with background scan. You can have mingw cross-compiler in linux if you cannot get normal filesystem on windows.

[martin-frbg]

I get the feeling that all the discussion around the fortran part of mingw in earlier issues were either misunderstandings or symptoms of an incomplete or broken installation of the cross-compiler in general. _cprintf is specifically declared to override the generic printf (in drivers/other/memory.c and drivers/other/xerbla.c) when compiling with mingw like this

https://github.com/martin-frbg/OpenBLAS/blob/425bcc1f8bc36571221e9babf8aea0b66ad03fba/driver/others/xerbla.c#L43-L47

#if defined(OS_WINDOWS) && (defined(__MINGW32__) || defined(__MINGW64__))
#include <conio.h>
#undef  printf
#define printf	_cprintf
#endif

and this code fragment appears to be unchanged from the original GotoBLAS of >15 years ago. My (older) mingw-gcc on Linux which I use to cross-build the Windows packages appears to provide the implementations in its libmsvcrt , so maybe this is a question of setting up the library paths for linking ?

[martin-frbg]

Suspect that the ucrt in your gcc version string may be the key here - perhaps it would be worth a try to remove the above five lines from both files.

[martin-frbg]

Getting a flawless build with an unmodified current develop branch and "MinGW-W64 x86_64-ucrt-mcf-seh, built by Brecht Sanders 13.2.0", from winlibs.com. Builds with "your" MinGW-W64 x86_64-ucrt-posix-seh, built by Brecht Sanders) 12.2.0 are currently timing out in the Azure cloud before they reach the critical link step, probably from getting scheduled on slower hardware.

[martin-frbg]

Built fine with MinGW-W64-x86_64-ucrt-posix-seh as well (once I reduced the build size to fit into Azure's time constraint).
So it is looking like an installation problem on your end again - all I did was download the single prebuilt archive from Brecht Sanders' site, unpack it somewhere and prepend its installation directory to the windows PATH variable.

    mkdir winlib
      cd winlib
      curl -L -o mingw64.zip https://github.com/brechtsanders/winlibs_mingw/releases/download/12.2.0-16.0.0-10.0.0-ucrt-r5/winlibs-x86_64-posix-seh-gcc-12.2.0-mingw-w64ucrt-10.0.0-r5.zip
      dir
      tar -xf mingw64.zip
      set PATH=%cd%\mingw64\bin;%PATH%

And I notice now that all the MinGW packages shown in your screenshot appear to be much older versions (4.8.2, 6.3.0) than the 12.2.0 from gcc -v (or even 13.1.0 - from the path names in your first make output ?) in your first post. Either you showed output from multiple computers, or your system has multiple (and probably conflicting?) mingw/gcc versions installed, only some of which show up in MinGW's installation manager. As Brecht Sanders' packages are "simply unpack and use", they will probably not show up anywhere in either MinGW's or Windows' installed software list. Make sure that you have the one you want to use first in your PATH

[martin-frbg]

And @brada4 I'm fairly sure the "error 1" reported by mingw32-make is simply the Unix-style exit code "failure" (of the preceding MinGW ld call) and not something from any Windows component. (I'm not even aware of there being a unique definition of this code across all Windows components, where did you get the "permission denied" from ?)

[SuperKogito]

I think this could be related to my setup, I have a very weird hybrid setup at this point and I am not even sure where to start. I tried to build within CLion but I got a different errors. However, finally I managed to install a compatible OpenBLAS from here https://packages.msys2.org/package/mingw-w64-x86_64-openblas?repo=mingw64
This was a much simpler install and worked like a charm. It is not built from source but it works enough for my use case.

Since my problem cannot be reproduced and seems more of a my setup issue. I suggest closing this for now. If I needed help again, I will open a new one.
Thank you so much for your efforts and help over the last couple of days, you made this debugging feel less overwhelming. ❤️

[martin-frbg]

CLion is just a commercial IDE on top of whatever compiler(s) you already have installed, or did I get that wrong ?
Anyway the msys2 package you found appears to be current (0.3.24), so you should be all good using this.
(And at least I know now that OpenBLAS compiles with the ucrt variant of mingw-gcc as well, and the imp__cprintf linker error is most likely due to mixing the paths of concurrent mingw installations.

[mmuetzel]

And at least I know now that OpenBLAS compiles with the ucrt variant of mingw-gcc as well

Would it be useful to add a runner to the existing GitHub-CI to build OpenBLAS for that environment of MSYS2?

[martin-frbg]

Thought about that, but it did not strike me as that different from the existing builds in the end.

[mmuetzel]

Given that projects start to switch to UCRT for binaries that they distribute for Windows, and the fact that mingw-w64 switched their default CRT to UCRT, we could also replace the MINGW64 runners with UCRT64 ones.
The main (only?) difference is that that environment uses binaries that link to the UCRT instead of the MSVCRT:
https://www.msys2.org/docs/environments/

[martin-frbg]

Yes, guess it would make sense to replace the MINW64 ones with UCRT64, given that old-style MSVCRT builds are also covered by Azure and Appveyor. (The alternative would seem to be to consolidate all these in runners, if the performance is consistently better - but Appveyor is only used for really ancient gcc builds anyway, not sure if these would fit in with the gh job matrix)

[mmuetzel]

(The alternative would seem to be to consolidate all these in runners, if the performance is consistently better - but Appveyor is only used for really ancient gcc builds anyway, not sure if these would fit in with the gh job matrix)

MSYS2 follows a rolling release model. That means that the compilers are always quite recent versions. I don't know if there is a way to install older versions of the compilers using MSYS2. (I'd guess there isn't.)

(If that is what you meant...)