I'm trying to install a patch on wireshark, and the compilation of the wireshark requires libtool library. However, after installing libtool from ftp://ftp.gnu.org/pub/gnu/libtool/, the command ./autogen.sh spits out this error:
error: /Library/Developer/CommandLineTools/usr/bin/libtool: unknown option character `-' in: --version
Usage: /Library/Developer/CommandLineTools/usr/bin/libtool -static [-] file [...] [-filelist listfile[,dirname]] [-arch_only arch] [-sacLT]
Usage: /Library/Developer/CommandLineTools/usr/bin/libtool -dynamic [-] file [...] [-filelist listfile[,dirname]] [-arch_only arch] [-o output] [-install_name name] [-compatibility_version #] [-current_version #] [-seg1addr 0x#] [-segs_read_only_addr 0x#] [-segs_read_write_addr 0x#] [-seg_addr_table <filename>] [-seg_addr_table_filename <file_system_path>] [-all_load] [-noall_load]
and then instructs me to download libtool.
What does the error mean, and what do I need to do to fix it?
What does the error mean
It means that:
NeXTSTEP had a program called "libtool" long before GNU libtool was created;
OS X, being a descendant of NeXTSTEP, also had such a tool;
earlier versions of OS X also provided GNU libtool;
this resulted in a name collision, which OS X worked around by renaming the GNU libtool to "glibtool";
if you're running on a version of OS X that provided the GNU libtool, you didn't realize it, and installed it yourself;
if you're not running on a version of OS X that provides the GNU libtool, you installed it yourself;
the installed version has the same name as the OS X libtool, so there's a name collision.
Either you, or somebody else, appears to have edited the autogen.sh script to directly run /Library/Developer/CommandLineTools/usr/bin/libtool or made some other change to cause it to run that script; this was the Wrong Thing To Do, as that's the OS X libtool, and that is most definitely NOT the libtool that Wireshark wants.
what do I need to do to fix it?
undo whatever was done to cause autogen.sh to make it run /Library/Developer/CommandLineTools/usr/bin/libtool;
rename whatever version of libtool you installed (probably /usr/local/bin/libtool) to glibtool, and rename the libtoolize in the same directory to glibtoolize, so that it looks just like the GNU libtool that OS X used to provide, and thus so that Wireshark's attempt to use the GNU libtool works.
Related
When compiling with -fsanitize=memory I get WARNING: Trying to symbolize code, but external symbolizer is not initialized! when running the program. How do I initialize the external symbolizer?
I solved my own problem using MSAN_SYMBOLIZER_PATH=$(which llvm-symbolizer-3.4) ./a.out. The problem is that Ubuntu postfixes the version number but the binary doesn't know that. Of course you need to use MSAN instead of ASAN when using the memory sanitizer.
You are supposed to be able to set the ASAN_FILTER environment variable to point at a symbolizer, but I could not get it to work. However, you can redirect stderr into a symbolizer after the fact. You'll still get the warnings about the uninitialized symbolizer, but the filenames and line numbers will be correct.
You can use asan_symbolizer.py as the external symbolizer. After downloading it from that link (to /tmp, for example), invoke your program like so (in bash, for this example):
./myprogram 2>&1 | /tmp/asan_symbolize.py | c++filt
On my Ubuntu system, the issue is that LLVM's tools are installed under /usr/bin with version suffixes (like llvm-symbolizer-4.0), and the sanitizer tools are looking for them without version suffixes.
LLVM also installs its binaries to, e.g., /usr/lib/llvm-4.0/bin; the tools under /usr/bin are actually just symlinks. So an easy solution is to add the appropriate /usr/lib/llvm-*/bin directory to your path when working with sanitizers.
I received such warning when I run program debug version (compiled with -fsanitize=address) on Linux machine that didn't contain clang installation. The problem disappeared after I installed clang from devtoolset.
I have sample "Hello, World!" code from the net and I want to run it on the GPU on my university's server. When I type "gcc main.c," it responds with:
CL/cl.h: No such file or directory
What should I do? How can I have this header file?
Are you using Ubuntu or Debian distro? Then you could use this package to solve the problem with missing header file:
apt-get install opencl-headers
You must install opencl library to solve linking issues using that Debian and Ubuntu package:
apt-get install ocl-icd-libopencl1
You can also use these nonfree libraries: nvidia-libopencl1 (Debian) or nvidia-libopencl1-xx (Ubuntu).
Make sure you have the appropriate toolkit installed.
This depends on what you intend running your code on. If you have an NVidia card then you need to download and install the CUDA-toolkit which also contains the necessary binaries and libraries for opencl.
Are you running Linux? If you believe you already have OpenCL installed it could be that it is found at a different location than the standard /usr/include. Type the following and see what results you get:
find / -iname cl.h 2>/dev/null
On my laptop for example, the header is found at /usr/local/cuda-5.5/include. If its the case were your header file is at a different location you simply have to specify the path during complication
g++ -I/usr/local/cuda-5.5/include main.c -lOpenCL
Alternatively, you can create a symbolic link from the path to /usr/include:
ln -s /usr/local/cuda-5.5/include/CL /usr/include
I am an extremely novice user of MPI and its relatives. On the node that I have access to at my institution, MPI is installed, but I would like to know what version I have.
From this old question, an answer suggests trying:
mpiexec --version
But when I try this, I get this error message:
invalid "local" arg: --version
usage:
mpiexec [-h or -help or --help] # get this message
mpiexec -file filename # (or -f) filename contains XML job description
mpiexec [global args] [local args] executable [args]
Having said this, I am not completely sure that I have MPICH. I may instead have OpenMPI. But I do, I think, have MPICH because I ran ldd on my program, and the output included references to libmpich.so, which an answer to this old question says is indicative of MPICH rather than OpenMPI.
Do you have any ideas of how I can extract the version of MPI that I am using?
Addendum
Another answer on that old question says to try:
mpicc -v
I have tried this, and I get this output:
mpicc for MPICH2 version 1.2.1p1
Using built-in specs.
Target: x86_64-linux-gnu
Thread model: posix
gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5.1)
So I guess I have MPICH2 version 1.2.1p1. But can I know from this that for sure that MPICH2 version 1.2.1p1 is currently installed? Or could it be that mpicc was configured with MPICH2 version 1.2.1p1 and now a different version of MPI could be installed?
It means that you have installed MPICH2 1.2.1p1 and it's your default mpicc. If you install another MPI distribution (e.g. Open MPI), then you need to adjust the paths such that you can use the newly installed one.
I am trying to compile Qt 4.7.3 on mignw32 using gcc 4.6.0.
I get the following error when running ./configure:
In file included from C:/work/qt-gcc-4.6.0/include/QtCore/private/qcore_unix_p.h:1:0,
from C:/work/qt-gcc-4.6.0/src/corelib/io/qfsfileengine_unix.cpp:45:
C:/work/qt-gcc-4.6.0/include/QtCore/private/../../../src/corelib/kernel/qcore_unix_p.h:59:3: error: #error "qcore_unix_p.h included on a non-Unix system"
The weird thing is that I am running Windows 7, and it is trying to include that.
Also in the Makefile it is using qfsfileengine_unix and qfsfileengine_iterator_unix instead of qfsfileengine_win and qfsfileengine_iterator_win.
If I change the Makefile to use the Windows' ones, I get the following error (the file does not exist):
In file included from C:/work/qt-gcc-4.6.0/include/QtCore/../../src/corelib/global/qglobal.h:62:0,
from C:/work/qt-gcc-4.6.0/include/QtCore/qglobal.h:1,
from C:/work/qt-gcc-4.6.0/mkspecs/win32-g++/qplatformdefs.h:53,
from C:/work/qt-gcc-4.6.0/src/corelib/io/qfsfileengine_win.cpp:43:
C:/work/qt-gcc-4.6.0/include/QtCore/qconfig.h:1:46: fatal error: ../../src/corelib/global/qconfig.h: No such file or directory
compilation terminated.
When compiling /qt/src/corelib/io/qfsfileengine_win.cpp
Suggestions?
Try ./configure --help
There is probably a flag for a ms-windows, x86 compilation.
It might be something like:
./configure --target-os=mingw32
Keep in mind -- the os parameter name might be different, and the selectable target values *might be different* -- with scripts from different authors -- some values you might encounter might be 'win32', 'win32-386', 'x86-windows32', etc.
See if
./configure --help
Won't give you a list...
You can also redirect its output to a file for easy reading in your favorite editor,
./configure --help > myconfighelp.txt
Good luck!
My programming experience is about 1 year of C/C++ experience from high school, but I did my research and wrote a simple program with OpenCL a few months ago. I was able to compile and run this on an Apple computer relatively easily with g++ and the --framework option. Now I'm on my Ubuntu machine and I have no idea how to compile it. The correct drivers have been downloaded along with ATI's Stream SDK (I have an ATI Radeon HD5870). Any help would be appreciated!
Try
locate libOpenCL.so
If it is in one of the standard directories (most likely /usr/lib, or /usr/local/lib) you need to replace "--framework OpenCL" with "-lOpenCL". If g++ cannot find the lib you can tell g++ to look in a specific directory by adding "-L/path/to/library".
I wish I had my Linux to be more helpful... It is probably best if you redownload the ati-stream-sdk, after extracting it, open the Terminal and "cd /path/to/extracted/files"; in that directory execute make && sudo make install
make you probably know this from windows, this compiles, whatever needs to be compiled
&& chains commands together, the following commands will only be executed if the first command succeeded
sudo make install this will put the files in the expected places (sudo executes a command with superuser priviledges, you will have to enter your password)
Hope that helps.
You might be missing the dynamic libraries from the dynamic linker configuration.
Search for where the libraries are. Most likely /usr/lib, or /usr/local/lib.
Make sure the path location is also configured at one of these places:
LD_LIBRARY_PATH - you can set it in you environment shell, like .bashrc
/etc/ld.so.conf - you will need to call ldconfig to update the cache and it requires root access to change the file.
Reason
Aside from #bjoernz, my system can't find the libOpenCL.so file
It's because the correct file directory is missing
After searchig over the internet, I found out that libOpenCL.so file can provided by ocl-icd-opencl-dev package
Solution
You just need to install the package mentioned above by typing into cmd
sudo apt update
sudo apt install ocl-icd-opencl-dev
Therefore, libOpenCL.so can be found under /usr/lib/x86_64-linux-gnu/ folder
My System Information
OS: Ubuntu 16.04 LTS
GPU: NVIDIA GeForce GTX 660
GPU Driver: nvidia-375
OpenCL: 1.2
Reference:
[1] How to install libOpenCL.so on ubuntu
[2] How to set up OpenCL in Linux