Statically linking libvpx.a

[Oliver Uvman]

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

(makefile here: https://gist.github.com/9208895 )

Any help appreciated.

[James Zern]

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]

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]

I've also tried using -Wl,--whole-archive <linker things> -Wl,--no-whole-archive to no avail.

[Pawel S. Veselov]

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.