Hi, Dr. Treeby,
I was trying to compile the C++ source file, and I followed the instructions in the user manual, but I still got the following errors when compiling the source code with the 'make' command:
/usr/bin/ld: cannot find -lz
/usr/bin/ld: cannot find -lstdc++
/usr/bin/ld: cannot find -lm
/usr/bin/ld: cannot find -lrt
/usr/bin/ld: cannot find -lpthread
/usr/bin/ld: cannot find -lc
FYI, My OS is Fedora 16, and I have installed the latest version of HDF5 and FFTW.
Thanks,
Chao
Hi Chao,
You need to install the development libraries (i.e. glibc). I'm not a Fedora user, but it should be something along the line of,
yum install glibc_xxx
Hope that helps.
Hi Huangchao,
I’ve succeeded on Fedora 16 using the following procedure. I installed a clean instance of Fedora 16 from LiveCD and downloaded hdf5-1.8.10.tar.gz from http://www.hdfgroup.org/ftp/HDF5/current/src/ and fftw-3.3.2.tar.gz from http://www.fftw.org/download.html
Everything was done as the super-user (su)
1) Make sure you have installed gcc and g++ compiler
yum install gcc
yum install gcc-c++
2) Then, it is necessary to install additional libraries
a. Install libc-static and libstdc++-static libraries
yum install glibc-static
yum install libstdc++-static
b. Install Z library
yum install zlib zlib-devel zlib-static
3) Compile the HDF5 and FFTW library following the procedure in the manual. If you'd compiled the libraries before installing zlib, you’d better recompile (configure, make, make install) the HDF5 library as it relies on zlib. (otherwise you could experience an error when launching the code.)
4) Make the source codes. You will probably see a warning, but the code works.
Finally, I also tired the precompiled binary file and it worked on Fedora 16 without any system modifications.
Jiri
Hi Jiri,
Thanks for you help, but I have difficulties to install the 'glibc-static' library on my machine. Here are the errors prompted during installation:
[root@localhost local]# yum install glibc-static
Loaded plugins: langpacks, presto, refresh-packagekit
ftp://mirrors.tummy.com/pub/rpm.livna.org/repo/16/x86_64/repodata/repomd.xml: [Errno 14] FTP Error 550 : ftp://mirrors.tummy.com/pub/rpm.livna.org/repo/16/x86_64/repodata/repomd.xml
Trying other mirror.
http://wftp.tu-chemnitz.de/pub/linux/livna/repo/16/x86_64/repodata/repomd.xml: [Errno 14] HTTP Error 404 - Not Found : http://ftp.tu-chemnitz.de/pub/linux/livna/repo/16/x86_64/repodata/repomd.xml
Trying other mirror.
http://ftp-stud.fht-esslingen.de/pub/Mirrors/rpm.livna.org/repo/16/x86_64/repodata/repomd.xml: [Errno 14] HTTP Error 404 - Not Found : http://ftp-stud.fht-esslingen.de/pub/Mirrors/rpm.livna.org/repo/16/x86_64/repodata/repomd.xml
Trying other mirror.
livna | 3.6 kB 00:00
rpmfusion-free-updates | 3.3 kB 00:00
rpmfusion-nonfree-updates | 3.3 kB 00:00
updates/metalink | 13 kB 00:00
updates | 4.7 kB 00:00
updates/primary_db | 7.2 MB 00:04
updates/group_gz | 435 kB 00:00
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package glibc-static.x86_64 0:2.14.90-24.fc16.9 will be installed
--> Processing Dependency: glibc-devel = 2.14.90-24.fc16.9 for package: glibc-static-2.14.90-24.fc16.9.x86_64
--> Running transaction check
---> Package glibc-devel.x86_64 0:2.14.90-24.fc16.4 will be updated
---> Package glibc-devel.x86_64 0:2.14.90-24.fc16.9 will be an update
--> Processing Dependency: glibc-headers = 2.14.90-24.fc16.9 for package: glibc-devel-2.14.90-24.fc16.9.x86_64
--> Processing Dependency: glibc = 2.14.90-24.fc16.9 for package: glibc-devel-2.14.90-24.fc16.9.x86_64
--> Running transaction check
---> Package glibc.x86_64 0:2.14.90-24.fc16.4 will be updated
--> Processing Dependency: glibc = 2.14.90-24.fc16.4 for package: glibc-common-2.14.90-24.fc16.4.x86_64
---> Package glibc.x86_64 0:2.14.90-24.fc16.6 will be updated
--> Processing Dependency: glibc = 2.14.90-24.fc16.6 for package: glibc-common-2.14.90-24.fc16.6.x86_64
---> Package glibc.x86_64 0:2.14.90-24.fc16.9 will be an update
---> Package glibc-headers.x86_64 0:2.14.90-24.fc16.4 will be updated
---> Package glibc-headers.x86_64 0:2.14.90-24.fc16.6 will be updated
---> Package glibc-headers.x86_64 0:2.14.90-24.fc16.9 will be an update
--> Running transaction check
---> Package glibc.x86_64 0:2.14.90-24.fc16.4 will be updated
---> Package glibc-common.x86_64 0:2.14.90-24.fc16.4 will be updated
---> Package glibc-common.x86_64 0:2.14.90-24.fc16.6 will be updated
---> Package glibc-common.x86_64 0:2.14.90-24.fc16.9 will be an update
--> Finished Dependency Resolution
Error: Package: glibc-common-2.14.90-24.fc16.4.x86_64 (@updates)
Requires: glibc = 2.14.90-24.fc16.4
Removing: glibc-2.14.90-24.fc16.4.x86_64 (@updates)
glibc = 2.14.90-24.fc16.4
Updated By: glibc-2.14.90-24.fc16.9.x86_64 (updates)
glibc = 2.14.90-24.fc16.9
Removing: glibc-2.14.90-24.fc16.6.x86_64 (installed)
glibc = 2.14.90-24.fc16.6
Updated By: glibc-2.14.90-24.fc16.9.x86_64 (updates)
glibc = 2.14.90-24.fc16.9
Available: glibc-2.14.90-14.i686 (fedora)
glibc = 2.14.90-14
You could try using --skip-broken to work around the problem
** Found 53 pre-existing rpmdb problem(s), 'yum check' output follows:
apr-1.4.6-1.fc16.x86_64 is a duplicate with apr-1.4.5-1.fc16.x86_64
freetype-2.4.6-5.fc16.x86_64 is a duplicate with freetype-2.4.6-4.fc16.x86_64
glibc-2.14.90-24.fc16.6.x86_64 is a duplicate with glibc-2.14.90-24.fc16.4.x86_64
glibc-common-2.14.90-24.fc16.6.x86_64 is a duplicate with glibc-common-2.14.90-24.fc16.4.x86_64
glibc-headers-2.14.90-24.fc16.6.x86_64 is a duplicate with glibc-headers-2.14.90-24.fc16.4.x86_64
gnutls-2.12.14-2.fc16.x86_64 is a duplicate with gnutls-2.12.14-1.fc16.x86_64
gnutls-c++-2.12.14-2.fc16.x86_64 is a duplicate with gnutls-c++-2.12.14-1.fc16.x86_64
httpd-2.2.22-2.fc16.x86_64 is a duplicate with httpd-2.2.21-1.fc16.x86_64
httpd-tools-2.2.22-2.fc16.x86_64 is a duplicate with httpd-tools-2.2.21-1.fc16.x86_64
intel-compilerpro-common-117-13.0-1.noarch has missing requires of lsb >= ('0', '3.0', None)
intel-compilerpro-common-117-13.0-1.noarch has missing requires of /usr/lib/libstdc++.so.6
intel-compilerpro-devel-117-13.0-1.i486 has missing requires of lsb >= ('0', '3.0', None)
intel-compilerpro-devel-117-13.0-1.i486 has missing requires of /usr/lib/libstdc++.so.6
intel-compilerpro-vars-117-13.0-1.noarch has missing requires of lsb >= ('0', '3.0', None)
intel-compilerpro-vars-117-13.0-1.noarch has missing requires of /usr/lib/libstdc++.so.6
intel-compilerproc-117-13.0-1.i486 has missing requires of lsb >= ('0', '3.0', None)
intel-compilerproc-117-13.0-1.i486 has missing requires of /usr/lib/libstdc++.so.6
intel-compilerproc-common-117-13.0-1.noarch has missing requires of lsb >= ('0', '3.0', None)
intel-compilerproc-common-117-13.0-1.noarch has missing requires of /usr/lib/libstdc++.so.6
intel-compilerproc-devel-117-13.0-1.i486 has missing requires of lsb >= ('0', '3.0', None)
intel-compilerproc-devel-117-13.0-1.i486 has missing requires of /usr/lib/libstdc++.so.6
intel-openmp-117-13.0-1.i486 has missing requires of lsb >= ('0', '3.0', None)
intel-openmp-117-13.0-1.i486 has missing requires of /usr/lib/libstdc++.so.6
intel-openmp-devel-117-13.0-1.i486 has missing requires of lsb >= ('0', '3.0', None)
intel-openmp-devel-117-13.0-1.i486 has missing requires of /usr/lib/libstdc++.so.6
intel-sourcechecker-common-117-13.0-1.noarch has missing requires of lsb >= ('0', '3.0', None)
intel-sourcechecker-common-117-13.0-1.noarch has missing requires of /usr/lib/libstdc++.so.6
intel-sourcechecker-devel-117-13.0-1.i486 has missing requires of lsb >= ('0', '3.0', None)
intel-sourcechecker-devel-117-13.0-1.i486 has missing requires of /usr/lib/libstdc++.so.6
kernel-headers-3.3.1-5.fc16.x86_64 is a duplicate with kernel-headers-3.2.2-1.fc16.x86_64
2:libpng-1.2.48-1.fc16.x86_64 is a duplicate with 2:libpng-1.2.46-1.fc16.x86_64
libtasn1-2.12-1.fc16.x86_64 is a duplicate with libtasn1-2.7-2.fc15.x86_64
libtasn1-devel-2.12-1.fc16.x86_64 is a duplicate with libtasn1-devel-2.7-2.fc15.x86_64
1:libvorbis-1.3.3-1.fc16.x86_64 is a duplicate with 1:libvorbis-1.3.2-1.fc15.x86_64
libvpx-1.0.0-1.fc16.x86_64 is a duplicate with libvpx-0.9.7.1-1.fc16.x86_64
linux-firmware-20120206-0.1.git06c8f81.fc16.noarch is a duplicate with linux-firmware-20110731-2.fc16.noarch
mysql-5.5.22-1.fc16.x86_64 is a duplicate with mysql-5.5.19-1.fc16.x86_64
mysql-libs-5.5.22-1.fc16.x86_64 is a duplicate with mysql-libs-5.5.19-1.fc16.x86_64
nspr-4.9-2.fc16.x86_64 is a duplicate with nspr-4.8.9-2.fc16.x86_64
nss-3.13.4-2.fc16.x86_64 is a duplicate with nss-3.13.1-10.fc16.x86_64
nss-softokn-3.13.4-1.fc16.x86_64 is a duplicate with nss-softokn-3.13.1-15.fc16.x86_64
nss-softokn-freebl-3.13.4-1.fc16.x86_64 is a duplicate with nss-softokn-freebl-3.13.1-15.fc16.x86_64
nss-sysinit-3.13.4-2.fc16.x86_64 is a duplicate with nss-sysinit-3.13.1-10.fc16.x86_64
nss-util-3.13.4-2.fc16.x86_64 is a duplicate with nss-util-3.13.1-3.fc16.x86_64
openssl-1.0.0h-1.fc16.x86_64 is a duplicate with openssl-1.0.0g-1.fc16.x86_64
php-cli-5.3.10-1.fc16.x86_64 is a duplicate with php-cli-5.3.9-1.fc16.x86_64
php-common-5.3.10-1.fc16.x86_64 is a duplicate with php-common-5.3.9-1.fc16.x86_64
php-pdo-5.3.10-1.fc16.x86_64 is a duplicate with php-pdo-5.3.9-1.fc16.x86_64
1:samba-common-3.6.4-82.fc16.x86_64 is a duplicate with 1:samba-common-3.6.1-77.fc16.x86_64
systemd-37-17.fc16.x86_64 is a duplicate with systemd-37-11.fc16.x86_64
systemd-sysv-37-17.fc16.x86_64 is a duplicate with systemd-sysv-37-11.fc16.x86_64
systemd-units-37-17.fc16.x86_64 is a duplicate with systemd-units-37-11.fc16.x86_64
xulrunner-11.0-3.fc16.x86_64 is a duplicate with xulrunner-9.0.1-1.fc16.x86_64
How should I resolve this?
Thanks,
Chao
Hi Huangchao,
It seems to me that your distribution is a little corrupted. Some packages seem to be installed twice and there are some unresolved and cross dependencies here.
I’d suggest trying one of the followings:
1) Try to install zlib and run the binary distributed with k-wave. This will tell us if there is anything else missing on your system.
2) Try to check your repository
yum check
I’d remove gcc, g++ and all gcc related libraries such as glibc, glibc-dev, libstdc++,etc. and install them again.
3) You can also try dynamic linking. In that case you do not need static libraries, however you have to setup the LD_LIBRARY_PATH variable to point at the folders where fftw, hdf5 and zlib libraries are installed (e.g. /usr/lib, /usr/lib64 or /usr/local/lib ).
4) You can also try to reinstall your OS, or install a new clean copy into a Virtual Box (VMWare) and try to compile the code there
Jiri.
Hi Jiri,
Thanks a lot for your help. Now I solved the problem by using the dynamic linking.
I compiled the source code with g++ & fftw and ran a test. After running the code with different numbers of threads, I found the best performance (took 76 sec to finish) was achieved when 11 or 12 threads were used. Our machine has 12 cores with HT is switched on.
However when I run the provided binary code (with the same input), which was compiled with icc & MKL according to the manual, the best performance was 90 seconds when 10/11 threads were used. The two binary codes gave the same results.
In my impression, icc compiler usually gives faster binary codes than the gcc/g++ compiler, or codes with the same speed, but I never saw icc generated slower codes than gcc/g++. So I don't understand and wonder if you noticed the same phenomenon before?
Also, why the best performance of the icc generated code was not achieved when 12 threads were used?
Thanks again!
Chao
Hi Huangchao,
I’m happy to see you got the code working!
We observed similar behaviour when benchmarking gcc and icc versions of the code. There are several reasons for this:
1) Intel MKL and FFTW differ in the way they choose the best algorithm to calculate the Fourier transform on a particular CPU. While MKL uses statically pre-coded and tuned routines for Intel CPUs, FFTW on the other hand tries to execute several scenarios first and then choose the fastest one. You may have noted that the initialisation phase is notably longer when compiled with FFTW; however, taking into account the simulation duration, this is a small overhead. There are immense of benchmarks on MKL and FFTW but the comparison is very sensitive on the size of the transform and CPU being used.
2) The k-wave code is highly memory bound. That means, the CPU cores are not fed with data sufficiently fast and have to wait for memory. When increasing the number of threads the available memory bandwidth is divided among more threads. And, there is always a non-zero penalty for thread switching, synchronising, etc. I got the best performance when using as many threads as CPU cores. Intel compiler was more sensitive to this phenomenon and was usually a little bit slower.
3) The binary code was compiled to be as portable as possible. If you use icc/icpc it utilises a special optimisations based on the CPU installed in your system by default. However, I couldn’t presume to do this and had to compile the code for as old CPUs as Pentium IV and Athlon XP 64.
You must log in to post.