[ 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. 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.
zz.gz
Description: application/gzip
