Mozilla has been distributing Firefox builds for GNU/Linux systems for a while, and 4.0 should even bring official builds for x86-64 (finally, some would say). The buildbots configuration for these builds uses gcc 4.3.3 to compile the Firefox source code. With the C++ part of gcc, it can sometimes mean side effects when using the C++ STL.
Historically, the Mozilla code base hasn t made a great use of the STL, most probably because 10+ years back, portability and/or compiler support wasn t very good. More recently, with the borrowing of code from the
Chromium project, this changed. While the borrowed code for out-of-process plugins support didn t have an impact on libstdc++ usage, the recent addition of
ANGLE had. This manifests itself in symbols version usage
These are the symbol versions required from libstdc++.so.6 on 3.6 (as given by
objdump -p):
And on 4.0:
CXXABI_1.3GLIBCXX_3.4GLIBCXX_3.4.9
This means Firefox 4.0 builds from Mozilla need the
GLIBCXX_3.4.9 symbol version, which was introduced with gcc 4.2. This means Firefox 4.0 builds don t work on systems with a libstdc++ older than that, while 3.6 builds would. It so happens that the system libstdc++ on the buildbots themselves is that old, which is why
we set LD_LIBRARY_PATH to the appropriate location during tests. This shouldn t however be a big problem for users.
Newer gcc, new problems
As part of making Firefox faster, we re planning to switch to gcc 4.5, to benefit from better (as in working) profile guided optimization, and other compiler improvements. We actually attempted to switch to gcc 4.5 twice during the 4.0 development cycle. But various problems made us go back to gcc 4.3.3, the main contender being the use of even newer libstdc++ symbols:
CXXABI_1.3GLIBCXX_3.4GLIBCXX_3.4.5GLIBCXX_3.4.9GLIBCXX_3.4.14
GLIBCXX_3.4.14 was added in gcc 4.5, making the build require a very recent libstdc++ installed on users systems. As this wouldn t work for Mozilla builds, we attempted to build with
-static-libstdc++. This options makes the resulting binary effectively contain libstdc++ itself, which means not requiring a system one. This is the usual solution used for builds such as Mozilla s, that require to work properly on very different systems.
The downside of
-static-libstdc++ is that it makes the libxul.so binary larger (about 1MB larger). It looks like the linker doesn t try to eliminate the code from libstdc++ that isn t actually used. Taras has been fighting to try to get libstdc++ in a shape that would allow the linker to remove that code that is effectively dead weight for Firefox.
Why do we need these symbols?
The actual number of symbols required with the
GLIBCXX_3.4.14 version is actually very low:
std::_List_node_base::_M_hook(std::_List_node_base*)std::_List_node_base::_M_unhook()
With the addition of the following on debug builds only:
std::string::_S_construct_aux_2(unsigned int, char, std::allocator<char> const&)std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::_S_construct_aux_2(unsigned int, wchar_t, std::allocator<wchar_t> const&)
The number of symbols required with the
GLIBCXX_3.4.9 version is even lower:
std::istream& std::istream::_M_extract<double>(double&)
It however varies depending on the compiler version. I have seen other builds also require
std::ostream& std::ostream::_M_insert(double).
All these are actually internal implementation details of the libstdc++. We re never calling these functions directly. I m going to show two small examples triggering some of these requirements (that actually generalize to all of them).
The case of templates
#include <iostream>
int main()
unsigned int i;
std::cin >> i;
return i;
This example, when built, requires
std::istream& std::istream::_M_extract<double>(double&), but we are effectively calling
std::istream& operator>>(unsigned int&). It is defined in
/usr/include/c++/4.5/istream as:
template<typename _CharT, typename _Traits>
class basic_istream : virtual public basic_ios<_CharT, _Traits>
basic_istream<_CharT, _Traits>& operator>>(unsigned int& __n)
return _M_extract(__n);
And
_M_extract is defined in
/usr/include/c++/4.5/bits/istream.tcc as:
template<typename _CharT, typename _Traits> template<typename _ValueT>
basic_istream<_CharT, _Traits>&
basic_istream<_CharT, _Traits>::_M_extract(_ValueT& __v)
(...)
And later on in the same file:
extern template istream& istream::_M_extract(unsigned int&);
What this all means is that libstdc++ actually provides an implementation of an instance of the template for the
istream (a.k.a.
basic_istream<char>) class, with an
unsigned int & parameter (and some more implementations). So, when building the example program, gcc decides, instead of instantiating the template, to use the libstdc++ function.
This
extern definition, however, is guarded by a
#if _GLIBCXX_EXTERN_TEMPLATE, so if we build with
-D_GLIBCXX_EXTERN_TEMPLATE=0, we actually get gcc to instantiate the template, thus getting rid of the
GLIBCXX_3.4.9 dependency. The downside is that this doesn t work so well with bigger code, because other things are hidden behind
#if _GLIBCXX_EXTERN_TEMPLATE.
There is however another (obvious) way to for the template instantiation: instantiating it. So adding
template std::istream& std::istream::_M_extract(unsigned int&); to our code is just enough to get rid of the
GLIBCXX_3.4.9 dependency. Other template cases obviously can be worked around the same way.
The case of renamed implementations
#include <list>
int main()
std::list<int> l;
l.push_back(42);
return 0;
Here, we get a dependency on
std::_List_node_base::_M_hook(std::_List_node_base*) but we are effectively calling
std::list<int>::push_back(int &). It is defined in
/usr/include/c++/bits/stl_list.h as:
template<typename _Tp, typename _Alloc = std::allocator<_Tp> >
class list : protected _List_base<_Tp, _Alloc>
void push_back(const value_type& __x)
this->_M_insert(end(), __x);
_M_insert is defined in the same file:
template<typename ... _Args>
void _M_insert(iterator __position, _Args&&... __args)
_List_node<_Tp>* __tmp = _M_create_node(std::forward<_args>(__args)...);
__tmp->_M_hook(__position._M_node);
Finally,
_M_hook is defined as follows:
struct _List_node_base
void _M_hook(_List_node_base * const __position) throw ();
In gcc 4.4, however,
push_back has the same definition, and while
_M_insert is defined similarly, it calls
__tmp->hook instead of
__tmp->_M_hook. Interestingly, gcc 4.5 s libstdc++ exports symbols for both
std::_List_node_base::_M_hook and
std::_List_node_base::hook, and the code for both methods is the same.
Considering the above, a work-around for this kind of dependency is to define the newer function in our code, and make it call the old function. In our case here, this would look like:
namespace std
struct _List_node_base
void hook(_List_node_base * const __position) throw ();
void _M_hook(_List_node_base * const __position) throw ();
;
void _List_node_base::_M_hook(_List_node_base * const __position) throw ()
hook(__position);
which you need to put in a separate source file, not including
<list>.
All in all, with
a small hack, we are able to build Firefox with gcc 4.5 without requiring libstdc++ 4.5. Now, another reason to switch to gcc 4.5 was to use
better optimization flags, but it turns out it makes the binaries 6MB bigger. But that s another story.
I spent part of today looking at packaging Peter Gutmann's CryptLib for debian. My conclusion: it may not be worth my time. One of the main reasons i wanted to package it for debian is because i would like to see more OpenPGP-compliant free software available to debian users and developers, particularly if the code is GPL-compatible. Cryptlib makes it quite clear that it intends to be GPL-compatible: 
It seems kind of unfair, given the name, but duplicity really doesn't
like to be run in parallel. This means that some naive admin (not me
of course, but uh, this guy I know 
) who writes a crontab
Conrad Sanderson continues an active release schedule for his wonderful
Dear Lazyweb, for a long time I have been using iproute2 s label feature to assign arbitrary labels to IP
addresses configured on Interfaces:
In order to ease creation of remote repositories to publish your Debian
packaging work git-buildpackage ships gbp-create-remote-repo: If you run
It looks like questions about contributing to 
When coming back from DebConf9, I wrote this pledge:
For those who are interested in the world of compiz, new development
snapshots have been trickling their way into experimental for the past
week and are now available for widespread testing.
They're being sent to experimental instead of straight to unstable for a
few reasons:
)
Something enabled by default but with a disable syntax:
Nokia has 
In the software community, people hold strong opinions on the subject of listening to users. Some feel that users are an essential source of information for making successful products, as evidenced in the 
Since the last post, few things did happen. Basically, it's
still not the right time for Debian users to upgrade to Xfce 4.8.
We eventually managed to upload the whole desktop part (except the
xfce metapackage) to experimental and we did upload some of the
goodies too. Licensing issues have been solved so the concerned
packages have been uploaded, and we're right now waiting on the
three packages sitting in NEW.