Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

weird linking issues on windows #3402

Closed
9il opened this issue Apr 14, 2020 · 2 comments
Closed

weird linking issues on windows #3402

9il opened this issue Apr 14, 2020 · 2 comments

Comments

@9il
Copy link

9il commented Apr 14, 2020

Hi folks,

What we are doing wrong?
Is there a way to make LDC automatically link with required win-runtime libs?

So, linking the libcmt.lib or libcmtd.lib forces you to link two dependent libs as well.
Here are all the linked libs in dub.sdl:

lflags `C:\Program Files (x86)\Windows Kits\10\Lib\10.0.18362.0\um\x64\BufferOverflowU.lib` platform="windows-x86_64"
lflags `C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.25.28610\lib\x64\libcmt.lib` platform="windows-x86_64"
lflags `C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.25.28610\lib\x64\libvcruntime.lib` platform="windows-x86_64"
lflags `C:\Program Files (x86)\Windows Kits\10\Lib\10.0.18362.0\ucrt\x64\libucrt.lib` platform="windows-x86_64"

Now, when I try to compile the project I get:

C:\Devel\mir_benchmarks>dub build --compiler=ldc2 --build=release
Performing "release" build using ldc2 for x86_64.
mir-core 1.1.2: building configuration "library"...
mir-algorithm 3.7.28: building configuration "default"...
mir-blas 1.1.13: building configuration "mkl-tbb-thread-dll"...
mir-random 2.2.14: building configuration "default"...
mir_benchmarks ~master: building configuration "application"...
lld-link: error: undefined symbol: open
>>> referenced by phobos2-ldc.lib(gzlib.c.obj):(gz_open)

lld-link: error: undefined symbol: fileno
>>> referenced by druntime-ldc.lib(dmain2.obj):(_d_print_throwable)
>>> referenced by druntime-ldc.lib(cover.obj):(_D2rt5cover25_sharedStaticDtor_L188_C1FZv)
>>> referenced by druntime-ldc.lib(cover.obj):(_D2rt5cover25_sharedStaticDtor_L188_C1FZv)

lld-link: error: undefined symbol: execv
>>> referenced by phobos2-ldc.lib(process.obj):(_D3std7process6execv_FxAyaxAQfZi)

lld-link: error: undefined symbol: execve
>>> referenced by phobos2-ldc.lib(process.obj):(_D3std7process7execve_FxAyaxAQfxQeZi)

lld-link: error: undefined symbol: execvp
>>> referenced by phobos2-ldc.lib(process.obj):(_D3std7process7execvp_FxAyaxAQfZi)

lld-link: error: undefined symbol: execvpe
>>> referenced by phobos2-ldc.lib(process.obj):(_D3std7process8execvpe_FxAyaxAQfxQeZi)

lld-link: error: undefined symbol: tzset
>>> referenced by phobos2-ldc.lib(timezone.obj):(_D3std8datetime8timezone9LocalTime9singletonFNeZ12__dgliteral4MFNaNbNiNfZOb)
>>> referenced by phobos2-ldc.lib(timezone.obj):(_D3std8datetime8timezone9LocalTime9singletonFNeZ9__lambda3FNbNiNfZb)
Error: linking with LLD failed
ldc2 failed with exit code 1.

Originally posted by @tastyminerals in libmir/mir-blas#6 (comment)
@9il 9il mentioned this issue Apr 14, 2020
Closed
@kinke
Copy link
Member

kinke commented Apr 14, 2020

This is apparently due to a wild mix of MinGW-based libs (default) and manually specified MS libs (without -mscrtlib etc.); simplest solution should be using the MS toolchain as I've posted in the libmir issue.

kinke added a commit to kinke/ldc that referenced this issue Apr 29, 2020
@kinke
Adopt DMD's MSVC toolchain detection
7fe0174 
This reduces the overhead for auto-detecting and setting up an MSVC
toolchain from a very rough 1 second to about 8 milliseconds on my box.
Enabling the auto-detection by default (and so preferring MSVC over the
'internal' toolchain if there's a Visual C++ installation) is now
possible, fixing issues like ldc-developers#3402.

The MSVC setup now consists of the bare minimum - prepending 3
directories to the LIB env var and 1-2 directories to PATH.
@kinke kinke mentioned this issue Apr 29, 2020
Merged
kinke added a commit to kinke/ldc that referenced this issue Apr 29, 2020
@kinke
Adopt DMD's MSVC toolchain detection
bfbca99 
This reduces the overhead for auto-detecting and setting up an MSVC
toolchain from a very rough 1 second to about 8 milliseconds on my box.
Enabling the auto-detection by default (and so preferring MSVC over the
'internal' toolchain if there's a Visual C++ installation) is now
possible, fixing issues like ldc-developers#3402.

The MSVC setup now consists of the bare minimum - prepending 3
directories to the LIB env var and 1-2 directories to PATH.
kinke added a commit to kinke/ldc that referenced this issue Apr 29, 2020
@kinke
Adopt DMD's MSVC toolchain detection
b3d94ff 
This reduces the overhead for auto-detecting and setting up an MSVC
toolchain from a very rough 1 second to about 8 milliseconds on my box.
Enabling the auto-detection by default (and so preferring MSVC over the
'internal' toolchain if there's a Visual C++ installation) is now
possible, fixing issues like ldc-developers#3402.

The MSVC setup now consists of the bare minimum - prepending 3
directories to the LIB env var and 1-2 directories to PATH.
kinke added a commit to kinke/ldc that referenced this issue Apr 29, 2020
@kinke
Adopt DMD's MSVC toolchain detection
ed0629f 
This reduces the overhead for auto-detecting and setting up an MSVC
toolchain from a very rough 1 second to about 8 milliseconds on my box.
Enabling the auto-detection by default (and so preferring MSVC over the
'internal' toolchain if there's a Visual C++ installation) is now
possible, fixing issues like ldc-developers#3402.

The MSVC setup now consists of the bare minimum - prepending 3
directories to the LIB env var and 1-2 directories to PATH.
kinke added a commit to kinke/ldc that referenced this issue Apr 29, 2020
@kinke
Adopt DMD's MSVC toolchain detection
99cf321 
This reduces the overhead for auto-detecting and setting up an MSVC
toolchain from a very rough 1 second to about 8 milliseconds on my box.
Enabling the auto-detection by default (and so preferring MSVC over the
'internal' toolchain if there's a Visual C++ installation) is now
possible, fixing issues like ldc-developers#3402.

The MSVC setup now consists of the bare minimum - prepending 3
directories to the LIB env var and 1-2 directories to PATH.
kinke added a commit to kinke/ldc that referenced this issue Apr 30, 2020
@kinke
Adopt DMD's MSVC toolchain detection
18406bc 
This reduces the overhead for auto-detecting and setting up an MSVC
toolchain from a very rough 1 second to about 8 milliseconds on my box.
Enabling the auto-detection by default (and so preferring MSVC over the
'internal' toolchain if there's a Visual C++ installation) is now
possible, fixing issues like ldc-developers#3402.

The MSVC setup now consists of the bare minimum - prepending 3
directories to the LIB env var and 1-2 directories to PATH.
@kinke kinke closed this as completed May 4, 2020
@kmturley
Copy link

I was getting:

lld-link: error: could not open libcmt.lib: no such file or directory
lld-link: error: could not open libvcruntime.lib: no such file or directory
Error: linking with LLD failed

Fixed it by setting a dummy env path:
export LDC_VSDIR="LDC_VSDIR"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@9il @kmturley @kinke