178999 2007-05-18 12:58 0000 dev-util/cmake has an internal copy of zlib 2008-02-13 17:25:41 0000 1 1 1 Unclassified Gentoo Linux Ebuilds unspecified All All RESOLVED FIXED P2 normal --- 1 flameeyes@gentoo.org kde@gentoo.org endgame.dos@gmail.com ingmar@gentoo.org pilla@gentoo.org flameeyes@gentoo.org 2007-05-18 12:58:04 0000 Not a good idea, in general it would be nicer to use the shared copy of zlib already present in the system, to avoid having to load more data (zlib is almost always already present in memory) and to allow fixes in zlib to be shared by its users too. carlo@gentoo.org 2007-05-20 22:46:05 0000 Why do you single out zlib? The other included stuff isn't less annoying, imho. flameeyes@gentoo.org 2007-05-20 22:53:27 0000 Because I found zlib during my survey of exported symbols :) adler32 symbols is quite specific to zlib, so it's the easiest to spot ;) But yes, everything they bundle in is annoying (and their failure at using a shared library and/or hiding the symbols they don't need to export makes it a big workload for ld.so). endgame.dos@gmail.com 2007-09-01 20:01:12 0000 The CMake bootstrap command has the option "--system-libs" to use system-installed 3rd party libraries. Perhaps that can be of some use? DEPEND will need to include net-misc/curl, dev-libs/expat, sys-libs/zlib (though that's in system, isn't it?) and dev-libs/xmlrpc-c with USE=curl (build fails without) When I configure cmake with configure --system-libs and those libraries, it will build and then running ldd on cmake looks like this: $ ldd bin/cmake linux-gate.so.1 => (0xffffe000) libdl.so.2 => /lib/libdl.so.2 (0xb7f4c000) libexpat.so.1 => /usr/lib/libexpat.so.1 (0xb7f2c000) libz.so.1 => /lib/libz.so.1 (0xb7f1a000) libstdc++.so.6 => /usr/lib/gcc/i686-pc-linux-gnu/4.2.0/libstdc++.so.6 (0xb7e3a000) libm.so.6 => /lib/libm.so.6 (0xb7e17000) libgcc_s.so.1 => /usr/lib/gcc/i686-pc-linux-gnu/4.2.0/libgcc_s.so.1 (0xb7e0c000) libc.so.6 => /lib/libc.so.6 (0xb7ce4000) /lib/ld-linux.so.2 (0xb7f61000) Is this a good thing? I think so, but I'm not 100% on this stuff. Let me know if there's anything else I can do to help. philantrop@gentoo.org 2007-09-07 20:51:08 0000 (In reply to comment #3) > The CMake bootstrap command has the option "--system-libs" to use > system-installed 3rd party libraries. Perhaps that can be of some use? Thanks, at least I wasn't aware of that. :) And, yes, it helps a lot but... I've been trying to use it and patched my way through some problems but with --as-needed in my LDFLAGS cmake fails to build. Even without it, things eventually always end up like this at one point or another (I've patched that one away by explicitly linking in libxml2 but ctest still fails then): [ 97%] Built target cpack [ 98%] Building CXX object Source/CMakeFiles/ccmake.dir/CursesDialog/cmCursesWidget.o [ 98%] Building CXX object Source/CMakeFiles/ccmake.dir/CursesDialog/ccmake.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.0/../../../../lib64/libxmlrpc.so: undefined reference to `xmlFreeParserCtxt' /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.0/../../../../lib64/libxmlrpc.so: undefined reference to `xmlCreatePushParserCtxt' /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.0/../../../../lib64/libxmlrpc.so: undefined reference to `xmlParseChunk' collect2: ld returned 1 exit status All three come from libxml2 and should be usable for xmlrpc but obviously something is still wrong with it even if neither of those are linked with --as-needed. If anyone has an idea, suggestions or even a solution, I'd be glad because I've wasted two days on this already. :-) endgame.dos@gmail.com 2007-09-10 18:56:10 0000 @Wulf: What happens if you add $(xml2-config --libs) to your LDFLAGS before trying the bootstrap? philantrop@gentoo.org 2007-09-23 21:41:30 0000 (In reply to comment #5) > @Wulf: What happens if you add $(xml2-config --libs) to your LDFLAGS before > trying the bootstrap? Unfortunately, exactly the same as in comment #4. endgame.dos@gmail.com 2007-09-23 22:08:14 0000 Should this block bug 129413 (the --as-needed tracking bug)? Now that I've got a system with LDFLAGS="-Wl,--as-needed", I've had a bit of a play around and found that it builds if you don't have "-Wl,--as-needed" when linking ctest. According to http://www.gentoo.org/proj/en/qa/asneeded.xml, libxmlrpc_client.so (from dev-libs/xmlrpc-c) will need to link to libxml2 correctly for this to work. I don't have time to probe this more deeply right now, unfortunately. philantrop@gentoo.org 2007-09-27 18:51:18 0000 This is fixed in cmake-2.4.7-r2 which is currently p.masked until a dependency has been properly keyworded. For now, --no-as-needed will be appended. philantrop@gentoo.org 2008-01-13 15:32:00 0000 I've just unmasked cmake-2.4.7-r2 which fixes this issue. pilla@gentoo.org 2008-02-13 17:22:07 0000 Sorry to bother you guys, but I just wanted to report that dev-util/cmake-2.4.7-r2 still fails for me if you have LDFLAGS="-Wl,--as-needed". [ 98%] Building CXX object Source/CMakeFiles/ctest.dir/ctest.o Linking CXX executable ../bin/ctest /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../libxmlrpc.so: undefined reference to `xmlFreeParserCtxt' /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../libxmlrpc.so: undefined reference to `xmlCreatePushParserCtxt' /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../libxmlrpc.so: undefined reference to `xmlParseChunk' collect2: ld returned 1 exit status make[2]: *** [bin/ctest] Error 1 make[1]: *** [Source/CMakeFiles/ctest.dir/all] Error 2 make: *** [all] Error 2 * * ERROR: dev-util/cmake-2.4.7-r2 failed. It compiles without --as-needed flameeyes@gentoo.org 2008-02-13 17:25:41 0000 Re-emerge xmlrpc-c as the ChangeLog already says.