Can't get libzippp working in 64 bit

[Roland17]

I'm looking for Zip libraries and libzippp looks to be what I want so I'm trying little POC console apps.
This is the first, which works fine in x86 but when I try to compile in x64 I get 'Unresolved External readAsText'.
I used vcpkg to get the libraries
vcpkg install libzippp
vcpkg install libzippp:x64-Windows


Error LNK2019 unresolved external symbol "public: class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > __cdecl libzippp::ZipEntry::readAsText(enum libzippp::ZipArchive::State,unsigned long)const " (? readAsText@ZipEntry@libzippp@@QEBA ? AV ? $basic_string@DU ? $char_traits@D@std@@V ? $allocator@D@2@@std@@W4State@ZipArchive@2@K@Z) referenced in function main Zip6 D : \rcodeNET\Dev\Zip6\Zip6.obj 1

#include <iostream>
#include "libzippp\libzippp.h"
using namespace std;
using namespace libzippp;

int main()
{
    ZipArchive zf("d:\\1zip\\Gender.zcd");
    bool ok = zf.open(ZipArchive::ReadOnly);

    vector<ZipEntry> entries = zf.getEntries();

    ZipEntry ze;
    for (int i = 0; i < entries.size(); i++)
    {
        ze = entries[i];
 
        string name = ze.getName();
        int size = ze.getSize();
        std::cout << name << "=" << size << "\n";

        string textData = ze.readAsText();
        std::cout << "text " << textData << "\n";
    }
}

[VictorN]

In your project properties try to add the .lib for x64 in the Linker/Input/Additional Dependencies

[Roland17]

In your project properties try to add the .lib for x64 in the Linker/Input/Additional Dependencies

Thanks, Victor, but it didn't change anything. I even put the full path in the property.

If I comment out the ze.readAsText() line it runs fine in 64 bit, meaning that ze.GetName() is recognised. I think that means it can find the .lib without extra properties. The puzzle is - why isn't readAsText() recognised when they're both in the same .lib?

[2kaud]

Use dumpbin /exports filename.lib to see the exported names from the .lib file

[Richard.J]

readAsText is exported by the DLL. I expect more of a compiler setting that causes a difference in the exported symbol and the expected one.

[Roland17]

I've collected the mangled name (I assume that is what it is) from the error message and the lib export and there is one difference (ignoring blank spaces)
Error says it's looking for:
?readAsText@ZipEntry@libzippp@@QEBA?AV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@W4State@ZipArchive@2@K@Z
Lib exports as:
?readAsText@ZipEntry@libzippp@@QEBA?AV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@W4State@ZipArchive@2@_K@Z

The difference is in the last few chars. Error message ends with @K@Z and the lib export ends with @_K@Z having an extra underscore.

Is that something that can be controlled by a compiler setting?

[2kaud]

The code that produces the .lib/.dll files needs to be re-compiled with your compiler using the same settings as for your main code. This is C++ 'name mangling'. The whole name must match exactly. This is a reason why exported functions are often exported as 'C' rather than C++ as if exported as 'C' this name mangling doesn't occur.