(CC'ing the list again) Ralf Nolden <nol...@kde.org> writes: > Am Samstag, 12. September 2015, 20:09:42 schrieben Sie: >> (Changing subject to stop mixing this with the Bugzilla thread) > >> Thanks for the patch. I've taken a look at it, and tried it out, and it >> needs some improvements: >> - It's actually missing dependencies. I'm not sure if you tried building >> the port inside Poudriere, but it fails at the configuration stage if >> you don't depend on uitools and concurrent. > No, I didn't check it with poudriere, I just tried it out after figuring out > how to move qt5 libs and to see if it would work with qt5. It failed with > quazip as that was only available for qt4 and when qcad loads that lib it > segfaults (obviously). That was the reason for checking to make two quazips, > one which is the current and a second which is linked against qt5, installed > in lib/qt4 and lib/qt5. > > Otherwise I just switched the current port to use the USE_QT5 stuff. > >> - `make check-plist' is broken: >> ===> Checking for items in pkg-plist which are not in STAGEDIR >> Error: Missing: >> %%DATADIR%%/plugins/script/%%QT_LIBDIR%%qtscript_network.so.1.0.0 - >> files/patch-support_ecmagenerator_src_srcml_RSpline.srcml needs to be >> updated, not removed. The lines that it used to change were just moved >> around. >> - Just like the patches in the port make it use openNURBS from the tree >> instead of the bundled copy, it would probably make sense to do the >> same with quazip. Bundled libraries are evil. > It does, like before - libquazip.so doesn't get installed (see pkg-plist) and > the program depends on an installed libquazip.so (that's the reasons for my > patches for quazip). So - it builds the bundled libquazip but doesn't ship it.
Right, I thought the libqcadzip.so part there was quazip, but it's actually from src/zip instead. In any case, this means that we're: - Building the bundled quazip and producing a libquazip.so in ${WRKSRC}. - Including the bundled quazip's headers when building other parts of the code. - Linking against the _ports_ libquazip.so due to -rpath-link being passed to the linker. I find it odd that this is happening, and would likely investigate why if I had some time :) It is more future-proof to avoid building the bundled library altogether. For example, -rpath-link might end up not being passed in the future, so you end up linking against one library and using another at run-time. _______________________________________________ kde-freebsd mailing list kde-freebsd@kde.org https://mail.kde.org/mailman/listinfo/kde-freebsd See also http://freebsd.kde.org/ for latest information