On Wed, Aug 16, 2006, Caleb Epstein wrote: > On 8/16/06, Ralf S. Engelschall <[EMAIL PROTECTED]> wrote: > [...] > I guess I am misunderstanding what "multiple instance" means. Does it mean > you > can have more than one comlpete OpenPKG instance ( e.g. different OpenPKG > versions with full sets of packages) installed at once, or does it mean that > you can have multiple instances of package <X> installed in one OpenPKG > instance (e.g. textutils 1.11 and 1.12 and 1.13 and ...)? Or is it something > else entirely.
It means that you can have multiple complete OpenPKG instances (including different OpenPKG versions and with full sets of packages) installed on the same underlying system without any chroot/jail/zone/whatever virtualization. See http://www.openpkg.org/product/feature/multiinstance.php for some sort of an illustration. Technically it means that you can have OpenPKG under /foo which is 100% unrelated to one under /bar and one under /quux. > [...] > There is also the issue of needing to recompile applications whenever a > library > they link with has changed. For example, lets take libxml2. Many > applications > link with this library. If a bug is found and fixed, all of those > applications > will require relinking using the current scheme. If the bug fix did not > change > the public interface to the library, and shared libraries were used, no > applications would require relinking to pick up the fix. Yes, that's correct. On case of a bug or security fix all applications have to be relinked. OTOH if you touch libxml all your applications at the same time could break if libxml is a shared library while with a static libxml built into each application you can more easily and smoothly upgrade. Well, as always in life: everything has an advantage and a disadvantage. > [...] > Shared libraries and loadable modules are nearly identical in that they are > built using the same tools and compiler switches. OpenPKG's use of > "--disable-shared" when calling configure causes zsh at least to omit its > loadable module support, which causes certain features not to work (for > example > programmable completion). I think this would be true of most applications > that > use configure and libtool to build their DSOs. Yes, that's why we have dozen packages where we --enable-shared but trick at least the application executable to be linked with -static. For ZSH I'm already investigating (see my other mail)... > So, we have to be precise here: OpenPKG is neither about statically > linked applications (we always link the executables _dynamically_, we > just link in our own libraries statically), nor is it about not using > Dynamic Shared Objects (DSO) at all (we use it for applications which do > their own libtool or dlopen stuff). OpenPKG currently just about _NOT_ > using shared libraries (i.e. <prefix>/lib/libfoo.so's) > > How are those applications configured? They still build/use dynamic loading > when --disable-shared is passed to configure? One has to be very careful here to not intermix things. The --disable-shared is usually nothing more than a GNU autoconf hint to a contained GNU libtool that it should build the _contained_ libraries as shared libraries (libfoo.so) instead of static libraries (libfoo.a). Nothing more. It especially does _NOT_ automatically built the whole application executable as a static executable (cc -static). Instead it just links in the contained libfoo.a statically and all other system libraries still fully dynamically. Proof this yourself by running "ldd <prefix>/bin/*" on an arbitrary OpenPKG instance: | $ ldd /usr/opkg/bin/* 2>/dev/null | head -20 | /usr/opkg/bin/411toppm: | libm.so.4 => /lib/libm.so.4 (0x28080000) | libc.so.6 => /lib/libc.so.6 (0x28096000) | /usr/opkg/bin/a2p: | libm.so.4 => /lib/libm.so.4 (0x28088000) | libcrypt.so.3 => /lib/libcrypt.so.3 (0x2809e000) | libutil.so.5 => /lib/libutil.so.5 (0x280b6000) | libc.so.6 => /lib/libc.so.6 (0x280c2000) | /usr/opkg/bin/a2ps: | libpaper.so.2 => /usr/local/lib/libpaper.so.2 (0x280c1000) | libm.so.4 => /lib/libm.so.4 (0x280c4000) | libc.so.6 => /lib/libc.so.6 (0x280da000) | /usr/opkg/bin/aafire: | libm.so.4 => /lib/libm.so.4 (0x280b3000) | libc.so.6 => /lib/libc.so.6 (0x280c9000) | /usr/opkg/bin/aainfo: | libm.so.4 => /lib/libm.so.4 (0x280b4000) | libc.so.6 => /lib/libc.so.6 (0x280ca000) | /usr/opkg/bin/aasavefont: | libm.so.4 => /lib/libm.so.4 (0x280b1000) BTW, the --enable-dynamic feature of ZSH is different here: it is a home-brewn DSO support of ZSH and is totally unrelated to GNU libtool. > Well, I also would like to see _optional_ shared library support for > OpenPKG since a longer time. I can only say that until now I still do > not see how we can achieve this with more advantages (usually under > run-time) than disadvantages (usually under packaging/build-time). But, > hey, perhaps someone has a rather clever idea how we can add optional > shared library support without having to poke dozen of %if's into > hundreds of packages. > > Shouldn't it be as simple as not passing --disable-shared to configure in most > cases? No, it isn't such simple. Because your applications might not find the shared libraries automatically under run-time -- well, at least not on all platforms. For true portability you would at least have to set LD_LIBRARY_PATH before running the applications. > At least until know I think that most people seem to overestimate the > effective benefit of shared library support.... > > know = now? Has something changed your mind? Sorry, yes, s/know/now/. Well, until now nobody was able to convince me that shared library support is really worth the effort and results in more advantages than disadvantages for OpenPKG. But that doesn't have to mean we cannot do it at all for OpenPKG. It just means that before I'm not convinced, I personally will at least not waste my time implementing this. But others are welcome to investigate theirself and supply patches (except if they just toggle --disable-shared to --enable-shared, as this is not a sufficient enough solution). Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com ______________________________________________________________________ The OpenPKG Project www.openpkg.org User Communication List openpkg-users@openpkg.org
