On Wed, 2007-09-05 at 15:06 -0500, Les Mikesell wrote: > Bill Nottingham wrote: > > Les Mikesell (lesmikesell@xxxxxxxxx) said: > >>> dlopen will cause you to break at runtime instead of buildtime if > >>> ABI changes - that's not good. > >> You should expect things to break when you change an interface - pretty > >> much by definition. If it hurts, don't do it. > > > > I was discussing a case where instead of linking against libvorbis, you > > dlopen() it - that's the sort of thing which is really much better to > > catch at buildtime. If you're dlopening the plugin that is itself linked > > against libvorbis (or whatever), that's better. > > Won't anything using a shared library break if you replace that library > with one that does not follow the same interface definition whether it's > dlopen()ed or not? That's kind of the whole concept of interfaces - > they aren't supposed to change. If you write a new one, call it > something else. That's what I meant when I said that catching interface changes like that should be escalated to a higher layer: the version. It won't get caught during loading of the executable (primarily because it's not linked against it), but it's like any software you develop. You can put error-checks at the lowest level function call and be assured of catching everything, or putting them at a higher level making sure that all entrances are checked. Coneptually, you could make changes to the library that doesn't change the ABI but changes the semantics of the function calls totally breaking the software that uses it but isn't caught during linking (far-fetched though it may be). The primary benefit to doing it this way (and a main concern of distro-makers) is, of course, that packages don't need to hard-Require optional modules (assuming they're optional to begin with). Other issues aren't as interesting to distribution-makers and one could spend weeks discussing the merits of doing it one way or another. Personally I've written software that does both and I'm not convinced one is always better over the other from a software developer's standpoint. Such isn't the case for distro-makers. -- Richi Plana -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
