[Soc-coordination] Report 3: Provide an alternative to libstdc++ with libc++

Andrej Belym white.wolf.2105 at gmail.com
Sun Jul 1 21:15:11 UTC 2012

it is third report for project "Provide alternative to libstdc++ with
libc++", mentored by Sylvestre Ledru.

On this weeks I cleared some things in my previously created libc++ and
libc++abi packages.

I've used Debian tool called "Lintian". I've fixed all warnings and errors,
that lintian produced on source package. Also most lintian warnings in
binary packages was fixed, except copyright warnings. E.g. binary packages
were renamed to libc++1 and libc++abi1 because lintian warning

Also I've created simple wrapper script called clang++-libc++ to help use
clang++ with libc++. My package provides clang++-libc++ as alternative for
/usr/bin/c++ using update-alternatives mechanism. Package install
alternative by call update-alternatives in postinst package script and
removes in prerm.

Also I tested my package in some ways.
One of aims of my project is to possible completely replace libstdc++ with
libc++. So compiled binary couldn't contain libstdc++ as dependency in
shared libraries that can be viewed with ldd. Below is example with simple
test program "Hello world" :) compiled with clang++ and libstdc++:
$ldd test
linux-vdso.so.1 =>  (0x00007fffa49ff000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
 libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fef087d9000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fef085c2000)
 libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fef0823b000)
/lib64/ld-linux-x86-64.so.2 (0x00007fef08d76000)

When compiling with clang++-libc++, it looks like:
$ldd test
        linux-vdso.so.1 =>  (0x00007fffcb3a0000)
libc++.so.1 => /usr/lib/libc++.so.1 (0x00007f10fe600000)
 libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f10fe37e000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f10fe167000)
 libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f10fdde0000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
 librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f10fd9bb000)
/lib64/ld-linux-x86-64.so.2 (0x00007f10fe902000)
Library links correctly - no libstdc++ in dependencies.
More real example - builded libxapian22 with libc++:
$ldd libxapian.so
        linux-vdso.so.1 =>  (0x00007fff169ff000)
 libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007ff0eb40e000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007ff0eb209000)
 libc++.so.1 => /usr/lib/libc++.so.1 (0x00007ff0eaf1d000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ff0eac9b000)
 libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff0ea914000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007ff0ea6fd000)
 /lib64/ld-linux-x86-64.so.2 (0x00007ff0eba5c000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
 librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007ff0ea2d9000)

Also I tried build debian packages with clang++-libc++. I've used trick
described by Sylvestre Ledru in http://clang.debian.net/: I've replaced
/usr/bin/g++-4.6 and /usr/bin/g++ with symlink to /usr/bin/clang++-libc++,
because in many makefiles gcc and g++ are hardcoded.

But results not very good:
- libc++ uses internal namespace __1 (e.g std::__1::cout).This behaviour
breaks linking when compiling program with shared libraries that has been
compiled and linked with  libstdc++ (just std::cout).  This trouble
described in http://wiki.freebsd.org/NewC%2B%2BStack.

- some programs require header cxxabi.h in standard path. maybe it must be
copied from libc++abi headers to libc++ headers. (So I have not builded
successfully libxapian22 : packaging fails when compiling tests
(/tests/harness/testsuite.cc), but library was compiled at this time.

- many programs used Qt cann't be compiled, because there is bug in Qt

- clang differences: clang is more strict compared to gcc. e.g IceWM cann't
be builded(../../src/apppstatus.cc:85:5: error: cannot delete expression of
type 'YColor *[3]'  delete[] color;)

Next I will consult with my mentor about plan of work considering these
troubles of packaging.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/soc-coordination/attachments/20120702/374443ff/attachment.html>

More information about the Soc-coordination mailing list