[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