On 29 June 2015 at 22:26, David Malcolm <dmalc...@redhat.com> wrote: > > I'm working on that, I know that it's important to Ravi (the deadline > for gcc-5.2 is Friday; 2015-07-03).
Thanks! > > There's no good way to track enums in binary metadata, so I'm currently > thinking of this approach for the new options: > > extern void > gcc_jit_context_set_bool_allow_unreachable_blocks (gcc_jit_context *ctxt, > int bool_value); > > tagging it within the linker mapfile as being a new API. > > > I'm looking at ways to manage libgccjit API/ABI as per this thread: > https://gcc.gnu.org/ml/gcc-patches/2015-06/msg01982.html > by transitioning to using symbol versioning, so that the linker can tag > subsets of libgccjit symbols in both libgccjit and in client binaries. > > Adding symbol versioning will involve a SONAME bump (from libgccjit.so.0 > to libgccjit.so.1), thus requiring anyone using libgccjit to recompile > for this one change (the transition to versioned symbols, that is); > hopefully we never need to bump the SONAME again. > > Given that this is needed by Ravi I feel that this break is worth > backporting to gcc 5.2 (I'd rather do this one-time ABI break for the > benefit of specific users, than not do it out of concern for > hypothetical ones). > > Hope this sounds sane. > If you are just adding some API then does it need to be versioned? Apologies if I am misunderstanding the reason here. A breaking change would be if you changed an existing API. Regards Dibyendu
