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.
This is the eighth Debian XSF News issue. For a change, I m going to
use a numbered list, which should help telling people which item to
look for when pointing to a given URL. Feel free to let me know if
that seems like a nice idea or whether that hurts readability.
Also, it was prepared several days ago already, so I m publishing it
(with the needed bits of polishing it still needed) without mentioning
what happened in the last few days (see you in the next DXN issue!).
For the whole week, I ve been in Bangalore for the 
), during my talk at FOSDEM 
So the other day, I was able to do this in an Ubuntu natty amd64 chroot
for the first time.
Anyone who went to a big Free Software conference has seen one of his colorful t-shirts. Or maybe you have heard the story where 
Well, three months in and still going. It's getting harder to find things around the house to photograph when I don't get the chance to get outside with my camera.
This image was shot in my makeshift home studio ( bedroom ) using only the light from the large window. If anyone is interested I may post some behind the scenes shots next time.
Having 
Update: Despite another email yesterday reasserting the 90-120 days lie, the source code has now landed on 
...and me. I turned 40 today and on such a momentous occasion I should pause
I, and maybe some others, wondered why people would (have to) send new lenses back claiming that they got a bad copy so often. I couldn't imagine quality control being so bad that two out of three (at least that's the impression I got from reading the occasional foto discussion forum) lenses are bad.
It turns out that it is not only people needing to be pampered and having the impression that their second (identical) copy of the expensive new lens is better. Nor is it bad QA by the manufacturers alone. Fact is that todays high megapixel cameras are at the limit of the manufacturing precision that can be achieved at a reasonable price. Roger Cicala (
I've just made a couple of software releases:
AltOS 0.9.2 Minor update to ground station software
Bdale and I are pleased to announce the release of
I've changed jobs recently and after 5 years of not having to work with a Windows system I am having all sorts of adaptation-to-Windows problems at the new job.
Those who followed the live stream or read our