|
From: Jim S. <ja...@ne...> - 2005-06-08 14:28:18
|
Dimitry Sibiryakov wrote: >On 8 Jun 2005 at 7:29, Jim Starkey wrote: > > > >>The problem is in shared libraries. >> >> > > I guessed so. In vulcan do you load such base things as string and >config handling classes from shared libraries? > > No. Shared libraries only work for products that allow version mix and match among components if all visible entrypoints are under strict architectural control. This is makes sense for architecturally controlled APIs -- the primary API, provider libraries, international libraries, misc plugins. It doesn't make sense for thing that can and should change from version to version. String, configuration, file handling, exception, and other utility classes are under constant revision and extension, and will be incompatible from release to release and, during development, from build to build. A major Vulcan feature is the ability to the Y-valve to select an appropriate engine from a particular database from an arbitrary list of engine providers, each representing a different engine version. This allows a system to run a stable release for production work, a beta release for testing, as well as a development version. To make this work, each provider should be a single loadable library. If different versions of the engine each has a dependency on identically named "common" libraries, chaos ensues. The problem is even more severe for the layer components. A user well might want to retain an old version of gbak to creating backups that can be restored on old versions of Firebird or Interbase. If gbak were dependent on a specific version of a common library, it would be difficult or impossible to do this. Shared libraries are wonderful things -- they are what makes large software possible. But they have to be used carefully and thoughtfully. The Unix and Linux communities have historically been very backward in their understanding of layered software, symbol management, and the larger issues of software engineering. Even today, I'd have to say the Unix/Linux world is essentially clueless when it comes to anything but the most primitive aspects of shared libraries. The organization that pioneered shared libraries -- DEC, Apollo, and Microsoft -- had a clear understanding of what problem they solved, what problems they introduce, and the absolute requirement for deliberate management of symbol visibility. On Linux, we're hanging by the finger nails on a version script file that almost isn't documented and isn't available on many platforms. Scary. >> A class body compiled into two components can >>be subject to version skew or conditional compilation, so the fact >>that two object modules derived from the same files at diffferent >>times doesn't mean that the object modules are interchangeable. >> >> > > A-ha! This is indeed the case with a lot of objects in FB. Current >POSIX build procedure handle it by using different dirs for object >file placement. That's the purpose of ObjModuleType variable. > > The problem isn't the object module, but when the object module get linked into a shared library and the symbols become visible. The ELF linker and loader are too stupid to resolve references within an executable before looking in loaded libraries, so even if you think you've linked with an appropriate object modules, the ELF loader may resolve symbols to an incompatible version the object module contained in a loaded library. "Bah! you say. Nobody would be that stupid!" To quote my brother, "Wrongo, Mary Lou.". -- Jim Starkey Netfrastructure, Inc. 978 526-1376 |