[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Re: ding dong, boost::filesystem is dead
From: |
Zack Weinberg |
Subject: |
Re: [Monotone-devel] Re: ding dong, boost::filesystem is dead |
Date: |
Fri, 13 Jul 2007 08:30:57 -0700 |
On 7/12/07, Anthony Williams <address@hidden> wrote:
> External libraries are definitely a problem for us. Due to boost's
> bizarro build system, it is not practical to bundle them in the
> monotone build, and "I can't get boost built" is among the top five
> problems people have trying to build monotone from source. If we use
> system-provided libraries, we have to match compilers and compile
> settings with them (see Debian bugs #404616 and #384565, for
> instance). We can't even bundle the header-only libraries we use,
> because version skew between them and the external boost libraries
> would be lethal.
Would you be happy for me to pass your comments over to the boost devel list?
Sure, go ahead.
> boost::regex in particular has the additional problem of depending on
> libicu (if built that way) whether or not the Unicode interfaces are
> used. (We don't.) Libicu is huge, and has a bug that (on at least
> Linux and Solaris) renders ineffective all our efforts to keep thread
> overhead out of the C++ runtime.
If you don't need ICU, don't use it --- I never use it, so I don't compile
regex that way.
Yes, and I'd be a lot happier with boost::regex if the shared library
were split into ASCII and Unicode modules. (Not enough happier with
it to keep using it in Monotone, though, just to be clear.)
I guess if you rely on system-supplied boost libraries then
you have to cope with what you're given, but that's true of any
system-supplied libraries. I understand from Nathaniel's post that
system-supplied versions of other libraries were causing problems, so they are
now packaged with monotone.
Right. Which we do get pushback from distribution maintainers on...
> It is also, itself, five times larger than libpcre.
Is that really a problem?
Yes. It means the statically-linked-against-boost binary we offer for
download is larger than it could be. Not by a large proportion, but
every bit helps. On i386-linux:
text data bss dec hex filename
5447158 2232 34868 5484258 53aee2 mtn
4025411 303 32727 4058441 3ded49 mtn-*.o
22679 9 6 22694 58a6 libplatform.a
55542 1876 68 57486 e08e libboost_date_time-mt.so
44530 1140 108 45778 b2d2 libboost_filesystem-mt.so
2316183 92 294 2316569 235919 lib3rdparty.a (lua, sqlite, botan)
1609047 8 6 1609061 188d65 botan/*.o
338250 80 283 338613 52ab5 sqlite/*.o
130447 0 0 130447 1fd8f lua/*.o
176246 0 4 176250 2b07a idna/*.o
123275 1472 8 124755 1e753 libpcre.so
659719 8664 352 668735 a343f libboost_regex-mt.so
77986 716 4 78706 13372 libz.so
(note that this binary is dynamically linked against libboost_regex,
and does not use libboost_filesystem or libboost_date_time).
(wow, Botan is huge...)
zw
- Re: [Monotone-devel] ding dong, boost::filesystem is dead, (continued)
- Re: [Monotone-devel] Re: ding dong, boost::filesystem is dead, Zack Weinberg, 2007/07/12
- [Monotone-devel] Re: ding dong, boost::filesystem is dead, Eric Niebler, 2007/07/13
- [Monotone-devel] Re: ding dong, boost::filesystem is dead, Anthony Williams, 2007/07/16
- Re: [Monotone-devel] Re: ding dong, boost::filesystem is dead, Zack Weinberg, 2007/07/16
- [Monotone-devel] Re: ding dong, boost::filesystem is dead, Eric Niebler, 2007/07/16
- [Monotone-devel] Re: ding dong, boost::filesystem is dead, Eric Niebler, 2007/07/13