Enable media.dll / libmedia.so.

Enable media.dll / libmedia.so.
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=95841

[darin (slow to review), 2011-08-04 23:46:30]

These are all changes required to make libmedia.so build on Linux.  Please make
sure I made the change to remoting.gyp properly, thanks!

[awong, 2011-08-05 00:01:45]

I haven't been following this export stuff 100%.  I would not have expected to
need to export the operator<< overload and AlsaWrapper.

Does MEDIA_EXPORT do something other than mark the symbol as exported for use
from other modules?  If not, then what other modules need to use the ostream for
AlsaPcmOutputStream::InternalState, and AlsaWrapper?

[darin (slow to review), 2011-08-05 03:45:14]

These are the build errors I'm attempting to fix:
http://build.chromium.org/p/chromium/builders/Linux%20Builder%20%28dbg%29%28s...

It looks like alsa_output_unittest.cc relies on operator<< for gtest error
reporting, which isn't surprising.

-Darin


On Thu, Aug 4, 2011 at 5:01 PM, <ajwong@chromium.org> wrote:

> I haven't been following this export stuff 100%.  I would not have expected
> to
> need to export the operator<< overload and AlsaWrapper.
>
> Does MEDIA_EXPORT do something other than mark the symbol as exported for
> use
> from other modules?  If not, then what other modules need to use the
> ostream for
> AlsaPcmOutputStream::**InternalState, and AlsaWrapper?
>
>
>
http://codereview.chromium.**org/7572040/<http://codereview.chromium.org/7572...
>

[awong, 2011-08-05 16:24:08]

LGTM

Ah, I see.  And there's no sane way to expose the dynamic symbol only to the
unittest short of building both an .a and a .so of the code...or doing something
even weirder in windows.  sadness.  


On 2011/08/05 03:45:14, darin wrote:
> These are the build errors I'm attempting to fix:
>
http://build.chromium.org/p/chromium/builders/Linux%2520Builder%2520%2528dbg%...
> 
> It looks like alsa_output_unittest.cc relies on operator<< for gtest error
> reporting, which isn't surprising.
> 
> -Darin
> 
> 
> On Thu, Aug 4, 2011 at 5:01 PM, <mailto:ajwong@chromium.org> wrote:
> 
> > I haven't been following this export stuff 100%.  I would not have expected
> > to
> > need to export the operator<< overload and AlsaWrapper.
> >
> > Does MEDIA_EXPORT do something other than mark the symbol as exported for
> > use
> > from other modules?  If not, then what other modules need to use the
> > ostream for
> > AlsaPcmOutputStream::**InternalState, and AlsaWrapper?
> >
> >
> >
>
http://codereview.chromium.**org/7572040/%3Chttp://codereview.chromium.org/75...>
> >

[darin (slow to review), 2011-08-05 16:59:31]

Right.  Even in our Linux build this is required since we hide symbols by
default.  Although given the way Linux exports symbols, we could get away
with a commonly named macro like EXPORT for use everywhere.  Windows forces
us into needing module specific macros.

-Darin


On Fri, Aug 5, 2011 at 9:24 AM, <ajwong@chromium.org> wrote:

> LGTM
>
> Ah, I see.  And there's no sane way to expose the dynamic symbol only to
> the
> unittest short of building both an .a and a .so of the code...or doing
> something
> even weirder in windows.  sadness.
>
>
>
> On 2011/08/05 03:45:14, darin wrote:
>
>> These are the build errors I'm attempting to fix:
>>
>
> http://build.chromium.org/p/**chromium/builders/Linux%**
> 2520Builder%2520%2528dbg%2529%**2528shared%2529/builds/5007/**
>
steps/compile/logs/stdio<http://build.chromium.org/p/chromium/builders/Linux%2520Builder%2520%2528dbg%2529%2528shared%2529/builds/5007/steps/compile/logs/stdio>
>
>
>  It looks like alsa_output_unittest.cc relies on operator<< for gtest error
>> reporting, which isn't surprising.
>>
>
>  -Darin
>>
>
>
>  On Thu, Aug 4, 2011 at 5:01 PM, <mailto:ajwong@chromium.org> wrote:
>>
>
>  > I haven't been following this export stuff 100%.  I would not have
>> expected
>> > to
>> > need to export the operator<< overload and AlsaWrapper.
>> >
>> > Does MEDIA_EXPORT do something other than mark the symbol as exported
>> for
>> > use
>> > from other modules?  If not, then what other modules need to use the
>> > ostream for
>> > AlsaPcmOutputStream::****InternalState, and AlsaWrapper?
>> >
>> >
>> >
>>
>
> http://codereview.chromium.****org/7572040/%3Chttp://coderevi**
> ew.chromium.org/7572040/ <http://codereview.chromium.org/7572040/>>
>
>  >
>>
>
>
>
>
http://codereview.chromium.**org/7572040/<http://codereview.chromium.org/7572...
>

[Ami GONE FROM CHROMIUM, 2011-08-05 17:20:08]

LGTM as far as it goes but requires undoing the 95561 revert.