Statically linking libvpx.a

251 views
Skip to first unread message

Oliver Uvman

unread,
Feb 25, 2014, 8:43:53 AM2/25/14
to apps-...@webmproject.org
Hello!

Since I'm bundling my screen capturing library as a .so to be included in a java applet, I need to statically link libvpx to it. I've tried building with
./configure
./configure --enable-pic
./configure --enable-pic --enable-shared

After copying over libvpx.a to my library's folder, and then attempting to compile, I get the following problem:

oliver@indal~/P/s/s/s/l/s/t/native> make clean; make
rm -f *.o *.so *.png *.webm *.ivf captester shared_captester gmon.out analysis.txt makemov.sh
gcc -fPIC -c -pg -ggdb -o libsc.o libsc.cpp libyuv/libyuv.a libvpx.a  -lX11   -lstdc++ -lrt
gcc: warning: libyuv/libyuv.a: linker input file unused because linking not done
gcc: warning: libvpx.a: linker input file unused because linking not done
gcc -shared -pg -ggdb -o libsc.so libsc.o libyuv/libyuv.a libvpx.a  -lX11   -lstdc++ -lrt
/usr/bin/ld: libvpx.a(subpixel_mmx.asm.o): relocation R_X86_64_PC32 against symbol `vp8_bilinear_filters_x86_8' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
make: *** [libsc.so] Error 1


Any help appreciated.

James Zern

unread,
Feb 25, 2014, 10:48:09 PM2/25/14
to Application Developers
Hi,

On Tue, Feb 25, 2014 at 5:43 AM, Oliver Uvman <embr...@gmail.com> wrote:
> Hello!
>
> Since I'm bundling my screen capturing library as a .so to be included in a
> java applet, I need to statically link libvpx to it. I've tried building
> with
> ./configure
> ./configure --enable-pic
> ./configure --enable-pic --enable-shared
>
> [...]
> gcc -shared -pg -ggdb -o libsc.so libsc.o libyuv/libyuv.a libvpx.a -lX11
> -lstdc++ -lrt
> /usr/bin/ld: libvpx.a(subpixel_mmx.asm.o): relocation R_X86_64_PC32 against
> symbol `vp8_bilinear_filters_x86_8' can not be used when making a shared
> object; recompile with -fPIC
> /usr/bin/ld: final link failed: Bad value
> collect2: error: ld returned 1 exit status
> make: *** [libsc.so] Error 1
>
This is might be due to the fact that the assembly references this
table, which has default visibility. That will result in a dynamic
relocation wherever it's referenced. It may be enough to specify
'--extra-cflags=-fvisibility=protected' in your libvpx configure.

Oliver

unread,
Feb 27, 2014, 1:34:06 PM2/27/14
to apps-...@webmproject.org
Hm, that did not work. Neither did --extra-cflags=-fvisibility=hidden

Getting a similar error:

gcc -fPIC -c -pg -ggdb -o libsc.o libsc.cpp libyuv/libyuv.a libvpx.a  -lX11   -lstdc++ -lrt
gcc: warning: libyuv/libyuv.a: linker input file unused because linking not done
gcc: warning: libvpx.a: linker input file unused because linking not done
gcc -shared -pg -ggdb -o libsc.so libsc.o libyuv/libyuv.a libvpx.a  -lX11   -lstdc++ -lrt
/usr/bin/ld: libvpx.a(vpx_codec.c.o): relocation R_X86_64_PC32 against protected symbol `vpx_mmap_dtor' can not be used when making a shared object
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
make: *** [libsc.so] Error 1

--
You received this message because you are subscribed to a topic in the Google Groups "Application Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/a/webmproject.org/d/topic/apps-devel/ZuMAPQiAY6s/unsubscribe.
To unsubscribe from this group and all its topics, send an email to apps-devel+...@webmproject.org.
To post to this group, send email to apps-...@webmproject.org.
Visit this group at http://groups.google.com/a/webmproject.org/group/apps-devel/.
For more options, visit https://groups.google.com/a/webmproject.org/groups/opt_out.

Oliver

unread,
Feb 27, 2014, 1:45:16 PM2/27/14
to apps-...@webmproject.org
I've also tried using -Wl,--whole-archive <linker things> -Wl,--no-whole-archive to no avail.

Pawel S. Veselov

unread,
Feb 27, 2014, 2:22:34 PM2/27/14
to apps-...@webmproject.org

I've seen this once, actually libvpx itself failed building with that error.
I would say, do one of these things:

1) re-configure with --enable-shared --disable-static, and clean before rebuild. Instead of adding libvpx.a, add the compiled objects directly into your library
2) have JVM load libvpx.so before your library, and link dynamically. I mean, if you can load your library into the applet, then you should be able to load libvpx.so as well. I also thought that loading libraries into JVM will resolve shared dependencies anyway, as long as they are found in whatever library path used. But again, you can always explicitly load it first from whatever location you need.
Reply all
Reply to author
Forward
0 new messages