Avoiding size_t in MIPS.

Avoiding size_t in MIPS.

TBR=pkasting@chromium.org

BUG=526716
Committed: https://chromium.googlesource.com/external/webrtc/+/32e2f461b13c530d34f9c434e7e76da6ff3eda83

[minyue-webrtc, 2015-08-31 15:17:21]

minyue@webrtc.org changed reviewers:
+ kwiberg@webrtc.org, pkasting@chromium.org

[minyue-webrtc, 2015-08-31 15:19:51]

Hi,

MIPS compiler shouts out for size_t. It may be best to update the build
environment, and an action item is put on someone (see the bug tracker). It
would be easiest to change size_t to int for now.

Please take a look.

[jonross, 2015-08-31 15:38:00]

On 2015/08/31 15:19:51, minyue-webrtc wrote:
> Hi,
> 
> MIPS compiler shouts out for size_t. It may be best to update the build
> environment, and an action item is put on someone (see the bug tracker). It
> would be easiest to change size_t to int for now.
> 
> Please take a look.

LGTM

[minyue-webrtc, 2015-08-31 15:38:25]

On 2015/08/31 15:19:51, minyue-webrtc wrote:
> Hi,
> 
> MIPS compiler shouts out for size_t. It may be best to update the build
> environment, and an action item is put on someone (see the bug tracker). It
> would be easiest to change size_t to int for now.
> 
> Please take a look.

Due to some urgency, I'd TBR this CL

[minyue-webrtc, 2015-08-31 15:40:23]

Committed patchset #1 (id:1) manually as
32e2f461b13c530d34f9c434e7e76da6ff3eda83 (presubmit successful).

[kwiberg-webrtc, 2015-08-31 17:55:37]

On 2015/08/31 15:40:23, minyue-webrtc wrote:
> Committed patchset #1 (id:1) manually as
> 32e2f461b13c530d34f9c434e7e76da6ff3eda83 (presubmit successful).

This is very strange. stddef.h should have defined size_t, but if it didn't, the
right way to solve this should be to find out which header does define it. But
since that might take some time given that we don't have a mips build env handy,
I guess this is an OK band-aid.

[Peter Kasting, 2015-08-31 18:26:16]

I don't understand how this could even compile.  The code in lattice.c
forward-declares this function ass taking a size_t, and you didn't change that. 
It seems like there's no way this could build on MIPS.

Are you sure my previous fix didn't actually fix this?  Note that the previous
fix got rolled in to Chrome and then the roll was reverted, so the MIPS build
would have still appeared to be failing.  The right answer would have been to
simply roll forward again to pick the fix back up.  By contrast, I think if you
roll this in, you'll simply exchange a compile error for a link error.

[minyue-webrtc, 2015-08-31 18:46:18]

On 2015/08/31 18:26:16, Peter Kasting wrote:
> I don't understand how this could even compile.  The code in lattice.c
> forward-declares this function ass taking a size_t, and you didn't change
that. 
> It seems like there's no way this could build on MIPS.
> 
> Are you sure my previous fix didn't actually fix this?  Note that the previous
> fix got rolled in to Chrome and then the roll was reverted, so the MIPS build
> would have still appeared to be failing.  The right answer would have been to
> simply roll forward again to pick the fix back up.  By contrast, I think if
you
> roll this in, you'll simply exchange a compile error for a link error.

I see, I didn't notice the forward declaration in lattice.c. So yes, it will
likely still fail.

I am not aware of the previous fix, would you try to investigate?

[Peter Kasting, 2015-08-31 18:50:03]

I'm now more convinced that this is wrong.

Here is a timeline:

https://chromium.googlesource.com/chromium/src/+/8a0217ea5c60e640290e4f51a05b...
- I roll in the original broken code on MIPS.
https://chromium.googlesource.com/chromium/src/+/6e3d2360717f4b96d0172614f25f...
- I roll in the compile fix.
https://chromium.googlesource.com/chromium/src/+/655c81e9f1b7821e1007ecf562d1...
- Compile fix roll is reverted.
https://chromium.googlesource.com/chromium/src/+/1eebe8692daf30d932cd4284bf54...
- Compile fix is rolled back in.

Now look at the bot's build log:
https://uberchromegw.corp.google.com/i/chromeos/builders/mipsel-o32-generic%2...

We see the build starts failing to compile, then the compile gets fixed.  Then a
day or so later the compile breaks again.  All these line up with the commits
above.  However, before the compile fix is rolled back in, the bot changes from
failing to compile to failing to sync, which happens before the compile step. 
So the bot never turns green after the compile fix is rolled back in because
it's not reaching that point.

So the right answer here is to revert this change and roll the revert into
Chromium, and separately for someone to figure out why the "emerge" step is
failing on the MIPS bot.  I don't know who owns that bot to ask about this. 
Minyue, can you get this looked into?

[ajm, 2015-08-31 18:51:58]

On 2015/08/31 18:46:18, minyue-webrtc wrote:
> On 2015/08/31 18:26:16, Peter Kasting wrote:
> > I don't understand how this could even compile.  The code in lattice.c
> > forward-declares this function ass taking a size_t, and you didn't change
> that. 
> > It seems like there's no way this could build on MIPS.
> > 
> > Are you sure my previous fix didn't actually fix this?  Note that the
previous
> > fix got rolled in to Chrome and then the roll was reverted, so the MIPS
build
> > would have still appeared to be failing.  The right answer would have been
to
> > simply roll forward again to pick the fix back up.  By contrast, I think if
> you
> > roll this in, you'll simply exchange a compile error for a link error.
> 
> I see, I didn't notice the forward declaration in lattice.c. So yes, it will
> likely still fail.
> 
> I am not aware of the previous fix, would you try to investigate?

I think we need to find someone who can do a MIPS build to repro.

[minyue-webrtc, 2015-08-31 18:55:23]

minyue@webrtc.org changed reviewers:
+ niklase@chromium.org

[minyue-webrtc, 2015-08-31 18:56:21]

On 2015/08/31 18:50:03, Peter Kasting wrote:
> I'm now more convinced that this is wrong.
> 
> Here is a timeline:
> 
>
https://chromium.googlesource.com/chromium/src/+/8a0217ea5c60e640290e4f51a05b...
> - I roll in the original broken code on MIPS.
>
https://chromium.googlesource.com/chromium/src/+/6e3d2360717f4b96d0172614f25f...
> - I roll in the compile fix.
>
https://chromium.googlesource.com/chromium/src/+/655c81e9f1b7821e1007ecf562d1...
> - Compile fix roll is reverted.
>
https://chromium.googlesource.com/chromium/src/+/1eebe8692daf30d932cd4284bf54...
> - Compile fix is rolled back in.
> 
> Now look at the bot's build log:
>
https://uberchromegw.corp.google.com/i/chromeos/builders/mipsel-o32-generic%2...
> 
> We see the build starts failing to compile, then the compile gets fixed.  Then
a
> day or so later the compile breaks again.  All these line up with the commits
> above.  However, before the compile fix is rolled back in, the bot changes
from
> failing to compile to failing to sync, which happens before the compile step. 
> So the bot never turns green after the compile fix is rolled back in because
> it's not reaching that point.
> 
> So the right answer here is to revert this change and roll the revert into
> Chromium, and separately for someone to figure out why the "emerge" step is
> failing on the MIPS bot.  I don't know who owns that bot to ask about this. 
> Minyue, can you get this looked into?

niklase@ believes that this is an infra problem, he has reverted this CL and is
looking into the true problem