I have compiled and run my Matlab code sucessfully in my computer, but there is something wrong when I run it on annother. The error information as following:
bash-3.1# sh /data/release/cli/forecaster_new/forecaster/run_dispatch.sh /usr/local/matlab /data/release/cli/forecaster_new/forecaster/1-1.txt /data/release/cli/forecaster_new/forecaster/1-1.out
------------------------------------------
Setting up environment variables
---
LD_LIBRARY_PATH is .:/usr/local/matlab/runtime/glnxa64:/usr/local/matlab/bin/glnxa64:/usr/local/matlab/sys/os/glnxa64:/usr/local/matlab/sys/java/jre/glnxa64/jre/lib/amd64/native_threads:/usr/local/matlab/sys/java/jre/glnxa64/jre/lib/amd64/server:/usr/local/matlab/sys/java/jre/glnxa64/jre/lib/amd64/client:/usr/local/matlab/sys/java/jre/glnxa64/jre/lib/amd64
Warning: This functionality is no longer supported under the -nojvm startup
option. For more information, see "Changes to -nojvm Startup Option" in the
MATLAB Release Notes. To view the release note in your system browser, run
web('http://www.mathworks.com/access/helpdesk/help/techdoc/rn/bropbi9-1.html#brubkzc-1',
'-browser')
> In run_predict at 5
??? Invalid MEX-file
'/usr/local/matlab/toolbox/compiler/mcr/compiler/deploywhich.mexa64':
/usr/local/matlab/runtime/glnxa64/libmwopczippackage.so: undefined symbol:
_ZN2fl10filesystem6detail19process_code_traits11to_internalERKSs.
Error in ==> fopen at 16
Error in ==> dlmwrite at 120
Error in ==> run_predict at 71
MATLAB:invalidMEXFile
Warning: 1 invisible figure(s) exist at MCR termination.
If your application has terminated unexpectedly, please note that
applications generated by the MATLAB Compiler terminate when there are no
visible figure windows. See the documentation for WaitForFiguresToDie and
WAITFORCALLBACKS for more information.
The OS of the compiling computer is Ubuntu 7.10(64-bits)， the Matlab version is Matlab r2010a, and the gcc version is 4.1.3.
Related
Title says it all - I am attempting to run a very basic Rust program using hyper_wasi, and everything compiles seemingly ok using cargo wasi run. Unfortunately when it actually executes, I get:
Error: failed to run main module `target/wasm32-wasi/debug/<my project name here>.wasm`
Caused by:
0: failed to instantiate "target/wasm32-wasi/debug/<my project name here>.wasm"
1: unknown import: `wasi_snapshot_preview1::sock_setsockopt` has not been defined
Execution environment is a rather older Mac (2013 MBP with Big Sur), clang version:
Homebrew clang version 15.0.3
Target: x86_64-apple-darwin20.6.0
Thread model: posix
InstalledDir: /usr/local/opt/llvm/bin
If anyone can point me at what I might be missing I'd appreciate it.
I inherited a C++ code with a dependency to OpenMPI that I want to delegate to Conan and CMake, and the automated build has a strange (to me at least) behavior related to sysctl that I want to understand.
How I tried to do it
I declared the required dependencies in my root CMakeLists.txt:
Note: I added the full list of requirements because I also suspect that some of them may be in conflict? That happened before with boost, that forced me to set explicitly zlib (if i remember correctly).
# stuff ...
conan_cmake_configure(
REQUIRES
zlib/1.2.12
mp-units/0.7.0
boost/1.79.0
openmpi/4.1.0
gsl/2.7
cspice/0067
GENERATORS
cmake
# that is required for cspice
CMakeDeps
CMakeToolchain
)
# more stuff ...
and then in the application CmakeLists.txt I find, include and link the executable to the required libraries:
add_executable(spock main.cpp)
find_package(cspice REQUIRED)
find_package(openmpi REQUIRED)
target_include_directories(
spock PRIVATE $<BUILD_INTERFACE:${PROJECT_SOURCE_DIR}/include>
$<BUILD_INTERFACE:${CMAKE_CURRENT_LIST_DIR}/include>
openmpi_INCLUDE_DIRS
cspice_INCLUDE_DIRS
)
target_link_libraries(spock
CONAN_PKG::boost
CONAN_PKG::mp-units
openmpi::openmpi
cspice::cspice
)
# We need C++ 20 activated with the concepts library
target_compile_features(spock PUBLIC cxx_std_20)
Problem: undefined reference to sysctl ... on my local system only.
Building on my local machine with CMake 3.23.2 results in the following error message:
Consolidate compiler generated dependencies of target spock
[ 25%] Building CXX object src/CMakeFiles/spock.dir/main.cpp.o
^[[A^[[A[ 50%] Linking CXX executable ../bin/spock
/usr/bin/ld: /home/becheler/.conan/data/openmpi/4.1.0/_/_/package/8f7048d1bf6fc2a7985eb087c34e69a5e64f6c86/lib/libopen-pal.a(evutil_rand.o): in function `arc4_stir.isra.0':
evutil_rand.c:(.text+0x3d2): undefined reference to `sysctl'
collect2: error: ld returned 1 exit status
gmake[2]: *** [src/CMakeFiles/spock.dir/build.make:146: bin/spock] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:135: src/CMakeFiles/spock.dir/all] Error 2
gmake: *** [Makefile:146: all] Error 2
However, the same build on Github workflows on Ubuntu 20.04 works. What is weird. The only difference before apart the distribution version is that github wokflows use higher privileges than me on local (I believe?).
What I tried so far
I've been trying to read about what this sysctlreference is. And I found conflicting information:
Frrom this man page:
The sysctl() function retrieves system information and allows processes with appropriate privileges to set system information.
this similar SO question came to the conclusion that
Linux does not support this function (other OS like MacOS or FreeBSD support it)
A comment from the same post concludes that in Linux,
these details can be obtained by reading the kernel-provided
pseudofiles /proc/cpuinfo and /proc/meminfo
So here is my question: why does it compile at all on the remote server if this command is not supposed to exist on the OS used?
I am trying to run a module in cactus cygwin with carpet driver. when i use external library i get following type of error.
Running configuration script for thorn MPI:
MPI selected, but MPI_DIR is not set. Computing settings...
Installing MPI into /home/hp/cactus/configs/backtrace/scratch/external/MPI
MPI was manually configured.
Finished running configuration script for thorn MPI.
------------------------------------------------------
Warnings were generated during execution of the CST
------------------------------------------------------
CST error in /home/hp/cactus/lib/sbin/ImpParamConsistency.pl (at 38)
-> Thorn 'Carpet' SHARES from non-existing implementation 'INITBASE'
CST error in /home/hp/cactus/lib/sbin/create_c_stuff.pl (at 140)
-> Unknown parameter type '' for parameter 'initial_data_setup_method'
------------------------------------------------------
make[1]: *** [/home/hp/cactus/lib/make/make.configuration:215: /home/hp/cactus/configs/backtrace/config-data/make.thornlist] Error 1
make: *** [Makefile:259: backtrace] Error 2
I've followed all the steps in the official guide. Except I built it using:
$ bazel build -c opt --copt=-mavx --copt=-mavx2 --copt=-mfma --copt=- msse4.1 --copt=-msse4.2 --config=opt -k //tensorflow/tools/pip_package:build_pip_package
And during ./config I've set the right paths and disabled Google Cloud Platform, Hadoop, XLA, VERBS, OpenCL, CUDA, MPI support.
Hardware:
Macbook Pro 13 inch (mid 2014)
CPU: Intel Core i5 (4278U)
RAM: 8GB
Software:
High Sierra (10.13.2)
Clang Version: clang-900.0.39.2
Bazel Version: 0.9.0
Conda Version: 4.4.3
Python: 3.6.3
All the packages are upto date. This worked perfectly fine 2 months ago on this machine. For some strange reasons it doesn't build anymore now. I'm just posting a part of the error list here:
WARNING: Config values are not defined in any .rc file: opt
ERROR: Skipping 'msse4.1': no such target '//:msse4.1': target 'msse4.1' not declared in package '' defined by /Users/rakshithgb/Documents/Tensorflow/tensorflow/BUILD
WARNING: Target pattern parsing failed.
ERROR: /private/var/tmp/_bazel_rakshithgb/fde7bc60972656b0c2db4fd0b79e24fb/external/com_googlesource_code_re2/BUILD:96:1: First argument of 'load' must be a label and start with either '//', ':', or '#'. Use --incompatible_load_argument_is_label=false to temporarily disable this check.
ERROR: /private/var/tmp/_bazel_rakshithgb/fde7bc60972656b0c2db4fd0b79e24fb/external/com_googlesource_code_re2/BUILD:98:1: name 're2_test' is not defined (did you mean 'ios_test'?)
ERROR: /private/var/tmp/_bazel_rakshithgb/fde7bc60972656b0c2db4fd0b79e24fb/external/com_googlesource_code_re2/BUILD:100:1: name 're2_test' is not defined (did you mean 'ios_test'?)
And it ends like this:
ERROR: /Users/rakshithgb/Documents/Tensorflow/tensorflow/tensorflow/core/kernels/BUILD:550:1: Target '#local_config_sycl//sycl:using_sycl' contains an error and its package is in error and referenced by '//tensorflow/core/kernels:debug_ops'
WARNING: errors encountered while analyzing target '//tensorflow/tools/pip_package:build_pip_package': it will not be built
INFO: Analysed target //tensorflow/tools/pip_package:build_pip_package (203 packages loaded).
INFO: Found 0 targets...
ERROR: command succeeded, but there were errors parsing the target pattern
INFO: Elapsed time: 12.763s, Critical Path: 0.02s
FAILED: Build did NOT complete successfully
Has anyone else had this issue? How do I fix it? I've uploaded the entire error log on GitHub Tensorflow issue page. #15622
Ok it looks like the new bazel version isn't compatible with the current Tensorflow release. It looks like the fix will be issued in the next release. According to this thread on GitHub - #15492
The temporary fix that worked for me was to build it using --incompatible_load_argument_is_label=false in the bazel command. So my build command now looks like this:
$ bazel build --config=opt --incompatible_load_argument_is_label=false //tensorflow/tools/pip_package:build_pip_package
i am using GLUT 3.7.6 with VC++6.0 n on compiling a program i get following error
--------------------Configuration: abc2 - Win32 Debug--------------------
Linking...
LINK : fatal error LNK1104: cannot open file "abc2.exe"
Error executing link.exe.
abc2.exe - 1 error(s), 0 warning(s)
i have included all the header files ...linked all the lib files bt still the result is same...!!...please guide me through this problem...THNX in advance...!!
This usually happens when the output file already exists and something has a lock on it. Check to see if abc2.exe is alright running, or of some program has a file lock on it.
You can check whether abc.exe is running using Process Explorer from sysinternals. If that's the case the link step will fail.
Also check the target file is not write-protected.
All the Microsoft tool error codes are documented online - see here for more reasons why you might see LNK1104.