Closed Bug 1089562 Opened 10 years ago Closed 10 years ago

*** No rule to make target ... media/libvpx/vp9/decoder/vp9_thread.c' needed by 'vp9_thread.o'.

Categories

(Core :: Audio/Video, defect)

Product:
Core
Component:
Audio/Video
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: ishikawa, Unassigned)

Details

During the local compilation of DEBUG BUILD of  
C-C thunderbird I get the error of missing file(s).

I checked TBPL, and somehow it seems to be working there.

I have no idea why my local PC has this issue.

Copying of a couple of files from |common| directory make the compilation and build succeed, but something is amiss.

TIA

Quote from the posts to mozilla.dev.platform NG.
 
> The error mentioned about the missing files was again observed on a PC
> which has C-C tree refreshed this morning.
>
> The error for one of the file is as follows:
>
> make[4]: *** No rule to make target
>
> '/new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/media/libvpx/vp9/decoder/vp9_thread.c',
> needed by 'vp9_thread.o'.  Stop.
> make[4]: *** Waiting for unfinished jobs....
> GrContext.o
> /new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/config/recurse.mk:74:
> recipe for target 'media/libvpx/target' failed
>
> If I recall correctly, after fixing this bug by temporarily copying
> vp9_thread.o from |common| directory,
> I would get error of the other missing file.
>
> I am not sure why others don't encounter this bug. Maybe different
> mozconfig
> setup.
>
> TIA
>
> On 2014年10月25日 14:00, ISHIKAWA,chiaki wrote:
>> On 2014/10/24 13:46, Anthony Jones wrote:
>>> I just wanted to give a heads up to everyone that we enabled Media
>>> Source Extensions on nightly for WebM/VP9. This brings Adaptive
>>> Streaming capability to Firefox video playback. The feature is not
>>> complete so the pref will automatically turn off when it gets to
>>> beta/release if we do nothing.
>>>
>>> You can check on YouTube by right clicking the playing video and
>>> selecting "Stats for nerds" which should appear above the "About the
>>> HTML5 player" option. If you see "DASH: yes" then you are now living in
>>> the future.
>>>
>>> This affects YouTube but may also affect sites that use MSE with
>>> WebM/VP9 but it could also affect sites that use MSE but fail to check
>>> codec compatibility.
>>>
>>> Please file any (unfiled) issues you experience as blocking bug 1083588.
>>> Don't expect it to be perfect and if you run into trouble you can set
>>> media.mediasource.enabled to false in your about:config
>>>
>>> Anthony
>>
>>
>> Hi,
>>
>> Just reporting what I observed after a source refresh half a day ago.
>>
>> I noticed during C-C TB compilation
>> a file under common needs to be copied to encoder, another one to decoder
>> directory .
>> I am talking about files below these directories.
>> mozilla/media/libvpx/vp9/{common,encoder,decoder}
>>
>> But since C-C was in such a disarray in terms of compilation lately,
> etc.,
>> and the source was refreshed just before this compilation effort,
>> I am not sure if the configuration was quite correct.
>> I failed to write down a memo exactly which files were
>> copied. I thought I was logging it using script, but did not.
>> I clobbered and then tried to see how it would work out, and then was
>> side-tracked by bug 1088497
>>
>> I can compare the directory to report what files were copied
>> if no such bugs have been filed yet and you are not aware of the issue.
>> (I tried to see which one by timestamp, but python client.py checkout
>> seems to give same timestamps to all the files and so I am not sure which
>> ones were copied. cp or Emacs's filecopy seems to preserve the timestamp.
>> That is good sometimes, but annoying sometimes.)
>>
>> But then again, I am not entirely sure if it was a temporal hiccup after
>> the source refresh.

TIA
This happened both under 32-bit and 64-bit Debian GNU/linux.
This typically means you need to clobber. The build system seems to not regenerate the build files properly after the source file name change. Try:

  ./mach clobber && ./mach build.

We had the same problem on tbpl, and clobbering the builds resolved the issue.
(In reply to Ralph Giles (:rillian) from comment #2)
> This typically means you need to clobber. The build system seems to not
> regenerate the build files properly after the source file name change. Try:
> 
>   ./mach clobber && ./mach build.
> 
> We had the same problem on tbpl, and clobbering the builds resolved the
> issue.

I see, thank you.
I left a machine compiling after manual clobbering. It would compile then.

Too bad, the revampled build infrastructure still can't cope with this type
of issue.

Clobbering and re-generating object is not a short-time task even ccache
is used and effective on a slow PC. So it would be insanely great if configure can
handle this automatically. Just a wish.

Thank you again.
(In reply to ISHIKAWA, Chiaki from comment #3)
> (In reply to Ralph Giles (:rillian) from comment #2)
> > This typically means you need to clobber. The build system seems to not
> > regenerate the build files properly after the source file name change. Try:
> > 
> >   ./mach clobber && ./mach build.
> > 
> > We had the same problem on tbpl, and clobbering the builds resolved the
> > issue.
> 
> I see, thank you.
> I left a machine compiling after manual clobbering. It would compile then.
> 

Confirmed that clobbering and invoke the make command again fixed the issue.

So I am closing as WONTFIX although I wish there is a manner to
warn the users of the trees who would probably refresh the tree once a month or so.

TIA
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.