libunwind ftbfs on amd64 and i386

The patch from Fedora you can find here:

http://cvs.fedoraproject.org/viewvc/devel/libunwind/libunwind-disable-setjmp.patch?view=log

sorry, still FTBFS (amd64):

make[3]: Entering directory `/tmp/buildd/libunwind-0.99'
make[3]: Nothing to be done for `install-exec-am'.
test -z "/usr/include" || /bin/mkdir -p "/tmp/buildd/libunwind-0.99/debian/tmp/usr/include"
 /usr/bin/install -c -m 644 include/libunwind-x86_64.h include/libunwind-dynamic.h include/libunwind-ptrace.h include/libunwind.h include/unwind.h '/tmp/buildd/libunwind-0.99/debian/tmp/usr/include'
test -z "/usr/include" || /bin/mkdir -p "/tmp/buildd/libunwind-0.99/debian/tmp/usr/include"
 /usr/bin/install -c -m 644 include/libunwind-common.h '/tmp/buildd/libunwind-0.99/debian/tmp/usr/include'
make[3]: Leaving directory `/tmp/buildd/libunwind-0.99'
make[2]: Leaving directory `/tmp/buildd/libunwind-0.99'
make[1]: Leaving directory `/tmp/buildd/libunwind-0.99'
dh_testdir
dh_testroot
dh_installchangelogs ChangeLog
dh_installchangelogs: Compatibility levels before 5 are deprecated.
dh_installdocs
dh_installdocs: Compatibility levels before 5 are deprecated.
dh_installexamples
dh_installexamples: Compatibility levels before 5 are deprecated.
dh_install
dh_install: Compatibility levels before 5 are deprecated.
cp: cannot stat `./debian/tmp/usr/lib/libunwind-setjmp.so': No such file or directory
dh_install: cp -a ./debian/tmp/usr/lib/libunwind-setjmp.so debian/libunwind-setjmp0-dev/usr/lib/ returned exit code 1
make: *** [binary-arch] Error 2

since libunwind-setjmp.so.0.0.0 is part of the package, I'm not 100% sure if the band-aid work from Fedora is breaking the ABI, I guess that should be considered as well.

Cheers,
   Stefan.

Oh well, I missed that in my heat ;)
Ok, we can get rid of the -setjmp library I'm not sure if google-perftools (which is my only known pkg which I know depends on libunwind) will use it at all.
Further investigation...

can somone unsubscribe main sponsors, pls?

thx,

\sh

Unsubscribed.

Does this look like it will make it for lucid? as well as the blocking google-perftools? Anything needing investigating or help with this?

Perftools does not depend on setjmp library so does not need to be built for perftools.

If anybody is interested in, I put libunwind 0.99 without setjmp library and google-perftools 1.5 (Jaunty, Karmic, Lucid) in my PPA:

https://launchpad.net/~csaba-kertesz/+archive/aiboplus

Moins,

simple non-intrusive patch for libunwind to compile cleanly.
rechecked with google-perftools and it works as expected.

Please sponsor ;)

Regards,

\sh

The core of this patch is:

diff -u libunwind-0.99/debian/rules libunwind-0.99/debian/rules
--- libunwind-0.99/debian/rules
+++ libunwind-0.99/debian/rules
@@ -12,7 +12,7 @@
 DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)

-CFLAGS = -Wall -g
+CFLAGS = -Wall -g -U_FORTIFY_SOURCE

 ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
  CFLAGS += -O0

That's an unacceptably large hammer, the use of which disables a number of security features that we have enabled by default in our compiler for a very good reason. Either the real *cause* of the bug should be identified and fixed, or the problematic bits of _FORTIFY_SOURCE should be *selectively* disabled.

Unsubscribing sponsors per the above.

@Steve:

Ok, this was the "official" patch by upstream.
The other solution will be to not build libunwind-setjmp.so from source...which was proposed by fedora (see first comment of me)

Regards,

\sh

Steve, as far as I can trace the problem it appears to be in src/setjmp/setjmp.c:

/* Why use K&R syntax here? setjmp() is often a macro and that
   expands into a call to, say, __setjmp() and we need to define the
   libunwind-version of setjmp() with the name of the actual function.
   Using K&R syntax lets us keep the setjmp() macro while keeping the
   syntax valid... This trick works provided setjmp() doesn't do
   anything other than a function call. */

with FORTIFY_SOURCE, unfortunately setjmp is no longer a function call, but rather _setjmp. I haven't found a way to disable the portion of FORTIFY_SOURCE which remaps setjmp to _setjmp specifically (_FORTIFY_SOURCE=1 doesn't do the trick), and I have slight doubts that there's one. At least, if there's one it's undocumented ;).

Any pointers or would an upload as proposed by Stephan be adequate for maverick?

This bug was fixed in the package libunwind - 0.99-0.2ubuntu1

---------------
libunwind (0.99-0.2ubuntu1) maverick; urgency=low

  * debian/rules:
    + adding -U_FORTIFY_SOURCE to CFLAGS to fix FTBFS on amd64 and i386
      (Fix came from: http://savannah.nongnu.org/bugs/?28397),
      LP: #522106.
 -- Stephan Hermann <email address hidden> Mon, 31 May 2010 08:06:26 +0000