Android & libstdc++
Vladimir Vukicevic
resembling a standard or complete libstdc++... specifically, the stdc++
dir includes:
cassert cfloat csetjmp cstdint cstring typeinfo
cctype climits csignal cstdio ctime new utility
cerrno cmath cstddef cstdlib cwchar stl_pair.h
... and I very much doubt that there are complete implementations of any
of those. We have code now that uses std::sort and other things... I
cannot believe it's 2010 and we're (again!) having to deal with crappy
standard c++ libs. Any thoughts on what we should do here? An obvious
one is build and ship our own standard c++ library; if so, is there a
free/open one that we can use for this? (The gnu libcstc++ is GPL, so
isn't suitable.)
- Vlad
Zack Weinberg
> One problem with Android is that Bionic doesn't include anything
> resembling a standard or complete libstdc++...
...
> An obvious one is build and ship our own standard c++
> library; if so, is there a free/open one that we can use for this?
> (The gnu libcstc++ is GPL, so isn't suitable.)
The gnu libstdc++ is *supposed* to be licensed under GPL + an exception
that allows it to be used for things like this, and even if it weren't,
I don't see why we couldn't use it; our own code is (effectively) GPL,
too.
It might be far too hard to extricate it from the gcc source tree,
though. There's also STLport, but I don't know how well maintained it
is nowadays.
zw
Mike Shaver
Robert O'Callahan
> ... and I very much doubt that there are complete implementations of any
> of those. We have code now that uses std::sort and other things...
Who's using std::sort? I thought we had a policy of not using stuff like
that.
Rob
Boris Zbarsky
> Who's using std::sort?
jsregexp.cpp, looks like (I'm ignoring breakpad's use).
> I thought we had a policy of not using stuff like that.
Apart from the jsregexp use, we use std::vector/pop_heap/make_heap in
imagelib, and what looks like std::pair in /storage. That seems like it
so far... So most of us are still adhering to said policy
-Boris
Robert O'Callahan
Seems like it would be easier and better to fix those usages.
Rob
Chris Jones
A couple of weeks ago, I wanted std::swap(), so I filed
https://bugzilla.mozilla.org/show_bug.cgi?id=525162 and added
xpcom/glue/Algorithm.h. I like that general approach because it taps
into STL "mindshare" without tying us to libstdc++.
Are there objections to using this same approach to add, say, std::pair?
Cheers,
Chris
dbradley
> A couple of weeks ago, I wanted std::swap(), so I filedhttps://bugzilla.mozilla.org/show_bug.cgi?id=525162and added
> xpcom/glue/Algorithm.h. I like that general approach because it taps
> into STL "mindshare" without tying us to libstdc++.
If you're going to add such things under xpcom/glue, you probably
really should change the namespace and not use std.
David
Ben Combee
I'd add that Bionic doesn't support C++ exceptions. They don't ship an
exception-capable runtime because when they started the Android project,
the ARM port of GCC had really bloaty codegen for code that allowed
exceptions to pass through.
Chris Jones
Of course. Please read the patch if you're interested.
Chris Jones
To clarify, I added mozilla::Swap. The "same approach" would be adding
mozilla::Pair, e.g.
Luke Wagner
>>
>> jsregexp.cpp, looks like (I'm ignoring breakpad's use).
>>
>>> I thought we had a policy of not using stuff like that.
Righto, will remove.
https://bugzilla.mozilla.org/show_bug.cgi?id=530366
Shawn Wilsher
> Apart from the jsregexp use, we use std::vector/pop_heap/make_heap in
> imagelib, and what looks like std::pair in /storage. That seems like it
> so far... So most of us are still adhering to said policy
making sure it was OK to use before I actually used it. Are we now
saying we shouldn't use it?
/sdwilsh
Boris Zbarsky
> I thought std::pair was safe. I had many discussions with lots of folks
> making sure it was OK to use before I actually used it. Are we now
> saying we shouldn't use it?
I'm not saying anything about that; just reporting on the places in our
code that use std::*. I've done no evaluation of appropriateness of use
or anything.
-Boris
Gervase Markham
> Vladimir Vukicevic<vlad...@pobox.com> wrote:
>
>> One problem with Android is that Bionic doesn't include anything
>> resembling a standard or complete libstdc++...
> ...
>> An obvious one is build and ship our own standard c++
>> library; if so, is there a free/open one that we can use for this?
>> (The gnu libcstc++ is GPL, so isn't suitable.)
>
> The gnu libstdc++ is *supposed* to be licensed under GPL + an exception
> that allows it to be used for things like this, and even if it weren't,
> I don't see why we couldn't use it; our own code is (effectively) GPL,
> too.
Our licensing policy requires anything we use to be compatible with all
three licences (so none of our downstream users becomes a second-class
citizen), so our own code is not "(effectively) GPL" for these purposes.
Here's the license for GNU libstdc++
http://gcc.gnu.org/onlinedocs/libstdc++/manual/license.html
An initial read suggests to me that we could use it, but if we actually
got around to considering this seriously, I'd need to take a closer look.
Gerv
Benjamin Smedberg
> Our licensing policy requires anything we use to be compatible with all
> three licences (so none of our downstream users becomes a second-class
> citizen), so our own code is not "(effectively) GPL" for these purposes.
Since we're only talking about shipping this on particular deficient mobile
platforms, and not in general, I don't know that this needs to be true.
--BDS
Zack Weinberg
>
> Our licensing policy requires anything we use to be compatible with
> all three licences (so none of our downstream users becomes a
> second-class citizen), so our own code is not "(effectively) GPL" for
> these purposes.
Out of curiosity, who is still using the code under the terms of the
MPL? I am only familiar with redistribution by Linux vendors, and they
prefer the (L)GPL as far as I know.
[I sometimes wonder why we bother with explicitly licensing as "LGPL or
GPL" when the LGPL already allows conversion to plain GPL, but that's
a separate matter.]
zw
Benjamin Smedberg
> Out of curiosity, who is still using the code under the terms of the
> MPL? I am only familiar with redistribution by Linux vendors, and they
> prefer the (L)GPL as far as I know.
Mozilla does! We're careful to avoid GPL taint so that you can ship e.g.
customized Firefox+extensions bundles without worry.
--BDS
Zack Weinberg
That just pushes the question back a step. Do we know of any current
downstream redistributor who actually makes use of this option (that
is, distributes in a way consistent with the MPL but not the (L)GPL)?
zw
Vladimir Vukicevic
> I'd add that Bionic doesn't support C++ exceptions. They don't ship an
> exception-capable runtime because when they started the Android project,
> the ARM port of GCC had really bloaty codegen for code that allowed
> exceptions to pass through.
That's fine, we don't support C++ exceptions either :-)
- Vlad
Vladimir Vukicevic
This is actually working quite well; it's tiny and builds nicely. I'd
rather go this direction than reimplementing our own STL piecemeal --
how do people feel about including this in the tree, to be used if the
OS provided c++ libs aren't sufficient? The only issue would be that
it's LGPL, but given that we'd build it as a shared library, and only
use it if the OS doesn't provide the lib, I think that's fine. (All of
our current tier 1 platforms provide decent c++ libs.)
- Vlad
Benjamin Smedberg
Or at least, I don't think anyone has done a legal analysis of how addons
and LGPL libraries as part of our core might interact, and I don't think we
want to enter that legal territory.
--BDS
Ted Mielczarek
> This is actually working quite well; it's tiny and builds nicely. I'd
> rather go this direction than reimplementing our own STL piecemeal -- how do
> people feel about including this in the tree, to be used if the OS provided
> c++ libs aren't sufficient? The only issue would be that it's LGPL, but
> given that we'd build it as a shared library, and only use it if the OS
> doesn't provide the lib, I think that's fine. (All of our current tier 1
> platforms provide decent c++ libs.)
>
>
I think the "reimplementing our own STL piecemeal" strategy was due to not
being able to use the STL due to its reliance on exceptions (and our lack
thereof).
-Ted
Vladimir Vukicevic
That's true; so, what do we want to do here? Options are 1) remove STL
usage from our tree, 2) use uClibc++ and make handwavy gestures about
exception support... both have downsides.
- Vlad
Vladimir Vukicevic
Just noticed that the jsapi tests are also using some simple normal c++
(iostreams, std::string, etc). If we try to go down the path of option
1, it feels like we're going backwards; can we figure out a way to work
around no exception support? Perhaps have a local patch to uClibc++
that makes unavailable the pieces that absolutely rely on exceptions,
and/or make some exceptions fatal? It already uses wrapper functions
for throwing each exception (void __throw_out_of_range() { throw
out_of_range(); }), so we can easily do something in there.
- Vlad
Ted Mielczarek
For test harnesses it's not as much of a concern, since if they try to throw
an exception we aren't exposing our users to potential security bugs. :) I
don't know what the right course of action for STL usage is. I agree that
removing existing STL code from our tree feels like the wrong thing to do,
but I don't know how to make it exception-safe. Perhaps taking uClibc++ and
doing something more intelligent with the exceptions is the way to go? I
remember someone (at the last platform work week?) suggesting that we just
take the existing C++ framework stuff we have (string classes, hashtables,
etc) and morph their APIs to be STL-compatible, but keep them in a mozilla
namespace as a possible compromise.
-Ted
Philip Chee
Not current, but AOL/Netscape used to ship products (Netscape Navigator
9 was based on Firefox 2.0 and Netscape Messenger 9 was based on
Thunderbird 2.0) used the MPL so that they could ship proprietary
extensions with their re-branded products (AIM, etc).
Perhaps you can ask Mike Kaply how many of his Brand Thunder clients are
shipping rebranded non GPL/LGPL versions of Firefox / Thunderbird /
SeaMonkey.
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
Philip Chee
> OS provided c++ libs aren't sufficient? The only issue would be that
> it's LGPL, but given that we'd build it as a shared library, and only
"I am also making it available with custom licenses for a fee. Contact
me for more information. Fees subject to the project and the phase of
the moon."
If push comes to the shove, I'm sure that MoFo can spring for a MPL licence.
Mook
> Out of curiosity, who is still using the code under the terms of the
> MPL? I am only familiar with redistribution by Linux vendors, and they
> prefer the (L)GPL as far as I know.
>
> [I sometimes wonder why we bother with explicitly licensing as "LGPL or
> GPL" when the LGPL already allows conversion to plain GPL, but that's
> a separate matter.]
>
> zw
Songbird does, for our non-GPL builds (which we can then send to
partners, since they kinda want to be able to distribute them in non-GPL
ways). We of course also mirror the code publicly under the GPL because
otherwise we wouldn't be an open source project ;)
(Our local patched xulrunner source is, as far as I know, still under
the tri-license because sharing things is good. That and not doing so
is dumb.)
--
Mook
Songbird hat on, for once.
Jean-Marc Desperrier
>>> I think the "reimplementing our own STL piecemeal" strategy was due to
>>> not
>>> being able to use the STL due to its reliance on exceptions (and our
>>> lack
>>> thereof).
>>
>> That's true; so, what do we want to do here? Options are 1) remove STL
>> usage from our tree, 2) use uClibc++ and make handwavy gestures about
>> exception support... both have downsides.
>
> around no exception support? Perhaps have a local patch to uClibc++
> that makes unavailable the pieces that absolutely rely on exceptions,
> and/or make some exceptions fatal?
I think the best choice is by far to make them all fatal.
That's the current long term strategy for OOM.
And what good will come out of not handling things like
__throw_out_of_range() as fatal ?
Gervase Markham
> Out of curiosity, who is still using the code under the terms of the
> MPL? I am only familiar with redistribution by Linux vendors, and they
> prefer the (L)GPL as far as I know.
Mozilla is. :-) Netscape did for Netscape 7+, I believe. There are
rather a lot of Mozilla-based applications:
http://www.mozilla.org/projects/mozilla-based.html
I suspect quite a few are using the MPL, because it most easily permits
the incorporation of proprietary changes.
> [I sometimes wonder why we bother with explicitly licensing as "LGPL or
> GPL" when the LGPL already allows conversion to plain GPL, but that's
> a separate matter.]
Because the LGPL->GPL conversion process as documented in the LGPL
requires changing all the licence headers. If people were to follow it,
that would mean that by default (i.e. the "easiest thing") would be for
them to license further changes as GPL-only, because that's what the
license headers would say. Which would mean we couldn't reincorporate them.
Having a tri-licence which includes all three means no change to the
headers is required, and so the "default" is to write code which is
available under all three, and so can be reincorporated into the Mozilla
tree.
Gerv
Gervase Markham
> Since we're only talking about shipping this on particular deficient mobile
> platforms, and not in general, I don't know that this needs to be true.
If people want to ship Mozilla derivatives on those self-same deficient
mobile platforms, I think they should get the same licence choice
freedom as people shipping Mozilla derivatives on other platforms.
But anyway, let's discuss this if it starts to look possible that we'll
actually use GNU libstdc++ :-)
Gerv
Gervase Markham
> "I am also making it available with custom licenses for a fee. Contact
> me for more information. Fees subject to the project and the phase of
> the moon."
>
> If push comes to the shove, I'm sure that MoFo can spring for a MPL licence.
The author may actually be less likely to provide it in this fashion
under a (less-strict-than-the-LGPL) open source licence than under a
proprietary one. Because it means that other potential customers of his
could instead use our MPLed version. I'm not saying it's not possible,
but it's not a given.
Gerv
Gervase Markham
>> http://cxx.uclibc.org/faq.html sounds promising, especially the latter
>> part. It's LGPL.
>
> This is actually working quite well; it's tiny and builds nicely.
If it starts looking like this is the way you want to go, can you please
file a bug in the Licensing component so we can look into that aspect?
Thanks,
Gerv
Mike Shaver
> On 23/11/09 16:23, Benjamin Smedberg wrote:
>>
>> Since we're only talking about shipping this on particular deficient
>> mobile
>> platforms, and not in general, I don't know that this needs to be true.
>
> If people want to ship Mozilla derivatives on those self-same deficient
> mobile platforms, I think they should get the same licence choice freedom as
> people shipping Mozilla derivatives on other platforms.
My recollection is that we have done this before, and shipped our
first Solaris binaries linked against GTK, which was also packaged in
our builds, because Solaris didn't ship with GTK at the time. We
provided the GTK source in the required-by-law FTP directory alongside
the binary packages, and all was fine.
People are more than welcome to ship Mozilla derivatives on those
self-same deficient mobile platforms with the libstdc++ of their
choosing; it's really a platform library, they can plug the hole with
whatever is handy.
Mike
Robert O'Callahan
> A couple of weeks ago, I wanted std::swap(), so I filed
> https://bugzilla.mozilla.org/show_bug.cgi?id=525162 and added
> xpcom/glue/Algorithm.h. I like that general approach because it taps
> into STL "mindshare" without tying us to libstdc++.
Sounds good to me!
Rob
Robert O'Callahan
> That's true; so, what do we want to do here? Options are 1) remove STL
> usage from our tree, 2) use uClibc++ and make handwavy gestures about
> exception support... both have downsides.
Isn't #1 a no-brainer, at least in non-test code, since it was never
allowed anyway and there isn't much of it?
Rob
Gervase Markham
> People are more than welcome to ship Mozilla derivatives on those
> self-same deficient mobile platforms with the libstdc++ of their
> choosing; it's really a platform library, they can plug the hole with
> whatever is handy.
OK, fair enough. :-)
Gerv
Nelson Bolyard
> On 23/11/09 16:49, Zack Weinberg wrote:
>> Out of curiosity, who is still using the code under the terms of the
>> MPL? I am only familiar with redistribution by Linux vendors, and they
>> prefer the (L)GPL as far as I know.
>
> Mozilla is. :-) Netscape did for Netscape 7+, I believe. There are
> rather a lot of Mozilla-based applications:
> http://www.mozilla.org/projects/mozilla-based.html
> I suspect quite a few are using the MPL, because it most easily permits
> the incorporation of proprietary changes.
I believe the vast majority of vendors that use NSS do so under MPL terms.