Bug 178999 - dev-util/cmake has an internal copy of zlib
|
Bug#:
178999
|
Product: Gentoo Linux
|
Version: unspecified
|
Platform: All
|
|
OS/Version: All
|
Status: RESOLVED
|
Severity: normal
|
Priority: P2
|
|
Resolution: FIXED
|
Assigned To: kde@gentoo.org
|
Reported By: flameeyes@gentoo.org
|
|
Component: Ebuilds
|
|
|
URL:
|
|
Summary: dev-util/cmake has an internal copy of zlib
|
|
Keywords:
|
|
Status Whiteboard:
|
|
Opened: 2007-05-18 12:58 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.
Why do you single out zlib? The other included stuff isn't less annoying, imho.
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).
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.
(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. :-)
@Wulf: What happens if you add $(xml2-config --libs) to your LDFLAGS before
trying the bootstrap?
(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.
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.
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.
I've just unmasked cmake-2.4.7-r2 which fixes this issue.
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
Re-emerge xmlrpc-c as the ChangeLog already says.