On Thu, Mar 3, 2016 at 3:13 AM, Richard Henderson <r...@redhat.com> wrote:
> [ Ho hum. Re-send due to spam rejection.
> Trying again with compressed patch. ]
>
>
> As discussed in the PR, let's take the opportunity while bumping the soname
> to add symbol versioning.
>
> Versioning is complicated by the fact that there are several pieces of API
> that are "optional" based on the target. If these optional pieces are later
> implemented by targets that currently do not, we can't have these extra
> symbols suddenly appear in the base version -- that voids the promise that
> symbol versioning makes.
>
> So the symbols are split among 4 different versions. Each version's set of
> symbols is either entirely present[*] or entirely absent. Programs using
> the library will only depend on the subset of versions that they use.
>
> Tested on {x86_64,ppc64,aarch64}-linux. Compile tested on mips64el-linux,
> which doesn't implement go closures or complex types.
>
> For gcc7, we really should pull out these m4 macros to new config/ files.
> I didn't really want to touch anything except libffi for now.
Thanks for doing this. I suppose this is also upstream now?
Richard.
>
> r~
>
>
> [*] Except for i386, where FFI_NATIVE_RAW_API modifies the API, suppressing
> ffi_java_raw_call, ffi_prep_java_raw_closure, ffi_prep_java_raw_closure_loc.
>
> IMO it's a libffi bug that these symbols are suppressed; they could just as
> easily have been aliases for other symbols within libffi. But it's too late
> now. Instead, users of libffi (e.g. libjava) are already checking
> FFI_NATIVE_RAW_API and adjusting the function called.
>
> Anyway, all is well so long as no target changes to define
> FFI_NATIVE_RAW_API that hasn't previously. I'm going to assume that i386 is
> unique and no other target will ever define FFI_NATIVE_RAW_API.
