[Bug]: Compile error when bit7z.lib is introduced into the project.

[leecn2093]

bit7z version

4.0.x

Compilation options

BIT7Z_PATH_SANITIZATION, BIT7Z_USE_NATIVE_STRING

7-zip version

v23.01

7-zip shared library used

7z.dll / 7z.so

Compilers

MSVC

Compiler versions

vs 2022

Architecture

x86

Operating system

Windows

Operating system versions

win 10 X64

Bug description

bit7z.lib I compiled with vs 2022 C++17 x86, introduced into my existing project which is C++20 x86, compilation does not pass!
The source code I used from December 22, 2023 is the one that compiles the .lib to my existing project and it compiles!

Steps to reproduce

No response

Expected behavior

No response

Relevant compilation output

1>bit7z.lib(bitinputarchive.obj) : error LNK2019: 无法解析的外部符号 ___std_find_trivial_2@12，函数 "wchar_t const * __cdecl __std_find_trivial<wchar_t const ,wchar_t>(wchar_t const *,wchar_t const *,wchar_t)" (??$__std_find_trivial@$$CB_W_W@@YAPB_WPB_W0_W@Z) 中引用了该符号
1>bit7z.lib(cmultivolumeinstream.obj) : error LNK2001: 无法解析的外部符号 ___std_find_trivial_2@12
1>bit7z.lib(fileextractcallback.obj) : error LNK2001: 无法解析的外部符号 ___std_find_trivial_2@12
1>bit7z.lib(fsutil.obj) : error LNK2001: 无法解析的外部符号 ___std_find_trivial_2@12 .

Code of Conduct

• By submitting this issue, I agree to follow bit7z's Code of Conduct

[rikyoz]

Hi!

bit7z.lib I compiled with vs 2022 C++17 x86, introduced into my existing project which is C++20 x86, compilation does not pass!

Uhm strange, I can't seem to be able to replicate the issue.

How are you including bit7z in your project? Do you link it via CMake or manually in a VS 2022 project?

The source code I used from December 22, 2023 is the one that compiles the .lib to my existing project and it compiles!

Sorry, I can't get what you mean here.
When you use an older version of bit7z it compiles, but it doesn't compile with the latest?

[leecn2093]

I use manually in a VS 2022 project,also references other third-party libraries, such as: zlib.lib, libcurl.lib, libeay32.lib, ssleay32.lib, alibabacloud-oss-cpp-sdk-static.lib, libwkhtmltox.lib, it is possible that a library with the latest version of the compilation of the It is possible that one of the libraries is conflicting with the latest version of the compiled static libraries in some places. I've also tried to write a simple demo to test referencing the latest bit7z compiled libraries, and it compiles fine, but when I referenced it to my existing project, it reported a compilation error. Currently I can only retreat to the second best to use back to the date of the old a little bit of source code compiled out of static libraries.

[rikyoz]

Thanks for the additional details!
I'll keep trying to replicate the problem.

[rikyoz]

Unfortunately, I cannot replicate the problem.

I have created a small C++20 demo project in VS 2022 which links all the libraries you mentioned, and which uses the latest bit7z version (i.e., v4.0.6) built separately always with the same VS 2022, C++17.
All the libraries were built using the same version of VS 2022.
The project builds and runs flawlessly.

Are you building bit7z and your project with the exact same version of Visual Studio 2022?

For reference:

#include "bit7z/bitarchivereader.hpp"
#include "zlib.h"
#include "curl/curl.h"
#include "alibabacloud/oss/OssClient.h"
#include "openssl/ssl.h"
#include "wkhtmltox/pdf.h"

#include <format>
#include <iostream>

auto main() -> int {
    using namespace bit7z;

    try {
        Bit7zLibrary lib{};
        BitArchiveReader reader{ lib, "./test.zip", BitFormat::Zip };
        for ( const auto& item : reader ) {
            std::cout << std::format( "[{}] {} (size: {})", item.index(), item.path(), item.size() ) << std::endl;
        }
    } catch ( const BitException& ex ) {
        std::cerr << std::format( "Error: {}", ex.what() ) << std::endl;
    }

    std::cout << std::format( "zlib version: {}", zlibVersion() ) << std::endl;

    curl_version_info_data* ver = curl_version_info( CURLVERSION_NOW );
    std::cout << std::format( "curl version: {}.{}.{}",
                              ( ver->version_num >> 16 ) & 0xff,
                              ( ver->version_num >> 8 ) & 0xff,
                              ver->version_num & 0xff ) << std::endl;

    std::string alibaba = "alibaba";
    std::string alibaba_md5 = AlibabaCloud::OSS::ComputeContentMD5( alibaba.c_str(), alibaba.size() );
    std::cout << "alibaba MD5: " << alibaba_md5 << std::endl;

    SSL_library_init();
    std::cout << std::format( "openssl version: {}", SSLeay_version( SSLEAY_VERSION ) ) << std::endl;

    std::cout << std::format( "wkhtmltox version: {}", wkhtmltopdf_version() ) << std::endl;
    return EXIT_SUCCESS;
}

[leecn2093]

First of all, thanks for your answer, because my project is quite big, maybe there are other factors affecting the compilation error reporting problem. I myself have tried to write a small demo to introduce the latest bit7z to test the compilation is no problem. I am using vs2022 with C++20 standard.

[rikyoz]

Uhm, okay. Yeah, I think there may be some other settings in your project that could cause this issue.

One option that could result in a similar issue is the /MT[d]//MD[d] flag.
Specifically, you need to build bit7z (and any static library in general, actually) with the same /MT[d]//MD[d] flag that you are using in your project.
For instance, if bit7z is built using /MD but your project uses /MT (or vice versa), the linking will fail.
By default, bit7z builds using /MD[d] (which is the default flag used by CMake). You can build bit7z using /MT[d] by enabling the option BIT7Z_STATIC_RUNTIME (e.g., -DBIT7Z_STATIC_RUNTIME=ON) when configuring the library via CMake.

What compilation options of MSVC are you using in your project?

[leecn2093]

None of the possibilities you describe are available on my end.At a later stage, is it possible to consider adding a dynamic library (dll) build to meet different needs, which also avoids the problem of setting up various parameters for static libraries.

[rikyoz]

None of the possibilities you describe are available on my end.

So building bit7z with -DBIT7Z_STATIC_RUNTIME=ON doesn't fix the issue? Or you can't test it?

At a later stage, is it possible to consider adding a dynamic library (dll) build to meet different needs, which also avoids the problem of setting up various parameters for static libraries.

Bit7z is a static-only library because it's already a library used to dynamically link to another library (7-Zip). If it were compiled as a dynamic library, you would have your program dynamically link to a library (bit7z) to dynamically link to another library (7-Zip).
This is possible, but I find it a bit too complex and cumbersome for the usual scenarios.

Maybe in the future I will add the possibility to include the whole 7-Zip source code directly into the library. In this case, dynamically linking bit7z will make much more sense.
However, this raises some licensing issues, and I'm now more focused on improving and adding new features to the library.

[leecn2093]

My projects including bit7z and 3rd party libraries are compiled with the /MD option!

[leecn2093]

My projects including bit7z and 3rd party libraries are compiled with the /MD option!

[rikyoz]

My projects including bit7z and 3rd party libraries are compiled with the /MD option!

Ah, I see. Thank you for the detail.