Linking issue since 5.1-1.8.0

[Werni2A]

Host Environment

• OS: Linux x64

Failure logs

/usr/bin/ld: ../vcpkg_installed/x64-linux/debug/lib/libzippp_static.a(libzippp.cpp.o): warning: relocation against `_ZSt7nothrow@@GLIBCXX_3.4' in read-only section `.text'
/usr/bin/ld: ../vcpkg_installed/x64-linux/debug/lib/libzippp_static.a(libzippp.cpp.o): relocation R_X86_64_PC32 against symbol `_ZTVN8libzippp8ZipEntryE' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status

See https://github.com/Werni2A/OpenAllegroParser/runs/7693726908 for the full compile log.

Additional context I tried to figure out which commit in vcpkg introduced the issue by fixing the baseline to a few 'interesting' commits. It happens that after incorporating https://github.com/microsoft/vcpkg/pull/24885 my software does not link anymore. The major change was to bump the libzippp package, therefore I guess that the issue is located somewhere here.

Do you experience similar issues or am I doing something wrong?

[ctabin]

Hi @Werni2A,

Actually, I don't see anything that could break the linkage in the changes since v5.0. Maybe related to the upgrade of zlib ? :thinking:

I did not have any issue other than yours about this kind of problem.

[Werni2A]

Hi @ctabin, I also took a look at the change set. My guess is that its somehow related to the changes of -fPIC for zlib compilation.

Later I will give it a try to create a small reproducer and get back to you.

[Werni2A]

Hi @ctabin,

I attached a small reproducer. You can build it with the following command where vcpkg is located in the parent directory.

cmake -B build -S . -DCMAKE_TOOLCHAIN_FILE=../vcpkg/scripts/buildsystems/vcpkg.cmake
cmake --build build

The library should build as is but as soon as you change the version in vcpkg.json from 5.0-1.8.0#0 to 5.1-1.8.0#0, linking fails.

Linking is only an issue when building a library. For executables it works somehow.

LibzippLinkIssueReproducer.zip

[ctabin]

Hi @Werni2A, Do you mind testing with the v6 version of libzippp if the problem is still present ? Thanks !

[Werni2A]

Hi, I tested again with 6.0-1.9.2#1 from vcpkg but the same issue still persists.

I tried adding set(CMAKE_POSITION_INDEPENDENT_CODE TRUE) to my CMakeFile which changes the the linking issue slightly. Find the error log below. Interestingly the PIC flag changes the linking issue against _ZTVN8libzippp8ZipEntryE as reported initially to stderr@@GLIBC_2.2.5. Still I have no idea what this issue is about. I don't even know if it's related to this library, the vcpkg port files or my own CMake scripts.

In case you have no suggestions what to do feel free to close this issue. I guess there is low value in leaving this open. Looks like I'm the only one having this issue anyway.

/usr/bin/ld: ../vcpkg_installed/x64-linux/debug/lib/libzippp_static.a(libzippp.cpp.o): warning: relocation against `_ZSt7nothrow@@GLIBCXX_3.4' in read-only section `.text'
/usr/bin/ld: ../vcpkg_installed/x64-linux/debug/lib/libzippp_static.a(libzippp.cpp.o): relocation R_X86_64_PC32 against symbol `stderr@@GLIBC_2.2.5' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status

[ctabin]

@Werni2A Thanks for the test.

Obviously it seems related to -fPIC flag. I remember having the issue while changing the Makefile (because I was defining a global CFLAGS and then changed it to ZLIB_CFLAGS). Maybe this give you some hint ?

At this point I don't have any idea about this issue neither :-(

[Werni2A]

I played around with different ways and locations to specify PIC but without any success. :disappointed: For now I will use the older version and close this issue.

Nonetheless, thank you for your time and maintaining this library. :smile: :+1:

[BengtGustafsson]

I experienced the same issue, also via vcpkg building. I put an issue in vcpkg but they had difficulties reproducing the error.

I "solved" this by letting my build system build libzippp.cpp itself, bypassing your cmake system and vcpkg and then it worked with the same source code file, so it is definitely something with how it is built. Note that I did not have to change anything in the build of zlib or other dependencies, these are still built by a standard vcpkg build (their tag 2023.02.24) so I'm pretty sure the problem is in your cmakelists files. I tried blaming there and saw there were recent changes, but didn't understand much.

It could be just that vcpkg is behind on following your releases, maybe.

[BengtGustafsson]

Note: -fPIC is needed when an object or static library is linked into a shared library, but not when linked into an executable. As I understand it this is as the shared library can be located anywhere when linked into the executable at runtime. So that's why it only fails when linked into a .so file.

[dg0yt]

The issue is there: https://github.com/ctabin/libzippp/blob/ec69c0d2b2d46877b67852e27a485f7e754b6f78/CMakeLists.txt#L27-L31

This overwrites flags from the toolchain.

[ctabin]

Hi @dg0yt,

Thanks for the analyze. Do you mind submitting a PR to solve it ? That would be great !

[dg0yt]

It is just adding ${<var name>} at the beginning or end of each string, to combine toolchain and project settings...

[BengtGustafsson]

Thanks a lot for fixing this!