mstorsjo / llvm-mingw

An LLVM/Clang/LLD based mingw-w64 toolchain

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

libMSVCRTD.a and libOLDNAMES.a are missing.

top-master opened this issue · comments

786 (math code)

Version: llvm-mingw-20231128-msvcrt-i686 (which's current latest).

Issue:

ld.lld: error: could not open 'libMSVCRTD.a': No such file or directory
ld.lld: error: could not open 'libOLDNAMES.a': No such file or directory

I checked installation and there was really no libmsvcrtd.a file anywhere, but there was one without the "D" suffix (the libmsvcrt.a file).

There is also NOT any liboldnames.a named file (but there was an "M" prefixed file, the libmoldname.a file).

Little test:

I copied and renamed from libmsvcrt.a to libmsvcrtd.a,
and from libmoldname.a to liboldnames.a.

Result; now build process goes further, but of course, I have few missing symbols, which I guess are part of the real "libmsvcrtd.a" file but not part of my copy-paste, see:
https://stackoverflow.com/a/25274090/8740349

ld.lld: error: undefined symbol: ___report_rangecheckfailure
>>> referenced by qtpcre.lib(pcre16_jit_compile.obj):(_fast_forward_first_n_chars)
>>> referenced by qtpcre.lib(pcre16_compile.obj):(_get_ucp)

ld.lld: error: undefined symbol: @__security_check_cookie@4
>>> referenced by qtpcre.lib(pcre16_jit_compile.obj):(@sljit_grow_stack@4)
>>> referenced by qtpcre.lib(pcre16_jit_compile.obj):(_fast_forward_first_char2_sse2)
>>> referenced by qtpcre.lib(pcre16_jit_compile.obj):(_fast_forward_first_n_chars)
>>> referenced 41 more times

ld.lld: error: undefined symbol: __alloca_probe_16
>>> referenced by qtpcre.lib(pcre16_jit_compile.obj):(@sljit_grow_stack@4)

ld.lld: error: undefined symbol: __chkstk
>>> referenced by qtpcre.lib(pcre16_jit_compile.obj):(_jit_machine_stack_exec)
>>> referenced by qtpcre.lib(pcre16_compile.obj):(_pcre16_compile2)

ld.lld: error: undefined symbol: ___security_cookie
>>> referenced by qtpcre.lib(pcre16_jit_compile.obj):(@sljit_grow_stack@4)
>>> referenced by qtpcre.lib(pcre16_jit_compile.obj):(_fast_forward_first_char2_sse2)
>>> referenced by qtpcre.lib(pcre16_jit_compile.obj):(_fast_forward_first_n_chars)
>>> referenced 12 more times

ld.lld: error: undefined symbol: __fltused
>>> referenced by qtpcre.lib(pcre16_compile.obj)
clang-17: error: linker command failed with exit code 1

You didn't specify what the actual setup is, what you're trying to do. From the symptoms, it sounds like you're trying to link static libraries built with an MSVC environments, with an mingw toolchain. That's not supported - no mingw toolchains support linking MSVC built static libraries.

You mean that the libmsvcrtd.a is intentionally NOT part of your package(s), and that libmsvcrt.a without d is enough to build both debug and release builds???

In mingw environments, there is no library provided for linking against msvcrtd - that is intentional.

Mingw environments do not use a library named msvcrt, only MSVC environments use that, and mixing MSVC and mingw environments in that way is not supported.

Also, we legally cannot redistribute the debug version of the various runtime dll, so even if we distribute the import library for it, you still need to source the dll by hand, by installing the Windows SDK, which the whole point of mingw-w64 is to avoid in the first place.

The MSVC's /GS option is enabled by default, which injects "__report_rangecheckfailure" dependency, I thought maybe MingW has such option/feature, but seems not, else the /GS- or -GS- option wouldn't raise error.

Then I reviewed my Makefile, and there was correctly the -lqtpcre option.

The problem was that the -lqtpcre option allows both libqtpcre.a and qtpcre.lib, while I had an old qtpcre.lib somewhere.

Is there any way to disable .lib and force .a instead, or is my only option removing .lib files from searched paths???

.a should already be prioritized over .lib
https://github.com/llvm/llvm-project/blob/1d5106d69cf475215887c42834158d710e586f1b/lld/MinGW/Driver.cpp#L146-L149

Is your file named libqtpcre.a exactly?

The -L paths have order.
What if the libqtpcre.a file is in one of my -L paths,
but the qtpcre.lib file is in another -L path which's before the .a file's path?

However, in my case libqtpcre.a was not built yet, hence the existing .lib got used.

To avoid future repeat of similar mistakes I would like a "way to disable .lib and force .a instead", which is possible because my project does not need any 3rd-party .lib file, just my own .a files.

It would be nice to have a compiler that warns like:

Failed to find "libqtpcre.a" file.
Note: ignored candidate "C:\my-folder\qtpcre.lib"
(because of `-force-a-lib` option).

However, I hope you can answer even after I close this, thanks for your time.

Today I met a similar issue, where llvm-Mingw was configured to create only the .dll file, and llvm-Mingw is even later able to link my other things to said .dll file, without ever needing the .a file related to the .dll file.

But the problem arises when we have in our library search-path, for example, these files:

libQt5Core.dll
Qt5Core.dll
Qt5Core.lib

Now although llvm-Mingw can link to libQt5Core.dll file without needing the .a file, llvm-Mingw never checks that, since a .lib file exists.

You may have seen many projects which provide different binaries, each built for a different compiler, similarly one may need Qt to be pre-built for both MSVC and Mingw, hence having MSVC binary there is not the issue.

Maybe the issue is that llvm-Mingw does not prioritize lib prefixed .dll files over other .dll files, however, corrently I work-around this by ensuring the .a file gets built.