We are using Dell SUSE Enterprise. No choice.
SUSE doesn't have libpcap-devel or anything similar in the zypper repositories.
I've downloaded and installed libpcap from the GIT repository. libpcap requires both flex and bison to be compiled. flex version 2.5.35 is in the repo, as is bison.
However, I can't get any problem that uses libpcap-devel to compile. The autoconf script fails on attempts to link in libpcap.so:
configure:3633: $? = 1
configure:3636: checking whether we are using the GNU C++ compiler
configure:3665: g++ -c conftest.cpp >&5
configure:3672: $? = 0
configure:3689: result: yes
configure:3698: checking whether g++ accepts -g
configure:3728: g++ -c -g conftest.cpp >&5
configure:3735: $? = 0
configure:3836: result: yes
configure:3861: checking dependency style of g++
configure:3952: result: gcc3
configure:3981: checking for a BSD-compatible install
configure:4049: result: /usr/bin/install -c
configure:4067: checking for pcap_lookupdev in -lpcap
configure:4102: gcc -o conftest -g -O2 conftest.c -lpcap >&5
/usr/local/lib/libpcap.so: undefined reference to `pcap_lex'
collect2: ld returned 1 exit status
configure:4109: $? = 1
configure: failed program was:
Running nm on the archive, I find:
$ nm /usr/local/lib/libpcap.so | grep pcap_lex
U pcap_lex
of course, pcap_lex is really a #define from yylex.
I'm not in over my head here. I'm trying to figure out why none of this stuff compiles properly on Suse. Does anybody have a clue?
Somehow, whatever you did to compile libpcap caused it not to build correctly.
Without:
the config.log file from the libpcap directory;
the Makefile from the libpcap directory;
the output of the build in the libpcap directory;
it will be impossible to determine what that was, and thus it will be impossible to fix the process so that libpcap builds correctly. I have never seen a problem with libpcaps built on Linux, so I cannot determine what's happening here.
(If you supply this information, you will be helping not only yourself but all the people who have reported similar problems but have refused to respond to similar questions and thus have not supplied any of the information in question.)
Related
I recently installed Intel® oneAPI Base Toolkit and Intel® oneAPI HPC Toolkit using the cimmands:
sudo yum install intel-basekit
sudo yum install intel-hpckit
The packages are installed in /opt/intel/oneapi
but when I run ./configure it usually specifies other compilers:
directory QEHeat/src : ok okkokCI : ok
directory ACFDT/src : not present in /rhome/pkgs/QE/qe-7.1/install
directory KCW/PP : okk
all dependencies updated successfully
checking build system type... x86_64-pc-linux-gnu
checking ARCH... x86_64
checking setting AR... ... ar
checking setting ARFLAGS... ... ruv
checking for gfortran... gfortran
checking whether the Fortran compiler works... yes
checking for Fortran compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU Fortran compiler... yes
checking whether gfortran accepts -g... yes
checking for mpiifort... no
checking for mpif90... no
checking for ifort... no
checking for nvfortran... no
checking for pgf90... no
checking for nagfor... no
checking for gfortran... gfortran
checking whether we are using the GNU Fortran compiler... yes
checking whether gfortran accepts -g... yes
checking version of gfortran... gfortran 4.8
checking for Fortran flag to compile .f90 files... none
setting F90... gfortran
setting MPIF90... gfortran
checking for cc... cc
checking whether we are using the GNU C compiler... yes
checking whether cc accepts -g... yes
checking for cc option to accept ISO C89... none needed
setting CC... cc
setting CFLAGS... -O3
using F90... gfortran
setting FFLAGS... -O3 -g
setting F90FLAGS... $(FFLAGS) -cpp
setting FFLAGS_NOOPT... -O0 -g
setting CPP... cpp
setting CPPFLAGS... -P -traditional -Uvector
setting LD... gfortran
setting LDFLAGS... -g
checking whether make sets $(MAKE)... yes
checking whether Fortran files must be preprocessed... no
checking whether we are using the GNU Fortran 77 compiler... yes
checking whether gfortran accepts -g... yes
checking for library containing dgemm... no
MKL not found
in /opt/intel/mkl/lib/intel64: checking for library containing dgemm... no
MKL not found
checking for library containing dgemm... no
in /usr/local/lib: checking for library containing dgemm... no
checking for library containing dgemm... -lblas
setting BLAS_LIBS... -lblas
checking for library containing dspev... -llapack
in /usr/local/lib: checking for library containing dspev... -llapack
checking FFT... checking for library containing dfftw_execute_dft... no
in /usr/local/lib: checking for library containing dfftw_execute_dft... no
using internal copy of FFTW
checking MASS...
checking for library containing mpi_init... no
checking ELPA...
checking for Environ... not used
checking for ranlib... ranlib
checking for wget... wget -O
setting WGET... wget -O
checking for git... git
setting DFLAGS... -D__FFTW
setting IFLAGS... -I. -I$(TOPDIR)/include -I$(TOPDIR)/FoX/finclude
configure: creating ./config.status
config.status: creating install/make_lapack.inc
config.status: creating include/configure.h
config.status: creating make.inc
config.status: creating configure.msg
config.status: creating install/make_wannier90.inc
config.status: creating include/qe_cdefs.h
--------------------------------------------------------------------
ESPRESSO can take advantage of several optimized numerical libraries
(essl, fftw, mkl...). This configure script attempts to find them,
but may fail if they have been installed in non-standard locations.
If a required library is not found, the local copy will be compiled.
The following libraries have been found:
BLAS_LIBS= -lblas
LAPACK_LIBS=-L/usr/local/lib -llapack -lblas
FFT_LIBS=
Please check if this is what you expect.
If any libraries are missing, you may specify a list of directories
to search and retry, as follows:
./configure LIBDIRS="list of directories, separated by spaces"
Parallel environment not detected \(is this a parallel machine?\).\
Configured for compilation of serial executables.
For more info, read the ESPRESSO User's Guide (Doc/users-guide.tex).
--------------------------------------------------------------------
configure: success
How to force ./configure to choose intel oneAPI compilers?
Here is a solution to your issue!
The key env vars to set
using F90... gfortran
setting FFLAGS... -O3 -g
setting F90FLAGS... $(FFLAGS) -cpp
setting FFLAGS_NOOPT... -O0 -g
so
export F90=ifort
export FFLAGS='-O3 -xhost -g'
export FFLAGS_NOOPT='-O0 -g'
When I was compiling Caffe, I had this error, despite OpenBLAS is installed:
AR -o .build_release/lib/libcaffe.a
LD -o .build_release/lib/libcaffe.so
/usr/bin/ld: cannot find -lopenblas
collect2: ld devolvió el estado de salida 1
make: *** [.build_release/lib/libcaffe.so] Error 1
Is there a solution for it?
Including the base packs even after cloning OpenBlas and making will link the appropriate libraries in 14.04 and 16.
apt install liblapack-dev liblapack3 libopenblas-base libopenblas-dev
apt install liblapack-dev liblapack3 libopenblas-base libopenblas-dev
I faced the same problem. Even adding library directory "/opt/OpenBLAS/lib/" to ldconfig cache didn't help (as my libopenblas.so is at "/opt/OpenBLAS/lib/libopenblas.so").
Using cmake helped me. Try this from caffe root directory:
mkdir build
cd build
cmake -DBLAS=open ..
make all
make runtest
If you need to use make, add the symlink of libopenblas.so to /usr/lib. I did the following:
ln -s /opt/OpenBLAS/lib/libopenblas.so /usr/lib/libopenblas.so
I saw the similar problem (I'm compiling caffe again for some reason).
I found the library file the builder is looking for (-lcblas or -latlas means libcblas.so and libatlas.so) are under /usr/lib64/atlas. So just added symbolic links under /usr/lib64 like this.
sudo ln /usr/lib64/atlas/libcblas.so.3.0 /usr/lib64/libcblas.so
sudo ln -s /usr/lib64/atlas/libatlas.so.3.0 /usr/lib64/libatlas.so
But I guess more proper method is to set Makefile.config (the CBLAS path). (I thought the default path will do away with it reading the comment saying so, but it did not.) Hope this helps anyone.
I'm currently trying to build a Cuda project with Cmake on MacOS 10.9. My C and C++ compiler are gcc, but it seems that since Mavericks gcc and g++ links to clang, which is not supported by CUDA.
Has anyone found a good solution to use the real gcc, or to make clang work without "dumpspecs"?
The issue with 10.9 is that gcc is actually clang. Please try latest CUDA toolkit and explicitely point NVCC to use /usr/bin/clang (nvcc -ccbin /usr/bin/clang). This way NVCC will know it's dealing with clang.
This is an extension of the answer provided by Eugene:
The CUDA toolkit download for Mac OSX 10.9 has been posted to the CUDA download page
It supports XCode 5 on 10.9, and will automatically use clang instead of gcc, FYI.
IF you are using XCode 5 on 10.8, please see the release notes:
· On Mac OS X 10.8, if you install XCode 5, including the command-line tools, the gcc compiler will get replaced with clang. You can continue to successfully compile with nvcc from the command-line by using the --ccbin /usr/bin/clang option, which instructs nvcc to use the clang compiler instead of gcc to compile any host code passed to it. However, this solution will not work when building with NSight Eclipse Edition. An alternative solution that will work from the command-line and with NSight Eclipse Edition is to download an older version of the command-line tools package from the Apple Developer website after installing XCode 5, which will re-install gcc to /usr/bin. In order to do this, go to
http://developer.apple.com/downloads/index.action
sign in with your Apple ID, and search for command-line tools using the search pane on the left side of the screen.
The problem actually was there before OS X Mavericks, I had the same problem with Moutain Lion and the answer from Eugene is 100% correct.
However, it seems that my Geforce card is not recognized as a CUDA capable device since the upgrade to Mavericks and it seems that people using softwares that use CUDA are having the same problems.
So better not update right now
I have just downloaded CUDA 5.5, installed under Mac OSX 10.8.5, with Xcode 5.0.2, and updated command line tools in Xcode.
But I couldn't get the CUDA sample "nbody" to compile.
I got all kinds of funny error messages, like clang error: unsupported option '-dumpspecs'
I thought I had solved that one by the help of some other web pages, but then other problems kept creeping up (e.g., GLEW not found, CUDA samples path undefined, ...).
(And the provided makefiles and cmake files seemed just too contrived, so that I couldn't find the bug.)
So I rolled my own makefile. I'm posting it here, in the hope that it might help others save some hours.
#!/usr/bin/make -R
# Simple Makefile for a CUDA sample program
# (because the provided ones don't work! :-( )
#
# We assume that all files in this directory produce one executable.
# Set your GPU version in variable NVCC below
#
# Developed and tested under Mac OS X 10.8.5;
# under Linux, you probably need to adjust a few paths, compiler options, and #ifdef's.
#
# Prerequisites:
# - CUDA 5.5
# - The "Command Line Tools" installed via XCode 5
# - DYLD_FALLBACK_LIBRARY_PATH or DYLD_LIBRARY_PATH must include
# /Developer/NVIDIA/CUDA-5.5/lib:/Developer/NVIDIA/CUDA-5.5/samples/common/lib/darwin
#
# GZ Dec 2013
# -------- variables and settings ---------
#
CUDA := /Developer/NVIDIA/CUDA-5.5
NVCC := nvcc -ccbin /usr/bin/clang -arch=sm_30 --compiler-options -Wall,-ansi,-Wno-extra-tokens
# -ccbin /usr/bin/clang is needed with XCode 5 under OSX 10.8
# -arch=sm_30 is needed for my laptop (it does not provide sm_35)
INCFLAGS := -I $(CUDA)/samples/common/inc
TARGET := nbody
OBJDIR := obj
MAKEFLAGS := kR
.SUFFIXES: .cu .cpp .h
ALLSOURCES := $(wildcard *.cu *.cpp)
ALLFILES := $(basename $(ALLSOURCES))
ALLOBJS := $(addsuffix .o,$(addprefix $(OBJDIR)/,$(ALLFILES)))
DEPDIR := depend
# --------- automatic targets --------------
.PHONY: all
all: $(OBJDIR) $(DEPDIR) $(TARGET)
#true
$(OBJDIR):
mkdir $#
# --------- generic rules --------------
UNAME = $(shell uname)
ifeq ($(UNAME), Darwin) # Mac OS X
# OpenGL and GLUT are frameworks
LDFLAGS = -Xlinker -framework,OpenGL,-framework,GLUT,-L,$(CUDA)/samples/common/lib/darwin,-lGLEW
endif
$(TARGET): $(ALLOBJS)
$(NVCC) $^ $(LDFLAGS) -o $#
$(OBJDIR)/%.o: %.cu
$(NVCC) -c $(INCFLAGS) $ $#
$(DEPDIR)/%.d : %.cpp $(DEPDIR)
#echo creating dependencies for $ $#
$(DEPDIR):
mkdir $#
# ------ administrative stuff -------
.PHONY: clean
clean:
rm -f *.o $(TARGET)
rm -rf $(DEPDIR) $(OBJDIR)
echo:
#echo $(ALLSOURCES)
#echo $(ALLFILES)
#echo $(ALLOBJS)
Clang become the default compiler with OsX Maverick release, gcc and g++ commands are redirected to the clang compiler. You can download gcc compiler via homebrew and link gcc and g++ commands back to the gcc compiler via following the steps below.
$ brew install gcc48
[...]
$ sudo mkdir /usr/bin/backup && sudo mv /usr/bin/gcc /usr/bin/g++ /usr/bin/backup
$ sudo ln -s /usr/local/bin/gcc-4.8 /usr/bin/gcc
$ sudo ln -s /usr/local/bin/g++-4.8 /usr/bin/g++
I have found the solution on this article:
http://gvsmirnov.ru/blog/tech/2014/02/07/building-openjdk-8-on-osx-maverick.html#all-you-had-to-do-was-follow-the-damn-train-cj
Here's a Homebrew recipe that works for me on Lion.
$ brew cat memtestG80
require "formula"
# Documentation: https://github.com/Homebrew/homebrew/wiki/Formula-Cookbook
# /usr/local/Library/Contributions/example-formula.rb
# PLEASE REMOVE ALL GENERATED COMMENTS BEFORE SUBMITTING YOUR PULL REQUEST!
# Requires at compile time nvcc from https://developer.nvidia.com/cuda-downloads
# Requires popt at compile time
class Memtestg80 < Formula
homepage ""
url "https://github.com/ihaque/memtestG80/archive/master.zip"
sha1 ""
version "c4336a69fff07945c322d6c7fc40b0b12341cc4c"
# depends_on "cmake" => :build
depends_on :x11 # if your formula requires any X11/XQuartz components
def install
# ENV.deparallelize # if your formula fails when building in parallel
system "make", "-f", "Makefiles/Makefile.osx", "NVCC=/usr/local/cuda/bin/nvcc -ccbin /usr/bin/clang", "POPT_DIR=/usr/local/Cellar/popt/1.16/lib"
system "cp", "-a", "memtestG80", "/usr/local/bin"
end
test do
# `test do` will create, run in and delete a temporary directory.
#
# This test will fail and we won't accept that! It's enough to just replace
# "false" with the main program this formula installs, but it'd be nice if you
# were more thorough. Run the test with `brew test memtestG80`.
#
# The installed folder is not in the path, so use the entire path to any
# executables being tested: `system "#{bin}/program", "do", "something"`.
system "false"
end
end
I'd like to convert Octave to use CuBLAS for matrix multiplication. This video seems to indicate this is as simple as typing 28 characters:
Using CUDA Library to Accelerate Applications
In practice it's a bit more complex than this. Does anyone know what additional work must be done to make the modifications made in this video compile?
UPDATE
Here's the method I'm trying
in dMatrix.cc add
#include <cublas.h>
in dMatrix.cc change all occurences of (preserving case)
dgemm
to
cublas_dgemm
in my build terminal set
export CC=nvcc
export CFLAGS="-lcublas -lcudart"
export CPPFLAGS="-I/usr/local/cuda/include"
export LDFLAGS="-L/usr/local/cuda/lib64"
the error I receive is:
libtool: link: g++ -I/usr/include/freetype2 -Wall -W -Wshadow -Wold-style-cast
-Wformat -Wpointer-arith -Wwrite-strings -Wcast-align -Wcast-qual -g -O2
-o .libs/octave octave-main.o -L/usr/local/cuda/lib64
../libgui/.libs/liboctgui.so ../libinterp/.libs/liboctinterp.so
../liboctave/.libs/liboctave.so -lutil -lm -lpthread -Wl,-rpath
-Wl,/usr/local/lib/octave/3.7.5
../liboctave/.libs/liboctave.so: undefined reference to `cublas_dgemm_'
EDIT2:
The method described in this video requires the use of the fortran "thunking library" bindings for cublas.
These steps worked for me:
Download octave 3.6.3 from here:
wget ftp://ftp.gnu.org/gnu/octave/octave-3.6.3.tar.gz
extract all files from the archive:
tar -xzvf octave-3.6.3.tar.gz
change into the octave directory just created:
cd octave-3.6.3
make a directory for your "thunking cublas library"
mkdir mycublas
change into that directory
cd mycublas
build the "thunking cublas library"
g++ -c -fPIC -I/usr/local/cuda/include -I/usr/local/cuda/src -DCUBLAS_GFORTRAN -o fortran_thunking.o /usr/local/cuda/src/fortran_thunking.c
ar rvs libmycublas.a fortran_thunking.o
switch back to the main build directory
cd ..
run octave's configure with additional options:
./configure --disable-docs LDFLAGS="-L/usr/local/cuda/lib64 -lcublas -lcudart -L/home/user2/octave/octave-3.6.3/mycublas -lmycublas"
Note that in the above command line, you will need to change the directory for the second -L switch to that which matches the path to your mycublas directory that you created in step 4
Now edit octave-3.6.3/liboctave/dMatrix.cc according to the instructions given in the video. It should be sufficient to replace every instance of dgemm with cublas_dgemm and every instance of DGEMM with CUBLAS_DGEMM. In the octave 3.6.3 version I used, there were 3 such instances of each (lower case and upper case).
Now you can build octave:
make
(make sure you are in the octave-3.6.3 directory)
At this point, for me, Octave built successfully. I did not pursue make install although I assume that would work. I simply ran octave using the ./run-octave script in the octave-3.6.3 directory.
The above steps assume a proper and standard CUDA 5.0 install. I will try to respond to CUDA-specific questions or issues, but there are any number of problems that may arise with a general Octave install on your platform. I'm not an octave expert and I won't be able to respond to those. I used CentOS 6.2 for this test.
This method, as indicated, involves modification of the C source files of octave.
Another method was covered in some detail in the S3527 session at the GTC 2013 GPU Tech Conference. This session was actually a hands-on laboratory exercise. Unfortunately the materials on that are not conveniently available. However the method there did not involve any modification of GNU Octave source, but instead uses the LD_PRELOAD capability of Linux to intercept the BLAS library calls and re-direct (the appropriate ones) to the cublas library.
A newer, better method (using the NVBLAS intercept library) is discussed in this blog article
I was able to produce a compiled executable using the information supplied. It's a horrible hack, but it works.
The process looks like this:
First produce an object file for fortran_thunking.c
sudo /usr/local/cuda-5.0/bin/nvcc -O3 -c -DCUBLAS_GFORTRAN fortran_thunking.c
Then move that object file to the src subdirectory in octave
cp /usr/local/cuda-5.0/src/fortran_thunking.o ./octave/src
run make. The compile will fail on the last step. Change to the src directory.
cd src
Then execute the failing final line with the addition of ./fortran_thunking.o -lcudart -lcublas just after octave-main.o. This produces the following command
g++ -I/usr/include/freetype2 -Wall -W -Wshadow -Wold-style-cast -Wformat
-Wpointer-arith -Wwrite-strings -Wcast-align -Wcast-qual
-I/usr/local/cuda/include -o .libs/octave octave-main.o
./fortran_thunking.o -lcudart -lcublas -L/usr/local/cuda/lib64
../libgui/.libs/liboctgui.so ../libinterp/.libs/liboctinterp.so
../liboctave/.libs/liboctave.so -lutil -lm -lpthread -Wl,-rpath
-Wl,/usr/local/lib/octave/3.7.5
An octave binary will be created in the src/.libs directory. This is your octave executable.
In a most recent version of CUDA you don't have to recompile anything. At least as I found in Debian. First, create a config file for NVBLAS (a cuBLAS wrapper). It won't work without it, at all.
tee nvblas.conf <<EOF
NVBLAS_CPU_BLAS_LIB $(dpkg -L libopenblas-base | grep libblas)
NVBLAS_GPU_LIST ALL
EOF
Then use Octave as you would usually do running it with:
LD_PRELOAD=libnvblas.so octave
NVBLAS will do what it can on a GPU while relaying everything else to OpenBLAS.
Further reading:
Benchmark for Octave.
Relevant slides for NVBLAS presentation.
Manual for nvblas.conf
Worth noting that you may not enjoy all the benefits of GPU computing depending on used CPU/GPU: OpenBLAS is quite fast with current multi-core processors. So fast that time spend copying data to GPU, working on it, and copying back could come close to time needed to do the job right on CPU. Check for yourself. Though GPUs are usually more energy efficient.
I'm trying to set up a development environment on my aging Macbook Pro that matches my Linux EC2 production environment. I'm on the home stretch now, need only to get the mod_auth_mysql plugin for apache working. After a few hours of googling and patching and scratching my head, I think I'm almost there, but I've hit something that nothing I've found online has been able to solve.
nathan#ichigo:/usr/local/mod_auth_mysql-2.9.0$ sudo apxs -c -L/usr/local/mysql/lib -I/usr/local/mysql/include/ -lmysqlclient -lm -lz mod_auth_mysql.c
/usr/share/apr-1/build-1/libtool --silent --mode=compile gcc -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -I/usr/local/include -I/usr/include/apache2 -I/usr/include/apr-1 -I/usr/include/apr-1 -I/usr/local/mysql/include/ -c -o mod_auth_mysql.lo mod_auth_mysql.c && touch mod_auth_mysql.slo
/usr/share/apr-1/build-1/libtool --silent --mode=link gcc -o mod_auth_mysql.la -L/usr/local/mysql/lib -lmysqlclient -lm -lz -rpath /usr/libexec/apache2 -module -avoid-version mod_auth_mysql.lo
ld: warning: in /usr/local/mysql/lib/libmysqlclient.dylib, file is not of required architecture
ld: warning: in /usr/local/mysql/lib/libz.a, file is not of required architecture
warning: no debug symbols in executable (-arch x86_64)
I think this is complaining because it's trying to build for 64-bit, but I'm on a 32-bit platform? I'm not entirely sure. I've tried forcing a 32-bit build with env ARCHFLAGS and -D arch on apxs, to no avail.
FWIW, I also tried mod_auth_mysql-3.0.0, and hit more or less the same result.
Alternatively, is there a more modern way to auth against mysql in Apache? I didn't find anything else, but this module hasn't gotten any love in a good 5 years, and I had to apply some patches I found scattered about the 'net to even get this far.
First, check what architectures your libraries support with file /usr/local/mysql/lib/libmysqlclient.dylib, etc. Once you know that, I think you can control what apxs builds for by adding flags like -Wc,"-arch i386" -Wl,"-arch i386"