Re: [Firebird-devel] Error compiling ScanDir.cpp

[Jim S. <ja...@ne...>]

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