pombreda / webm

Automatically exported from code.google.com/p/webm
0 stars 0 forks source link

libvpx build fails, bad interpreter error #945

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
building vpx_scale_rtcd.h
    [CREATE] vpx_scale_rtcd.h
/nix/store/pn5ckn51r8g7qbjff5cz1qyhz45q84lf-bash-4.3-p33/bin/bash: 
/tmp/nix-build-libvpx.drv-0/libvpx-a5a5b11/build/make/rtcd.pl: /usr/bin/env: 
bad interpreter: No such file or directory

When build/make/rtcd.pl is called from libs.mk it fails with a bad interpreter 
error.  The shebang in the perl file is fine.  The problem is how the file is 
being called.

Using 'perl ' instead of '$$(qexec)' resolves the issue, however I am 
unfamiliar with libvpx so I don't know what the best solution is.

Original issue reported on code.google.com by codyo...@gmail.com on 6 Feb 2015 at 5:13

GoogleCodeExporter commented 9 years ago
$(qexec) merely keeps the command from being echo'd, you can override that with 
'make V=1'.
The problem here is: '/usr/bin/env: bad interpreter'. The shebang uses that to 
pick up the first perl in PATH using env rather than the shell, cf. perlrun [1].
In your case you either don't have it or it's elsewhere, e.g., /bin/env. What 
system are you running this under?

[1] http://perldoc.perl.org/perlrun.html

Original comment by jz...@google.com on 7 Feb 2015 at 4:14

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
Any update?

Original comment by fgalli...@google.com on 12 Feb 2015 at 11:05

GoogleCodeExporter commented 9 years ago
I haven't had a chance to look any further, there is a workaround as described.

Original comment by jz...@google.com on 12 Feb 2015 at 11:41

GoogleCodeExporter commented 9 years ago
This works for me out of the box using a recent release [1], modulo needing to 
force yasm due to configure's use of which.

# target is being set merely for clarity
$ ../configure --as=yasm --target=x86_64-linux-gcc

As mentioned a similar report 'bad interpreter: No such file or directory' can 
be made to occur by changing the command to something non-existent. In this 
case if env is there was rtcd.pl modified at all? If it were dos line endings 
for instance you'd get ': bad interpreter ...' which isn't quite right. I don't 
see anything odd in the output, so most likely not.
Do you have any exotic shell options set?

[1] nixos-minimal-14.12.428.acfbdf7-x86_64-linux.iso

Original comment by jz...@google.com on 19 Feb 2015 at 11:29

GoogleCodeExporter commented 9 years ago

Original comment by renganat...@google.com on 26 Feb 2015 at 11:09