Samofatov, Nickolay wrote:

>It isn't. ELF entrypoint names are process-global. And resolution for
>conflicting names strongly depends on library load order, dl_open flags
>and run-time access pattern (there is LD_LIBRARY_PRELOAD and other env.
>vars on Linux where you can set library load order to get around some of
>the issues). This is why Firebird-internal classes and functions should
>be put to Firebird namespace to avoid collisions with other programs and
>libraries (part of this work is done in FB2 HEAD codebase).
>
>

The namespace solution works particularly well in Vulcan since a
subsystem exports exactly one entrypoint, a function that returns an
instance of the Subsystem class. I'll look at FB 2.0 and get back to you.

>>
>>
>Jim, you insist on wrong provision. There is no technical problem on
>having two same C/C++ symbols on Win32 in different modules (and in all
>other cases except ELF .SO) - I can show you an example (also, I work
>closely with front-end writers; they can confirm there is no such
>problem exists). In case of ELF .SO nothing can save you - your approach
>doesn't work anyway. All symbols (including internal ones - this work is
>now in progress) must be changed to get some safety on ELF. This
>approach would create unnecessary work for front-end writers (you are
>trying to care of them, right?) and even if we implement this, all
>public API has to be changed at once, along with creation of wrapper
>library for backward compatibility (and I'm not sure if this work really
>needs to be done). Horrible mixture of isc_ and fb_ prefixes should
>never exist.
>
>
>

Nickolay, please address the question: How can two organizations without
a conflict resolution mechanism share a client visible namespace?

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376