On 27/10/15 10:56, Vincent Schwarzer wrote:
2015-10-26 21:13 GMT+01:00 Antti Kantee <[email protected]>:
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
Ah, now I noticed. Why are you using --target instead of --host?
x86_64-rumprun-netbsd-gcc -pedantic -I /tmp/thesis_vs/gcc-build/
omp_hello.c -c
x86_64-rumprun-netbsd-gcc -pedantic omp_hello.o -lgomp -o omp_hello.bin
/tmp/thesis_vs/gcc-build/.libs/libgomp.a -pthread
btw, you can also run that with just one command if you like, just like
with regular cc. (though, nothing wrong doing it in two pieces)
After reading this from
https://gcc.gnu.org/onlinedocs/gccint/Configure-Terms.html:
If build, host, and target are all the same, this is called a native. If
build and host are the same but target is different, this is called a
cross. If build, host, and target are all different this is called a
canadian (for obscure reasons dealing with Canada's political party and
the background of the person working on the build at that time). If host
and target are the same, but build is different, you are using a
cross-compiler to build a native for a different system. Some people call
this a host-x-host, crossed native, or cross-built native. If build and
target are the same, but host is different, you are using a cross compiler
to build a cross compiler that produces code for the machine you're
building on. This is rare, so there is no common way of describing it.
There is a proposal to call this a crossback.
Yea reading that always makes my head hurt so I just use --host without
trying to rationalize why --host is correct for specifying the target
system. I guess the last "crossback" explains best why you want --host.
I wonder If I should specify --host=x86_64-netbsd-rumprun additional to the
current configure arguments since I cross-compile the library for netbsd
environment?
And apparently you noticed too. Yes, you should specify only --host.
I executed the make script with x86_64-rumprun-netbsd-make.
foo-rumprun-netbsd-make has been removed in the latest rumprun, just use
make with autoconf programs.
Sure , here we go :
/bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I.
-I../gcc/libgomp -I../gcc/libgomp/config/posix -I../gcc/libgomp -Wall
-Werror -Wc,-pthread -g -O2 -pthread -MT alloc.lo -MD -MP -MF
.deps/alloc.Tpo -c -o alloc.lo ../gcc/libgomp/alloc.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../gcc/libgomp
-I../gcc/libgomp/config/posix -I../gcc/libgomp -Wall -pthread -Werror -g
-O2 -pthread -MT alloc.lo -MD -MP -MF .deps/alloc.Tpo -c
../gcc/libgomp/alloc.c -o alloc.o
You can see it's using "gcc" to compile. It should be using
"x86_64-rumprun-netbsd-gcc". I think it will be fixed with make
distclean and re-running configure with the right params.
I found following libc.a files in my rumprun directory
./rumprun/lib/libc.a
./obj-xen-amd64/buildrump.sh/lib/libc/libc.a
./obj-xen-amd64/dest.stage/lib/libc.a
./platform/xen/rumpobj/lib/libc/libc.a
./platform/xen/rump/lib/libc.a
And you are right I should have been more precise and said different
locations because the first three locations are identical copies only the
last two libc.a files differ from the first three. I used vimdiff <(nm
./platform/xen/rumpobj/lib/libc/libc.a) <(nm ./rumprun/lib/libc.a).
The latter two are probably leftovers from older builds (look at the
timestamps). I recently changed the build system to move toward a
single object directory instead of sprinkling the objects all around the
tree. For one, it makes "make clean" very easy (rm -rf obj).
