Is this reproducing in GYP and GN builds?

Sort of strange this is coming up only now... These two files have coexisted since July of last year. New diagnostics/warning from LIBTOOL-STATIC?

+cc more libvpx people; might need to rename a file upstream if basename collisions are a problem. I'm a little surprised that the build is not failing w/an undefined symbol if this warning means the .a file is missing the symbols from one of the files due to the collision.

This is my component build with GN on my Mac. Dunno if it's happening in gyp; I switched over because that's apparently what all the cool kids are doing.

+rsesek if it's a build system thing.

Some background: https://groups.google.com/a/chromium.org/forum/#!topic/gn-dev/bbOBxxheLgc

Could be a GN problem: How does GN name .o files? Can we control it in BUILD.gn? 

When using upstream libvpx (i.e. non-gyp non-GN) loopfilter_sse2.asm produces loopfilter_sse2.asm.o (and loopfilter_sse2.c.o for the .c file). 

The gypi files referencing the two files don't appear to be doing anything special re output file naming:
https://chromium.googlesource.com/chromium/deps/libvpx/+/master/libvpx_srcs_x86.gypi
https://chromium.googlesource.com/chromium/deps/libvpx/+/master/libvpx_srcs_x86_intrinsics.gypi

The gni file references both:
https://chromium.googlesource.com/chromium/deps/libvpx/+/master/libvpx_srcs.gni

Apparently with gyp we get behavior similar to upstream libvpx (i.e. .c -> .c.o and .asm -> .asm.o), but with gyp we lose the original extension (.c -> .o and .asm -> .o).

Renaming things upstream is probably not going to work here: There are many collisions like this. (quantize_sse2, variance_sse2, more). 

@rsesek, re #3 & #4:

I read the background information: Was the proposed target_hash thing implemented? Is there any guidance on how it would be integrated in the libvpx BUILD.gn (or a live example where someone else is using it)?

It seems like to make this go away the upstream project has to make sure there are no basename collisions in any of its source files.  Getting to that point would cause heavy churn upstream making it something that isn't really feasible in the near term. 

Also, having to internalize a list of rules related to the requirements of the build systems of downstream projects before creating a new source file in libvpx seems ridiculous, and that's where it sounds like this issue is headed unless I'm missing something.

Moving myself to CC because I have no idea how to proceed on this at present.

Brett/Sylvain: Was any progress made about the unique output names for static libs?

I didn't make any progress on the unique ouput names as we decided to use a framework (i.e. a dynamic library) for the targets that experienced the same issue on iOS.

No, nothing has been added for this.

Brett, can we assign this to you / someone from the GN team?

this came up in  https://crbug.com/649698  with the suggestion that it get filtered out as the two files are expected to be in the build together.

 Issue 649698  has been merged into this issue.

Yup, see discussion in  bug 649698 ; if folks are still seeing this we should filter it out, probably in src/build/toolchain/mac/filter_libtool.py

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This was fixed by https://chromium-review.googlesource.com/c/chromium/src/+/735132.