Stupid questions with LNK2001/LNK2019

[Polar-Pumpkin]

I wrote a static library that referenced bit7z, and then I wrote a console application that referenced my static library for testing. I'm getting a lot of LNK2001/LNK2019 errors when compiling my test program, and I don't know where the problem is and how to fix it. I searched the web for a long time and couldn't find any clues. (I hope you can forgive me if this question is stupid because I just started learning C++ code)

I feel very strange. Because both projects (static library and test program) were written on my laptop, they could compile and run normally without encountering any errors. When I copied the entire project folder to another computer, the static library could still be compiled, but the test program could not be compiled.

The bit7z.lib I use comes from GitHub Releases, a version compiled with msvc 2017. On the computer where the error occurred, I was using Visual Studio 2017 (v141) Version 15.2 (26430.16), and the MSVC version was probably 14.10.25017.

In my static library, I follow these steps to reference the bit7z library:

1. Add path\to\bit7z\include to Configuration Properties > C/C++ > General > Additional Include Directories
2. Add path\to\bit7z\lib\$(IntDir) to Configuration Properties > Linker > Input > Additional Library Directories
3. Add bit7z.lib to Configuration Properties > Linker > Input > Additional Dependencies

In my test program, I follow these steps to reference my static library:

1. I copied the header files of my static library to the headers folder in the test program directory, and added this folder to Configuration Properties > C/C++ > General > Additional Include Directories
2. I copied the .lib file of my static library to the libs folder in the test program directory, and added this folder to Configuration Properties > Linker > Input > Additional Library Directories
3. Add mylibrary.lib to Configuration Properties > Linker > Input > Additional Dependencies

Is there anything wrong with the way I'm referencing the static library? In fact, I am not very familiar with how to write static/dynamic libraries and how to reference other people's static/dynamic libraries. I have tried hard to follow the tutorials on the Internet (especially the tutorials on learn.microsoft.com), but I'm still having some issues that I just can't understand and I'd really appreciate it if you could teach me some experience!

Thank you for taking the time to reply to me, I will be very grateful for any reply!

(I'm sorry that the screenshot from Visual Studio is in Chinese, because this computer must be used offline so I can't install the English language pack)

[rikyoz]

Hi!
I've tried replicating your issue following the steps you described, but unfortunately I have not yet succeeded. I may have missed something, so I'll try again as soon as possible.

Is there anything wrong with the way I'm referencing the static library?

As far as I know, what you described seems the correct way!

From the error messages, there seems to be some linking issue with the std::filesystem functions used internally by bit7z, which is quite strange!

One thing to ensure when manually linking bit7z is to define the same set of BIT7Z_* options used for building the library. Since you're using the library released on GitHub, you should not define any option (GitHub releases don't use any option).

Also, make sure to use the same MSVC's /MT//MD option of the bit7z binary you downloaded (even though, when using mismatching options, the error message is different than yours); in the GitHub release, you should find the binaries for both /MT and /MD (the first ones are in tarballs with the _mt_ suffix, the other ones have no suffix).

Anyway, I'll keep trying to replicate the issue!

[rikyoz]

So, I've done some further tests, and the only way I was able to have similar LNK2001/LNK2019 errors was by removing the %(AdditionalDependencies) value in Configuration Properties > Linker > Input > Additional Dependencies.

This is the correct value of the property:

This generates LNK2001/LNK2019 errors while building the application:

[Polar-Pumpkin]

Sorry for replying to you so late. I am busy with other projects recently. I will try to compile bit7z later. Thanks for helping me solve my problem! :D

[Polar-Pumpkin]

I just tried to compile bit7z myself. According to the instructions in the wiki, it can be compiled successfully through the command line (but using MSVC 19.38.33130.0, Windows SDK 10.0.20348, these are all installed through the Visual Studio 17 2022 build tool, because I previously encountered an old version of the generation tool that did not recognize the vcvars_ver parameter, causing cmake to fail to generate). I replaced the compiled .lib file into the project, but many LNK2001/2019 errors still occurred. 😢

