Hi, Jim!

> >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.

The problem is that all non-static functions from various modules are
normally exported. Currently, I don't know any portable way to prevent
this export (there may be some GCC __attribute definitions for this, I
may look).

> >>
> >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?

They should not share it. Namespaces should be separated using module
(this is possible on Windows) or process boundary (ELF dictates this
limitation).

If single piece of code needs to support IB and FB at the same time (not
at IB6 BC level) it needs to load client library dynamically. When you
pick up entrypoints on Windows you pass HMODULE to GetProcAddress so you
know which library you are using. In any case you know which client
library you are using and what to expect from this entrypoint.

Applications using ibase.h must target single engine (IB or FB) if they
are using features that appeared after IB6.

---------------

BTW, 2All, what about putting appropriate define to ibase.h. Something
like
#define FB_CLIENT_VER 15 for FB 1.5 and
#define FB_CLIENT_VER 20 for FB 2.0 ?

Nickolay Samofatov