Re: Splitting up a library without breaking ABI?
On Tue, 23 Aug 2011 19:35:46 +0200, Josselin Mouette wrote: Le mardi 23 août 2011 à 10:20 +0200, Stef Walter a écrit : > Is there a way to split a library into two without breaking ABI? > > The current pkg-config file library is libgcr-3.so. Would it work to > have libgcr-3.so depend on the two new libraries (eg: libgcr-base-3.so, > libgcr-gtk-3.so). What I have already seen working is libgcr-3.so keeping some of the symbols, depending on libgcr-base-3.so with the others. But I don’t see a reason why it wouldn’t work at the moment. And I really mean “at the moment”; in the future the dynamic linker might stop automatically looking for symbols in indirect dependencies, since AFAIK it is not part of its specification to do so. Darwin's linker has for many years used two-level namespaces. At compiletime, ld encodes in the binary the name of the file where wach symbol was resolved. At runtime, it has to be in that same library, not just "somewhere in the linked higherarchy". dan -- Daniel Macks dma...@netspace.org ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Splitting up a library without breaking ABI?
Le mardi 23 août 2011 à 10:20 +0200, Stef Walter a écrit : > Is there a way to split a library into two without breaking ABI? > > The current pkg-config file library is libgcr-3.so. Would it work to > have libgcr-3.so depend on the two new libraries (eg: libgcr-base-3.so, > libgcr-gtk-3.so). What I have already seen working is libgcr-3.so keeping some of the symbols, depending on libgcr-base-3.so with the others. But I don’t see a reason why it wouldn’t work at the moment. And I really mean “at the moment”; in the future the dynamic linker might stop automatically looking for symbols in indirect dependencies, since AFAIK it is not part of its specification to do so. > Or is this just not worth it, and I'll just worry about preserving API > backwards compatibility in such a split and not ABI? Given the low number of affected packages, you might not want to bother. Cheers, -- .''`. Josselin Mouette : :' : `. `' `- signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Splitting up a library without breaking ABI?
On Tue, Aug 23, 2011 at 4:20 AM, Stef Walter wrote: > > Is there a way to split a library into two without breaking ABI? Not really, now. > The current pkg-config file library is libgcr-3.so. Would it work to > have libgcr-3.so depend on the two new libraries (eg: libgcr-base-3.so, > libgcr-gtk-3.so). While this might work for most cases, you could perpaps construct situations where it breaks. But then, this is not really an answer to the initial question, since you continue to ship the old library (at least an empty shell of it), in addition to the two new ones. > Or is this just not worth it, and I'll just worry about preserving API > backwards compatibility in such a split and not ABI? I'd say this is probably the better position to take. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
New release for ptlib/opal needed by ekiga
Hi, A new release of ekiga, 3.3.2, is made right now. As usually :o(, it needs new ptlib and opal library releases, 2.10.2 respectively 3.10.2. I will upload them shortly. Please contact me for any question. Cheers, -- Eugen Dedu Ekiga maintainer ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Splitting up a library without breaking ABI?
The libgcr library lives inside the gnome-keyring project. I'd like to split it out into its own module, which is easy enough. But at the same time I'd like to split it into two libraries: one with a GTK+ dependency (UI bits), and the other without. I'm not a release 'superstar', hence the question: Is there a way to split a library into two without breaking ABI? The current pkg-config file library is libgcr-3.so. Would it work to have libgcr-3.so depend on the two new libraries (eg: libgcr-base-3.so, libgcr-gtk-3.so). Or is this just not worth it, and I'll just worry about preserving API backwards compatibility in such a split and not ABI? Cheers, Stef ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
