Re: Coordinating libffi upgrade
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El Thu, 17 Jan 2013 06:35:08 -0500 (EST) Anthony Green gr...@redhat.com escribió: Dennis wrote: I am right now building a compat-libffi package that has just the old .so nothing to be built against. so expect that early this week the .so of libffi will be bumped. Hey, thanks Dennis! I really appreciate this. I'm hoping to release 3.0.12 soon and get that into the F19 release. Among other things, this include AArch64 support. Anthony Green No problem. seemed it was kinda important and needed doing. as long as the soname of 3.0.12 doesnt change it should be simple. aarch64 support will be needed :) Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlD+0rcACgkQkSxm47BaWfc8mACdG8ly6e52UA+sxhAe8dn2a+4B KvwAnjSRnDkECahj6f/7zk0bGPtKkXcM =k4Nx -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Coordinating libffi upgrade
Dennis wrote: I am right now building a compat-libffi package that has just the old .so nothing to be built against. so expect that early this week the .so of libffi will be bumped. Hey, thanks Dennis! I really appreciate this. I'm hoping to release 3.0.12 soon and get that into the F19 release. Among other things, this include AArch64 support. Anthony Green -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Coordinating libffi upgrade
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El Fri, 02 Nov 2012 16:04:29 -0400 Adam Jackson a...@redhat.com escribió: On 11/2/12 3:18 PM, Anthony Green wrote: Several months ago I attempted to upgrade libffi 3.0.10 to 3.0.11. The change was reverted because the soname change in this version of the library broke the build environment. I would still like to get 3.0.11 in Fedora. I don't anticipate any future ABI-breaking changes, and 3.0.12 will include additional ports like Aarch64, which is likely of interest to some Fedora developers. How do we coordinate a rebuild for dependent packages? Also, I assume this will have to wait 'til F18 is out (fine by me), but I'd like to deal with it early in the F19 cycle. It looks like libffi is emitted into the minimal buildroot (rpm-build - pkg-config - glib2 - libffi), so during the transition we'll need to build both sonames of libffi. It might be worth keeping a compat-libffi around for a release or two anyway, the current soname has a _long_ history. I am right now building a compat-libffi package that has just the old .so nothing to be built against. so expect that early this week the .so of libffi will be bumped. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlD0TvoACgkQkSxm47BaWfeWkwCeN3gJR5lfWjgPwWYjpFeN/KTl 5/8AoJ4JaVMRJct2RsSG57QVHHk5flET =WBEh -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Coordinating libffi upgrade
Several months ago I attempted to upgrade libffi 3.0.10 to 3.0.11. The change was reverted because the soname change in this version of the library broke the build environment. I would still like to get 3.0.11 in Fedora. I don't anticipate any future ABI-breaking changes, and 3.0.12 will include additional ports like Aarch64, which is likely of interest to some Fedora developers. How do we coordinate a rebuild for dependent packages? Also, I assume this will have to wait 'til F18 is out (fine by me), but I'd like to deal with it early in the F19 cycle. Thanks, Anthony Green -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Coordinating libffi upgrade
On 11/2/12 3:18 PM, Anthony Green wrote: Several months ago I attempted to upgrade libffi 3.0.10 to 3.0.11. The change was reverted because the soname change in this version of the library broke the build environment. I would still like to get 3.0.11 in Fedora. I don't anticipate any future ABI-breaking changes, and 3.0.12 will include additional ports like Aarch64, which is likely of interest to some Fedora developers. How do we coordinate a rebuild for dependent packages? Also, I assume this will have to wait 'til F18 is out (fine by me), but I'd like to deal with it early in the F19 cycle. It looks like libffi is emitted into the minimal buildroot (rpm-build - pkg-config - glib2 - libffi), so during the transition we'll need to build both sonames of libffi. It might be worth keeping a compat-libffi around for a release or two anyway, the current soname has a _long_ history. After that, though, the rebuilds should be pretty straightforward, it looks like all affected source packages are provenpackager+. The caveat might be things like ghc which generate their prov/reqs based on a sha hash of, well, something; if that something includes the list of DT_NEEDED then we might be looking at a rebuild of many more things. But even that should be straightforward if tedious. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Coordinating libffi upgrade
On Fri, 2012-11-02 at 16:04 -0400, Adam Jackson wrote:
It looks like libffi is emitted into the minimal buildroot (rpm-build -
pkg-config - glib2 - libffi), so during the transition we'll need to
build both sonames of libffi. It might be worth keeping a compat-libffi
around for a release or two anyway, the current soname has a _long_ history.
Or just apply the patch from here:
http://lists.fedoraproject.org/pipermail/devel/2012-April/165871.html
And skip tons of pain for all the libffi consumers at the tiny cost of a
stub symbol.
Hm, no links to the patch in the archives. Well, I'll attach it again,
since I still have it sitting around in my libffi git checkout.
From ce7211733bd2d1748c3dcd3d3717850e28d4594d Mon Sep 17 00:00:00 2001
From: Colin Walters walt...@verbum.org
Date: Sat, 14 Apr 2012 10:03:59 -0400
Subject: [PATCH] Revert to previous ABI
Bumping the SONAME just to delete 3 symbols that no one called anyways
is quite simply not worth the pain, given how many low-level modules
consume libffi.
Just keep the symbols around as empty stubs.
---
Makefile.am | 6 +-
libtool-version | 2 +-
src/debug.c | 12 ++--
3 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index 8a32794..7829a36 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -97,11 +97,7 @@ libffi_la_SOURCES = src/prep_cif.c src/types.c \
pkgconfigdir = $(libdir)/pkgconfig
pkgconfig_DATA = libffi.pc
-nodist_libffi_la_SOURCES =
-
-if FFI_DEBUG
-nodist_libffi_la_SOURCES += src/debug.c
-endif
+nodist_libffi_la_SOURCES = src/debug.c
if MIPS
nodist_libffi_la_SOURCES += src/mips/ffi.c src/mips/o32.S src/mips/n32.S
diff --git a/libtool-version b/libtool-version
index 95f48c5..b8b80e0 100644
--- a/libtool-version
+++ b/libtool-version
@@ -26,4 +26,4 @@
#release, then set age to 0.
#
# CURRENT:REVISION:AGE
-6:0:0
+5:10:0
diff --git a/src/debug.c b/src/debug.c
index 51dcfcf..ae42afd 100644
--- a/src/debug.c
+++ b/src/debug.c
@@ -27,33 +27,41 @@
#include stdlib.h
#include stdio.h
-/* General debugging routines */
+/* General debugging routines; note these were accidentally
+ * made public, so we keep empty stubs in the case where
+ * we weren't compiled with FFI_DEBUG.
+ */
void ffi_stop_here(void)
{
+#ifdef FFI_DEBUG
/* This function is only useful for debugging purposes.
Place a breakpoint on ffi_stop_here to be notified of
significant events. */
+#endif
}
/* This function should only be called via the FFI_ASSERT() macro */
void ffi_assert(char *expr, char *file, int line)
{
+#ifdef FFI_DEBUG
fprintf(stderr, ASSERTION FAILURE: %s at %s:%d\n, expr, file, line);
ffi_stop_here();
abort();
+#endif
}
/* Perform a sanity check on an ffi_type structure */
void ffi_type_test(ffi_type *a, char *file, int line)
{
+#ifdef FFI_DEBUG
FFI_ASSERT_AT(a != NULL, file, line);
FFI_ASSERT_AT(a-type = FFI_TYPE_LAST, file, line);
FFI_ASSERT_AT(a-type == FFI_TYPE_VOID || a-size 0, file, line);
FFI_ASSERT_AT(a-type == FFI_TYPE_VOID || a-alignment 0, file, line);
FFI_ASSERT_AT(a-type != FFI_TYPE_STRUCT || a-elements != NULL, file, line);
-
+#endif
}
--
1.7.11.7
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Coordinating libffi upgrade
Colin Walters (walt...@verbum.org) said: On Fri, 2012-11-02 at 16:04 -0400, Adam Jackson wrote: It looks like libffi is emitted into the minimal buildroot (rpm-build - pkg-config - glib2 - libffi), so during the transition we'll need to build both sonames of libffi. It might be worth keeping a compat-libffi around for a release or two anyway, the current soname has a _long_ history. Or just apply the patch from here: http://lists.fedoraproject.org/pipermail/devel/2012-April/165871.html And skip tons of pain for all the libffi consumers at the tiny cost of a stub symbol. Hm, no links to the patch in the archives. Well, I'll attach it again, since I still have it sitting around in my libffi git checkout. And note that whatever you do, F-19 is open for doing it now - you don't need to wait until F-18 ships... Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Coordinating libffi upgrade
On Fri, Nov 02, 2012 at 04:49:01PM -0400, Bill Nottingham wrote: Colin Walters (walt...@verbum.org) said: On Fri, 2012-11-02 at 16:04 -0400, Adam Jackson wrote: It looks like libffi is emitted into the minimal buildroot (rpm-build - pkg-config - glib2 - libffi), so during the transition we'll need to build both sonames of libffi. It might be worth keeping a compat-libffi around for a release or two anyway, the current soname has a _long_ history. Or just apply the patch from here: http://lists.fedoraproject.org/pipermail/devel/2012-April/165871.html And skip tons of pain for all the libffi consumers at the tiny cost of a stub symbol. Hm, no links to the patch in the archives. Well, I'll attach it again, since I still have it sitting around in my libffi git checkout. And note that whatever you do, F-19 is open for doing it now - you don't need to wait until F-18 ships... And has been since August. Development starts when rawhide and F-next branch. https://fedoraproject.org/wiki/Schedule -Toshio pgpvzoWu2xWVX.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Coordinating libffi upgrade
On Fri, Nov 02, 2012 at 03:23:48PM -0700, Toshio Kuratomi wrote: And has been since August. Development starts when rawhide and F-next branch. We need some way to put this in bigger letters. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
