Thread: libpq compatibility policy across versions
Hi all, We have a libpq client application written in C. We want to deliver the software so that can it be used with different PostgreSQL client versions, from 8.3 to 9.3 (and future versions). So far, we build (compile and link) a binary with each major version of PostgreSQL (8.3, 8.4, 9.0, 9.1, 9.2, 9.3) - in fact we have shared libraries (database driver) for each PostgreSQL version. Is this the proper way, or could we just compile/link with a given version (9.3) and assume that it's backward compatible with any prior version such as 8.3 ? Assuming that we could dynamically load the libpq.so client, search for existing API symbols and only use them if present? Is this risky? Do the C headers define C structures that are compatible between newer and older versions? I would expect some note about libpq compatibility policy here: http://www.postgresql.org/docs/9.3/static/libpq-build.html I can see that the lib version number of libpq.so.x.y changes for each major version: /opt3/dbs/pgs/9.2/lib/libpq.so -> libpq.so.5.5 /opt3/dbs/pgs/9.2/lib/libpq.so.5 -> libpq.so.5.5 /opt3/dbs/pgs/9.2/lib/libpq.so.5.5 /opt3/dbs/pgs/9.3.0/lib/libpq.so -> libpq.so.5.6 /opt3/dbs/pgs/9.3.0/lib/libpq.so.5 -> libpq.so.5.6 /opt3/dbs/pgs/9.3.0/lib/libpq.so.5.6 The binaries are dependent from libpq.so.5: $ ldd -r dbmpgs92x.so...libpq.so.5 => /opt3/dbs/pgs/9.2.3/lib/libpq.so.5 (0xb77bb000)... What does this mean? Theoritically, a binary linked in a 9.3 env can use le libpq.so version of a prior version down to 8.2 ... (8.1 has libpq.so.4) The main question is about C header compatibility: - Compile + link with PostgreSQL client version X.Y.? - What PostgreSQL client version can be used at runtime? Thanks. Seb
Thank you Pavel, On 10/01/2013 02:28 PM, Pavel Golub wrote:> Yes, you should use the latest client library. It's compatible with> all priorversions. Just to be clear: We deliver our product without any PostgreSQL lib included. Our product installs beside an existing PostgreSQL install, typically on an application server, where both PostgreSQL client and server are installed in the same directory. Imagine for ex a machine with PostgreSQL 8.3 installed. I am asking how I must compile my source code and how to link, to build my binary, to be sure that it's compatible with PostgreSQL 8.3, and any in fact any existing PostgreSQL versions. Can I for ex, use the V 9.3 headers and library on my dev platform and then deliver this binary for any PostgreSQL version? In other words, is the PostgreSQL client C API backward compatible? Today the lib is stamped with 5 (libpq.so.5), will this never change in future versions? Is there a way to detect dynamically the version of the PostgreSQL server? Thanks! Seb On 10/01/2013 02:28 PM, Pavel Golub wrote: > Hello, Sebastien. > > You wrote: > > SF> Hi all, > > SF> We have a libpq client application written in C. > > SF> We want to deliver the software so that can it be used with different > SF> PostgreSQL client versions, from 8.3 to 9.3 (and future versions). > > SF> So far, we build (compile and link) a binary with each major version > SF> of PostgreSQL (8.3, 8.4, 9.0, 9.1, 9.2, 9.3) - in fact we have shared > SF> libraries (database driver) for each PostgreSQL version. > > SF> Is this the proper way, or could we just compile/link with a given > SF> version (9.3) and assume that it's backward compatible with any > SF> prior version such as 8.3 ? > > Yes, you should use the latest client library. It's compatible with > all prior versions. > > SF> Assuming that we could dynamically load the libpq.so client, search > SF> for existing API symbols and only use them if present? > > SF> Is this risky? Do the C headers define C structures that are compatible > SF> between newer and older versions? > > SF> I would expect some note about libpq compatibility policy here: > > SF> http://www.postgresql.org/docs/9.3/static/libpq-build.html > > SF> I can see that the lib version number of libpq.so.x.y changes > SF> for each major version: > > SF> /opt3/dbs/pgs/9.2/lib/libpq.so -> libpq.so.5.5 > SF> /opt3/dbs/pgs/9.2/lib/libpq.so.5 -> libpq.so.5.5 > SF> /opt3/dbs/pgs/9.2/lib/libpq.so.5.5 > SF> /opt3/dbs/pgs/9.3.0/lib/libpq.so -> libpq.so.5.6 > SF> /opt3/dbs/pgs/9.3.0/lib/libpq.so.5 -> libpq.so.5.6 > SF> /opt3/dbs/pgs/9.3.0/lib/libpq.so.5.6 > > SF> The binaries are dependent from libpq.so.5: > > SF> $ ldd -r dbmpgs92x.so > SF> ... > SF> libpq.so.5 => /opt3/dbs/pgs/9.2.3/lib/libpq.so.5 (0xb77bb000) > SF> ... > > SF> What does this mean? > > SF> Theoritically, a binary linked in a 9.3 env can use le libpq.so version > SF> of a prior version down to 8.2 ... (8.1 has libpq.so.4) > > SF> The main question is about C header compatibility: > > SF> - Compile + link with PostgreSQL client version X.Y.? > SF> - What PostgreSQL client version can be used at runtime? > > SF> Thanks. > SF> Seb > > > > >
Hello, Sebastien. You wrote: SF> Hi all, SF> We have a libpq client application written in C. SF> We want to deliver the software so that can it be used with different SF> PostgreSQL client versions, from 8.3 to 9.3 (and future versions). SF> So far, we build (compile and link) a binary with each major version SF> of PostgreSQL (8.3, 8.4, 9.0, 9.1, 9.2, 9.3) - in fact we have shared SF> libraries (database driver) for each PostgreSQL version. SF> Is this the proper way, or could we just compile/link with a given SF> version (9.3) and assume that it's backward compatible with any SF> prior version such as 8.3 ? Yes, you should use the latest client library. It's compatible with all prior versions. SF> Assuming that we could dynamically load the libpq.so client, search SF> for existing API symbols and only use them if present? SF> Is this risky? Do the C headers define C structures that are compatible SF> between newer and older versions? SF> I would expect some note about libpq compatibility policy here: SF> http://www.postgresql.org/docs/9.3/static/libpq-build.html SF> I can see that the lib version number of libpq.so.x.y changes SF> for each major version: SF> /opt3/dbs/pgs/9.2/lib/libpq.so -> libpq.so.5.5 SF> /opt3/dbs/pgs/9.2/lib/libpq.so.5 -> libpq.so.5.5 SF> /opt3/dbs/pgs/9.2/lib/libpq.so.5.5 SF> /opt3/dbs/pgs/9.3.0/lib/libpq.so -> libpq.so.5.6 SF> /opt3/dbs/pgs/9.3.0/lib/libpq.so.5 -> libpq.so.5.6 SF> /opt3/dbs/pgs/9.3.0/lib/libpq.so.5.6 SF> The binaries are dependent from libpq.so.5: SF> $ ldd -r dbmpgs92x.so SF> ... SF> libpq.so.5 => /opt3/dbs/pgs/9.2.3/lib/libpq.so.5 (0xb77bb000) SF> ... SF> What does this mean? SF> Theoritically, a binary linked in a 9.3 env can use le libpq.so version SF> of a prior version down to 8.2 ... (8.1 has libpq.so.4) SF> The main question is about C header compatibility: SF> - Compile + link with PostgreSQL client version X.Y.? SF> - What PostgreSQL client version can be used at runtime? SF> Thanks. SF> Seb -- With best wishes,Pavel mailto:pavel@gf.microolap.com
Thank you Pavel, I appreciate your help, but I would however prefer a clear statement from the PostgreSQL C API developpers, written in the doc... ;-) We have a commercial software: not sure we can deliver the PostgreSQL client library in our packages, regarding open source license policy. We don't want to make the sources of our product public. Further, I don't like to ship other software libs in our product, typically you want to use what is installed on the system. If there is a bug in the PostgreSQL client lib, it's up to the user to install the new lib that fixes the bug, without asking us to rebuild a package with the new pgs lib. Nothing new here, just traditional shared lib usage and dependency. Yes, my instinct is also to use the C headers matching the lib version used at runtime, we do this for now... But some people think it's possible to provide a unique binary for all versions of PostgreSQL, so I ask for a clear rule for the PostgreSQL C API. Note also that we want to use the latest version, to get the latest features with new C structures and defines... So typically, we would compile with PostgreSQL 9.3 headers... Seb On 10/01/2013 04:38 PM, Pavel Golub wrote: > Hello, Sebastien. > > You wrote: > > SF> Thank you Pavel, > > SF> On 10/01/2013 02:28 PM, Pavel Golub wrote: > >> Yes, you should use the latest client library. It's compatible with > >> all prior versions. > > SF> Just to be clear: > > SF> We deliver our product without any PostgreSQL lib included. > > Well, I prefer to deploy products with the latest lib included. Thus > I'm absolutely sure in the environment used. > > SF> Our product installs beside an existing PostgreSQL install, typically > SF> on an application server, where both PostgreSQL client and server are > SF> installed in the same directory. > > That's possible of course, but there are a lot of issues you may face > with IMHO > > SF> Imagine for ex a machine with PostgreSQL 8.3 installed. > > SF> I am asking how I must compile my source code and how to link, to build > SF> my binary, to be sure that it's compatible with PostgreSQL 8.3, and > SF> any in fact any existing PostgreSQL versions. > > SF> Can I for ex, use the V 9.3 headers and library on my dev platform > SF> and then deliver this binary for any PostgreSQL version? > > SF> In other words, is the PostgreSQL client C API backward compatible? > > I'm not sure it is. > > > SF> Today the lib is stamped with 5 (libpq.so.5), will this never change > SF> in future versions? > > SF> Is there a way to detect dynamically the version of the PostgreSQL server? > > "SELECT version()" will do the trick using direct SQL. > http://www.postgresql.org/docs/9.3/static/functions-info.html > > PQserverVersion - will help you if you need an integer representing the backend version. > http://www.postgresql.org/docs/9.3/static/libpq-status.html > > > > SF> Thanks! > SF> Seb > > > SF> On 10/01/2013 02:28 PM, Pavel Golub wrote: >>> Hello, Sebastien. >>> >>> You wrote: >>> >>> SF> Hi all, >>> >>> SF> We have a libpq client application written in C. >>> >>> SF> We want to deliver the software so that can it be used with different >>> SF> PostgreSQL client versions, from 8.3 to 9.3 (and future versions). >>> >>> SF> So far, we build (compile and link) a binary with each major version >>> SF> of PostgreSQL (8.3, 8.4, 9.0, 9.1, 9.2, 9.3) - in fact we have shared >>> SF> libraries (database driver) for each PostgreSQL version. >>> >>> SF> Is this the proper way, or could we just compile/link with a given >>> SF> version (9.3) and assume that it's backward compatible with any >>> SF> prior version such as 8.3 ? >>> >>> Yes, you should use the latest client library. It's compatible with >>> all prior versions. >>> >>> SF> Assuming that we could dynamically load the libpq.so client, search >>> SF> for existing API symbols and only use them if present? >>> >>> SF> Is this risky? Do the C headers define C structures that are compatible >>> SF> between newer and older versions? >>> >>> SF> I would expect some note about libpq compatibility policy here: >>> >>> SF> http://www.postgresql.org/docs/9.3/static/libpq-build.html >>> >>> SF> I can see that the lib version number of libpq.so.x.y changes >>> SF> for each major version: >>> >>> SF> /opt3/dbs/pgs/9.2/lib/libpq.so -> libpq.so.5.5 >>> SF> /opt3/dbs/pgs/9.2/lib/libpq.so.5 -> libpq.so.5.5 >>> SF> /opt3/dbs/pgs/9.2/lib/libpq.so.5.5 >>> SF> /opt3/dbs/pgs/9.3.0/lib/libpq.so -> libpq.so.5.6 >>> SF> /opt3/dbs/pgs/9.3.0/lib/libpq.so.5 -> libpq.so.5.6 >>> SF> /opt3/dbs/pgs/9.3.0/lib/libpq.so.5.6 >>> >>> SF> The binaries are dependent from libpq.so.5: >>> >>> SF> $ ldd -r dbmpgs92x.so >>> SF> ... >>> SF> libpq.so.5 => /opt3/dbs/pgs/9.2.3/lib/libpq.so.5 (0xb77bb000) >>> SF> ... >>> >>> SF> What does this mean? >>> >>> SF> Theoritically, a binary linked in a 9.3 env can use le libpq.so version >>> SF> of a prior version down to 8.2 ... (8.1 has libpq.so.4) >>> >>> SF> The main question is about C header compatibility: >>> >>> SF> - Compile + link with PostgreSQL client version X.Y.? >>> SF> - What PostgreSQL client version can be used at runtime? >>> >>> SF> Thanks. >>> SF> Seb >>> >>> >>> >>> >>> > > > > > >
Hello, Sebastien. You wrote: SF> Thank you Pavel, SF> On 10/01/2013 02:28 PM, Pavel Golub wrote:>> Yes, you should use the latest client library. It's compatible with>> allprior versions. SF> Just to be clear: SF> We deliver our product without any PostgreSQL lib included. Well, I prefer to deploy products with the latest lib included. Thus I'm absolutely sure in the environment used. SF> Our product installs beside an existing PostgreSQL install, typically SF> on an application server, where both PostgreSQL client and server are SF> installed in the same directory. That's possible of course, but there are a lot of issues you may face with IMHO SF> Imagine for ex a machine with PostgreSQL 8.3 installed. SF> I am asking how I must compile my source code and how to link, to build SF> my binary, to be sure that it's compatible with PostgreSQL 8.3, and SF> any in fact any existing PostgreSQL versions. SF> Can I for ex, use the V 9.3 headers and library on my dev platform SF> and then deliver this binary for any PostgreSQL version? SF> In other words, is the PostgreSQL client C API backward compatible? I'm not sure it is. SF> Today the lib is stamped with 5 (libpq.so.5), will this never change SF> in future versions? SF> Is there a way to detect dynamically the version of the PostgreSQL server? "SELECT version()" will do the trick using direct SQL. http://www.postgresql.org/docs/9.3/static/functions-info.html PQserverVersion - will help you if you need an integer representing the backend version. http://www.postgresql.org/docs/9.3/static/libpq-status.html SF> Thanks! SF> Seb SF> On 10/01/2013 02:28 PM, Pavel Golub wrote: >> Hello, Sebastien. >> >> You wrote: >> >> SF> Hi all, >> >> SF> We have a libpq client application written in C. >> >> SF> We want to deliver the software so that can it be used with different >> SF> PostgreSQL client versions, from 8.3 to 9.3 (and future versions). >> >> SF> So far, we build (compile and link) a binary with each major version >> SF> of PostgreSQL (8.3, 8.4, 9.0, 9.1, 9.2, 9.3) - in fact we have shared >> SF> libraries (database driver) for each PostgreSQL version. >> >> SF> Is this the proper way, or could we just compile/link with a given >> SF> version (9.3) and assume that it's backward compatible with any >> SF> prior version such as 8.3 ? >> >> Yes, you should use the latest client library. It's compatible with >> all prior versions. >> >> SF> Assuming that we could dynamically load the libpq.so client, search >> SF> for existing API symbols and only use them if present? >> >> SF> Is this risky? Do the C headers define C structures that are compatible >> SF> between newer and older versions? >> >> SF> I would expect some note about libpq compatibility policy here: >> >> SF> http://www.postgresql.org/docs/9.3/static/libpq-build.html >> >> SF> I can see that the lib version number of libpq.so.x.y changes >> SF> for each major version: >> >> SF> /opt3/dbs/pgs/9.2/lib/libpq.so -> libpq.so.5.5 >> SF> /opt3/dbs/pgs/9.2/lib/libpq.so.5 -> libpq.so.5.5 >> SF> /opt3/dbs/pgs/9.2/lib/libpq.so.5.5 >> SF> /opt3/dbs/pgs/9.3.0/lib/libpq.so -> libpq.so.5.6 >> SF> /opt3/dbs/pgs/9.3.0/lib/libpq.so.5 -> libpq.so.5.6 >> SF> /opt3/dbs/pgs/9.3.0/lib/libpq.so.5.6 >> >> SF> The binaries are dependent from libpq.so.5: >> >> SF> $ ldd -r dbmpgs92x.so >> SF> ... >> SF> libpq.so.5 => /opt3/dbs/pgs/9.2.3/lib/libpq.so.5 (0xb77bb000) >> SF> ... >> >> SF> What does this mean? >> >> SF> Theoritically, a binary linked in a 9.3 env can use le libpq.so version >> SF> of a prior version down to 8.2 ... (8.1 has libpq.so.4) >> >> SF> The main question is about C header compatibility: >> >> SF> - Compile + link with PostgreSQL client version X.Y.? >> SF> - What PostgreSQL client version can be used at runtime? >> >> SF> Thanks. >> SF> Seb >> >> >> >> >> -- With best wishes,Pavel mailto:pavel@gf.microolap.com
Sebastien FLAESCH wrote: > I am asking how I must compile my source code and how to link, to build > my binary, to be sure that it's compatible with PostgreSQL 8.3, and > any in fact any existing PostgreSQL versions. As an example, if your binary calls PQescapeLiteral() and your end user has libpq.so.5.1 which ships with PostgreSQL 8.3, then the dynamic link will fail because this version of libpq lacks this function. Not sure if that disqualifies it as backward compatible. It depends on your interpretation. Best regards, -- Daniel PostgreSQL-powered mail user agent and storage: http://www.manitou-mail.org
Hello, Sebastien. You wrote: SF> Thank you Pavel, I appreciate your help, but I would however prefer a clear SF> statement from the PostgreSQL C API developpers, written in the doc... ;-) Fare enough. :) SF> We have a commercial software: not sure we can deliver the PostgreSQL client SF> library in our packages, regarding open source license policy. We don't want SF> to make the sources of our product public. We have commercial software too. And we ship it with client library. It's all OK woth license. SF> Further, I don't like to ship other software libs in our product, typically SF> you want to use what is installed on the system. SF> If there is a bug in the PostgreSQL client lib, it's up to the user to install SF> the new lib that fixes the bug, without asking us to rebuild a package with SF> the new pgs lib. SF> Nothing new here, just traditional shared lib usage and dependency. SF> Yes, my instinct is also to use the C headers matching the lib version used SF> at runtime, we do this for now... SF> But some people think it's possible to provide a unique binary for all versions SF> of PostgreSQL, so I ask for a clear rule for the PostgreSQL C API. SF> Note also that we want to use the latest version, to get the latest features SF> with new C structures and defines... SF> So typically, we would compile with PostgreSQL 9.3 headers... SF> Seb SF> On 10/01/2013 04:38 PM, Pavel Golub wrote: >> Hello, Sebastien. >> >> You wrote: >> >> SF> Thank you Pavel, >> >> SF> On 10/01/2013 02:28 PM, Pavel Golub wrote: >> >> Yes, you should use the latest client library. It's compatible with >> >> all prior versions. >> >> SF> Just to be clear: >> >> SF> We deliver our product without any PostgreSQL lib included. >> >> Well, I prefer to deploy products with the latest lib included. Thus >> I'm absolutely sure in the environment used. >> >> SF> Our product installs beside an existing PostgreSQL install, typically >> SF> on an application server, where both PostgreSQL client and server are >> SF> installed in the same directory. >> >> That's possible of course, but there are a lot of issues you may face >> with IMHO >> >> SF> Imagine for ex a machine with PostgreSQL 8.3 installed. >> >> SF> I am asking how I must compile my source code and how to link, to build >> SF> my binary, to be sure that it's compatible with PostgreSQL 8.3, and >> SF> any in fact any existing PostgreSQL versions. >> >> SF> Can I for ex, use the V 9.3 headers and library on my dev platform >> SF> and then deliver this binary for any PostgreSQL version? >> >> SF> In other words, is the PostgreSQL client C API backward compatible? >> >> I'm not sure it is. >> >> >> SF> Today the lib is stamped with 5 (libpq.so.5), will this never change >> SF> in future versions? >> >> SF> Is there a way to detect dynamically the version of the PostgreSQL server? >> >> "SELECT version()" will do the trick using direct SQL. >> http://www.postgresql.org/docs/9.3/static/functions-info.html >> >> PQserverVersion - will help you if you need an integer representing the backend version. >> http://www.postgresql.org/docs/9.3/static/libpq-status.html >> >> >> >> SF> Thanks! >> SF> Seb >> >> >> SF> On 10/01/2013 02:28 PM, Pavel Golub wrote: >>>> Hello, Sebastien. >>>> >>>> You wrote: >>>> >>>> SF> Hi all, >>>> >>>> SF> We have a libpq client application written in C. >>>> >>>> SF> We want to deliver the software so that can it be used with different >>>> SF> PostgreSQL client versions, from 8.3 to 9.3 (and future versions). >>>> >>>> SF> So far, we build (compile and link) a binary with each major version >>>> SF> of PostgreSQL (8.3, 8.4, 9.0, 9.1, 9.2, 9.3) - in fact we have shared >>>> SF> libraries (database driver) for each PostgreSQL version. >>>> >>>> SF> Is this the proper way, or could we just compile/link with a given >>>> SF> version (9.3) and assume that it's backward compatible with any >>>> SF> prior version such as 8.3 ? >>>> >>>> Yes, you should use the latest client library. It's compatible with >>>> all prior versions. >>>> >>>> SF> Assuming that we could dynamically load the libpq.so client, search >>>> SF> for existing API symbols and only use them if present? >>>> >>>> SF> Is this risky? Do the C headers define C structures that are compatible >>>> SF> between newer and older versions? >>>> >>>> SF> I would expect some note about libpq compatibility policy here: >>>> >>>> SF> http://www.postgresql.org/docs/9.3/static/libpq-build.html >>>> >>>> SF> I can see that the lib version number of libpq.so.x.y changes >>>> SF> for each major version: >>>> >>>> SF> /opt3/dbs/pgs/9.2/lib/libpq.so -> libpq.so.5.5 >>>> SF> /opt3/dbs/pgs/9.2/lib/libpq.so.5 -> libpq.so.5.5 >>>> SF> /opt3/dbs/pgs/9.2/lib/libpq.so.5.5 >>>> SF> /opt3/dbs/pgs/9.3.0/lib/libpq.so -> libpq.so.5.6 >>>> SF> /opt3/dbs/pgs/9.3.0/lib/libpq.so.5 -> libpq.so.5.6 >>>> SF> /opt3/dbs/pgs/9.3.0/lib/libpq.so.5.6 >>>> >>>> SF> The binaries are dependent from libpq.so.5: >>>> >>>> SF> $ ldd -r dbmpgs92x.so >>>> SF> ... >>>> SF> libpq.so.5 => /opt3/dbs/pgs/9.2.3/lib/libpq.so.5 (0xb77bb000) >>>> SF> ... >>>> >>>> SF> What does this mean? >>>> >>>> SF> Theoritically, a binary linked in a 9.3 env can use le libpq.so version >>>> SF> of a prior version down to 8.2 ... (8.1 has libpq.so.4) >>>> >>>> SF> The main question is about C header compatibility: >>>> >>>> SF> - Compile + link with PostgreSQL client version X.Y.? >>>> SF> - What PostgreSQL client version can be used at runtime? >>>> >>>> SF> Thanks. >>>> SF> Seb >>>> >>>> >>>> >>>> >>>> >> >> >> >> >> >> -- With best wishes,Pavel mailto:pavel@gf.microolap.com
On 10/01/2013 08:50 PM, Daniel Verite wrote: > Sebastien FLAESCH wrote: > >> I am asking how I must compile my source code and how to link, to build >> my binary, to be sure that it's compatible with PostgreSQL 8.3, and >> any in fact any existing PostgreSQL versions. > > As an example, if your binary calls PQescapeLiteral() and your end user > has libpq.so.5.1 which ships with PostgreSQL 8.3, then the dynamic link > will fail because this version of libpq lacks this function. > > Not sure if that disqualifies it as backward compatible. It depends > on your interpretation. > > Best regards, Thank you Daniel, I understand you point. In fact we *could* manage to load dynamically (dlopen/dlsym) libpq.so, (without a specific .5 version number), then lookup for existing PQ* symbols, and use them only if they exist. So in the case you describe, if PQescapeLiteral() does not exist, we would not use it, assuming that the feature is not mandatory or can be workaround... But that's only possible if the PostgreSQL client C API header files are compatible with all versions. I mean, if I compile with PGS 9.3 (to get the latest C structures / API), it must be compatible with older client libraries. If structures such as PGconn, PGresult are not compatible, using an older client lib will potentially memory corruption and invalid/loss of data or crash the program. This cross-version compatibility must work for existing and future versions. I am conscious that this is a strong constraint for PostgreSQL. And I am not ASKING for it: We are just evaluating this solution. My instinct is that it's insane to load dynamically a libpq.so, to be used with a binary that was compiled with C header of a more recent version. But without a clear statement in the docs, I have no counter argument. Note that, Oracle OCI doc states that when your compile with OCI headers of 10g, your binary will work with 11g and 12c environments, without the need to recompile / relink. Here Oracle 11g / 12c is *backward* compatible with 10g... And Oracle 10g headers are *upward* compatible with future versions. See 5.5.2.3 and 5.6 of: http://docs.oracle.com/cd/E16655_01/server.121/e17642/app.htm#i1006731 But in our case we want to compile with recent .h headers (to use recent features) and use potentially older libs at runtime.. Thanks. Seb