I'm compiling my matlab .m functions (and mex files) to run as a standalone program on a Linux server. In the end, I manage to compile all files and even run them, although in the process I do get some warnings:
Warning: Adding path "input_folder1" to Compiler path instance.
Warning: Adding path "input_folder2" to Compiler path instance.
Warning: Adding path "input_folder3" to Compiler path instance.
Basically, my question is what is causing these warnings and how can I avoid them?
And, can I run into trouble if I move this standalone program to a different server?
The mcc line that is causing these warnings is:
mcc -m -d output_folder -I input_folder1 -I input_folder2 -I input_folder3 -a mex_file1.mexa64 -a mex_file2.mexa64 MainScriptFile.m SubFunction1.m SubFunction2.m SubFunction3.m
These warnings are caused by a missing path. If you want to shut them off, you can either disable them using warning off or add the input_folders to the Compiler path before compiling. But since mcc does that anyway (and displays a warning), you can safely ignore them.
Basically, they're just mcc telling you "Couldn't you have done that to start with? Now I'll have to do it myself...".
I can't answer your second question the way it is worded, so I'll have to go with this: You will not run into trouble caused by these warnings or any implications. If you do run into trouble, it's for a different reason.
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
I am trying to get syntax highlighting for C++ code working in Emacs using flymake. I know that with the standard flymake configuration for C++ it will try and run make syntax-check, however, my build system does not use a Makefile (or at least not directly). It uses rosmake which is a wrapper over cmake for the ROS system.
In order to get around the fact that I don't have control over the Makefile I've been trying to add a custom flymake checker based on the flymake website and this stackoverflow question.
I've created the command g++ -Wall -Wextra -fsyntax-only -Iinclude_dir file_to_check.cpp. When I run the command in bash I get the expected output. With no syntax errors I have an exit code 0 and no output. With syntax errors I have an exit code 1 and errors listed by line. However, whenever I try to run this with flymake I get a CFGERR and am told that flymake has been disabled.
I'm pretty sure that the correct command is running because the error displays the full command and everything looks the same as what I type in the terminal. I turned the logging level all the way up to 3 in order to see what the problem is. There is an error about halfway through the log
file /home/rhololkeolke/ros_workspace/team-hku-drc/robot_code/state_trigger/src/Broadcaster.cpp, init=flymake-cc-init [3 times]
create-temp-inplace: file=/home/rhololkeolke/ros_workspace/team-hku-drc/robot_code/state_trigger/src/Broadcaster.cpp temp=/home/rhololkeolke/ros_workspace/team-hku-drc/robot_code/state_trigger/src/Broadcaster_flymake.cpp
saved buffer Broadcaster.cpp in file /home/rhololkeolke/ros_workspace/team-hku-drc/robot_code/state_trigger/src/Broadcaster_flymake.cpp
started process 14517, command=(g++ -Wall -Wextra -fsyntax-only -std=c++0x -I/home/rhololkeolke/ros_workspace/team-hku-drc/robot_code/state_trigger/include -I/home/rhololkeolke/ros_workspace/team-hku-drc/robot_code/state_trigger/msg_gen/cpp/include -I/home/rhololkeolke/ros_workspace/team-hku-drc/robot_code/state_trigger/srv_gen/cpp/include -I/opt/ros/fuerte/include
Broadcaster_flymake.cpp), dir=/home/rhololkeolke/ros_workspace/team-hku-drc/robot_code/state_trigger/src/
received 40 byte(s) of output from process 14517
file /home/rhololkeolke/ros_workspace/team-hku-drc/robot_code/state_trigger/src/Broadcaster.cpp, init=flymake-cc-init
parsed 'g++: error: : No such file or directory', no line-err-info
file /home/rhololkeolke/ros_workspace/team-hku-drc/robot_code/state_trigger/src/Broadcaster.cpp, init=flymake-cc-init
process 14517 exited with code 1
cleaning up using flymake-simple-cleanup
deleted file /home/rhololkeolke/ros_workspace/team-hku-drc/robot_code/state_trigger/src/Broadcaster_flymake.cpp
Broadcaster.cpp: 0 error(s), 0 warning(s), 0 info in 0.07 second(s)
switched OFF Flymake mode for buffer Broadcaster.cpp due to fatal status CFGERR, warning Configuration error has occured while running (g++ -Wall -Wextra -fsyntax-only -std=c++0x -I/home/rhololkeolke/ros_workspace/team-hku-drc/robot_code/state_trigger/include -I/home/rhololkeolke/ros_workspace/team-hku-drc/robot_code/state_trigger/msg_gen/cpp/include -I/home/rhololkeolke/ros_workspace/team-hku-drc/robot_code/state_trigger/srv_gen/cpp/include -I/opt/ros/fuerte/include
Broadcaster_flymake.cpp)
The main error appears to be parsed 'g++: error: : No such file or directory', no line-err-info. I thought it might be because the Broadcaster_flymake.cpp never got created but I checked that and it seems to be working. I get these errors regardless of whether or not there is a syntax error. I can't figure out why it can't find the file as copying and pasting the command into Bash works perfectly. I also tried (shell-command "g++") in an buffer just to make sure that emacs was finding the g++ binary and it is.
If you have any idea why flymake is failing to run the command please let me know. Thank you.
I figured out what the problem is. I overloaded the function flymake-get-project-include-dirs. In that function I was running the rospack cflags-only-I command to get the current ROS package's necessary include directories. What I didn't realize is that the final include directory included a newline character at the end after I had finished processing the output of the rospack command. When I was seeing the command it was trying to run in the buffer I noticed that the filename it was trying to check was always on a new line but I thought that was just a formatting thing.
Now that I've removed all newlines from my include directories everything is working great.
I have a question about Clozure CL.
While I was trying to quickload a package from quicklisp.
It throws out an error. Have googled it, but nothing useful found.
Here is the error message:
(ql:quickload :drakma)
To load "drakma":
Load 1 ASDF system:
drakma
; Loading "drakma"
..
Read error between positions 6342 and 6532 in /Users/Mac/quicklisp/dists/quicklisp/software/cl+ssl-20111105-git/streams.lisp.
> Error: Foreign variable "O_NONBLOCK" not found
> While executing: CCL::%LOAD-VAR, in process Listener(6).
Thank you in advance
I've asked on mailing list:
answer from mailing list:
If you move or rename the "darwin-x86-headers" directory (or otherwise
try to simulate an incomplete installation):
[src/ccl-dev] gb#antinomial> mv darwin-x86-headers64 darwin-x86-headers64X
and then run CCL and try to access something (O_NONBLOCK) defined in the
interface files in that directory:
[src/ccl-dev] gb#antinomial> ccl64
Welcome to Clozure Common Lisp Version 1.8-dev-r15225M-trunk (DarwinX8664)!
? #$O_NONBLOCK
you get a warning or two about the missing interface files
; Warning: Interface file #P"/usr/local/src/ccl-dev/darwin-x86-headers64/libc/constants.cdb" does not exist, and the containing directory does not exist.
; This may mean that that the "ccl:" logical-pathname host has not been properly initialized. ; While executing: CDB-OPEN, in process listener(1).
; Warning: Interface file #P"/usr/local/src/ccl-dev/darwin-x86-headers64/libc/vars.cdb" does not exist, and the containing directory does not exist.
; This may mean that that the "ccl:" logical-pathname host has not been properly initialized.
before getting the same error that you reported.
If you use Quicklisp to load some code that tries to lookup that constant's value
in (missing) database files, you don't see that warning.
On the other hand, you do see dot characters printed when using
Quicklisp. (Sometimes lots of them !)
I don't claim to be part of Quicklisp's target audience, but I had a vote
I think I'd vote for being able to see progress messages and diagnostics
(even if that meant seeing fewer dots and even - especially - if the diagnostics
indicate an installation problem, as they seem to in this case.)
To stop flaming and try to address the original question, if the interface directory
is moved back to where CCL expects it to be, then:
? #$O_NONBLOCK
4
things work as expected. (If they didn't, it wouldn't be possible to compile
CCL itself or to compile lots of other code that uses the FFI's reader macros.)
That means that my best guess is that CCL isn't installed correctly on your
system. I don't know that with absolute certainty and I don't have any way
of knowing how it's installed on your system, but I believe that if it's installed
the way that the manual and website suggest problems like this are avoided.
Your CCL installation is incomplete or incorrect. Try asking on the CCL mailing list about it.
My Cygwin environment (Windows 7 O/S) has developed a strange problem. A couple of days ago I was running a perl script fine, but today I'm getting
0 [main] perl 5056 C:\cygwin\bin\perl.exe: *** fatal error - unable to remap \\?\C:\cygwin\lib\perl
5\5.10\i686-cygwin\auto\Socket\Socket.dll to same address as parent: 0x8F0000 != 0x960000
Stack trace:
Frame Function Args
0088B508 6102749B (0088B508, 00000000, 00000000, 00000000)
0088B7F8 6102749B (61177B80, 00008000, 00000000, 61179977)
0088C828 61004AFB (611A136C, 6123E0FC, 008F0000, 00960000)
End of stack trace
I tried running rebase, as advised here but the problem persists. Any answers appreciated, as I have a demo tomorrow for which this script is needed. Wasn't expecting a problem like this!
This is a semi-informed answer, as I have had similar difficulty and eventually flailed around until the problem went away.
rebaseall with no arguments will rebase all of the dll files that were installed from cygwin packages. However you will often have many other dlls from other programs you have built and installed, including from installed Perl modules with XS code, and you will need to tell rebaseall about these modules somehow.
There may be an easier way to do this, and I hope I haven't forgotten any steps, but I think I had some success doing something like this:
Get a list of all the dll's in your system that run under cygwin. Maybe something like find /bin /lib /usr /home -name \*.dll > /tmp/file1
exit all cygwin processes, open as ash or dash shell from a Windows command prompt, and run /bin/rebaseall -v > /tmp/file2. The -v switch sets a Verbose flag in rebase that lists all the files that get rebased with the default setting.
Use /tmp/file1 and /tmp/file2 to create a new file, say /tmp/file3 with the complete list of files you will want to rebase. From what I remember it is important for the system dlls (all the files in /tmp/file2) to be listed first,
Now run rebaseall -v -T /tmp/file3 (in ash, after closing all cygwin procs, etc.). Pay attention to the output. If there are error messages about rebasing some particular dll, remove that entry from /tmp/file3 and try again.
This may not solve your problem, but maybe it will get you most of the way there. If you do eventually figure it out, I hope you will come back and fill in some of the holes in this solution.
I think it is useful to point out that for most people running into this a simple "rebaseall" without any arguments seems to resolve this issue. I'll post a link to a very useful blog post from My Life, Starting up (I have no relation to that blog):
http://www.mylifestartingup.com/2009/04/fatal-error-unable-to-remap-to-same.html
The action list, (copied directly from the blog) is:
Let me tell you what you can do if you don't care what's actually happening.
1) Close out of Cygwin (and all cygwin processes).
2) Open a Windows command prompt (start -> run - > type 'cmd' or on vista : start -> type 'cmd' in the start search window)
3) Go to your cygwin bin directory. For me it is c:\cygwin\bin.
4) Type ash
5) Type '/usr/bin/rebaseall'
6) Resolve any errors (I had a warning that went unresolved and it still worked fine)
7) Reboot...and you should be good.
And if you DO care what's actually happening, read the blog entry, in addition to the answer by mob here on this same question.
I'm trying to circumvent using MEX to link to MATLAB and just call a binary using "!" as in:
>> !template_image_rigid -args ....
template_image_rigid: /opt/MatlabR2010a/sys/os/glnxa64/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by /usr/lib/libboost_program_options.so.1.40.0)
template_image_rigid: /opt/MatlabR2010a/sys/os/glnxa64/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by /usr/lib/libdirac_encoder.so.0)
Is there a way to easily fix this dynamic link issue from within MATLAB? I know I can recompile the source with MATLAB and use a MEX call, but since it takes a while to run the solver I just want to run it as shell command and import text data later into MATLAB.
If it helps, the source & CMakeLists.txt can be found here: https://github.com/pkarasev3/nlmagick/tree/master/samples
Grr, community = fail.
Diagnoising: do !gnome-terminal from within matlab and look at "env":
env | grep Matlab
which gives
XKEYSYMDB=/opt/MatlabR2010a/X11/app-defaults/XKeysymDB
MATLABPATH=/opt/MatlabR2010a/toolbox/local
XAPPLRESDIR=/opt/MatlabR2010a/X11/app-defaults
LD_LIBRARY_PATH=/opt/MatlabR2010a/sys/os/glnxa64:/opt/MatlabR2010a/bin/glnxa64:/opt/MatlabR2010a/extern/lib/glnxa64:/opt/MatlabR2010a/runtime/glnxa64:/opt/MatlabR2010a/sys/java/jre/glnxa64/jre/lib/amd64/native_threads:/opt/MatlabR2010a/sys/java/jre/glnxa64/jre/lib/a md64/server:/opt/MatlabR2010a/sys/java/jre/glnxa64/jre/lib/amd64
OSG_LD_LIBRARY_PATH=/opt/MatlabR2010a/sys/openscenegraph/lib/glnxa64
TOOLBOX=/opt/MatlabR2010a/toolbox
XFILESEARCHPATH=/opt/MatlabR2010a/sys/java/jre/glnxa64/jre/lib/locale/%L/%T/%N%S::/usr/dt/app-defaults/%L/Dt
MATLAB=/opt/MatlabR2010a
Ok so the LD_LIBRARY_PATH is bad.
Trick: write a poltergeist script and run it from gnome-terminal, Launch it from Matlab with:
!./hack.sh RunStuffThatLinksElsewhere
where hack.sh is a script with something like:
#!/bin/bash
source ~/.bashrc
export LD_LIBRARY_PATH=''
gnome-terminal --command="${1}"
so an easy test is to try it with "eog", this hack gets around the link issue and lets you run it from within matlab...
Simpler:
setenv('foo',num2str(some_value) )
!LD_LIBRARY_PATH="" && ./my_binary -f $foo
disp('done with external program!')
I solved this problem by replacing the version of libstdc++.so.6 with a newer version from my system (I use ubuntu 12.04).
First find the system version of libstdc++.so.6.
From the command line type:
locate libstdc++.so.6
My system version of libstdc was
/usr/lib/i386-linux-gnu/libstdc++.so.6
Then replace the matlab libstdc version with a link to the system libstdc.
From the command line type (replace [....] with you settings):
cd [matlab_dir]/sys/os/glnx86
mv libstdc++.so.6 libstdc++.so.6-OLD
ln -s [your_system_version_of_libstdc] libstdc++.so.6
I recently ran into the same problem. My solution also uses a poltergeist script like other answers. The script is as follows (poltergeist.sh):
#!/bin/bash
export LD_LIBRARY_PATH=''
eval "$#"
It basically resets the library path and subsequently evaluates the call given by the arguments to the script. From within matlab I then call in this manner:
system([pwd,'/poltergeist.sh echo hello world!']);
The advantage to this approach is that you can dynamically modify the call command within matlab. As far as I know this is not possible using the bang syntax in the currently provided answers.