osmesa: drop workaround for VS2013 allocator shim

osmesa: drop workaround for VS2013 allocator shim

This is a partial revert of crrev.com/1616793003 .

crrev.com/1616793003 introduced a workaround to the clearkeycdmadapter
and osmesa libs to deal with a breakage on windows. The breakage was
because in the days of MSVS2013 and gyp the win shim was working by:
1. removing the dependency to libcrt from any target that would depend
   directly or indirectly on //base.
2. giving them a replacement shim which did redefine allocator syms.

However, all this was working only in the case that the target
was ending up linking //base, which is the case for *almost* any target
in chrome. It was known to break if we had a case of a target depending
on //base only via a shared library dependency (so depending on, but not
linking, //base).
In such case only 1 would happen but not 2, leading to a build failure
on win, as highlighted in the commit message of crrev.com/1616793003 .
We estimated this to be very rare in the codebase, and effectively did
affect only osmesa and cdmadaptr, so we added a workaround there.

Now that both gyp and MSVS2013 are no more, we can go back to the
more sensible case where only the root executable (chrome, or whatever
else executable linking base) is the only thing defining the allocator
symbols. No workaround should be needed anymore.

This only removes the shim from osmesa, but not clearkeycdmadapter.

BUG=617732
TBR=kbr@chromium.org

