CODEWITHSUNDEEP
c++openmp
Teol11
Teol11

Reputation: 55

c++ & OpenMP : undefined reference to GOMP_loop_dynamic_start

I'm stuck in the following problem : at first I compile the following file cancme.cpp :

void funct()
{
int i,j,k,N;
double s;
#pragma omp parallel for default(none) schedule(dynamic,10) private(i,k,s) shared(j,N)
for(i=j+1;i<N;i++) {}
}

by:

mingw32-g++.exe -O3 -std=c++11 -mavx -fopenmp -c C:\pathtofile\cancme.cpp -o C:\pathtofile\cancme.o

Next I build a second file, test.cpp to simply link cancme.o with :

int main()
{
return(0);
}

by: 

mingw32-g++.exe -O3 -std=c++11 -mavx -fopenmp -c C:\pathtofile\test.cpp -o C:\pathtofile\test.o

When linking it with cancme.o, by :

mingw32-g++.exe  -o C:\pathtofile\test.exe C:\pathtofile\test.o  -lgomp  C:\pathtofile\cancme.o

I get the following error messages :

C:\pathtofile\cancme.o:cancme.cpp:(.text+0x39): undefined reference to  `GOMP_loop_dynamic_start'
C:\pathtofile\cancme.o:cancme.cpp:(.text+0x49): undefined reference to `GOMP_loop_dynamic_next'
C:\pathtofile\cancme.o:cancme.cpp:(.text+0x52): undefined reference to `GOMP_loop_end_nowait'
C:\pathtofile\cancme.o:cancme.cpp:(.text+0x92): undefined reference to `GOMP_parallel_start'
C:\pathtofile\cancme.o:cancme.cpp:(.text+0x9f): undefined reference to   `GOMP_parallel_end'

Does anyone have an idea about what's going wrong there??? The OpenMP library is correctly linked by the -lgomp flag but it is like it was not recognized.

note : I use MingW 4.8.1 c++ compiler under windows 7 64 bit:

thank you

renato

Upvotes: 0

Views: 12594

Answers (2)

Hristo Iliev
Hristo Iliev

Reputation: 74405

The GNU linker is a single pass linker. It means that it only resolves symbols that it has seen before it has reached the object file that defines the corresponding symbol. That means, if object file foo.o refers symbols from library libbar.a, then having ... foo.o -lbar ... will result in successful link since the undefined references seen in foo.o are satisfied during the processing of libbar.a (as long as no other object listed after -lbar refers symbols from the library). The opposite, i.e. ... -lbar foo.o ... won't work since once the linker has processed libbar.a, it will no longer search it while trying to resolve the references in foo.o.

On Unix systems that support dynamic link libraries (e.g. Linux, FreeBSD, Solaris, etc.), this is often not the case since -lbar will first look for the dynamic version of the library, e.g. libbar.so, and only if not found would try to link against the static libbar.a. When linking with dynamic libraries, the order doesn't matter since the unresolved references are handled later by the runtime link editor.

On Windows, linking against dynamic link libraries (DLLs) require the so-called import libraries to be statically linked into the executable. Therefore, even if the external dependencies are handled by the runtime linker, one still needs to properly order the static import libraries. libgomp.a is one such library.

Note that this behaviour is specific to the GNU linker that is part of MinGW. The Microsoft linker behaves differently: when resolving a reference, it first searches the libraries listed after the object file and then the libraries listed before it.

Upvotes: 4

VP.
VP.

Reputation: 16725

You made a mistake in compile command:

mingw32-g++.exe  -o C:\pathtofile\test.exe C:\pathtofile\test.o  -lgomp  C:\pathtofile\cancme.o

If you'd use some makefile generators such as CMake for example you not get any linking error.

Don't mess compiler parameters like this: object_file_1 linker_flag_1 object_file_2.

Correct command to compile would be this:

mingw32-g++.exe  -o C:\pathtofile\test.exe C:\pathtofile\test.o   C:\pathtofile\cancme.o -lgomp

Upvotes: 1

Related Questions