New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 664310 link

Starred by 1 user

Issue metadata

Status: Assigned
Owner:
Last visit > 30 days ago
Cc:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

[chromecast] Use libcast_media.so consistently for cast_shell and tests

Project Member Reported by alokp@chromium.org, Nov 10 2016

Issue description

We statically link libcast_media_1.0_default_core into tests, but only for public builds. Building and running tests for internal builds crashes because it picks up the dummy library.

1. We should not statically link for tests. We should be consistent.
2. We should rename libcast_media_1.0_default to libcast_media_1.0_dummy because the current dummy implementation is useless; and "default" gives the wrong impression that it can be used in production.

I believe all of this inconsistency was added to avoid symbol leakage from libcast_media_1.0_default, but I am pretty sure there must be some build flags that can be used to avoid those issues.
 

Comment 1 by alokp@chromium.org, Nov 10 2016

Cc: byungchul@chromium.org halliwell@chromium.org

Comment 2 by s...@chromium.org, Dec 2 2016

We can set -fvisibility=hidden in the ldflags, then mark the necessary CastMedia interfaces with __attribute__(visibility("default")) to control what exactly is exported. Since //base, //media, etc. are source_sets (producing a bunch of .o files instead of a .a file), this should hide all of the //media and //base symbols, and expose only the symbols we want to expose.

If we want to be very sure that the only symbols exposed are cast symbols, we can run readelf in a script as a build step to verify the exposed symbols. That way, if media and base are ever subtly changed to build .a, that will break our build.

Byungchul, thoughts?
This is not for symbols we define and expose. This is for symbols of other standard libraries.

For example, cast_shell statically links libstdc++.a and/so libraries also have to link it statically. If a library has a code to refer std::string, then it links and provides cast_shell std::string rather than from cast_shell's own libstdc++ linkage.

We need a flag to hide all linked library symbols since we can't change visibilities of symbols in already compiled object files. I couldn't find it unfortunately.

Sign in to add a comment