Review-Url: https://codereview.chromium.org/2736613005
Cr-Commit-Position: refs/heads/master@{#455245}
Committed: https://chromium.googlesource.com/chromium/src/+/efcd0c614acac68022267a2eb1af6519353906fb

[krasin1, 2017-03-07 19:20:36]

The CQ bit was checked by krasin@chromium.org to run a CQ dry run

[krasin1, 2017-03-07 19:20:56]

krasin@chromium.org changed reviewers:
+ primiano@chromium.org

[commit-bot: I haz the power, 2017-03-07 19:22:48]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[krasin1, 2017-03-07 19:30:37]

The CQ bit was unchecked by krasin@chromium.org

[Primiano Tucci (use gerrit), 2017-03-07 20:17:30]

primiano@chromium.org changed reviewers:
+ kbr@chromium.org

[Primiano Tucci (use gerrit), 2017-03-07 20:17:31]

LGTM from my side.
kbr seems OOO. I think should be fine to TBR him considered that this CL is a
subset of https://codereview.chromium.org/2429773002/ that he did already LGTM
(I didn't land that because of security concerns on the clearkeycdmadapter) and
that this is causing a bot breakage.

[krasin1, 2017-03-07 20:30:24]

Description was changed from

==========
osmesa: drop workaround for VS2013 allocator shim

This is a partial revert of crrev.com/1616793003 .

crrev.com/1616793003 introduced a workaround to the clearkeycdmadapter
and osmesa libs to deal with a breakage on windows. The breakage was
because in the days of MSVS2013 and gyp the win shim was working by:
1. removing the dependency to libcrt from any target that would depend
   directly or indirectly on //base.
2. giving them a replacement shim which did redefine allocator syms.

However, all this was working only in the case that the target
was ending up linking //base, which is the case for *almost* any target
in chrome. It was known to break if we had a case of a target depending
on //base only via a shared library dependency (so depending on, but not
linking, //base).
In such case only 1 would happen but not 2, leading to a build failure
on win, as highlighted in the commit message of crrev.com/1616793003 .
We estimated this to be very rare in the codebase, and effectively did
affect only osmesa and cdmadaptr, so we added a workaround there.

Now that both gyp and MSVS2013 are no more, we can go back to the
more sensible case where only the root executable (chrome, or whatever
else executable linking base) is the only thing defining the allocator
symbols. No workaround should be needed anymore.

This only removes the shim from osmesa, but not clearkeycdmadapter.

BUG=617732
==========

to

==========
osmesa: drop workaround for VS2013 allocator shim

This is a partial revert of crrev.com/1616793003 .

crrev.com/1616793003 introduced a workaround to the clearkeycdmadapter
and osmesa libs to deal with a breakage on windows. The breakage was
because in the days of MSVS2013 and gyp the win shim was working by:
1. removing the dependency to libcrt from any target that would depend
   directly or indirectly on //base.
2. giving them a replacement shim which did redefine allocator syms.

However, all this was working only in the case that the target
was ending up linking //base, which is the case for *almost* any target
in chrome. It was known to break if we had a case of a target depending
on //base only via a shared library dependency (so depending on, but not
linking, //base).
In such case only 1 would happen but not 2, leading to a build failure
on win, as highlighted in the commit message of crrev.com/1616793003 .
We estimated this to be very rare in the codebase, and effectively did
affect only osmesa and cdmadaptr, so we added a workaround there.

Now that both gyp and MSVS2013 are no more, we can go back to the
more sensible case where only the root executable (chrome, or whatever
else executable linking base) is the only thing defining the allocator
symbols. No workaround should be needed anymore.

This only removes the shim from osmesa, but not clearkeycdmadapter.

BUG=617732
TBR=kbr@chromium.org
==========

[krasin1, 2017-03-07 20:30:36]

The CQ bit was checked by krasin@chromium.org

[commit-bot: I haz the power, 2017-03-07 20:31:17]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-07 22:15:15]

CQ is committing da patch.

Bot data: {"patchset_id": 1, "attempt_start_ts": 1488918636184380, "parent_rev":
"336d5878c4c612627f0a8333f71b50a04b7091d1", "commit_rev":
"efcd0c614acac68022267a2eb1af6519353906fb"}

[commit-bot: I haz the power, 2017-03-07 22:15:53]

Description was changed from

==========
osmesa: drop workaround for VS2013 allocator shim

This is a partial revert of crrev.com/1616793003 .

crrev.com/1616793003 introduced a workaround to the clearkeycdmadapter
and osmesa libs to deal with a breakage on windows. The breakage was
because in the days of MSVS2013 and gyp the win shim was working by:
1. removing the dependency to libcrt from any target that would depend
   directly or indirectly on //base.
2. giving them a replacement shim which did redefine allocator syms.

However, all this was working only in the case that the target
was ending up linking //base, which is the case for *almost* any target
in chrome. It was known to break if we had a case of a target depending
on //base only via a shared library dependency (so depending on, but not
linking, //base).
In such case only 1 would happen but not 2, leading to a build failure
on win, as highlighted in the commit message of crrev.com/1616793003 .
We estimated this to be very rare in the codebase, and effectively did
affect only osmesa and cdmadaptr, so we added a workaround there.

Now that both gyp and MSVS2013 are no more, we can go back to the
more sensible case where only the root executable (chrome, or whatever
else executable linking base) is the only thing defining the allocator
symbols. No workaround should be needed anymore.

This only removes the shim from osmesa, but not clearkeycdmadapter.

BUG=617732
TBR=kbr@chromium.org
==========

to

==========
osmesa: drop workaround for VS2013 allocator shim

This is a partial revert of crrev.com/1616793003 .

crrev.com/1616793003 introduced a workaround to the clearkeycdmadapter
and osmesa libs to deal with a breakage on windows. The breakage was
because in the days of MSVS2013 and gyp the win shim was working by:
1. removing the dependency to libcrt from any target that would depend
   directly or indirectly on //base.
2. giving them a replacement shim which did redefine allocator syms.

However, all this was working only in the case that the target
was ending up linking //base, which is the case for *almost* any target
in chrome. It was known to break if we had a case of a target depending
on //base only via a shared library dependency (so depending on, but not
linking, //base).
In such case only 1 would happen but not 2, leading to a build failure
on win, as highlighted in the commit message of crrev.com/1616793003 .
We estimated this to be very rare in the codebase, and effectively did
affect only osmesa and cdmadaptr, so we added a workaround there.

Now that both gyp and MSVS2013 are no more, we can go back to the
more sensible case where only the root executable (chrome, or whatever
else executable linking base) is the only thing defining the allocator
symbols. No workaround should be needed anymore.

This only removes the shim from osmesa, but not clearkeycdmadapter.

BUG=617732
TBR=kbr@chromium.org

Review-Url: https://codereview.chromium.org/2736613005
Cr-Commit-Position: refs/heads/master@{#455245}
Committed:
https://chromium.googlesource.com/chromium/src/+/efcd0c614acac68022267a2eb1af...
==========

[commit-bot: I haz the power, 2017-03-07 22:15:54]

Committed patchset #1 (id:1) as
https://chromium.googlesource.com/chromium/src/+/efcd0c614acac68022267a2eb1af...