search

Shinmera / qt-libs

Helper system to ensure the necessary library for CommonQt/Qtools development are available and deployable.
zlib License
18 stars 8 forks source link

Problem with libssl1.0.0 / How are qtlibs .so's linked? #13

Open shelvick opened 6 years ago

shelvick commented 6 years ago

I'm trying to recompile QtNetwork with a newer version of libssl/libcrypto -- I believe 1.0.0 is deprecated (it's not even available in the repos on my Fedora 26 system). I have done ensure-standalone-libs multiple times, but the result still links incorrectly:

$ ldd qtlibs!QtNetwork.so ldd: warning: you do not have execution permission for './qtlibs!QtNetwork.so' linux-vdso.so.1 (0x00007ffe96106000) qtlibs!QtCore.so => ./qtlibs!QtCore.so (0x000070acd3fb6000) libpthread.so.0 => /lib64/libpthread.so.0 (0x000070acd3d97000) libssl.so.1.0.0 => not found libcrypto.so.1.0.0 => not found libstdc++.so.6 => /lib64/libstdc++.so.6 (0x000070acd3a0e000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x000070acd37f7000) libc.so.6 => /lib64/libc.so.6 (0x000070acd3422000) libdl.so.2 => /lib64/libdl.so.2 (0x000070acd321e000) libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x000070acd2f0b000) librt.so.1 => /lib64/librt.so.1 (0x000070acd2d03000) libm.so.6 => /lib64/libm.so.6 (0x000070acd29ed000) /lib64/ld-linux-x86-64.so.2 (0x000070acd4916000) libpcre.so.1 => /lib64/libpcre.so.1 (0x000070acd277b000)

However, the libQtNetwork.so on my system (along with a cached libQtNetwork.so that I found), is linked correctly:

$ ldd /usr/lib64/libQtNetwork.so linux-vdso.so.1 (0x00007ffdeb3f1000) libQtCore.so.4 => /lib64/libQtCore.so.4 (0x000071f79a3da000) libpthread.so.0 => /lib64/libpthread.so.0 (0x000071f79a1bb000) libz.so.1 => /lib64/libz.so.1 (0x000071f799fa4000) libssl.so.10 => /lib64/libssl.so.10 (0x000071f799d37000) libcrypto.so.10 => /lib64/libcrypto.so.10 (0x000071f7998d6000) libstdc++.so.6 => /lib64/libstdc++.so.6 (0x000071f79954d000) libm.so.6 => /lib64/libm.so.6 (0x000071f799237000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x000071f799020000) libc.so.6 => /lib64/libc.so.6 (0x000071f798c4b000) libdl.so.2 => /lib64/libdl.so.2 (0x000071f798a47000) libgthread-2.0.so.0 => /lib64/libgthread-2.0.so.0 (0x000071f798845000) libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x000071f798532000) librt.so.1 => /lib64/librt.so.1 (0x000071f79832a000) /lib64/ld-linux-x86-64.so.2 (0x000071f79ac2a000) libpcre.so.1 => /lib64/libpcre.so.1 (0x000071f7980b8000)

Is there a precompiled .so that's being downloaded from somewhere?

Shinmera commented 6 years ago

Did you follow the README or how did you invoke ensure-standalone-libs?

shelvick commented 6 years ago

Yep, exactly as in the README: (ensure-standalone-libs :method :install-sources :force t). I also tried the default :install-binaries but I assume that's not going to be helpful.

Shinmera commented 6 years ago

It should print plenty of output about where it's copying things from and to. That should give you an indication of whether it's properly copying your library versions.

shelvick commented 6 years ago

Yeah, so what happens is that it copies libQtNetwork.so (the good one) over to qtlibs!QtNetwork.so -- then, later in the process, it overwrites that file again with a different qtlibs!QtNetwork.so (the bad one).

I was going to copy the good file back and show you the new output, but it turns out that now I am running into this issue: https://github.com/Shinmera/qt-libs/issues/7 :-/

IIRC, if I forced it to use the properly-linked library, then it issued warnings like these:

WARNING: compiling #<FOREIGN-LIBRARY-COMPONENT "smokebase" "smokebase"> completed without its input file #P"/home/user/quicklisp/dists/quicklisp/software/qt-libs-20171227-git/systems/smokebase.so" WARNING: loading #<FOREIGN-LIBRARY-COMPONENT "smokebase" "smokebase"> completed without its input file #P"/home/user/quicklisp/dists/quicklisp/software/qt-libs-20171227-git/systems/smokebase.so" WARNING: compiling #<FOREIGN-LIBRARY-COMPONENT "commonqt" "QtCore"> completed without its input file #P"/home/user/quicklisp/dists/quicklisp/software/qt-libs-20171227-git/systems/QtCore.so" WARNING: loading #<FOREIGN-LIBRARY-COMPONENT "commonqt" "QtCore"> completed without its input file #P"/home/user/quicklisp/dists/quicklisp/software/qt-libs-20171227-git/systems/QtCore.so" WARNING: compiling #<FOREIGN-LIBRARY-COMPONENT "commonqt" "QtGui"> completed without its input file #P"/home/user/quicklisp/dists/quicklisp/software/qt-libs-20171227-git/systems/QtGui.so" WARNING: loading #<FOREIGN-LIBRARY-COMPONENT "commonqt" "QtGui"> completed without its input file #P"/home/user/quicklisp/dists/quicklisp/software/qt-libs-20171227-git/systems/QtGui.so"

Not sure if those warnings mean anything, but I think I need to clean up and test again. What should I delete other than the qt-libs FASLs?

Shinmera commented 6 years ago

Other than the FASL directory, you should also delete the standalone directory in the qt-libs source root folder.

shelvick commented 6 years ago

Sharing workarounds in case they help others:

First off, the detour with compiling standalone libs from source was a red herring. I never needed to do that, though we did learn that it may be triggering that other bug.

To fix the original problem, I had to copy /usr/lib64/libQtNetwork.so over the standalone/qtlibs!QtNetwork.so file. And then, to fix another linking problem, I had to symlink /usr/lib64/qtlibs!QtNetwork.so --> /usr/lib64/libQtNetwork.so.

Those FOREIGN-LIBRARY-COMPONENT warnings are still present, but they don't seem to be affecting my program and it seems I can get rid of them with yet more symlinks.

Whew.

Shinmera commented 6 years ago

Doing it this way will make things fuck up guaranteed during deployment. If you just copy the library over, you might also run into version mismatches. If you don't, you're just lucky. Either way, the linking problem fix you're doing with the symlink will cause major issues down the line. You need to edit the shared libraries to fix up the dependency references. You can do this automatically with something like:

(qt-lib-generator::fix-ldlib-collection (uiop:directory-files qt-libs:*standalone-libs-dir* (make-pathname :type "so" :defaults uiop:*wild-path*))))

After that, check with ldd that all the references to other Qt libs are the properly uniquely named qtlibs! files.

The ASDF warnings are nonsense and you can ignore them safely.

shelvick commented 6 years ago

I figured as much, but unfortunately fix-ldlib-collection doesn't seem to solve the problem, no matter when I run it. I run it after loading qt-libs, I still have to copy the QtNetwork file or I get the libssl error. I run it after copying the file, I still have to do the symlink in /usr/lib64 or my program fails at runtime.

None of this really addresses with the original problem, though: that the QtNetwork.so shipped with qt-libs is linked to an old version of libssl and libcrypto. I tried to compile a new one myself, but got stuck on #7. I'm out of ideas.