Issue 491978 in chromium: [Cronet] compatibility with single-process apps using C++

[chro...@googlecode.com]

Status: Available
Owner: ----
CC: m...@chromium.org, tha...@chromium.org, k...@chromium.org
Labels: OS-Android Pri-2 Cr-Internals-Network-Library

New issue 491978 by pa...@chromium.org: [Cronet] compatibility with
single-process apps using C++
https://code.google.com/p/chromium/issues/detail?id=491978

As discussed in Issue 427718, mixing a few C++ libraries in the same
process should be done carefully, if done at all. With cronet this is
somewhat less of a problem because cronet provides only java APIs (so two
libs don't call each other, C++ exceptions don't fly across the libs).

Options:
1. ship cronet as a dynamic library, exporting _only_ JNI interfaces, all
other internal symbols (including ones coming from libc++) should be hidden.
2. ship all of cronet C++ stuff as source, and teach apps to build it (I
suspect it won't work at scale)

It might be that (1) is the current plan, in this case .. sgtm I guess

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[chro...@googlecode.com]

Updates:
Status: WontFix

Comment #2 on issue 491978 by pa...@chromium.org: [Cronet] compatibility

with single-process apps using C++
https://code.google.com/p/chromium/issues/detail?id=491978

For the binary size: I'd suggest to compare the full list of
compiler/linker options for libchrome.so and libchronet.so. If there are
interesting differences, let me know. Misha, is there a specific issue for
that?

Orthogonally, we have a few ideas how to shrink some c++ support objects
(listed in Issue 485154). If you have cycles to actually ship them, that'd
be great, feel free to ask questions to all CC'ed there.

In any case, there is nothing left to do in this bug.