How to make an application (for Linux) which will support a few xercesc shared objects versions without any re-compiling/re-linking.

[Alexey Chemakin <al...@yandex.ru>]

Hello colleagues,

(Sorry if my message will appear twice, the first one was sent to 
xerces-c-users@xerces.apache.org according to my local docs on 2.7.0).

My name is Alexey.


Let's assume that we issued an application linked with 2.7.0 xerces-c.so
and sent it to our clients (binaries only).
Let's assume that our clients want to migrate to 2.8.0.
So the questions from subj is arised.



I have some predicates. Please, confirm or contradict them.
Also there are some questions.
Any links to documentation, remarks, explanations are welcome.


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

P (Predicate): Physically it (subj) is possible,
   but functions used by the application must have the same interfaces 
for all "a few xercesc shared objects versions"
   (to avoid some stack corruption).
   Please, confirm or contradict.

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

P: To track any interfaces changing it is enough to read
  migration guide (like http://xerces.apache.org/xerces-c/migrate.html)
  and make sure that functions which are used by the application are not 
met in the following chapters:
  "Modified Public API"
  "Deprecated/Removed Public API"
   Please, confirm or contradict.


Q: Here is a question: why Deprecated and Removed API are not separated 
to different chapters ?

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

The article
"http://www.codesynthesis.com/~boris/blog/2007/09/02/xerces-2-8-0-released/" 

has such strings:

"2.8.0 is interface-compatible with 2.7.0 which means all you will need 
to do to take advantage of all the improvements
is to recompile your applications."

So there are questions:

Q: Does such an intention (subj) violate some principles ?

Q: Will there be some troubles if the client, say, just will rename 
xerces-c.so.28.0 to xerces-c.so.27.0
   (provided that "Modified Public API" and "Deprecated/Removed Public 
API" chapters of migrations guide are empty) ?


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

Q : Is there a standard way to do so (subj) ?
    If yes, explain, please, how to link the application, which linker 
options and links to shared object to use etc.?

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

I noticed that after XercesC building, the $XERCESCROOT/lib directory 
contains smth like this:

libxerces-c.so
libxerces-c.so.27
libxerces-c.so.27.0

where libxerces-c.so is a link which points to libxerces-c.so.27,
and libxerces-c.so.27 is a link which points to libxerces-c.so.27.0 
(this is real shared objects).

When I use "-lxerces-c" linker option, ldd shows that my application 
needed libxerces-c.so.27 (i.e. link).

Q: Is there a way (probably linker options) to make so that
   my application will require libxerces-c.so (link) ?
Q: If there are not standard solutions, will such solution be appropriate:
   to create a link libxerces-c_tmp.so which will point to 
libxerces-c.so and to use "-lxerces-c_tmp" linker option ?


Q: If I understand correctly that all libxerces-c.so.Y.x shared objects 
have exactly the same interface for different x
   *if Y is a constant* ?

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

Thank you,
-------
Alexey

Re: How to make an application (for Linux) which will support a few xercesc shared objects versions without any re-compiling/re-linking.

[Alexey Chemakin <al...@yandex.ru>]

Boris Kolpackov wrote:
> Hi Alexey,
>
> To answer all your questions at once, what you are trying to do is
> not possible. It might work for some versions but that is not
> guaranteed by the Xerces-C++ project.
>
> Xerces-C++ has the following release numbering policy:
>
> 1. Releases with different major versions (e.g., 2.8.0 and 3.0.0)
>    are interface (and thus binary) incompatible.
>
> 2. Releases with the same major versions but different minor
>    versions (e.g., 2.7.0 and 2.8.0) are interface-compatible
>    but binary-incompatible. This means that an application
>    should be able to migrate from one version to the other
>    without any source code changes but will require a
>    recompilation. Common changes that are interface-compatible
>    but binary-incompatible are adding and reordering virtual
>    functions, changing function signatures in a compatible
>    way, and changing sizes of objects (e.g., adding or removing
>    a private member variable).
>
> 3. Releases with the same major and minor versions but different
>    revisions (e.g., 2.8.0 and 2.8.1) are binary (and thus
>    interface) compatible.
>
> Boris
>
>   
Hello Boris,
Thank you for fast answer and for clarification. :)

Re: How to make an application (for Linux) which will support a few xercesc shared objects versions without any re-compiling/re-linking.

[Boris Kolpackov <bo...@codesynthesis.com>]

Hi Alexey,

To answer all your questions at once, what you are trying to do is
not possible. It might work for some versions but that is not
guaranteed by the Xerces-C++ project.

Xerces-C++ has the following release numbering policy:

1. Releases with different major versions (e.g., 2.8.0 and 3.0.0)
   are interface (and thus binary) incompatible.

2. Releases with the same major versions but different minor
   versions (e.g., 2.7.0 and 2.8.0) are interface-compatible
   but binary-incompatible. This means that an application
   should be able to migrate from one version to the other
   without any source code changes but will require a
   recompilation. Common changes that are interface-compatible
   but binary-incompatible are adding and reordering virtual
   functions, changing function signatures in a compatible
   way, and changing sizes of objects (e.g., adding or removing
   a private member variable).

3. Releases with the same major and minor versions but different
   revisions (e.g., 2.8.0 and 2.8.1) are binary (and thus
   interface) compatible.

Boris

-- 
Boris Kolpackov, Code Synthesis Tools
Open source XML data binding for C++:   http://codesynthesis.com/products/xsd
Mobile/embedded validating XML parsing: http://codesynthesis.com/products/xsde