(End of the IRC discussion:)
22:42 < Q_> But it's the right way to do it, just because they can relink
everything to the new glib, it's not the right way to do it.
22:43 < vorlon> Q_: actually, IME they'll use any excuse to change sonames
between stable branches
22:44 < Q_> They do?
22:44 < Q_> Then I don't see why they would have a problem with it.
22:46 < Q_> Mithrandir: Do you have any idea around what time jamesh is around
ussualy?
22:46 < Mithrandir> if you have App A, lib B and lib C. B links to C. A uses
B directly, but also dereferences structs which it has
gotten from C, through B. C then changes soname (new ABI,
same API), but not removed from the system, B is recompiled
on the system without any soname changes. Is there any way
you can make A continue working?
22:46 < Mithrandir> Q_: he lives in western .au, so he might be around in a
couple of hours.
22:47 < lool> Mithrandir: ah you make me think of something really painful,
there are weird macros accessing structs in headers
22:48 < lool> so including headers of lib C in lib B might be enough for app A
to get smoe code dependent on the structs in C added to it and
hence crashing with a newer C
22:49 < Mithrandir> I'm wondering if my case will work correctly if A is linked
with both B and C and C has versioned symbols.
22:49 < Q_> Mithrandir: I don't think you can keep A working without also
relinking it.
22:49 < lool> I'm not sure I have a real life example, but I think the fact
it's possible might be enough to try to guard against it
22:56 < vorlon> Mithrandir: in that scenario, why is it *not* a bug for B to be
recompiled without an soname change?
22:57 < Q_> Mithrandir: A will get linked to 2 lib C's in that case.
22:57 < Mithrandir> Q_: that's fine if they have versioned symbols, AIUI?
22:57 < vorlon> Mithrandir: if the headers from C are being included into B, it
must be for a reason; I can't think of any non-ABI-breaking
reasons for this other than including trivial enums or defines,
and that just tells me C's headers should be more granular and
B shouldn't be linking to C either.
22:58 < vorlon> hmm, ok. possibility: C makes ABI changes to parts that aren't
referenced by B. Meh.
22:59 < Mithrandir> vorlon: I didn't talk about headers, I talked about
linking. A might very well include C's headers itself, to
get struct definitions.
22:59 < Mithrandir> I was wondering if you could make it work or not.
22:59 < Q_> Mithrandir: If A include's C's headers, it should link to it itself.
22:59 < vorlon> oh. then I guess you're only talking about the usual
"versioned symbols" case.
23:00 < Mithrandir> vorlon: yes, I might very well be, and that works, doesn't
it?
23:00 < Mithrandir> Q_: yes, I meant to write that, but didn't
23:00 < vorlon> Mithrandir: yes, it does.
23:00 < Q_> Mithrandir: And versioned symbols might make it work, but I don't
think in all cases.
23:01 < vorlon> Q_: it works unless B's API is pathological.
23:01 < vorlon> (takes as arguments objects which are defined by C)
23:03 < Mithrandir> I'm thinking that jamesh is correct, but I can't really
tell you why. :-/
23:07 < Mithrandir> well, I gotta sleep. I have some vacation in a little less
than a week, I'll see if I can get to it then. Or in the
weekend.
--
Loïc Minier <[EMAIL PROTECTED]>
