I sometimes get this error when compiling a program:
make[1]: /usr/bin/perl: Command not found
make[1]: *** [links] Error 127
This happens with any program that requires perl to compile, such as openssl and automake. However:
sh-2.05b# perl -v
This is perl, v5.10.0 DEVEL34342 built for arm-linux-thread-multi
(with 1 registered patch, see perl -V for more detail)
sh-2.05b# /usr/bin/perl -v
This is perl, v5.10.0 DEVEL34342 built for arm-linux-thread-multi
(with 1 registered patch, see perl -V for more detail)
I definitely have perl installed. What's going on?
If this is reproducible, run the make command with strace -f, to see unambiguously which command is attempting (and failing) to exec.
I can recall from my own experience the following two situations in which an exec-family might fail on Linux with ENOENT despite that the command is actually there:
The .interp referred to by the binary isn't present (example: the LSB-compatible binary refers to /lib/ld-lsb.so.3 instead of the usual /lib/ld-linux.so.2, and LSB compatibility packages haven't been installed on the Linux machine). Seems unlikely in your scenario :)
Some kernel-level non-standard security mechanism is in place which is blocking execution of the binary - especially on locked-down embedded devices. One would think EACCES would be the more logical errno in this case, but maybe ENOENT is used to prevent leaking information about the existence of binaries to unprivileged processes.
Related
I get the following error:
Can't load '...\AppData\Local\Temp\par-6e72616f\cache-20221205133501\5743946b.xs.dll' for module GD:
load_file:
The specified module could not be found at <embedded>/DynaLoader.pm line 193.
at <embedded>/PAR/Heavy.pm line 140.
(Line breaks added for readability.)
Here is the file t2.pl:
use GD;
Here is the command to convert it to an exe (I use a batch file that timestamps it):
pp -T 20221205133501 -o t2_20221205133501.exe t2.pl
On my laptop, the exe works, but on a barebones Citrix environment it fails.
My environment:
Strawberry Perl v5.32.1 built for MSWin32-x86-multi-thread-64int
GD v2.73
I know the file is simple, but that one line is enough to cause the crash.
The file it complains about exists and is located where it is looking.
I have looked and is looks like I need to add -m GD, or -l xxx to make it work. I tried adding all the dll files I could find for GD, but failed.
I have a corporate environment so I can't really use anything that depends on external programs not in Windows 10. pp_simple depends on wxpar which I do not have. I have used:
objdump -x C:\Strawberry\perl\vendor\lib\auto\GD\GD.xs.dll | find "DLL"
which got me a list of DLLs, and I did try using them with -l.
From Re: Par with strawberry-Perl
There are likely missing DLLs that need to be added to the pp call
using the --link option.
Finding these manually can be a pain, so have a look at pp_autolink or
pp_simple (the former is mine, but adapted from the latter).
https://github.com/shawnlaffan/perl-pp-autolink
https://www.perlmonks.org/?node_id=1148802
When I run
perl -e 'which("clang")'
in Windows Command Prompt I get an empty line, but on Linux I get:
Undefined subroutine &main::which called at -e line 1.
I am asking because I am trying to figure out why which does not work in OpenSSL build script:
# see if there is NDK clang on $PATH, "universal" or "standalone"
if (which("clang") =~ m|^$ndk/.*/prebuilt/([^/]+)/|) { ... }
where the condition is always false even if clang is in the PATH.
which is not a Perl builtin function.
% perl -we 'print which("clang")'
Undefined subroutine &main::which called at -e line 1.
Keep in mind the Windows command line does not use the same quoting rules as the Linux command line, unless you're using something like WSL or bash for Windows.
The subroutine which is defined at https://github.com/openssl/openssl/blob/master/Configure#L3264 (or a similar line in other versions of the code). You'll need to make sure you've got all the build dependencies installed, all the application paths and library/include paths configured correctly, that you're following the installation directions accurately, and that you're doing things in the proper order.
You'll especially want to look in https://github.com/openssl/openssl/blob/af33b200da8040c78dbfd8405878190980727171/NOTES-WINDOWS.md and https://github.com/openssl/openssl/blob/master/NOTES-PERL.md to make sure you're following the OpenSSL project's recommendations for their build system on Windows if native Windows is where you intend to do the builds.
According to this slide from Supercharging Perl - Daina Pettit,
It reads,
Avoid versions of perl compiled with threading or DDEBUGGING unless you know you need them.
I know most distros compile Perl with threading, but my Perl on Debian (as observed with perl -V_ is compiled with -DDEBUGGING=-g does this slow it down?
Perl with debugging enabled is slower.,
Note that a perl built with -DDEBUGGING will be much bigger and will run much, much more slowly than a standard perl.
However, -DDEBUGGING=-g does not enable debugging:
As a convenience, debugging code (-DDEBUGGING) and debugging symbols (-g) can be enabled jointly or separately using a Configure switch, also (somewhat confusingly) named -DDEBUGGING. For a more eye appealing call, -DEBUGGING is defined to be an alias for -DDEBUGGING. For both, the -U calls are also supported, in order to be able to overrule the hints or Policy.sh settings.
and also documented:
Configure -DEBUGGING=-g
Adds -g to optimize, but does not set -DDEBUGGING. (Note: Your system may actually require something like cc -g2. Check your man pages for cc(1) and also any hint file for your system.)
You can test status with: perl -D, if you see the following you do not have -DDEBUGGING,
Recompile perl with -DDEBUGGING to use -D switch (did you mean -d ?)
I'm beginning to write a simple Perl program on my Mac, and I understand that the first line needs to be the location of Perl itself, every example or tutorial I find tells me the first line should be:
"#!/usr/bin/perl"
However, with that there, I attempt to run the file under localhost and I get this error:
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator, you#example.com and inform them of the time the error occurred, and anything you might have done that may have caused the error.
More information about this error may be available in the server error log.
Anyone have any idea why this is happening?
Thanks in advance, and let me know if any more information is needed!
P.S. if it helps, when I execute the command: "perl -v" it tells me
This is perl, v5.10.0 built for darwin-thread-multi-2level
(with 2 registered patches, see perl -V for more detail)
As Erik said, /usr/bin/perl is the standard location for Perl on OSX. You can also verify this by running which -a perl from terminal (this will list all instances of Perl on your path).
Can you run your script from the command-line, i.e. ./<myscript>.pl? It's possible that you haven't made the script executable.
#!/usr/bin/perl is the correct path for 10.6. If you're running from the webserver, your first line before any output should be a HTML header. You may have forgotten one?
#!/usr/bin/perl
use CGI;
print CGI->header('text/html');
print "hello world";
Attempting to install the Perl module DBD::mysql on Windows 7
From the Windows command line I executed
perl -MCPAN -e 'install DBD::mysql'
Which downloaded and uncompressed the file -- then gave me this ERROR:
CPAN.pm: Going to build C/CA/CAPTTOFU/DBD-mysql-4.018.tar.gz
Set up gcc environment - 3.4.5 (mingw-vista special r3)
C:\PROGRA~1\MySQL\MYSQLS~1.1\bin\MYSQLA~1.EXE: connect to server at 'localhost'
failed
error: 'Access denied for user 'ODBC'#'localhost' (using password: NO)'
Problem running C:\PROGRA~1\MySQL\MYSQLS~1.1\bin\MYSQLA~1.EXE - aborting ...
Warning: No success on command[C:\Perl\bin\perl.exe Makefile.PL INSTALLDIRS=site
]
Guessing the issue is that MySQL's root user has a password, but what's not clear is how I resolve the issue.
Questions, feedback, requests -- just comment, thanks!!
----------
UPDATE (1): RE: force install DBD::mysql
cpan> force install DBD::mysql
Running install for module 'DBD::mysql'
Running make for C/CA/CAPTTOFU/DBD-mysql-4.018.tar.gz
Has already been unwrapped into directory C:\Perl\cpan\build\DBD-mysql-4.018-A
1T8Uh
'C:\Perl\bin\perl.exe Makefile.PL INSTALLDIRS=site' returned status 256, won't
make
Running make test
Make had some problems, won't test
Running make install
Make had some problems, won't install
On other platforms, the build process runs the mysql_config command to get necessary information about the mysql installation without need of a user and password; on win32, if you have a mysql_config command, you have to explicitly tell Makefile.PL about it with a --mysql_config yourpathname parameter. If you don't, it looks for the mysqladmin program and uses its location to determine as much as it can but runs mysqladmin version to get the mysql version. You can provide a user/password for it to be able to do this using --testuser and --testpassword parameters to Makefile.PL.
Following up on "Robert P" comment, I checked the install guide for installing DBD::MySQL in ActivePerl on Win32; on 64, but doesn't appear to have mattered.
Command that did the job was:
ppm install DBD::mysql
The only way I've got round this in the past is a forced install. It always feels like a bodge but I haven't been able to find a better way.
Open up a CPAN shell:
perl -MCPAN -e 'shell'
Then do a force install
force install DBD::mysql
quit gets you back out of the shell.
as ysth said , maybe try this :
cd C:\Perl\cpan\build\DBD-mysql-4.018-A
and run
perl Makefile.PL --testuser validuser --testpassword validpassword
and then try to make - make test - make install,
or its equivalents on windows