Hello,<div>it is third report for project "Provide alternative to libstdc++ with libc++", mentored by Sylvestre Ledru.</div><div><br></div><div>On this weeks I cleared some things in my previously created libc++ and libc++abi packages.</div>
<div><br></div><div>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 <a href="http://lintian.debian.org/tags/package-name-doesnt-match-sonames.html">http://lintian.debian.org/tags/package-name-doesnt-match-sonames.html</a>.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Also I tested my package in some ways.</div><div>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++:</div>
<div><div>$ldd test</div><div><span style="white-space:pre-wrap"> </span>linux-vdso.so.1 => (0x00007fffa49ff000)</div><div><span style="white-space:pre-wrap"> </span>libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fef08a5b000)</div>
<div><span style="white-space:pre-wrap"> </span>libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fef087d9000)</div><div><span style="white-space:pre-wrap"> </span>libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fef085c2000)</div>
<div><span style="white-space:pre-wrap"> </span>libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fef0823b000)</div><div><span style="white-space:pre-wrap"> </span>/lib64/ld-linux-x86-64.so.2 (0x00007fef08d76000)</div>
</div><div><br></div><div>When compiling with clang++-libc++, it looks like:</div><div><div>$ldd test </div><div> linux-vdso.so.1 => (0x00007fffcb3a0000)</div><div><span style="white-space:pre-wrap"> </span>libc++.so.1 => /usr/lib/libc++.so.1 (0x00007f10fe600000)</div>
<div><span style="white-space:pre-wrap"> </span>libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f10fe37e000)</div><div><span style="white-space:pre-wrap"> </span>libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f10fe167000)</div>
<div><span style="white-space:pre-wrap"> </span>libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f10fdde0000)</div><div><span style="white-space:pre-wrap"> </span>libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f10fdbc4000)</div>
<div><span style="white-space:pre-wrap"> </span>librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f10fd9bb000)</div><div><span style="white-space:pre-wrap"> </span>/lib64/ld-linux-x86-64.so.2 (0x00007f10fe902000)</div>
</div><div>Library links correctly - no libstdc++ in dependencies.</div><div>More real example - builded libxapian22 with libc++:</div><div><div>$ldd libxapian.so</div><div> linux-vdso.so.1 => (0x00007fff169ff000)</div>
<div><span style="white-space:pre-wrap"> </span>libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007ff0eb40e000)</div><div><span style="white-space:pre-wrap"> </span>libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007ff0eb209000)</div>
<div><span style="white-space:pre-wrap"> </span>libc++.so.1 => /usr/lib/libc++.so.1 (0x00007ff0eaf1d000)</div><div><span style="white-space:pre-wrap"> </span>libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ff0eac9b000)</div>
<div><span style="white-space:pre-wrap"> </span>libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff0ea914000)</div><div><span style="white-space:pre-wrap"> </span>libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007ff0ea6fd000)</div>
<div><span style="white-space:pre-wrap"> </span>/lib64/ld-linux-x86-64.so.2 (0x00007ff0eba5c000)</div><div><span style="white-space:pre-wrap"> </span>libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ff0ea4e1000)</div>
<div><span style="white-space:pre-wrap"> </span>librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007ff0ea2d9000)</div></div><div><br></div><div>Also I tried build debian packages with clang++-libc++. I've used trick described by Sylvestre Ledru in <a href="http://clang.debian.net/" target="_blank">http://clang.debian.net/</a>: 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. </div>
<div><br></div><div>But results not very good:</div><div>- 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 <a href="http://wiki.freebsd.org/NewC%2B%2BStack" target="_blank">http://wiki.freebsd.org/NewC%2B%2BStack</a>.</div>
<div><br></div><div>- 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.</div>
<div><br></div><div>- many programs used Qt cann't be compiled, because there is bug in Qt headers:<a href="http://comments.gmane.org/gmane.comp.compilers.clang.devel/21945" target="_blank">http://comments.gmane.org/gmane.comp.compilers.clang.devel/21945</a></div>
<div><br></div><div>- 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;)</div>
<div><br></div><div>Next I will consult with my mentor about plan of work considering these troubles of packaging.</div><div> </div><div><br></div><div><br></div>