[Polar-Pumpkin]

😯 I can compile my project normally using platform toolset v143 (Installed by Visual Studio BuildTool 2022), using the .lib on GitHub Release

[rikyoz]

That is strange! 🤔
Maybe there were some differences between the settings used by bit7z and those used in the project where you ultimately use it, which makes them incompatible.
Unfortunately, being unable to reproduce the problem makes it difficult for me to help you!

Re-reading your error messages, I noticed that most undefined references belong to the std::filesystem implementation of MSVC.
I recently pushed some changes on the hotfix/v4.0.5 that might help with those undefined references.
In particular, I added the CMake option BIT7Z_DISABLE_USE_STD_FILESYSTEM, which, when enabled, should force bit7z to (internally) use a third-party library for the filesystem library instead of the compiler's std::filesystem. The library used is header-only, so it should not produce undefined references.
This could help you or, at least, might uncover other errors/undefined references.

[Polar-Pumpkin]

Thank you for all the work you do! ❤️ I will try it

[Polar-Pumpkin]

So far, I have tried using the BIT7Z_DISABLE_USE_STD_FILESYSTEM compilation option in hotfix/v4.0.5. However, in my Visual Studio 2017 (v141), I am unable to compile with v4.0.4 (master, no compilation options), hotfix/v4.0.5 (no compilation options), or hotfix/v4.0.5 (with BIT7Z_DISABLE_USE_STD_FILESYSTEM checked). I can only compile bit7z using the "Build Tools for Visual Studio 2022" (v143).

However, I didn't mention that if I use my own compiled bit7z (currently compiled with v143), I encounter more unresolved external symbol errors when compiling my library. (Currently, I believe this is because I compiled bit7z using v143, as I can't compile bit7z with v141, and then compile my library with v141, possibly due to significant changes in MSVC 2017/2019 or differences in C++ standards).

But there is good news: using BIT7Z_DISABLE_USE_STD_FILESYSTEM in hotfix/v4.0.5 indeed solves the problem of missing __std_fs_??? symbols. Now, the only issue left is the missing __Cxx??? symbols, which are the additional errors I mentioned when using my own compiled bit7z.

Strangely, with the same Visual Studio 2017 (v141), my laptop (Windows in a virtual machine) can compile bit7z, but my PC cannot, but I'm not using the exact same version of Visual Studio 2017, even the startup interfaces are different.

I really appreciate all your efforts in trying to solve this problem! This issue has been very troublesome for me, and I'm sure it must be frustrating for you as well. Regardless of whether this problem is ultimately resolved, I will be grateful for your help!

At the end, I'm attaching the output information from compiling bit7z and my library.

bit7z-404-VS2022.txt
bit7z-404.txt
bit7z-405-ghc-fs.txt
bit7z-405.txt
compile-bit7z-404.txt
compile-bit7z-405-ghc-fs.txt
compile-bit7z-405.txt
lib-[404(cmake)]-v141-debug.txt
lib-[404(cmake)]-v141-release.txt
lib-[404(github)]-v141-debug.txt
lib-[404(github)]-v141-release.txt
lib-[405-ghc-fs(laptop)]-v141-debug.txt
lib-[405-ghc-fs(laptop)]-v141-release.txt

[rikyoz]

Hey, sorry for the late reply!
First of all, thank you for all the details; they really helped me better understand the issue!

Currently, I believe this is because I compiled bit7z using v143, as I can't compile bit7z with v141, and then compile my library with v141, possibly due to significant changes in MSVC 2017/2019 or differences in C++ standards

Yeah, the issue there is the difference between v143 and v141 that makes the compilation fail!

But there is good news: using BIT7Z_DISABLE_USE_STD_FILESYSTEM in hotfix/v4.0.5 indeed solves the problem of missing _std_fs??? symbols. Now, the only issue left is the missing __Cxx??? symbols, which are the additional errors I mentioned when using my own compiled bit7z.

