My testing environment includes some older platforms. I'm trying to test OpenSSL on an older Debian 6 platform, and the OpenSSL test scripts are having trouble with Perl 5.10. So I am trying to fix a "Test::More version 0.96 required..." when running OpenSSL's test suite.
I downloaded Perl 5.22.1, built it from sources, and installed it in /opt/perl with ./configure -des -Dprefix=/opt/perl:
$ ls /opt/perl/
bin lib
$ ls -Al /opt/perl/bin/ | grep perl
-rwxr-xr-x 2 root root 1879707 Mar 30 12:01 perl
-rwxr-xr-x 2 root root 1879707 Mar 30 12:01 perl5.22.1
-rwxr-xr-x 2 root root 45365 Mar 30 12:01 perlbug
...
$ ls /opt/perl/lib
5.22.1 site_perl
I created a script to forward calls into the new Perl:
$ which perl
/usr/local/bin/perl
$ cat /usr/local/bin/perl
#!/usr/bin/env bash
LD_LIBRARY_PATH="/opt/perl/lib:$LD_LIBRARY_PATH"; PERL5LIB="/opt/perl/lib/5.22.1:$PERL5LIB"; \
/opt/perl/bin/perl5.22.1 "$#"
However, when I run the OpenSSL test script I continue to encounter "Test::More version 0.96 required..." (both with and without PERL5LIB):
$ make test
( cd test; \
SRCTOP=../. \
BLDTOP=../. \
EXE_EXT= \
OPENSSL_ENGINES=.././engines \
/usr/bin/perl .././test/run_tests.pl )
../test/recipes/01-test_abort.t ........... Test::More version 0.96 required--this is only version 0.92
...
I'm obviously doing something wrong with the new Perl on this testing machine.
What's wrong with the Perl installation?
Test::More is available:
$ find /opt/perl -name '*More*'
/opt/perl/lib/5.22.1/Test/More.pm
And it seems to be a version that meets requirements:
$ cat /opt/perl/lib/5.22.1/Test/More.pm | grep VERSION
our $VERSION = '1.001014';
$VERSION = eval $VERSION; ## no critic (BuiltinFunctions::ProhibitStringyEval)
Related, I'm not experienced with Perl, so I have lots of gaps. I thought it had to do with PERL5LIB since Test::More seems to be related to it. Perl's INSTALL has this to say:
When using the newer perl, you can add these paths again in the
PERL5LIB environment variable or with perl's -I runtime option.
I don't quite understand why the new PM files would not be included with the new Perl by default. And I don't understand why adding them via PERL5LIB does not resolve the issue. So I guess it means PERL5LIB is not part of the problem.
Debugging these is never fun...
Your problem is that when you make test it eventually does /usr/bin/perl .././test/run_tests.pl which is going to pull in the old Perl and not the new Perl you created.
You need to either figure out where it gets that /usr/bin/perl from, or to put your new Perl there instead. A natural guess is that you began installing with your old Perl, installed a new one, went back to your old one, and it has the original configuration.
Related
Am new to lua/luajit. I was looking for a socket api for lua, and luasocket came up in searches, pacman -Ss luasocket doesnt exist so I have to compile it from source. Have not been successful, I was wondering if anyone can provide a makefile to build luasocket on msys2? Thanks in advance
I made a fork to to this using mingw64 and lua 5.3.
It's not as clean I wish it could be but it works : https://github.com/pmalhaire/luasocket
build and install :
$ git clone git#github.com:pmalhaire/luasocket.git
[...]
$ cd luasocket
[...]
$ make LUAV=5.3 PLAT=msys2
[...]
$ make LUAV=5.3 PLAT=msys2 install
[...]
$ make test
lua test/hello.lua
Hello from LuaSocket 3.0-rc1 and MIME 1.0.3!
GNU make gives me a strange error message, which I do not understand.
gao#L8470-130213 ~
$ make
echo Test
C:\Program: C:\Program: is a directory
make: *** [test] Error 126
This is what I thought of verifying:
gao#L8470-130213 ~
$ less makefile
test:
echo Test
gao#L8470-130213 ~
$ which make
/c/Programx86/GnuWin32/bin/make
gao#L8470-130213 ~
$ /c/Progra~2/GnuWin32/bin/make.exe test
echo Test
C:\Program: C:\Program: is a directory
make: *** [test] Error 126
gao#L8470-130213 ~
$ make --version
GNU Make 3.81
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
This program built for i386-pc-mingw32
It feels like some other program is trying to run at the end, and that its path includes some spaces. In that case, what program could it be, and how can I prevent it from running?
I have seen this thread and tried to disable my antivirus, which did not help.
I have also looked into permissions, but I am not sure if makefile needs execution rights. I can't seem to be able to change that anyway (running in bash on windows. makefile is not read-only when I check in explorer):
gao#L8470-130213 ~
$ ls -l makefile
-rw-r--r-- 1 gao Administ 21 Apr 15 14:53 makefile
gao#L8470-130213 ~
$ chmod +x makefile
gao#L8470-130213 ~
$ ls -l makefile
-rw-r--r-- 1 gao Administ 21 Apr 15 14:53 makefile
What is going on with make, what can I do?
It's not "some other program" that's trying to run, it's the echo command. Make prints the command to be run, echo test, but you never see the output (test) so that means it failed trying to find the echo program. Unfortunately I'm not very familiar with the vagaries of running GNU make on Windows: there are lots of different options. One possibility would be to get a newer version of GNU make; 3.81 is very old. 3.82 is now available and might work better for you.
Good info you added above about your environment re: using bash; that wasn't clear from the original question and on Windows there are many different ways to do things. You're using the mingw version of make; that version (as I understand it) does NOT use bash as the shell to run commands in: it's supposed to be used with native Windows environments which do not, certainly, have bash available. I believe that the version of make you have is invoking commands directly, and/or using command.com. Certainly not a UNIX shell like bash.
If you want to use bash you should set the SHELL make variable to the path of your bash.exe program. If you're using a Cygwin environment you can use the GNU make that comes with Cygwin which behaves more like a traditional make + shell.
Otherwise you'll need to write your commands using Windows command.com statements.
Again, I don't use Windows so this is mostly hearsay.
PS. The makefile does not need to be executable.
What is going on is that make doesn't like file names or directory names with spaces in them, such as Program Files. Neither do most of the utilities that makefiles typically rely on, such as the shell to execute commands with.
I create a junction from Program Files to ProgramFiles and use the latter whenever I encounter cases like this.
Building our own deb packages we've run into the issue of having to patch manually some scripts so they get the proper prefix.
In particular,
We're building mono
We're using official tarballs.
The scripts that end up with wrong prefix are: mcs, xbuild, nunit-console4, etc
An example of a wrong script:
#!/bin/sh
exec /root/7digital-mono/mono/bin/mono \
--debug $MONO_OPTIONS \
/root/7digital-mono/mono/lib/mono/2.0/nunit-console.exe "$#"
What should be the correct end result:
#!/bin/sh
exec /usr/bin/mono \
--debug $MONO_OPTIONS \
/usr/lib/mono/2.0/nunit-console.exe "$#"
The workaround we're using in our build-package script before calling dpkg-buildpackage:
sed -i s,`pwd`/mono,/usr,g $TARGET_DIR/bin/mcs
sed -i s,`pwd`/mono,/usr,g $TARGET_DIR/bin/xbuild
sed -i s,`pwd`/mono,/usr,g $TARGET_DIR/bin/nunit-console
sed -i s,`pwd`/mono,/usr,g $TARGET_DIR/bin/nunit-console2
sed -i s,`pwd`/mono,/usr,g $TARGET_DIR/bin/nunit-console4
Now, what is the CORRECT way to fix this? Full debian package creation scripts here.
Disclaimer: I know there are preview packages of Mono 3 here! But those don't work for Squeeze.
the proper way is to not call ./configure --prefix=$TARGET_DIR
this tells all the binaries/scripts/... that the installated files will end up in ${TARGET_DIR}, whereas they really should endup in /usr.
you can use the DESTDIR variable (as in make install DESTDIR=${TARGET_DIR}) to change (prefix) the installation target at install time (files will end-up in ${TARGET_DIR}/${prefix} but will only have ${prefix} "built-in")
I am wondering if it is possible for CMake to run tests like one might run with a configure script. Specifically I want to test if the system I am compiling on has support for the rdtscp instruction.
I am using Linux and if I were using a configure script I could do something like:
cat /proc/cpuinfo | head -n 19 | tail -1 | grep -c rdtscp
which would give me 0 if the rdtscp feature was not present or a 1 if it were. I could then use this to determine whether to #define RDTSCP. I'm wondering if it's possible to do something similar with CMake even if it's not completely portable (I'm only running under Linux I'm not using Visual Studio, etc.).
execute_process(COMMAND cat /proc/cpuinfo
COMMAND head -n 19
COMMAND tail -1
COMMAND grep -c rdtscp
OUTPUT_VARIABLE OUT)
Selecting line 19 exactly makes this brittle. On my desktop (Linux 4.20 on i7-6700k), that line is
wp : yes
Instead use grep's pattern-matching ability to check for the flags\t\t: line.
grep -l '^flags[[:space:]]*:.*rdtscp' /proc/cpuinfo prints the filename and exits with success after the first match. Or prints nothing and exists with failure status if it doesn't find a match.
I don't know CMake, but based on the other answer presumably you'd use
execute_process(COMMAND grep -l '^flags[[:space:]]*:.*rdtscp' /proc/cpuinfo
OUTPUT_VARIABLE OUT)
The simpler version of this is just grep -l rdtscp /proc/cpuinfo, but requiring a match in the flags : line will prevent any possible false-positive. (To be even more belt-and-suspenders, you could require space or end of line before/after, maybe with PCREgrep for zero-width assertions. In case some future feature flag like XYZrdtscpABC that can be present without RDTSCP support becomes a thing in the future. Or like broken_rdtscp). Or we could just assume that rdtscp is never at the end of the a line and look for ^flags.*:.* rdtscp.
Using -l gets grep to exit after the first match, in case you were using head/tail as an optimization to avoid processing more lines on massively multi-core systems like Xeon Phi? It will still read the whole file if there's no match for rdtscp, but probably any massively-multi-core system will have RDTSCP. And grep is very fast anyway.
I've just installed RVM on a new machine and when switching into a directory containing a .rvmrc file (which I've accepted) I'm getting:
ERROR: Neither sha256sum nor shasum found in the PATH
I'm on OS X 10.5.8. — Probably missing something somewhere. Any ideas what's going on and how to fix this?
My OpenSSL happened to not have a sha256 enc function for some reason:
$ openssl sha256
openssl:Error: 'sha256' is an invalid command.
After some googling, I found that there is an equivalent called gsha256sum that comes with the homebrew recipe "coreutils". After installing that (brew install coreutils), I had a gsha256sum binary in /usr/local/bin, so it was just a matter of symlinking it:
$ sudo ln -s /usr/local/bin/gsha256sum /usr/local/bin/sha256sum
That fixed it for me.
ciastek's answer worked for me until I tried to run rvm within a $() in a bash script - rvm couldn't see the sha256sum function. So I created a file called sha256sum with the following contents:
openssl sha256 "$#" | awk '{print $2}'
put it in ~/bin, made it executable, and added that folder to my path (and removed the function from my .bashrc).
(Many thanks to my coworker Rob for helping me find that fix.)
Means you're missing the binary in /usr/bin or your path is somehow missing /usr/bin. Open a new shell and run echo $PATH | grep '/usr/bin' and see if its returned. Also, ls -alh /usr/bin/shasum and make sure the binary is there and executable. There is no sha256sum on OS X, just shasum.
On MacOS Sierra run
$ shasum -a 256 filename
Based on #vikas027 comment just add
alias sha256sum='shasum -a 256' to your ~/.zshrc
In my opinion Leopard just doesn't have /usr/bin/shasum.
Take a look at shasum manpage - this manpage is only for Snow Leopard. Other manpages, like ls manpage (can't link to it, not enough reputation), are for previous versions of MacOS X.
Workaround: Use OpenSSL to calculate sha256 checksums.
Leopards' OpenSSL (0.9.7) doesn't handle sha256. Upgrade OpenSSL. I've used MacPorts (can't link to it, not enough reputation). OpenSSL's dependecy zlib 1.2.5 required to upgrade XCode to 3.1. Can I get Xcode for Leopard still? is helpful.
Alias sha256sum to OpenSSL and correct the way it formats an output. I've put in my .bash_profile:
function sha256sum() { openssl sha256 "$#" | awk '{print $2}'; }
I'm on a relatively fresh install of Lion (OS X 10.7.4). In my /usr/bin/ folder I had these files:
-rw-rw-rw- 35 root wheel 807B /usr/bin/shasum
-rwxr-xr-x 1 root wheel 7.5K /usr/bin/shasum5.10
-rwxr-xr-x 1 root wheel 7.5K /usr/bin/shasum5.12
I had a shasum, it just wasn't marked as executable. A quick sudo chmod a+x /usr/bin/shasum solved the issue for me.
For mac os X 10.9.5 and you profile get /usr/bin path
date +%s | shasum | base64 | head -c 32 ; echo
And if you found yourself here in 2022 wondering what works on the latest Mac (Mac OS Big Sur). Do following.
sudo brew install coreutils
sudo ln -s /usr/bin/shasum<Version_for_your_installation> /usr/local/bin/sha256sum