longjmp link error

[GoogleCodeExporter]

What is the expected behavior?
libvpx.a links ok

What do you see instead?
link error on longjmp function

What version are you using?
0.9.1
On what operating system?
lucid

Can you reproduce using the ivfdec or ivfenc tools?
no

What command line are you using?
build libvpx with gcc 4.4.3
../libvpx/configure --target=x86_64-linux-gcc --enable-pic 
--disable-install-docs --disable-codecs --enable-vp8 --disable-ccache 
--disable-debug --disable-psnr --disable-postproc
make clean
make
sudo make install

link it into a project that is built with gcc 4.2
converse is okay... libvpx with 4.2 links into project with 4.4

Please provide any additional information below.
longjmp is only used in 2 places:

vpx\internal\vpx_codec_internal.h:        longjmp(info->jmp, info->error_code);

vpx_mem\memory_manager\include\hmm_cnfg.h:        longjmp(HMM_UNIQUE(jmp_buf), 
1); }

Can longjmp be removed?

Original issue reported on code.google.com by fbarch...@chromium.org on 26 Aug 2010 at 8:47

[GoogleCodeExporter]

The intent is to allow it to be used as an exception mechanism without having 
to propagate error codes through speed critical functions. Probably don't want 
to remove it entirely.

This issue seems to be that Ubuntu turned on some hardening features in glibc 
by default, and one of those is error checking on longjmp. This check was added 
in glibc 2.11, and Ubuntu turned it on by default in their 8.10 release. You 
can work around this by disabling it at configure time:

  $ CFLAGS=-D_FORTIFY_SOURCE=0 ../libvpx/configure ...

Do you need a more permanent solution going forward? Really you want to be 
building against the libc you want to run on, so maybe we could add support for 
the --libc option on gcc targets like we do for RVCT.. then you'd install the 
glibc you want to target on your system and point the libvpx configure at that. 
It's another case of cross compiling.

Original comment by jkoles...@google.com on 30 Aug 2010 at 6:56

[GoogleCodeExporter]

-D_FORTIFY_SOURCE=0 will do, but could you add that to the configure script?

Original comment by fbarch...@chromium.org on 8 Sep 2010 at 9:21

[GoogleCodeExporter]

I don't think its desirable to make it the default behavior, as extra checks 
should be useful in general. Might be able to come up with a different 
workaround that only fixes this linking problem without disabling all 
_FORTIFY_SOURCE checks everywhere -- Can you try this patch?

diff --git a/vpx/internal/vpx_codec_internal.h b/vpx/internal/vpx_codec_internal
index ab4cad1..23c7bf4 100644
--- a/vpx/internal/vpx_codec_internal.h
+++ b/vpx/internal/vpx_codec_internal.h
@@ -421,6 +421,15 @@ vpx_codec_pkt_list_get(struct vpx_codec_pkt_list *list,

 #include <stdio.h>
 #include <setjmp.h>
+
+#if __GNUC_PREREQ (2,11)
+    #if ARCH_X86_64
+        __asm__(".symver __longjmp_chk,longjmp@GLIBC_2.2.5");
+    #else
+        __asm__(".symver __longjmp_chk,longjmp@GLIBC_2.0");
+    #endif
+#endif
+

Original comment by jkoles...@google.com on 9 Sep 2010 at 8:38

[GoogleCodeExporter]

Original comment by jkoles...@google.com on 16 Mar 2011 at 6:12

• Changed state: NeedMoreInfo

[GoogleCodeExporter]

Applied in https://review.webmproject.org/2624

Original comment by jkoles...@google.com on 11 Jul 2011 at 3:27

• Changed state: Fixed
• Added labels: Version-Cayuga

[GoogleCodeExporter]

Original comment by albe...@google.com on 8 Mar 2012 at 12:10

• Added labels: Type-Bug
• Removed labels: Type-Defect