[OE-core] Link issue of virglrenderer on x86 with gcc options '-O2 -fvisibility=default'
Kang Kai
Kai.Kang at windriver.com
Tue Apr 2 15:45:07 UTC 2019
Hi Raj,
I meet a link problem of virglrenderer with gcc options '-O2
-fvisibility=default' configured in local.conf:
SELECTED_OPTIMIZATION = "-O2 -fvisibility=default"
It fails on qemux86 but succeeds on x86-64.
And the error message:
| i586-poky-linux-libtool: link: i586-poky-linux-gcc -m32 -march=i586
-fstack-protector-strong -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security
-Werror=
format-security
--sysroot=/home/kkang/buildarea/Yocto/build-systemd/tmp/work/i586-poky-linux/virglrenderer/0.7.0-r0/recipe-sysroot
-shared -fPIC -DPIC
.libs/virglrenderer.o *-Wl,--whole-archive* ./.libs/libvrend.a
gallium/auxiliary/.libs/libgallium.a *-Wl,--no-whole-archive* -lm -ldrm
-lgbm -lepoxy -lX1
1 -m32 -march=i586 -fstack-protector-strong
--sysroot=/home/kkang/buildarea/Yocto/build-systemd/tmp/work/i586-poky-linux/virglrenderer/0.7.0-r0/recipe-
sysroot -O2 -Wl,-Bsymbolic -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed
-fstack-protector-strong -Wl,-z -Wl,relro -Wl,-z -Wl,now -pthread
-Wl,-soname
-Wl,libvirglrenderer.so.0 -o .libs/libvirglrenderer.so.0.2.0
|
/home/kkang/buildarea/Yocto/build-systemd/tmp/work/i586-poky-linux/virglrenderer/0.7.0-r0/recipe-sysroot-native/usr/bin/i586-poky-linux/../../libexec/
i586-poky-linux/gcc/i586-poky-linux/8.3.0/ld:
gallium/auxiliary/.libs/libgallium.a(u_cpu_detect.o): relocation
R_386_GOTOFF against undefined symbol `ut
il_cpu_caps' can not be used when making a shared object
It could pass if options -Wl,--whole-archive and -Wl,--no-whole-archive
are removed.
It says 'relocation R_386_GOTOFF' but when I check the file, it shows
relocation type is R_386_GOT32X:
$ readelf --relocs ./util/.libs/u_cpu_detect.o | grep util_cpu_caps
00000092 0000102b R_386_GOT32X 00000004 util_cpu_caps
AFAIK R_386_GOT32X is not used with PIC. But I don't know why the type
is R_386_GOT32X that -fPIC has been applied already?
Any suggestion is great appreciated. Thanks.
--
Kai Kang
More information about the Openembedded-core
mailing list