On 26 April 2016 at 09:35, Arun Raghavan <[email protected]> wrote: > On 26 April 2016 at 18:02, Arun Raghavan <[email protected]> wrote: >> On 26 April 2016 at 17:58, Felipe Sateler <[email protected]> wrote: >>> On 26 April 2016 at 03:29, Tanu Kaskinen <[email protected]> wrote: >>>> >>>> We've had this problem before. According to this[1] blog post, the >>>> issue was fixed earlier by linking json-glib with -Bsymbolic. The >>>> option forces json-glib's internal json_object_get_type() calls to >>>> always use json-glib's own implementation, but I don't think it helps >>>> applications that use json-glib. >>> >>> >>> According to the same blog post: >>> >>>> another solution is to link json-c with -Bsymbolic >>> >>> And that is done by the latest json-c (0.12)[1]. What version do you >>> have installed? >> >> I have 0.12. > > From what I could tell of -Bsymbolic, it only guarantees that calls to > functions within the library will be resolved to use the version in > the library even if an external version of the symbol is available. > > I saw no way to guarantee via linker flags that calls from one library > into another are always resolved to the intended library.
Right. The real solution then is for either of the libraries to use symbol versioning (I wonder why neither does, actually...). -- Saludos, Felipe Sateler _______________________________________________ pulseaudio-discuss mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
