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

Andrej Belym white.wolf.2105 at gmail.com
Sun Jun 17 20:55:17 UTC 2012


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

I've focused previous days to better integrate my port of libc++  to clang.
Firstly I've changed headers path for libc++ to /usr/include/c++/v1/ -
clang is finding here libc++ headers here if invoked with option
"-stdlib=libc++".

Next I found way to avoid end-user link  explicitly libc++abi to his
application. On Mac it realises with specific linker option
-reexport_library=libc++abi when linking libc++, but on Linux ld doesn't
have this feature. Also, since 2010 GNU ld doesn't link implicit
dependencies (inter-library dependencies,  in this case libc++abi)
automaticaly:
http://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking,
http://fedoraproject.org/wiki/UnderstandingDSOLinkChange.

And so I think only way is to create static version of libc++abi, and link
it to libc++. On this way I had troubles that libc++ realises some ABI
functions itself (in files exceptions.cpp, stdexceptions.cpp,
typeinfo.cpp). When compiling these files, cxxabi.h header will connected
only if macroses __APPLE__ or LIBCXXRT is defined. In these cases some ABI
function will be imported from ABI library. Otherwise these function will
be declared and implemented in these files. And when linking libc++ with
libc++abi staticaly, these functions will be double implemented, and it
causes linking error.

I've succesfully solved this task. Now libc++ abi as libc++ dependecy is
removed, because they compiled statically. Also I've created static version
of libc++, and with static libc++abi, they are added to libc++-dev and
libc++abi-dev packages.

After all libc++ can be simply used with specifying option "-stdlib=libc++"
in clang++ command line.

Also I've packaged sources and test cases of libraries to libc++-src and
libc++abi-src packages. Test cases for libc++ can be runned by copying
folder /usr/lib/libcxx/test directory to place where user have r/w
permissions, and running "testit" in this folder. Test cases for libc++abi
require sources, so copy src and test folders from /usr/lib/libcxxabi/, and
run "testit" in folder "test". Current directory must be "test" folder when
running "testit". Testing requires installed binary packages, of course.

Also, I measured time to complete libc++ tests. On my Intel Core i3-350M
with 2Gb RAM, 5400 rpm HDD it takes:
real 32m13.624s
user 28m35.727s
sys 2m20.129s
I've used cpufreq governor "userspace" and frequency 2.27GHz(maximum).

Also, some improvements was maked to help updating package with updates in
upstream sources.
Currently there is no tarballs of libc++ nor libc++abi (because no releases
were for both), only (two separate) svn repositories. So uscan cann't be
used.
So script called libc++-get-orig-source.sh and makefile target
get-orig-source in debian/rules were created . Script downloads sources
from svn repositories, and packs to gzipped tar. Script takes as argument
version of package in two formats: X.Y~svnZ or X.Y. If first form is
specified, script uses SVN revision Z when checkouting sources, otherwise,
it uses current revision of libc++ SVN repository. Target in debian/rules
get-orig-source just invoke script with version specified in
debian/changelog file.

And finally, I have uploaded my work to pkg-llvm SVN repository on alioth.
Link below can be used to checkout it:
svn://anonscm.debian.org/pkg-llvm/libcxx/trunk

To check pkg-llvm repository in browser:
https://alioth.debian.org/scm/browser.php?group_id=100069

Also I've set property mergeWithUpstream on libcxx/trunk/debian to use with
svn-buildpackage. My package could be builded with following commands:

svn co svn://anonscm.debian.org/pkg-llvm/libcxx/trunk libc++
 mkdir tarballs; cd libc++;
debian/rules get-orig-source; mv *.tar.gz ../tarballs/
svn-buildpackage -us -uc -rfakeroot

On next week I plan to clean and test my package, and so on.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/soc-coordination/attachments/20120618/6b550bdc/attachment-0001.html>


More information about the Soc-coordination mailing list