I have realized that it's lots of trouble and pain to compile qemu with gcc4,
so I have installed gcc-3.2 toolchain in my linux box and now I'm compiling qemu,
These are the steps that I have followed and emitted output.
root#sandun-Aspire-4741:/src/openmoko/qemu-neo1973# ./configure --target-list=arm-softmmu --cc=gcc-3.4 --disable-sdl --disable-gfx-check --extra-cflags='-isystem=\usr\include'
big/little test failed
Install prefix /usr/local
BIOS directory /usr/local/share/qemu
binary directory /usr/local/bin
Manual directory /usr/local/share/man
ELF interp prefix /usr/gnemul/qemu-%M
Source path /src/openmoko/qemu-neo1973
C compiler gcc-3.4
Host C compiler gcc
make make
install install
host CPU i386
host big endian no
target list arm-softmmu
gprof enabled no
profiler no
static build no
-Werror enabled no
SDL support no
mingw32 support no
Adlib support no
AC97 support no
GUS support no
CoreAudio support no
ALSA support no
EsounD support no
DSound support no
FMOD support no
OSS support yes
VNC TLS support no
kqemu support yes
Documentation no
root#sandun-Aspire-4741:/src/openmoko/qemu-neo1973# make
gcc-3.4 -isystem=\usr\include -Wall -O2 -g -fno-strict-aliasing -I. -I/src/openmoko/qemu-neo1973 -MMD -MP -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I/src/openmoko/qemu-neo1973/slirp -c -o qemu-img.o qemu-img.c
qemu-img.c: In function `read_password':
qemu-img.c:178: error: `EAGAIN' undeclared (first use in this function)
qemu-img.c:178: error: (Each undeclared identifier is reported only once
qemu-img.c:178: error: for each function it appears in.)
qemu-img.c:178: error: `EINTR' undeclared (first use in this function)
qemu-img.c: In function `img_create':
qemu-img.c:307: error: `EOPNOTSUPP' undeclared (first use in this function)
qemu-img.c: In function `img_commit':
qemu-img.c:359: error: `ENOENT' undeclared (first use in this function)
qemu-img.c:362: error: `EACCES' undeclared (first use in this function)
qemu-img.c:365: error: `EOPNOTSUPP' undeclared (first use in this function)
qemu-img.c: In function `img_convert':
qemu-img.c:481: error: `EOPNOTSUPP' undeclared (first use in this function)
make: *** [qemu-img.o] Error 1
But compilations stops with these error messages, sounds like it does not have correct
system include path,so I gave it explicitly with -isystem switch. But still not compiling
correctly.
Any workaround on this?
--Thanks in advance--
which version of qemu? operating system? We need more gold info.
for example on my ubuntu 12.04 and git version of qemu:
$ git clone git://git.qemu.org/qemu.git > /dev/null
...
$ cd qemu/
$ ./configure --target-list=arm-softmmu --disable-sdl
Install prefix /usr/local
BIOS directory /usr/local/share/qemu
binary directory /usr/local/bin
library directory /usr/local/lib
libexec directory /usr/local/libexec
include directory /usr/local/include
config directory /usr/local/etc
local state directory /usr/local/var
Manual directory /usr/local/share/man
ELF interp prefix /usr/gnemul/qemu-%M
Source path /home/user/qemu
C compiler cc
Host C compiler cc
Objective-C compiler cc
CFLAGS -O2 -D_FORTIFY_SOURCE=2 -g
QEMU_CFLAGS -Werror -fPIE -DPIE -m32 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fstack-protector-all -Wendif-labels -Wmissing- include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -I/usr/include/p11-kit-1 -I/usr/include/libpng12 -I/usr/include/pixman-1
LDFLAGS -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -pie -m32 -g
make make
install install
python python
smbd /usr/sbin/smbd
host CPU i386
host big endian no
target list arm-softmmu
tcg debug enabled no
gprof enabled no
sparse enabled no
strip binaries yes
profiler no
static build no
-Werror enabled yes
pixman system
SDL support no
curses support yes
curl support yes
mingw32 support no
Audio drivers oss
Extra audio cards ac97 es1370 sb16 hda
Block whitelist
Mixer emulation no
VirtFS support no
VNC support yes
VNC TLS support yes
VNC SASL support yes
VNC JPEG support no
VNC PNG support yes
xen support no
brlapi support yes
bluez support yes
Documentation yes
NPTL support yes
GUEST_BASE yes
PIE yes
vde support yes
Linux AIO support no
ATTR/XATTR support yes
Install blobs yes
KVM support yes
TCG interpreter no
fdt support yes
preadv support yes
fdatasync yes
madvise yes
posix_madvise yes
sigev_thread_id yes
uuid support yes
libcap-ng support no
vhost-net support yes
Trace backend nop
Trace output file trace-<pid>
spice support no (/)
rbd support no
xfsctl support no
nss used no
usb net redir no
OpenGL support yes
libiscsi support no
build guest agent yes
seccomp support no
coroutine backend ucontext
GlusterFS support no
virtio-blk-data-plane no
gcov gcov
gcov enabled no
$ make -j3 >/dev/null
$
so everything fine...
Related
I have just started experimenting with XDP in an VM. I tried to build for bpf and I face an error, how can I resolve this?
# clang -O2 -Wall -target bpf -c all_dropper.c -o dropper.o
error: unknown target triple 'bpf', please use -triple or -arch
This issue is resolved, I had to upgrade the clang version to 3.9.
I am working on tesseract engine . Used red hat linux to build both leptonica and tesseract . On running tesseract getting following error.
[tesseract-ocr]$ tesseract address.png out1
Error in pixReadMemTiff: function not present
Error in pixReadMem: tiff: no pix returned
Error in pixaGenerateFontFromString: pix not made
Error in bmfCreate: font pixa not made
Tesseract Open Source OCR Engine v4.00.00alpha with Leptonica
Error in pixReadStreamPng: function not present
Error in pixReadStream: png: no pix returned
Error in pixRead: pix not read
Error during processing.
while searching on the net , i came to find that it is problem with leptonica build . and it is not built properly with ltiff . In fact in config.log which gets generated out of ./configure command . i can see following
configure:12538: checking for TIFFOpen in -ltiff
configure:12564: gcc -o conftest -g -O2 -Wl,-rpath -Wl,/lib64 conftest.c -ltiff -lm
>&5
/bin/ld: cannot find -ltiff
However i see that libtiff is present in the system
[ec2-user#ip-172-31-35-131 lib]$ ldconfig -p | grep libtif
libtiffxx.so.5 (libc6,x86-64) => /lib64/libtiffxx.so.5
libtiff.so.5 (libc6,x86-64) => /lib64/libtiff.so.5
I tried pointing to /lib64 path , as per reference from leptonica site [http://www.leptonica.com/source/README.html][1]
Finally, if you find that the installed programs are unable to link
at runtime to the installed library, which is in /usr/local/lib,
try to run configure in this way:
LDFLAGS="-Wl,-rpath -Wl,/usr/local/lib" ./configure
which causes the compiler to pass those options through to the linker.
changing LDFLAGS to point to /lib64 is also not working LDFLAGS="-Wl,-rpath -Wl,/lib64" ./configure
Any suggestions ?
Try to install
apt-get install -y libtiff5-dev
Then install leptonica from source
git clone https://github.com/DanBloomberg/leptonica.git leptonica
cd leptonica
./autobuild
./configure --with-libtiff
make -j
make install
And reinstall tesseract after that
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 am installing DBD-mysql-4.020 perl module on 5.14.2.
when running make, I encounter the below error:
cc -c -I/u01/app/appadmin/product/perl-5.14.2/lib/site_perl/5.14.2/x86_64-linux/auto/DBI -I/usr/local/mysql-standard-4.1.14-pc-linux-gnu-i686/include -mtune=pentiumpro -DDBD_MYSQL_INSERT_ID_IS_GOOD -g -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -DVERSION=\"4.020\" -DXS_VERSION=\"4.020\" -fPIC "-I/u01/app/appadmin/product/perl-5.14.2/lib/5.14.2/x86_64-linux/CORE" dbdimp.c
dbdimp.c:1: error: CPU you selected does not support x86-64 instruction set
make: * [dbdimp.o] Error 1
upgraded compiler to gcc4.4 and did put a lot of effort to overcome this. Your inputs in resolving this and installing the perl Module are greatly appreciated.
error: CPU you selected does not support x86-64 instruction set make:
Does this machine have a 64-bit CPU?
If so, have you checked to see if you have 64 bit versions of perl and mysql? Or you can you the 'lazy' route and just try installing a 32 bit version of DBD-mysql and see what happens.