Good, at least we can restrict the cause of the issues!
The missing __Cxx??? symbols are a symptom of using libraries built for different platform toolsets (https://stackoverflow.com/a/69210665/3497024).

Strangely, with the same Visual Studio 2017 (v141), my laptop (Windows in a virtual machine) can compile bit7z, but my PC cannot, but I'm not using the exact same version of Visual Studio 2017, even the startup interfaces are different.

Looking at the logs, there are definitely some issues due to the version of Visual Studio 2017 used.
In particular, I noticed many Command line warning D9002: ignoring unknown option '/Zc:__cplusplus' lines.
This message should not appear, as the /Zc:__cplusplus option is available starting in Visual Studio 2017 version 15.7 (at least according to https://learn.microsoft.com/en-us/cpp/build/reference/zc-cplusplus?view=msvc-170).
So, one of your machines is running an older version of Visual Studio 2017, and the difference between the versions you are using is probably the cause of some of the undefined reference errors.

As for the compilation errors, they seem to be caused by this warning:

2>C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.10.25017\include\xutility(2436): warning C4996: 'std::copy_n::_Unchecked_iterators::_Deprecate': Call to 'std::copy_n' with parameters that may be unsafe - this call relies on the caller to check that the passed values are correct. To disable this warning, use -D_SCL_SECURE_NO_WARNINGS. See documentation on how to use Visual C++ 'Checked Iterators' (compiling source file E:\bit7z-405\src\internal\cfixedbufferoutstream.cpp)
2>C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.10.25017\include\xutility(2436): note: see declaration of 'std::copy_n::_Unchecked_iterators::_Deprecate' (compiling source file E:\bit7z-405\src\internal\cfixedbufferoutstream.cpp)
2>E:\bit7z-405\src\internal\cfixedbufferoutstream.cpp(91): note: see reference to function template instantiation '_OutIt std::copy_n<const bit7z::byte_t*,::size_t,bit7z::byte_t*>(_InIt,_Diff,_OutIt)' being compiled
2>        with
2>        [
2>            _OutIt=bit7z::byte_t *,
2>            _InIt=const bit7z::byte_t *,
2>            _Diff=::size_t
2>        ]

which is being treated as an error:

2>C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.10.25017\include\xutility(2436): error C2220: warning treated as error - no 'object' file generated (compiling source file E:\bit7z-405\src\internal\cfixedbufferoutstream.cpp)

Now, that warning message is familiar to me.
For example, the same warning appears in the build logs of the Visual Studio 2015 v4.0.4 release build (https://ci.appveyor.com/project/rikyoz/bit7z/build/job/pff98gvaf48gt0hf).
However, it disappears on newer MSVC versions, including VS 2017, hence why you don't have issues on VS 2022.
For example, on the VS 2017 v4.0.4 release build, the warning doesn't appear anywhere (https://ci.appveyor.com/project/rikyoz/bit7z/build/job/htv1sa0fvjlqrxas).
This seems to be related to your use of an older version of VS 2017.

Even on MSVC 2015, the warning never prevented bit7z from building successfully, though; that is new!

Anyway, I'll fix the warning so you can compile bit7z without issues!

I really appreciate all your efforts in trying to solve this problem! This issue has been very troublesome for me, and I'm sure it must be frustrating for you as well.

Yeah, it's a bit frustrating, but I think we are close to solving it!

Regardless of whether this problem is ultimately resolved, I will be grateful for your help!

No problem!

[rikyoz]

Update: I just pushed a couple of commits to the hotfix/v4.0.5 branch that should fix/suppress the warnings and allow the compilation of bit7z to complete.
Please let me know if it works!

[Polar-Pumpkin]

The compilation was successful and everything is normal now! thank you very much 🥰 Which reply should I mark as answer?

[rikyoz]

The compilation was successful and everything is normal now!

Great!

thank you very much 🥰

You're welcome! Happy to have helped! 😄

Which reply should I mark as answer?

I just marked the message that I think explains the issue better.

Anyway, thank you for using bit7z! 🙏