I'm having trouble linking against Intel MKL using Eclipse CDT. The advice from Intel's Link Line Advisor Tool, per my specific requirements, is to use the Link Line:
-Wl,--start-group ${MKLROOT}/lib/intel64/libmkl_intel_lp64.a ${MKLROOT}/lib/intel64/libmkl_sequential.a ${MKLROOT}/lib/intel64/libmkl_core.a -Wl,--end-group -lpthread -lm -ldl
A more readable form of what I need:
--start-group -lmkl_intel_lp64 -lmkl_sequential -lmkl_core --end-group
The problem is the --start-group --end-group syntax is not (AFAIK) an option within Eclipse. The MKL library has a lot of circular dependencies; this syntax is necessary to avoid having to repeatedly link libraries. Without this syntax, I have this terrible list of libs:
-lmkl_core -lmkl_intel_lp64 -lmkl_sequential -lmkl_core -lmkl_sequential -lmkl_core -lmkl_sequential -lmkl_core -lmkl_sequential
So the question is how to configure Eclipse CDT to link Intel MKL libraries, using the --start-group syntax to prevent circular references?
I solved my problem searching StackOverflow. This Answer on Eclipse CDT and the --start-group option was almost exactly the solution. A slight modification was required; putting the $(LIBS) variable in the group, not the $(USER_OBS).
So From:
${COMMAND} ${FLAGS} ${OUTPUT_FLAG} ${OUTPUT_PREFIX}${OUTPUT} ${INPUTS}
To This:
${COMMAND} ${FLAGS} ${OUTPUT_FLAG} ${OUTPUT_PREFIX}${OUTPUT} $(OBJS) $(USER_OBJS) -Wl,--start-group $(LIBS) -Wl,--end-group
Results in a working Eclipse build. Command line looks like:
g++ -L"Intel MKL 2019.5.281/linux/lib" -shared -o "myLibrary.so" ./MyObject.o -Wl,--start-group -lmkl_intel_lp64 -lmkl_sequential -lmkl_core -Wl,--end-group
Related
The problem is in the title, I'll try to list what I've already tried and so on below.
First off, in my understanding, in order to use OpenGL 4.0 on windows you must extend and or bypass the default windows library as it only ships OpenGL 1.1.
So we have MinGW installed at C:/MinGW/. Next I setup FreeGLUT by downloading the tarball from the project site. Extract and compile by running the makefiles according to the instructions with a minor addition of --prefix to the ./configure command.
./configure --prefix=/c/Users/Owner/root/
make all
make install
Now I have freeglut in /c/Users/Owner/root/lib/, /c/Users/Owner/root/include/ and so on. Next up is GLEW, my problem child as far as I can tell.
Download the source archive from the project site (direct 1.7.0.zip link). Compiling is a tad more complicated, my current recipe is derived from the stack overflow question " Building glew on windows with mingw ". An abbreviated form is listed below:
mkdir lib/
mkdir bin/
gcc -DGLEW_NO_GLU -O2 -Wall -W -Iinclude -DGLEW_BUILD -o src/glew.o -c src/glew.c
gcc -shared -Wl,-soname,libglew32.dll -Wl,--out-implib,lib/libglew32.dll.a -o lib/glew32.dll src/glew.o -L/mingw/lib -lglu32 -lopengl32 -lgdi32 -luser32 -lkernel32
ar cr lib/libglew32.a src/glew.o
gcc -DGLEW_NO_GLU -DGLEW_MX -O2 -Wall -W -Iinclude -DGLEW_BUILD -o src/glew.mx.o -c src/glew.c
gcc -shared -Wl,-soname,libglew32mx.dll -Wl,--out-implib,lib/libglew32mx.dll.a -o lib/glew32mx.dll src/glew.mx.o -L/mingw/lib -lglu32 -lopengl32 -lgdi32 -luser32 -lkernel32
ar cr lib/libglew32mx.a src/glew.mx.o
and should be run from the "root" of /path/to/glew-1.7.0/.
Now with setup of libraries "done" (assuming no mistakes... ) compiling my simple program is done with this line.
${G++} -DFREEGLUT_STATIC -DGLEW_STATIC -m32 main.cpp -o main.exe -lfreeglut_static -lopengl32 -lwinmm -lgdi32 -lglew32 -I ${ROOTPATH}/include -L ${ROOTPATH}/lib --static
Now to decompose this a bit and walk through why I have various "extra" arguments and to show you what errors and problems I've already run into and solved.
-DFREEGLUT_STATIC and -lfreeglut_static are used instead of the normal -lfreeglut as we want a static build here. Failure to do this gives linker errors relating to freeglut.
-DGLEW_STATIC is added for the same reason.
-lwinmm is added to fix the linker error: freeglut_init.c:(.text+0x5d9): undefined reference to '_timeBeginPeriod#4'.
-lgdi32 is added to fix the linker error: c:/Users/Owner/root//lib\libfreeglut_static.a(freeglut_init.o):freeglut_init.c:(.text+0x58c): undefined reference to '_GetDeviceCaps#8'
Now I'm stumped with the following linker error:
c:/Users/Owner/root//lib\libglew32.a(glew.o):glew.c:(.text+0x83e8): undefined reference to `_glGetString#4'
c:/Users/Owner/root//lib\libglew32.a(glew.o):glew.c:(.text+0xa1b2): undefined reference to `_glGetString#4'
c:/Users/Owner/root//lib\libglew32.a(glew.o):glew.c:(.text+0xa290): undefined reference to `_glGetString#4'
The minimal test case that produces this error (main.cpp) is.
#include <GL/glew.h>
#include <GL/freeglut.h>
int main(int argc, char **argv) {
glEnableVertexAttribArray(0);
}
Ideas?
Try adding -lopengl32 last on the line to compile your program and see if it helps.
Argument order is significant with gcc linker options.
Try this:
${G++} -DFREEGLUT_STATIC -DGLEW_STATIC -m32 main.cpp -o main.exe -I ${ROOTPATH}/include -L ${ROOTPATH}/lib -lopengl32 -lwinmm -lgdi32 -lglew32 -static -lfreeglut_static
Also, I don't think there's a double-dash --static option, just -static.
And on win32 you're going to need a successful glewInit() before your glEnableVertexAttribArray() function pointer will be valid. After checking your core version and/or extension, of course :)
This question already has answers here:
What is an undefined reference/unresolved external symbol error and how do I fix it?
(39 answers)
Closed 5 years ago.
I am trying to compile a FLTK project from linux, using the output of the commands:
fltk-config --use-gl --use-images --ldflags
And:
fltk-config --use-gl --use-images --cxxflags
I am using this makefile to compile the project:
I installed the latest FLTK version by just downloading it from fltk.org, and then I compiled and installed it. I also installed X11 and OpenGL. But I still get these errors:
I checked the file system and these headers are in /usr/local/include/FL even if they are not recognized, although I included the directory (-I/usr/local/include) and then in the .cpp and .h files:
#include <FL/Fl_PNG_Image.H>
#include <FL/Fl_Box.H>
etc...
What could be the problem? do I need to install more libraries?
EDIT
I tried to change the makefile:
CXXFLAGS=-I/usr/local/include -I/usr/local/include/FL/images -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE -D_REENTRANT -I/home/ramy/boost_1_63_0 -std=c++11
LDFLAGS=-L/usr/local/lib -lfltk_images -lfltk_png -lz -lfltk_jpeg -lfltk_gl -lGLU -lGL -lfltk -lXrender -lXcursor -lXfixes -lXext -lXinerama -lpthread -ldl -lm -lX11 -L/home/ramy/boost_1_63_0/lib
SOURCES=Car.cpp Map.cpp CarState.cpp Utilities.cpp CarCollection.cpp TableView.cpp MapView.cpp
OBJECTS=Car.o Map.o CarState.o Utilities.o CarCollection.o TableView.o MapView.o
make:
g++ $(LDFLAGS) $(CXXFLAGS) -c $(SOURCES)
g++ $(LDFLAGS) $(CXXFLAGS) -o ../Evolution table-example.cpp $(OBJECTS)
clean:
rm -f $(OBJECTS) ../Evolution
But I still get the same errors.
Those errors don't mean that you are lacking headers, but libraries.
Here you can read the basis (go down to "Compiling Programs with Standard Compilers").
Basically add -L/usr/local/lib -lfltk -lXext -lX11 -lm to your app compiler command; or use fltk-config --cxxflags.
I try to compile a Fortran 90 program using autotools. My makefile.am is here :
AUTOMAKE_OPTIONS = foreign subdir-objects
bin_PROGRAMS = medys
medys_SOURCES = src/all_v001/basics.f90 src/all_v001/variables.f90 src/all_v001/read_input.f90 src/all_v001/math.f90 src/all_v001/champ1.f90 src/all_v001/grille.f90 src/all_v001/NewSubroutines.f90 src/all_v001/Tests.f90 src/all_v001/string.f90 src/all_v001/io_module.f90 src/all_v001/precision.f90 src/core/error.f90 src/all_v001/matrix_modifications.f90 src/all_v001/matrix_temp_lowlvl.f90 src/all_v001/matrix_temp_highlvl.f90 src/all_v001/read_columbus.f90 src/all_v001/ortho.f90 src/all_v001/qp_integrals.f90 src/all_v001/observable.f90 src/all_v001/nouveaudrt.f90 src/all_v001/read_gamess.f90 src/all_v001/dynamique.f90 src/main/main.f90
AM_FCFLAGS = -L/opt/intel/composer_xe_2013_sp1.3.174/mkl/lib/intel64 -I/opt/intel/composer_xe_2013_sp1.3.174/mkl/include/intel64/lp64/ -lmkl_intel_lp64 -lmkl_core -lmkl_intel_thread -lpthread -liomp5 -lmkl_blas95_lp64 -lmkl_lapack95_lp64 -nogen-interface -fpe0 -traceback -debug extended -heap-arrays -fp-stack-check -debug all -openmp
and my configure.ac is here:
AC_INIT([medys], [0.1], [meitnerium109#gmail.com])
m4_define([_AC_F95_FC], [ifort])
AC_CONFIG_SRCDIR([src/main/main.f90])
AC_CONFIG_AUX_DIR([build-aux])
AM_INIT_AUTOMAKE
AC_PROG_FC
AC_PROG_CC
AC_CONFIG_FILES([Makefile])
AC_OUTPUT
Every .o file compiles correctly, but for the bin files compilation fails. If I do the compilation manually, but adding FLAG at the end of the compilation, the compilation is successful. With the make command, the compilation fails:
ifort -L/opt/intel/composer_xe_2013_sp1.3.174/mkl/lib/intel64 -I/opt/intel/composer_xe_2013_sp1.3.174/mkl/include/intel64/lp64/ -lmkl_intel_lp64 -lmkl_core -lmkl_intel_thread -lpthread -liomp5 -lmkl_blas95_lp64 -lmkl_lapack95_lp64 -nogen-interface -fpe0 -traceback -debug extended -heap-arrays -fp-stack-check -debug all -openmp -g -L/opt/intel/composer_xe_2013_sp1.3.174/mkl/lib/intel64 -I/opt/intel/composer_xe_2013_sp1.3.174/mkl/include/intel64/lp64/ -lmkl_intel_lp64 -lmkl_core -lmkl_intel_thread -lpthread -liomp5 -lmkl_blas95_lp64 -lmkl_lapack95_lp64 -o medys src/all_v001/basics.o src/all_v001/variables.o src/all_v001/read_input.o src/all_v001/math.o src/all_v001/champ1.o src/all_v001/grille.o src/all_v001/NewSubroutines.o src/all_v001/Tests.o src/all_v001/string.o src/all_v001/io_module.o src/all_v001/precision.o src/core/error.o src/all_v001/matrix_modifications.o src/all_v001/matrix_temp_lowlvl.o src/all_v001/matrix_temp_highlvl.o src/all_v001/read_columbus.o src/all_v001/ortho.o src/all_v001/qp_integrals.o src/all_v001/observable.o src/all_v001/nouveaudrt.o src/all_v001/read_gamess.o src/all_v001/dynamique.o src/main/main.o
with lof of message error like this one
src/main/main.f90:471: undefined reference to `zgemm_mkl95_'
But if I put the compilation flag at the end, the compilation works:
ifort -o medys src/all_v001/basics.o src/all_v001/variables.o src/all_v001/read_input.o src/all_v001/math.o src/all_v001/champ1.o src/all_v001/grille.o src/all_v001/NewSubroutines.o src/all_v001/Tests.o src/all_v001/string.o src/all_v001/io_module.o src/all_v001/precision.o src/core/error.o src/all_v001/matrix_modifications.o src/all_v001/matrix_temp_lowlvl.o src/all_v001/matrix_temp_highlvl.o src/all_v001/read_columbus.o src/all_v001/ortho.o src/all_v001/qp_integrals.o src/all_v001/observable.o src/all_v001/nouveaudrt.o src/all_v001/read_gamess.o src/all_v001/dynamique.o src/main/main.o -L/opt/intel/composer_xe_2013_sp1.3.174/mkl/lib/intel64 -I/opt/intel/composer_xe_2013_sp1.3.174/mkl/include/intel64/lp64/ -lmkl_intel_lp64 -lmkl_core -lmkl_intel_thread -lpthread -liomp5 -lmkl_blas95_lp64 -lmkl_lapack95_lp64 -nogen-interface -fpe0 -traceback -debug extended -heap-arrays -fp-stack-check -debug all -openmp -g -L/opt/intel/composer_xe_2013_sp1.3.174/mkl/lib/intel64 -I/opt/intel/composer_xe_2013_sp1.3.174/mkl/include/intel64/lp64/ -lmkl_intel_lp64 -lmkl_core -lmkl_intel_thread -lpthread -liomp5 -lmkl_blas95_lp64 -lmkl_lapack95_lp64
autotools use the following command for the compilation :
$(FC) $(AM_FCFLAGS) $(FCFLAGS) -c $(FCFLAGS_f90) $<
Can I change it? Do you have other suggestion?
Your AM_FCFLAGS should really only contain the -I flags, and even then only those that are essential for your build local system structure (aka, all those flags will use $(top_srcdir) most likely.
When you want to link with a third party library, you should pass the
compiler flags (which include the -I flags) to FCFLAGS and linker flags to LDADD, for example
medys_FCFLAGS = -I/opt/intel/composer_xe_2013_sp1.3.174/mkl/include/intel64/lp64/ -nogen-interface -fpe0 -traceback -debug extended -heap-arrays -fp-stack-check -debug all -openmp
medys_LDADD = -L/opt/intel/composer_xe_2013_sp1.3.174/mkl/lib/intel64 -lmkl_intel_lp64 -lmkl_core -lmkl_intel_thread -lpthread -liomp5 -lmkl_blas95_lp64 -lmkl_lapack95_lp64
or something along those lines.
I'm a C++ coder, but there isn't much difference there (I just have to use CXX where you use FC). Here is an example of how a good Makefile.am looks like: https://github.com/CarloWood/ai-xml/blob/master/Makefile.am
As you can see, all my third party library flags, compiler and linker alike, are AC_SUBST's from configure.ac. For example, the BOOST*, LIBXML_CFLAGS and LIBXML_LIBS in there are set by having this included (with m4_include()) in my configure.ac: https://github.com/CarloWood/ai-xml/blob/master/configure.m4
I'm trying to link Ipopt with Intel MKL (instructions).
Intel's Link Advisor suggests:
Link line:
-Wl,--start-group ${MKLROOT}/lib/intel64/libmkl_intel_ilp64.a ${MKLROOT}/lib/intel64/libmkl_core.a ${MKLROOT}/lib/intel64/libmkl_intel_thread.a -Wl,--end-group -lpthread -lm -ldl
Compiler options:
-DMKL_ILP64 -qopenmp -I${MKLROOT}/include
I try to configure Ipopt with:
../configure CXX=icpc CC=icc F77=ifort --with-blas=" -Wl,--start-group ${MKLROOT}/lib/intel64/libmkl_intel_ilp64.a ${MKLROOT}/lib/intel64/libmkl_core.a ${MKLROOT}/lib/intel64/libmkl_intel_thread.a -Wl,--end-group -lpthread -lm -ldl" CXXFLAGS=" -DMKL_ILP64 -qopenmp -I${MKLROOT}/include"
This eventually fails indicating:
checking whether user supplied BLASLIB=[text above] does not work
First you need to make sure that MKL is correctly installed and configured as shown here.
https://software.intel.com/en-us/get-started-with-parallel-studio-xe-for-linux
A permanent way is to put the following line in your .bashrc or .profile
source /opt/intel/parallel_studio_xe_2016.<##>.<###>/psxevars.sh intel64
You could use the following cmdline to check if MKL is ready. It should display the valid MKL installation dir.
$ echo $MKLROOT
If you are using MKL link line advisor, why don't you follow the instruction precisely? I noticed you miss the OpenMP lib -liomp5 in link option, and the whole compile option.
I can build Ipopt with single dynamic MKL by
$ mkdir build
$ cd build
$ ../configure --with-blas=' -Wl,--no-as-needed -L${MKLROOT}/lib/intel64 -lmkl_rt -lpthread -lm -ldl' CFLAGS=' -m64 -I${MKLROOT}/include' CXXFLAGS=' -m64 -I${MKLROOT}/include'
and with dynamic MKL by
$ mkdir build
$ cd build
$ ../configure --with-blas='-Wl,--no-as-needed -L${MKLROOT}/lib/intel64 -lmkl_intel_lp64 -lmkl_core -lmkl_intel_thread -liomp5 -lpthread -lm -ldl' CFLAGS=' -m64 -I${MKLROOT}/include' CXXFLAGS=' -m64 -I${MKLROOT}/include'
But it does not work with static MKL.
The above settings only work with gcc compiler.
Dynamic MKL with icc compiler also works with the following setting.
$ mkdir build
$ cd build
$ ../configure --with-blas=' -L${MKLROOT}/lib/intel64 -lmkl_intel_ilp64 -lmkl_core -lmkl_intel_thread -lpthread -lm -ldl' CFLAGS=' -DMKL_ILP64 -qopenmp -I${MKLROOT}/include' CXXFLAGS=' -DMKL_ILP64 -qopenmp -I${MKLROOT}/include' CC=icc CXX=icpc
Following up on #kangshiyin 's answer: I found that one needs the -liomp5 library and use the LP64 integer representation instead of ILP64. I also defined the Fortran compilers in F77 and FC. The configure command looked like:
../configure --prefix=${YOUR_PREFIX} \
--with-blas=' -L${MKLROOT}/lib/intel64 -lmkl_intel_lp64 -lmkl_core \
-lmkl_intel_thread -liomp5 -lpthread -lm -ldl' \
CC=icc CXX=icpc FC=ifort F77=ifort \
CFLAGS=' -DMKL_LP64 -qopenmp -I${MKLROOT}/include' \
CXXFLAGS='-std=c++11 -DMKL_LP64 -qopenmp -I${MKLROOT}/include' \
OPT_CCFLAGS="-Ofast" OPT_CXXFLAGS="-Ofast" OPT_FCFLAGS="-Ofast"
This worked on an Ubuntu 16.04.3 LTS installation, with the 2017.0.2 versions of the Intel compilers and the MKL. The Ipopt version was 3.12.7.
Update: I tried this also on MacOS "El Capitan" (OS X 10.11.6). Turns out that you have to add the following linker flags to your invocation of configure:
LDFLAGS="-Wl,-rpath,$MKLROOT/../compiler/lib -Wl,-rpath,$MKLROOT/lib"
otherwise the libiomp5.dylib library will not be found. This is apparently due to the changed security setup in "El Capitan", according to some posts on the Intel C++ compiler forum.
Ipopt needs to link against an LP64 Blas and Lapack library, it uses 32 bit integer indices. The ILP64 version of MKL you tried to link against is built for 64 bit integer indices.
The problem is in the title, I'll try to list what I've already tried and so on below.
First off, in my understanding, in order to use OpenGL 4.0 on windows you must extend and or bypass the default windows library as it only ships OpenGL 1.1.
So we have MinGW installed at C:/MinGW/. Next I setup FreeGLUT by downloading the tarball from the project site. Extract and compile by running the makefiles according to the instructions with a minor addition of --prefix to the ./configure command.
./configure --prefix=/c/Users/Owner/root/
make all
make install
Now I have freeglut in /c/Users/Owner/root/lib/, /c/Users/Owner/root/include/ and so on. Next up is GLEW, my problem child as far as I can tell.
Download the source archive from the project site (direct 1.7.0.zip link). Compiling is a tad more complicated, my current recipe is derived from the stack overflow question " Building glew on windows with mingw ". An abbreviated form is listed below:
mkdir lib/
mkdir bin/
gcc -DGLEW_NO_GLU -O2 -Wall -W -Iinclude -DGLEW_BUILD -o src/glew.o -c src/glew.c
gcc -shared -Wl,-soname,libglew32.dll -Wl,--out-implib,lib/libglew32.dll.a -o lib/glew32.dll src/glew.o -L/mingw/lib -lglu32 -lopengl32 -lgdi32 -luser32 -lkernel32
ar cr lib/libglew32.a src/glew.o
gcc -DGLEW_NO_GLU -DGLEW_MX -O2 -Wall -W -Iinclude -DGLEW_BUILD -o src/glew.mx.o -c src/glew.c
gcc -shared -Wl,-soname,libglew32mx.dll -Wl,--out-implib,lib/libglew32mx.dll.a -o lib/glew32mx.dll src/glew.mx.o -L/mingw/lib -lglu32 -lopengl32 -lgdi32 -luser32 -lkernel32
ar cr lib/libglew32mx.a src/glew.mx.o
and should be run from the "root" of /path/to/glew-1.7.0/.
Now with setup of libraries "done" (assuming no mistakes... ) compiling my simple program is done with this line.
${G++} -DFREEGLUT_STATIC -DGLEW_STATIC -m32 main.cpp -o main.exe -lfreeglut_static -lopengl32 -lwinmm -lgdi32 -lglew32 -I ${ROOTPATH}/include -L ${ROOTPATH}/lib --static
Now to decompose this a bit and walk through why I have various "extra" arguments and to show you what errors and problems I've already run into and solved.
-DFREEGLUT_STATIC and -lfreeglut_static are used instead of the normal -lfreeglut as we want a static build here. Failure to do this gives linker errors relating to freeglut.
-DGLEW_STATIC is added for the same reason.
-lwinmm is added to fix the linker error: freeglut_init.c:(.text+0x5d9): undefined reference to '_timeBeginPeriod#4'.
-lgdi32 is added to fix the linker error: c:/Users/Owner/root//lib\libfreeglut_static.a(freeglut_init.o):freeglut_init.c:(.text+0x58c): undefined reference to '_GetDeviceCaps#8'
Now I'm stumped with the following linker error:
c:/Users/Owner/root//lib\libglew32.a(glew.o):glew.c:(.text+0x83e8): undefined reference to `_glGetString#4'
c:/Users/Owner/root//lib\libglew32.a(glew.o):glew.c:(.text+0xa1b2): undefined reference to `_glGetString#4'
c:/Users/Owner/root//lib\libglew32.a(glew.o):glew.c:(.text+0xa290): undefined reference to `_glGetString#4'
The minimal test case that produces this error (main.cpp) is.
#include <GL/glew.h>
#include <GL/freeglut.h>
int main(int argc, char **argv) {
glEnableVertexAttribArray(0);
}
Ideas?
Try adding -lopengl32 last on the line to compile your program and see if it helps.
Argument order is significant with gcc linker options.
Try this:
${G++} -DFREEGLUT_STATIC -DGLEW_STATIC -m32 main.cpp -o main.exe -I ${ROOTPATH}/include -L ${ROOTPATH}/lib -lopengl32 -lwinmm -lgdi32 -lglew32 -static -lfreeglut_static
Also, I don't think there's a double-dash --static option, just -static.
And on win32 you're going to need a successful glewInit() before your glEnableVertexAttribArray() function pointer will be valid. After checking your core version and/or extension, of course :)