Cannot link with libcassandra_static.a



Couldn't find another place to post an issue so here it is.

I'm trying to link the static library into a shared object and I'm getting:

This was possible before 2.14.

The change in this pull request does not fix the issue. It was only a failed attempt, I've included it because there was no other way to open the pull request.

I'm compiling my shared object itself with -fPIC.

Do you have any ideas what might be wrong?

See start of the discussion here:



Pull Requests



Michael Fero
October 29, 2019, 7:51 PM

1) What operating system and architecture are you using?
2) Are you building the driver or are you using one of the pre-built binaries?

At first glance this looks like you are mixing 32-bit and 64-bit builds. I have attempted to reproduce the issue using Ubuntu 18.04 64-bit builds and I am not running into the current issue There is an issue with our build when performing CASS_USE_STATIC_LIBS=On which is solvable by adding pthread to the required linking libraries.

Andrei Pavel
October 30, 2019, 10:05 AM

Thank you for looking into this.

  1. Ubuntu 19.10, x86_64

  2. Building the driver with:

I prefer clang++ to g++ which you might notice from the cmake flags. I also have clang set in Ubuntu’s update-alternatives so it is taken by default in the flags' absence.

I am linking the lib in an autotools project. With GNU ld, I’m getting the errors in the initial description. With LLVM lld, I am getting something similar:

However with the following minimal setup:


It works for clang, but fails for gcc which is interesting. And this outcome is for both ld and lld.

I think this might be an incompatibility between compilers or linkers . So unless a certain compiler is hardcoded to be used somehwere like in third parties, this issue can be safely disregarded since I think cross-compiler interoperability is not guaranteed.

I will settle for linking with the dynamic library for now, I will have time next week to:

  1. test all-around with gcc

  2. use pre-built binaries

Will return with results if this issue is still open by then.

Michael Fero
October 30, 2019, 5:55 PM

I am unable to reproduce the problem you are experiencing with Ubuntu 19.10 with either clang or gcc.

Here is my setup for a fresh install of Ubuntu 19.10

This will install all the required dependencies for building the driver and also allow for a Apache Cassandra v3.11.5 server to be made available for testing a complete connection using the python library CCM.

Below is a updated source application to validate connection to a server and retrieve the server version:

With all of the above I then built the driver with both gcc and clang and disabled the building of the shared library against the latest release v2.14.0. Once the builds were completed I executed the server_version test application to ensure the driver was able to connect and execute a simple query:

Since we don't have builds for non LTS releases, I downloaded and forced the install of the Ubuntu 18.04 LTS binary packages (Note: It is not recommended to perform this forced installation step on a production environment):

After the pre-built binaries were installed I used the server_version source application to create two new executables using both gcc and clang:

Would you be able to spin up a fresh install of Ubuntu 19.10 and try to see if you are able to re-produce the issue?

Andrei Pavel
November 3, 2019, 7:00 AM

Tried it on a fresh docker pull of Ubuntu 19.10. Apart from giving me connection refused, my experiment yielded the same result as yours. The issue did not replicate.

What might be special about the problematic setup was that it was upgraded from Ubuntu 18.04.

Tried to install the latest compilers as I had done on the previous Ubuntu with:

But compiler versions hadn’t changed on 19.10, they were already at that version.

The issue also does not replicate on Arch.

I’ve done a nm comparison between static libraries between problematic-Ubuntu and Arch and the results are interesting, there’s something about http_parser in there which might be relevant but nothing about unz_copyright. Here is the diff in which the right side is from problematic-Ubuntu:

But I don’t know what to make of it.

I’m willing to give up on this, but can provide any information if needed. I’m happy that it works on all the other machines.

Thank you for investigating!

Andrei Pavel
April 13, 2020, 12:04 PM

You may close this issue.

Not a Problem




Andrei Pavel



PM Priority


Reproduced in


External issue ID


Doc Impact




Pull Request




Affects versions