On 26/10/15 14:55, Vincent Schwarzer wrote:
Hey,
I have compiled OpenMP from source using following options:
./configure --target=x86_64-rumprun-netbsd --disable-multilib
--disable-shared
I want to test the library with a simple OMP program i.e.
https://computing.llnl.gov/tutorials/openMP/samples/C/omp_hello.c .
I compile and link the program in two separate steps:
x86_64-rumprun-netbsd-gcc -pedantic -I <Path to omp.h> omp_hello.c -c
Ok, that looks correct, but please copypaste unedited commands. That
way there's no chance of human error. I can easily filter irrelevant
paths out, but I can't filter in data which was accidentally removed
during copypaste edit.
Depending on the Link command I run into two different erros:
x86_64-rumprun-netbsd-gcc -pedantic omp_hello.o -o omp_hello.bin <path to
OMP>/libgomp.a -pthread
mp_hello.bin: In function `gomp_verror':
/tmp/gcc-build/../gcc/libgomp/error.c:41: undefined reference to `stderr'
omp_hello.bin: In function `vfprintf':
/usr/include/x86_64-linux-gnu/bits/stdio2.h:127: undefined reference to
`stderr'
/usr/include/x86_64-linux-gnu/bits/stdio2.h:127: undefined reference to
`__vfprintf_chk'
[etc]
That looks like the libgomp you are trying to link was built against
Linux, not against Rumprun. Maybe you can paste the complete output for
building libgomp.
x86_64-rumprun-netbsd-gcc -pedantic omp_hello.o -o omp_hello.bin *-L* <path
to OMP>/libgomp.a -pthread
omp_hello.bin: In function `main':
(.text+0x10): undefined reference to `omp_get_thread_num'
omp_hello.bin: In function `main':
(.text+0x32): undefined reference to `omp_get_num_threads'
collect2: error: ld returned 1 exit status
That looks like libgomp.a isn't being linked (and judging from your
command line and use of -L, looks like PEBCAK).
My guess at the first error would be that I have to link the rumprun
libc.a. But which one is the correct one? I found 4 different libc.a in the
rumprun source folder.
Linking libc is done automatically by the toolchain.
But, to answer your question, the correct one is the one in the
destination directory. How did you determine that the libc.a files are
*different*? The others are most likely identical copies in the object
directory and installation staging area (not sure what the fourth one is).
