Is the linking with -lodbc necessary? (--with-odbc)

Hello all!

Long story short: Is there a need to link psqlodbcw.so plugin against
libodbc.so?  Principal problem: That library provides ABI for applications
- not for plugins; at least it seem to be like that.

I tried to remove this linking by following tweak:

 | diff --git a/configure.ac b/configure.ac
 | index 5fb401e..5d75db3 100644
 | --- a/configure.ac
 | +++ b/configure.ac
 | @@ -65,7 +65,7 @@ fi
 |  # ODBC include and library
 |  #
 |
 | -if test "$ODBC_CONFIG" != ""; then
 | +if false; then
 |         if test "$with_iodbc" != no; then
 |                 ODBC_INCLUDE=`${ODBC_CONFIG} --cflags`
 |                 CPPFLAGS="$CPPFLAGS ${ODBC_INCLUDE}"

And both unixODBC and psqlodbcw.so communicates with each other correctly
at the first sight.

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

And now the long story.

The real problem comes now for 'isql' from unixODBC (and most probably
also for others) on s390x architecture in Linux.

As you know, unixODBC (== libodbc.so) uses lt_dlopen() (which just wraps
dlopen() in described scenario) for opening plugins.  And also, the 'isql'
tool is linked against libodbc.so library.

And now.  Lets look at one example API function now, e.g.
SQLAllocConnect() (but the same problem may be with any other API
function).  This function is called directly from 'isql' somewhere
- and on that place, there desired to call the SQLAllocConnect() function
provided by libodbc.so.

The 'isql' loads plugins through libodbc.so.
The psqlodbcw.so plugin does not provide SQLAllocConnect().  But during
loading of any plugin, libodbc.so tries to search for possible existence
of that function inside the plugin.  According to documented dlsym()
behavior - if the SQLAllocConntect() function is not defined in the
plugin, it tries to look more deeply in plugin's dependencies..  and it is
successful ~> because one of the dependencies is: "libodbc.so".  But
because libodbc.so don't wan't to use that "internal" method - only if the
method was defined in plugin directly, unixODBC guys prepared very ugly
workaround for that situation - they try to "blacklist" addresses of
internal methods into template_func[] array for later comparison with
return of lt_dlsym() output.

Now we have the problem: That template_func array is initialized (at
least) on s390x differently than on other platforms - the
template_func[0].dm_func is *CORRECTLY* initialized to the "internal"
SQLAllocConntect() function address.  But note!  It is different address
than also *CORRECT* address  returned from lt_dlsym() call later - so
detecting based on template_func[] is not successful (actually, the
function is located in memory at least twice).  You can look into unixODBC
into the file DriverManager/SQLConnect.c:

 582 /*
 583  * structure to contain the loaded lib entry points
 584  */
 585
 586 static struct driver_func  template_func[] =
 587 {
 588     /* 00 */ { SQL_API_SQLALLOCCONNECT,      "SQLAllocConnect", (void*)SQLAllocConnect },

That part of template_func[0] is initialized to the same SQLAllocConnect
address as it is in 'isql'.  Actually, if there was _no_ direct call to
SQLAllocConnect in 'isql' code, linker on s390 would assign to that place
the expected address (the same which would be later returned by dlsym()).

----

I don't know yet whether the linker behavior is correct or not (whether
such linker behavioral expectations are ok), I'll observe it in next few
days and file a bug against s390x linker.  Also, I'll try to ask for
better unixODBC api later, probably.

But firstly asking here:  is that linkage against libodbc.so needed?  I
can see that the blacklisting ugly hack in unixODBC is there just because
of plugins which are linked back against unixODBC.

Pavel