Closed bobhairgrove closed 2 years ago
What happens if you just add -lz
without the -L/usr/lib/x86_64-linux-gnu
part? The latter is one of the default system library dirs, and should be visible to the linker by default. Adding it manually may confuse the linker. Something like that happened to me in the past, when one of my *.pro
files had something like LIBS += $$PREFIX/lib
, and when PREFIX
was set to $HOME
(installing for a specific user without root privileges) it worked fine, but as soon as I tried to install it globally by setting PREFIX=/usr
, I had to remove that LIBS
line, or else it would give me cryptic errors. Don’t remember which ones.
Thanks for the suggestion. Unfortunately, it gives me the same errors as when I specify the directory.
All right, could you attach the full build log, after doing full clean? I’d like to have a look at the compiler/linker options used.
Thanks again! I cleaned the entire build directory and rebuilt everything.
Here is the build log: build_log_2022-06-29.txt
And here is my project file (renamed to .txt because GitHub doesn't like .pro files): SBBL_pro.txt
In the build log, I suspected that the order of -lz
might have something to do with everything, so after all the object files were built, I copied the last linker command (line 285 in the log) and moved the -lz
switch to the end of the line, then ran that in a terminal. Unfortunately, same thing happens (2817 linking errors).
Thank you very much for looking into this!
What made you think it’s related to zlib in the first place? I see a bunch of errors saying that the linker can’t find some of your symbols. Does it compile fine when you don’t link to -lz
? Do you see in the build log the source files where the missing symbols are defined? Are their respective object files present in the linker command line?
No matter how I look at it, it looks that you just have some of your source files missing. But of course I can be missing something myself.
No, you are absolutely correct -- I suspected as much because the errors all concerned maybe only 5 or 6 variable names, but since I hadn't seen them until I added QuaZip to the project, I erroneously believed that this was somehow a linker problem. So I took QuaZip out of the project and replaced the function using it with a dummy, and I got the same errors... :(
The variables which caused the errors were declared "extern", but for two of them I had repeated the "extern" keyword in the .cpp file where they were defined. In the other cases it was because of the way the namespace was referenced.
I am sorry that you wasted some time looking at this! Everything works correctly now -- at least I can build my project again!
I have added QuaZip as source code to my project. I define QUAZIP_STATIC, and it compiles fine.
However, I have trouble linking with the system's zlib. I am building on Ubuntu 18.04 with Qt 5.15.5 (using qmake) and the latest QuaZip sources (1.3). Zlib is provided by the repository package
zlib1g-dev
and is version 1.2.11. Qt was compiled from source and configured to use the systemzlib
.To link with the system library for zlib, I add the following line to my project file:
LIBS += -L/usr/lib/x86_64-linux-gnu -lz
But then I get over 2000 linker errors with undefined references to some global variables which are declared
extern
similar to the following:where
sbbl::cmd_line_opts
is a variable of a custom type,sbbl::NV
isstd::vector<std::string>
, andsbbl::NS
isstd::string
. I also tried defining the macro_GLIBCXX_USE_CXX11_ABI
to 0 and 1, but this didn't help, either.If I leave off the
LIBS
line, I get the following error:Also, I tried building QuaZip as a shared library and linking that to the project, but I get the same errors when trying to link to zlib.
Has anyone else seen this? I've been pulling out my hair for days now...