| Message ID | 56DB2541.8030409@redhat.com |
|---|---|
| State | New |
| Headers | show |
On 05.03.2016 19:28, Richard Henderson wrote: > When I went to apply my symbol versioning patch to upstream, > I discovered that upstream had already bumped their soname to > 6.4.0, beyond the bump that I'd applied to gcc to 5.0.0. > > So I bumped upstream to 7.0.0, including the symbol versioning, > and this adjusts gcc to match. Looking at the libffi upstream git repo, I can't find this change upstream, and neither mentioned on the libffi mailing list. What am I missing? Matthias
On 03/06/2016 07:24 PM, Matthias Klose wrote: > On 05.03.2016 19:28, Richard Henderson wrote: >> When I went to apply my symbol versioning patch to upstream, >> I discovered that upstream had already bumped their soname to >> 6.4.0, beyond the bump that I'd applied to gcc to 5.0.0. >> >> So I bumped upstream to 7.0.0, including the symbol versioning, >> and this adjusts gcc to match. > > Looking at the libffi upstream git repo, I can't find this change upstream, and > neither mentioned on the libffi mailing list. What am I missing? That must of libffi's workflow is via github, I think. https://github.com/atgreen/libffi/pull/230 r~
On 07.03.2016 12:59, Richard Henderson wrote: > On 03/06/2016 07:24 PM, Matthias Klose wrote: >> On 05.03.2016 19:28, Richard Henderson wrote: >>> When I went to apply my symbol versioning patch to upstream, >>> I discovered that upstream had already bumped their soname to >>> 6.4.0, beyond the bump that I'd applied to gcc to 5.0.0. >>> >>> So I bumped upstream to 7.0.0, including the symbol versioning, >>> and this adjusts gcc to match. >> >> Looking at the libffi upstream git repo, I can't find this change upstream, and >> neither mentioned on the libffi mailing list. What am I missing? > > That must of libffi's workflow is via github, I think. > > https://github.com/atgreen/libffi/pull/230 well, then I don't understand the subject, because there's no upstream commit yet. Plus this patch doesn't seem to be relevant for GCC because libffi is only used as a convenience library, and isn't installed at all. Unless a distributor decides to ship libffi built from the GCC sources again. Matthias
On Thu, Mar 10, 2016 at 3:03 PM, Matthias Klose <doko@ubuntu.com> wrote: > On 07.03.2016 12:59, Richard Henderson wrote: >> >> On 03/06/2016 07:24 PM, Matthias Klose wrote: >>> >>> On 05.03.2016 19:28, Richard Henderson wrote: >>>> >>>> When I went to apply my symbol versioning patch to upstream, >>>> I discovered that upstream had already bumped their soname to >>>> 6.4.0, beyond the bump that I'd applied to gcc to 5.0.0. >>>> >>>> So I bumped upstream to 7.0.0, including the symbol versioning, >>>> and this adjusts gcc to match. >>> >>> >>> Looking at the libffi upstream git repo, I can't find this change >>> upstream, and >>> neither mentioned on the libffi mailing list. What am I missing? >> >> >> That must of libffi's workflow is via github, I think. >> >> https://github.com/atgreen/libffi/pull/230 > > > well, then I don't understand the subject, because there's no upstream > commit yet. Plus this patch doesn't seem to be relevant for GCC because > libffi is only used as a convenience library, and isn't installed at all. > Unless a distributor decides to ship libffi built from the GCC sources > again. Which I incidentially (as the original bugreporter) do. The shared libffi is always built when bootstrapping. It's not installed by a toplevel make install but a make install inside $target/libffi/ works just fine. Richard. > Matthias >
diff --git a/libffi/libffi.map.in b/libffi/libffi.map.in index ca50967..8bd27ef 100644 --- a/libffi/libffi.map.in +++ b/libffi/libffi.map.in @@ -3,7 +3,7 @@ #include <fficonfig.h> #include <ffitarget.h> -LIBFFI_BASE_5 { +LIBFFI_BASE_7.0 { global: /* Exported data variables. */ ffi_type_void; @@ -46,17 +46,17 @@ LIBFFI_BASE_5 { }; #ifdef FFI_TARGET_HAS_COMPLEX_TYPE -LIBFFI_COMPLEX_5 { +LIBFFI_COMPLEX_7.0 { global: /* Exported data variables. */ ffi_type_complex_float; ffi_type_complex_double; ffi_type_complex_longdouble; -} LIBFFI_BASE_5; +} LIBFFI_BASE_7.0; #endif #if FFI_CLOSURES -LIBFFI_CLOSURE_5 { +LIBFFI_CLOSURE_7.0 { global: ffi_closure_alloc; ffi_closure_free; @@ -66,13 +66,13 @@ LIBFFI_CLOSURE_5 { ffi_prep_raw_closure_loc; ffi_prep_java_raw_closure; ffi_prep_java_raw_closure_loc; -} LIBFFI_BASE_5; +} LIBFFI_BASE_7.0; #endif #if FFI_GO_CLOSURES -LIBFFI_GO_CLOSURE_5 { +LIBFFI_GO_CLOSURE_7.0 { global: ffi_call_go; ffi_prep_go_closure; -} LIBFFI_CLOSURE_5; +} LIBFFI_CLOSURE_7.0; #endif diff --git a/libffi/libtool-version b/libffi/libtool-version index 0a841ca..dfb8b11 100644 --- a/libffi/libtool-version +++ b/libffi/libtool-version @@ -3,4 +3,4 @@ # a separate file so that version updates don't involve re-running # automake. # CURRENT:REVISION:AGE -5:0:0 +7:0:0
When I went to apply my symbol versioning patch to upstream, I discovered that upstream had already bumped their soname to 6.4.0, beyond the bump that I'd applied to gcc to 5.0.0. So I bumped upstream to 7.0.0, including the symbol versioning, and this adjusts gcc to match. r~ 2016-03-02 Richard Henderson <rth@redhat.com> * libtool-version: Increase to 7:0:0. * libffi.map.in: Increase version numbers to 7.0.