when I configure mydlp from Github I get the following error
please help me
beam/beam_load.c(1158): Error loading module compile:
mandatory chunk of type 'Atom' not found
root#mydlp01:/home/mydlp# ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for erlc... /usr/bin/erlc
checking for a prefix by checking for erl... /usr/bin/erl
checking for erl... /usr/bin/erl
checking for Erlang/OTP root directory... configure: error: in /home/mydlp':
configure error: test Erlang program execution failed
Seeconfig.log' for more details
The system is telling you that some data in the byte code is missing. If you want to start reading up, you can start here. In my experience this is probably due to you having compiled it using Erlang with version X and now you are running it and loading it using Erlang with version Y.
Related
I'd like to build on this post, because my symptoms are identical, but the solution seems to be something else.
I am working in a Ubuntu container (Ubuntu 16.04.3 LTS), trying to compile a toy C program that will eventually connect to an SQL server. First things first: I have the latest libmysqlclient-dev installed:
root#1234:/home# apt install libmysqlclient-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
libmysqlclient-dev is already the newest version (5.7.24-0ubuntu0.16.04.1).
0 upgraded, 0 newly installed, 0 to remove and 88 not upgraded.
root#1234:/home#
And when I look in the /usr/include/mysql directory, I see the critical header file I'll need:
root#1234:/home# ls -l /usr/include/mysql | grep mysql.h
-rw-r--r-- 1 root root 29207 Oct 4 05:48 /usr/include/mysql/mysql.h
root#1234:/home#
So far, so good. Now I found this little toy program from here:
#include <stdio.h>
#include "/usr/include/mysql/mysql.h"
int main() {
MYSQL mysql;
if(mysql_init(&mysql)==NULL) {
printf("\nInitialization error\n");
return 0;
}
mysql_real_connect(&mysql,"localhost","user","pass","dbname",0,NULL,0);
printf("Client version: %s",mysql_get_client_info());
printf("\nServer version: %s",mysql_get_server_info(&mysql));
mysql_close(&mysql);
return 1;
}
Now, following the advice of the previous post, I compile using the "-I" option to point to the mysql.h header file. (Yes, I am required to use GCC here):
root#1234:/home# gcc -I/usr/include/mysql sqlToy.c
/tmp/cc8c5JmT.o: In function `main':
sqlToy.c:(.text+0x25): undefined reference to `mysql_init'
sqlToy.c:(.text+0x69): undefined reference to `mysql_real_connect'
sqlToy.c:(.text+0x72): undefined reference to `mysql_get_client_info'
sqlToy.c:(.text+0x93): undefined reference to `mysql_get_server_info'
sqlToy.c:(.text+0xb4): undefined reference to `mysql_close'
collect2: error: ld returned 1 exit status
root#1234:/home#
Belly flop! The compiler has no idea what all the mySQL functions are, even though I've done all I can think of to point to that header file. As a sanity check, I made sure those mySQL functions are indeed in that header file; here's one as an example:
root#1234:/home# more /usr/include/mysql/mysql.h | grep mysql_init
libmysqlclient (exactly, mysql_server_init() is called by mysql_init() so
MYSQL * STDCALL mysql_init(MYSQL *mysql);
root#1234:/home#
So while I've pointed the compiler to the mysql.h header file in both my code AND with the "-I" option, it still has no clue what those 'mysql' functions are. The "-I" option was the solution in the previous post, but is not working for me here.
So... What might be the problem? I'm assuming this isn't a compiling problem, but maybe a linking one? In other words, I'm showing GCC where the mysql.h file is, but he is still not using it when processing the code?
Headers are not libraries. You are including the MySQL header during compilation, so these functions are defined, but you are not linking against the library which actually provides those functions.
These functions are provided by the libmysqlclient library, so you need to add the -lmysqlclient flag to your command line to fix this. (Note that this is a lower-case l, not an I.)
Additionally, since you are adding /usr/include/mysql to your system header path, you can include the library as
#include <mysql.h>
You do not need to -- and should not! -- specify the full path to the library in the #include directive.
I recently tried to build my https://github.com/eyalroz/cuda-api-wrappers/ library's examples after switching to another Linux distribution on the same machine. Strangely enough, I encountered a linking issue. The command:
/usr/bin/c++ -Wall -std=c++11 -g CMakeFiles/device_management.dir/examples/by_runtime_api_module/device_management.cpp.o -o examples/bin/device_management -rdynamic lib/libcuda-api-wrappers.a -Wl,-Bstatic -lcudart_static -Wl,-Bdynamic -lpthread -ldl -lrt
fails to find the CUDA runtime library, and I get:
CMakeFiles/device_management.dir/examples/by_runtime_api_module/device_management.cpp.o: In function `cuda::device::peer_to_peer::get_attribute(cudaDeviceP2PAttr, int, int)':
/home/eyalroz/src/mine/cuda-api-wrappers/src/cuda/api/device.hpp:38: undefined reference to `cudaDeviceGetP2PAttribute'
collect2: error: ld returned 1 exit status
but if I add -L/usr/local/cuda/lib64 it builds fine. This didn't use to happen before; and it doesn't happen on another machine I've checked on, nor does it even happen to other targets using the CUDA runtime in the same CMakeLists.txt (like version_managament).
FindCUDA seems to be finding everything, as the value of ${CUDA_LIBRARIES} is /usr/local/cuda/lib64/libcudart_static.a;-lpthread;dl;/usr/lib/x86_64-linux-gnu/librt.so. And the target lines in CMakeLists.txt are:
add_executable(device_management EXCLUDE_FROM_ALL examples/by_runtime_api_module/device_management.cpp)
target_link_libraries(device_management cuda-api-wrappers ${CUDA_LIBRARIES})
as is suggested in answers to other related questions (e.g. here). Why is this happening? Should I "manually" add the -L switch?
Edit: Following #RobertCrovella's suggestion, here are the ld search paths:
$ gcc -print-search-dirs | sed '/^lib/b 1;d;:1;s,/[^/.][^/]*/\.\./,/,;t 1;s,:[^=]*=,:;,;s,;,; ,g' | tr \; \\012 | tr ':' "\n" | tail -n +3
/usr/local/cuda/lib64/x86_64-linux-gnu/5/
/usr/local/cuda/lib64/x86_64-linux-gnu/
/usr/local/cuda/lib/
/usr/lib/gcc/x86_64-linux-gnu/5/
/usr/x86_64-linux-gnu/lib/x86_64-linux-gnu/5/
/usr/x86_64-linux-gnu/lib/x86_64-linux-gnu/
/usr/x86_64-linux-gnu/lib/
/usr/lib/x86_64-linux-gnu/5/
/usr/lib/x86_64-linux-gnu/
/usr/lib/
/lib/x86_64-linux-gnu/5/
/lib/x86_64-linux-gnu/
/lib/
/usr/lib/x86_64-linux-gnu/5/
/usr/lib/x86_64-linux-gnu/
/usr/lib/
/usr/local/cuda/lib64/
/usr/x86_64-linux-gnu/lib/
/usr/lib/
/lib/
/usr/lib/
$ ld --verbose | grep SEARCH_DIR | tr -s ' ;' \\012
SEARCH_DIR("=/usr/local/lib/x86_64-linux-gnu")
SEARCH_DIR("=/lib/x86_64-linux-gnu")
SEARCH_DIR("=/usr/lib/x86_64-linux-gnu")
SEARCH_DIR("=/usr/local/lib64")
SEARCH_DIR("=/lib64")
SEARCH_DIR("=/usr/lib64")
SEARCH_DIR("=/usr/local/lib")
SEARCH_DIR("=/lib")
SEARCH_DIR("=/usr/lib")
SEARCH_DIR("=/usr/x86_64-linux-gnu/lib64")
SEARCH_DIR("=/usr/x86_64-linux-gnu/lib")
Notes:
Yes, I know the CMakeLists.txt there is ugly.
TL;DR:
After the FindCUDA invocation, add the lines:
get_filename_component(CUDA_LIBRARY_DIR ${CUDA_CUDART_LIBRARY} DIRECTORY)
set(CMAKE_EXE_LINKER_FLAGS ${CMAKE_EXE_LINKER_FLAGS} "-L${CUDA_LIBRARY_DIR}")
and building should succeed on both systems.
Discussion:
(Paraphrasing #RobertCrovella and myself in the comments:)
OP was expecting, that if the following hold:
FindCUDA succeeds
${CUDA_LIBRARIES} includes a valid full path to either the static or the dynamic CUDA runtime library
the library dependency is indicated using target_link_libraries(relevant_target ${CUDA_LIBRARIES})
... then the CMake-based build he was attempting should succeed on a variety of valid CUDA installations. That is (unfortunately) not the case, since while FindCUDA does locate the CUDA library path, it does not actually make your linker search that path. So a failure should actually be expected. The build had worked on OP's old system due to a "fluke", or rather, due to OP having added the CUDA library directory to the linker's search path, somehow, apriori.
The linking command must be issued with the -L/path/to/cuda/libraries switch, so that the linker knows where to looks for the (unspecified-path) libraries referred to be the CUDA-related -l switches (in OP's case, -lcudart_static).
This answer discusses how to do that in CMake for different kinds of targets. You might also want to have a look at man gcc (the GCC manual page, also available here) regarding the -l and -L options, if you are not familiar with them.
I'm trying to install CUDA 7.0 on Ubuntu 14.04. I've followed the installation instructions as outlined here. Specifically, I've followed steps in section 3.6 and Chapter 6. While compiling the examples (Section 6.2.2.2) using make, I'm getting the following error:
make[1]: Entering directory `/usr/local/cuda-7.0/samples/3_Imaging/cudaDecodeGL'
/usr/local/cuda-7.0/bin/nvcc -ccbin g++ -m64 -gencode arch=compute_20,
code=compute_20 -o cudaDecodeGL FrameQueue.o ImageGL.o VideoDecoder.o
VideoParser.o VideoSource.o cudaModuleMgr.o cudaProcessFrame.o
videoDecodeGL.o -L../../common/lib/linux/x86_64 -L/usr/lib/"nvidia-346"
-lGL -lGLU -lX11 -lXi -lXmu -lglut -lGLEW -lcuda -lcudart -lnvcuvid
/usr/bin/ld: cannot find -lnvcuvid
collect2: error: ld returned 1 exit status
make[1]: *** [cudaDecodeGL] Error 1
make[1]: Leaving directory `/usr/local/cuda-7.0/samples/3_Imaging/cudaDecodeGL'
make: *** [3_Imaging/cudaDecodeGL/Makefile.ph_build] Error 2
If you notice, there is -L/usr/lib/"nvidia-346". In my case, I have installed nvidia-349. What worked for me is to edit NVIDIA_CUDA-7.0_Samples/3_Imaging/cudaDecodeGL/findgllib.mk and change UBUNTU_PKG_NAME = "nvidia-346" to nvidia-349.
In order to properly install CUDA 7.0 on Ubuntu 14.04, you need a nvidia driver version 346 or higher.
If you're using the .deb installation method, the nvidia graphics driver is installed automatically.
If you used the .run file installation method and chose not to install the nvidia driver, you can manually install the driver afterwards through the package manager:
sudo apt-add-repository ppa:xorg-edgers/ppa && sudo apt-get update
sudo apt-get install nvidia-346 nvidia-346-dev nvidia-346-uvm libcuda1-346 nvidia-libopencl1-346 nvidia-icd-346
In my case, I installed nvidia-352 afterwards due to a bug in nvidia-346 and I stumbled upon the same error.
andoum's approach of manually changing the hard-coded UBUNTU_PKG_NAME = "nvidia-346" to UBUNTU_PKG_NAME = "nvidia-352" in NVIDIA_CUDA-7.0_Samples/3_Imaging/cudaDecodeGL/findgllib.mk worked fine for me.
I met the same issue and solution is that put path of nvidia into system path:
sudo gedit /etc/environment
add these path into environment
LIBRARY_PATH=/usr/lib/your_nvidia_edition:$LIBRARY_PATH
In fact I have encountered this problem when I made a make. I installed Cuda 8.0 under my Ubuntu 16.04. This problem had been confusing me for several weeks and I was almost tending to reinstall ubuntu for that after reviewing many suggestions via google, but finally I addressed it myself recently.
First of all, you should replace all the UBUNTU_PKG_NAME= ##nvidia-3xx## to the one of your actually installed nvidia driver version as recommended above. Then you will probably get compiling error after you do a new make. In my case, I have the link errors like
/usr/bin/ld: warning: libGLX.so.0, needed by /usr/lib/nvidia-
375/libGL.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libGLdispatch.so.0, needed by /usr/lib/nvidia-
375/libGL.so, not found (try using -rpath or -rpath-link)
....
or whatever contains missing link errors. Do locate the files you miss like
$ locate libGLX.so.
/usr/lib/nvidia-375/libGLX.so.0
/usr/lib32/nvidia-375/libGLX.so.0
$ locate libGLdispatch.so.0
/usr/lib/nvidia-375/libGLdispatch.so.0
/usr/lib32/nvidia-375/libGLdispatch.so.0
The error above is probably caused the compiling files cannot find in the default cuda libraries as you set, so you just need to copy the missing files to /usr/lib/nvidia-3xx/ (the actual path in your case) and this should work(it works in my case), if it doesn't maybe you could try to link the new add files to the one that need using a
$ sudo ln -s (requested file) (requesting file).
Hope this will help.
i have tried installing Apache Axis2/C on Linux but no success.. with libxml2
Here are my efforts
1) libxml2 was installed successfully
Flags : LIBXML2_CFLAGS = -I/usr/local/include/libxml2
LIBXML2_LIBS='-L/usr/local/lib/hpux32 -lxml2 -lz -lpthread -liconv -lm'
AXIS2C_HOME = /tmp
LD_LIBRARY_PATH = {$LD_LIBRARY_PATH}:$AXIS2C_HOME/lib
Ran --prefix=${AXIS2C_HOME} --enable-libxml2=yes
Installation fails with following error:
checking whether to build libxml2 xml parser library... checking pkg-config is at least version 0.9.0... ./configure[21268]: /local/lib/hpux32.
no
yes
checking for LIBXML2... configure: error: The pkg-config script could not be found or is too old. Make sure it
is in your PATH or set the PKG_CONFIG environment variable to the full
path to pkg-config.
Alternatively, you may set the environment variables LIBXML2_CFLAGS
and LIBXML2_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
i do not hold pkg-config utility but i have set LIBXML2_CFLAGS and LIBXML2_LIBS, configuration file does not have any information.
can someone please assist here?
Thanks,
Hilesh
I am trying to install rasqal 0.9.20 library http://librdf.org/rasqal/ onto a windows 7 machine with cygwin.Earlier i have successfully installed the raptor-2.2.0 library http://librdf.org/raptor/ and i can verify this with the rapper tool was created after the installation(./configure , ./make ,/make install)
The error that i am getting from the configuration of rasqal is :
./configure --enable-raptor2
...
checking for raptor... configure: error: Raptor2 is not installed - see http://librdf.org/raptor/ to get a version newer than 1.9.0
I can't find a way to fix it. The code from the cofigure file that handles this flag is the below :
11840 # raptor is REQUIRED despite the checking here
11841 RAPTOR_MIN_VERSION=1.4.19
11842 RAPTOR_MAX_VERSION=1.8.99
11843 RAPTOR2_MIN_VERSION=1.9.0
11844
11845 raptor2=no
11846 # Check whether --enable-raptor2 was given.
11847 if test "${enable_raptor2+set}" = set; then :
11848 enableval=$enable_raptor2; raptor2="$enableval"
11849 else
11850 raptor2="no"
11851 fi
Raptor 2.0.0 uses only pkg-config to provide configuration information, raptor-config was removed. The same applies to rasqal itself, the rasqal-config program will go away at some point. The --enable-raptor2 option to rasqal and librdf was for testing the beta raptor2, and it has been removed from rasqal 0.9.22 and librdf GIT head.
Set PKG_CONFIG_PATH to include the correct path:
env PKG_CONFIG_PATH=/usr/local/lib/pkgconfig ./configure
Another method, if available on your system, is to define the environment variable in /etc/environment:
PKG_CONFIG_PATH=/usr/local/lib/pkgconfig