I made exe file with pp using Strawberry Perl, but when I run it on another machine, I get following error:
The program can't start because libexpat-1__.dll is missing from your computer. Try reinstalling the program to fix this problem.
I make the executable with this command:
pp -M FindBin -M DateTime -M DateTime::Format::JSON::MicrosoftDateFormat -M DateTime::Format::DateParse -M REST::Client -M JSON::XS -M Spreadsheet::ParseExcel -M Spreadsheet::ParseXLSX -M Log::Log4perl::Tiny -o test.exe test.pl
I tried using -a "c:\strawberry\c\bin\libexpat-1_.dll" (didn't help) and -l "c:\strawberry\c\bin\libexpat-1_.dll" ("Can't find shared library.." error).
How can I resolve this issue?
I had a typo in DLL name. Using -l option resolved issue. Specifying modules in the command wasn't necessary, as pp scans script for the used modules, and includes them automatically. Built it with:
pp -l "libexpat-1__.dll" -o test.exe test.pl
Related
I'm try to compile a matlab project on RHEL 7.6,
Whene I try to run the follow command:
mcc -m SliceViewerMain.m -a <PATH>/*.fig -a <PATH>/*.bmp -a <PATH>/*.m
I get this error:
Error: You specified the file "<PATH>/pause_e.bmp" without using the "-a" option.
Is anyone know why I get that?
You don't specify, but I suspect you're using mcc at the shell command-prompt, rather than in MATLAB? In which case, the shell is expanding the * wildcard before mcc gets to see it, so it's as if you said:
$ mcc ... -a <PATH>/pause_a.bmp <PATH>/pause_b.bmp <PATH>/pause_c.bmp ...
The fix is either run the command inside MATLAB, or hide the wildcard expansion from the shell and let mcc expand by doing
$ mcc ... -a '<PATH>/*.fig' ...
I.e. use single quotes.
I have the need to start a java rest server with concourse that lives on an Ubuntu 18.04 machine. The version of concourse my company uses is 5.5.11. The server code is written in Java, so a simple java -jar <uber.jar> suffices from the command line (see below). In production, I will not have this simple luxury, hence my question.
I have an scp command working that copies the .jar from concourse to the target Ubuntu machine:
scp -i /tmp/key.p8 -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null ./${NEW_DIR}/${ARTIFACT_NAME}.${ARTIFACT_FILE_TYPE} ${SRV_ACCOUNT_USER}#${JAVA_VM_HOST}:/var/www
Note that my private key is passed with -i and I can confirm that is working.
I followed this other SO Q&A that seemed to be promising: Getting ssh to execute a command in the background on target machine
, but after trying a few permutations of the suggested solution and other answers, I still don't have my rest service kicked off.
I've tried a few permutations of this line in my concourse script:
ssh -f -i /tmp/pvt_key1.p8 -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null ${SRV_ACCOUNT_USER}#${JAVA_VM_HOST} "bash -c 'nohup java -jar /var/www/${ARTIFACT_NAME}.${ARTIFACT_FILE_TYPE} -c \"/opt/testcerts/clientkeystore\" -w \"password\" > /dev/null 2>&1 &'"
I've tried with and without the -f and -t switches in ssh, with and without the file stream redirection, with and without nohup and the Linux background ('&') command and various ways to escape the quotes.
At the bash prompt, this line successfully starts my server. The two switches are needed to point to the certificate and provide the password:
java -jar rest-service.jar -c "/opt/certificates/clientkeystore" -w "password"
I really think this is possible to do in Concourse, but I'm stuck at this point.
After a lot of trial an error, it seems I needed to do this:
ssh -f -i /tmp/pvt_key1.p8 -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null ${SRV_ACCOUNT_USER}#${JAVA_VM_HOST} "bash -c 'sudo java -jar /var/www/${ARTIFACT_NAME}.${ARTIFACT_FILE_TYPE} -c \"/path/to/my/certificate\" -w \"password\" > /var/www/log.txt 2>&1 &'"
The key was I was missing the 'sudo' portion of the command. Using nohup as opposed to putting in a Linux bash background indicator ('&') seems to give me an error in the pipeline. This works for me, but others are welcome to post responses with better answers or methods that might be a better practice.
I am trying to download all files starting with traceroute from https://data-store.ripe.net/datasets/atlas-daily-dumps/ via wget.
I am running the following command:
wget -A traceroute* -m -np https://data-store.ripe.net/datasets/atlas-daily-dumps/ --no-check-certificate
It creates the directories, checks index.html's and then within 5 minutes it stops, without downloading any traceroute files.
When I try another type of file via
wget -A connection* -m -np https://data-store.ripe.net/datasets/atlas-daily-dumps/ --no-check-certificate
it donwloads the connection files no problem. What can be the issue?
You probably have a local file that matches the glob traceroute*; you need to put single quotes around it so the shell won't match anything:
wget -A 'traceroute*' -m -np https://data-store.ripe.net/datasets/atlas-daily-dumps/ --no-check-certificate
specifying traceroute*.bz2 seems to have fixed the problem
I'm using Par::Packer on OSX and Linux to create binaries for some applications that utilize Paws.
I'm calling pp like so:
pp -o build_cluster -x -c -I lib/ #ppdeps bin/build_cluster
ppdeps contains a list of modules that caused pp to fail because they weren't detected at build time. The only way that I'm aware of to make this work is to run pp repeatedly, wait for it to fail, then add the module it complains about to ppdeps.
My question is whether there's a better way to do this, or a way to get a full list of dependencies beforehand? I could write a script to do what I've been doing manually, but if there's a better way, I'd be glad to know it.
ppdeps contents:
-I local/lib/perl5/
-a fakename.conf
-M Paws::Net::Caller
-M Paws::Net::RetryCallerRole
-M Paws::Net::APIResponse
-M Paws::Net::S3Signature
-M Paws::Net::RestXmlCaller
-M Paws::Net::RestXMLResponse
-M Paws::API::Caller
-M Paws::API::EndpointResolver
-M Paws::S3
-M Paws::S3::ListBuckets
-M Paws::S3::ListBucketsOutput
-M Paws::Route53
-M Method::Generate::BuildAll
-M IO::Socket::SSL
-M Net::SSLeay
-M Archive::Zip::ZipFileMember
This is incomplete, I'm still building it for this app. The more Paws modules are included in the app, the more hidden dependencies pop up.
This has only been an issue with apps that use Paws and, to a lesser extent, Moose.
Here is how i make a build.
pp -o build/run -B -I local/lib/perl5/ script/app.pl
In the following example, I expected the error message to come from xyz, not from getopt. What am I doing wrong?
/tmp> getopt --name xyz --options "xyz:" -- -x
-x --
/tmp> getopt --name xyz --options "xyz:" -- -x -z
getopt: option requires an argument -- z
-x --
How do I make it say xyz: option requires an argument -- z; isn't that what --name is for?
UPDATE
Seems to be a bug. My getopt comes from cygwin
$ getopt --version
getopt from util-linux 2.25.2
It seems to be bug in some versions of the program.
It works for me in in Centos 7.3 and Fedora 19
[vps1 ~]$ cat /etc/redhat-release
CentOS Linux release 7.3.1611 (Core)
[vps1 ~]$ getopt --name xyz --options "xyz:" -- -x -z
xyz: option requires an argument -- 'z'
-x --
[vps1 ~]$ getopt -V
getopt from util-linux 2.23.2
But it doesn't in my MinGW shell (from Git for Windows)
$ getopt --name xyz --options "xyz:" -- -x -z
getopt: option requires an argument -- z
-x --
$ getopt -V
getopt from util-linux 2.26.2
Update: It works also in 2.27.1 in Linux. And it doesn't work in (at least some version of) Cygwin. So the problem seems to be in the Windows ports (both Mingw and Cygwin, interestingly).
I'll throw a wild guess (not big probability of hitting the target):
The getopt program, since this commit tries to deal with some environnments (in particular, BSD; not Linux) that have/use the getprogname/setprogname to get/set the "current" program name (instead of relying on argv[0]).
#if defined (HAVE_SETPROGNAME) && !defined (__linux__)
setprogname(name);
Now, let's imagine that
Cygwin and MinGW/Msis both support those functions.
However, they lack the HAVE_SETPROGNAME define
Further, their getopt functions (mind you, not the program), just like the BSD version, use getprogname instead of argv[0]
In that case, the problem would be explained. However, I'm skeptical - of point 3 especially.
This is a bug (or just a non-portability issue) which is already fixed in util-linux 2.28, by commit 30fbf2f6. Before this fix it worked only on Linux, OSX and a few BSD flavors but not on WIN32 or GNU-Hurd for example.
If you can't upgrade util-linux (might be difficult to build on windows), then you could use this shell workaround:
bash -c 'exec -a "XYZ" getopt --options "xyz:" -- -x -z'
Note that still using the --name option would override this trick again once if getopt will be updated one day.
Of course you could also simply copy/link/rename the getopt program to whatever name you want.