minimal driver config under Linux and how to get rid of dblgen8.res
Marten Lehmann
I was looking for a very simple way to connect to as ASA8 database using
unixODBC under Linux because I don't want to do a complete Sybase client
installation, but I want just to copy the absoletely requirement libs.
This is my result:
I included /opt/sybase/SYBSsa8/lib in the ldconfig paths.
My odbc.ini looks like this:
[readonly]
Userid = readonly
Password = xxxxx
Driver = /opt/sybase/SYBSsa8/lib/libdbodbc8_r.so
ServerName = mydb
CommLinks = tcpip(host=1.2.3.4;DoBroadcast=None)
Connecting with "isql readonly -v" works successfully.
These are the libraries that are required:
/opt/sybase/SYBSsa8/lib:
dbodbc8_r.so
dbodbc8_r.so.1
dbodbc8.so
dbodbc8.so.1
libdbodbc8_r.so
libdbodbc8.so
libdbtasks8_r.so
libdbtasks8_r.so.1
libdbtasks8.so
libdbtasks8.so.1
But thats not all to get in running. Now there is this strange binary
file named "dblgen8.res" in "/opt/sybase/SYBSsa8/res".
When I remove it I always get this error when I try to connect:
[IM004][unixODBC][Driver Manager]Driver's SQLAllocHandle on
SQL_HANDLE_HENV failed
[ISQL]ERROR: Could not SQLConnect
As soon as I'm putting dblgen8.res back into the directory, connecting
works fine again.
What is this file dblgen8.res for? Can I get rid of it somehow? The
Sybase ODBC drivers only establish a connection when the current working
dir is /opt/sybase/SYBSsa8 or when I set $ASANY to /opt/sybase/SYBSsa8.
But the first way is not an option and the second is problematic too,
since some services using chroot() to increase security remove existing
environment variables and I simply don't want to set an env variable in
every script and application server that needs to connect to a sybase
database.
How can I avoid this dblgen8.res? Do I have to pass additional
parameters when connecting?
Kind regards
Marten
John Smirnios [Sybase]
error messages and strings generated by SQL Anywhere software. It is
absolutely required to do pretty much anything. It is opened as a
regular file so if you allocate your ODBC environment before you chroot,
you might be okay since the file handle will stay open. If you only
attempt to use SQLAnywhere after chroot, the file will need be be
accessible somewhere within the new root and SQL Anywhere is going to
need to know how to find it (via env variable, etc).
-john.
--
John Smirnios
Senior Software Developer
iAnywhere Solutions Engineering
Whitepapers, TechDocs, bug fixes are all available through the iAnywhere
Developer Community at http://www.ianywhere.com/developer
Marten Lehmann
> The .res file is the language resource file -- it contains all of the
> error messages and strings generated by SQL Anywhere software. It is
> absolutely required to do pretty much anything.
I have nothing against the file in general, I'm just annoyed about the
setenv thing. I found a note at
http://manuals.sybase.com/onlinebooks/group-sas/awg0800e/dbpgen8/@Generic__BookTextView/31955%3Bpt=31027/*
"The following table shows the files needed for a working Adaptive
Server Anywhere ODBC driver. These files should be placed in a single
directory."
Under "UNIX", dblgen8.res is mentioned there. But simply putting
dblgen8.res into the same directory as libdbodbc8.so etc. does not work.
Where else can I put it so I don't have to set environment variables? I
just want to put libraries into lets say /usr/lib/sybase, include this
dir in ldconfig and be able to use them. Any ideas?
Kind regards
Marten
John Smirnios [Sybase]
loader where to find them. For SQLAnywhere to find things, you'll have
to tell SQLAnywhere where to find them. That said, SQLAnywhere looks in
lots of different places for files. The doc should list the set of
directories where we will look but I have listed below what I glean from
a quick look at the code. Another method that is likely to be most
accurate is just to use strace to find out where the software is
looking. Notice that if you use chroot, many (all?) of the places we
search pretty much become invalid because the paths are no longer
meaningful. When you chroot(), something has to give. You need to update
the PATH variable and/or other variables that programs need.
For each of the following directories (in v8):
. (provided current directory is not /)
same directory as the executable (if known)
$SYBASE
each component of $PATH
each component of $LD_LIBRARY_PATH
$ASDIR
look in each of:
the specified directory
..
tix/
../tix/
res/
../res/
scripts/
../scripts/
bin/
../bin/
lib/
../lib/
java/
../java/
shared/
../shared/
-john.
--
John Smirnios
Senior Software Developer
iAnywhere Solutions Engineering
Whitepapers, TechDocs, bug fixes are all available through the iAnywhere
Developer Community at http://www.ianywhere.com/developer
Marten Lehmann
> Another method that is likely to be most
> accurate is just to use strace to find out where the software is
> looking.
yes, that list is pretty long:
/bin64/dblgen9.res
./bin64/dblgen9.res
../bin64/dblgen9.res
bin64/dblgen9.res
/bin/../bin64/dblgen9.res
/bin/bin64/dblgen9.res
/bin/../dblgen9.res
/bin/dblgen9.res
/bin/../java/dblgen9.res
/bin/java/dblgen9.res
/bin/../lib64/dblgen9.res
/bin/lib64/dblgen9.res
/bin/../res/dblgen9.res
/bin/res/dblgen9.res
/bin/../scripts/dblgen9.res
/bin/scripts/dblgen9.res
/bin/../shared/dblgen9.res
/bin/shared/dblgen9.res
/bin/../tix/dblgen9.res
/bin/tix/dblgen9.res
/dblgen9.res
./dblgen9.res
../dblgen9.res
dblgen9.res
/java/dblgen9.res
./java/dblgen9.res
../java/dblgen9.res
java/dblgen9.res
/lib64/dblgen9.res
./lib64/dblgen9.res
../lib64/dblgen9.res
lib64/dblgen9.res
/res/dblgen9.res
./res/dblgen9.res
../res/dblgen9.res
res/dblgen9.res
/root/bin/../bin64/dblgen9.res
/root/bin/bin64/dblgen9.res
/root/bin/../dblgen9.res
/root/bin/dblgen9.res
/root/bin/../java/dblgen9.res
/root/bin/java/dblgen9.res
/root/bin/../lib64/dblgen9.res
/root/bin/lib64/dblgen9.res
/root/bin/../res/dblgen9.res
/root/bin/res/dblgen9.res
/root/bin/../scripts/dblgen9.res
/root/bin/scripts/dblgen9.res
/root/bin/../shared/dblgen9.res
/root/bin/shared/dblgen9.res
/root/bin/../tix/dblgen9.res
/root/bin/tix/dblgen9.res
/root/dblgen9.res
/sbin/../bin64/dblgen9.res
/sbin/bin64/dblgen9.res
/sbin/../dblgen9.res
/sbin/dblgen9.res
/sbin/../java/dblgen9.res
/sbin/java/dblgen9.res
/sbin/../lib64/dblgen9.res
/sbin/lib64/dblgen9.res
/sbin/../res/dblgen9.res
/sbin/res/dblgen9.res
/sbin/../scripts/dblgen9.res
/sbin/scripts/dblgen9.res
/sbin/../shared/dblgen9.res
/sbin/shared/dblgen9.res
/sbin/../tix/dblgen9.res
/sbin/tix/dblgen9.res
/scripts/dblgen9.res
./scripts/dblgen9.res
../scripts/dblgen9.res
scripts/dblgen9.res
/../shared/dblgen9.res
/shared/dblgen9.res
./../shared/dblgen9.res
./shared/dblgen9.res
../shared/dblgen9.res
shared/dblgen9.res
/tix/dblgen9.res
./tix/dblgen9.res
../tix/dblgen9.res
tix/dblgen9.res
/usr/bin/../bin64/dblgen9.res
/usr/bin/bin64/dblgen9.res
/usr/bin/../dblgen9.res
/usr/bin/dblgen9.res
/usr/bin/../java/dblgen9.res
/usr/bin/java/dblgen9.res
/usr/bin/../lib64/dblgen9.res
/usr/bin/lib64/dblgen9.res
/usr/bin/../res/dblgen9.res
/usr/bin/res/dblgen9.res
/usr/bin/../scripts/dblgen9.res
/usr/bin/scripts/dblgen9.res
/usr/bin/../shared/dblgen9.res
/usr/bin/shared/dblgen9.res
/usr/bin/../tix/dblgen9.res
/usr/bin/tix/dblgen9.res
/usr/kerberos/bin/../bin64/dblgen9.res
/usr/kerberos/bin/bin64/dblgen9.res
/usr/kerberos/bin/../dblgen9.res
/usr/kerberos/bin/dblgen9.res
/usr/kerberos/bin/../java/dblgen9.res
/usr/kerberos/bin/java/dblgen9.res
/usr/kerberos/bin/../lib64/dblgen9.res
/usr/kerberos/bin/lib64/dblgen9.res
/usr/kerberos/bin/../res/dblgen9.res
/usr/kerberos/bin/res/dblgen9.res
/usr/kerberos/bin/../scripts/dblgen9.res
/usr/kerberos/bin/scripts/dblgen9.res
/usr/kerberos/bin/../shared/dblgen9.res
/usr/kerberos/bin/shared/dblgen9.res
/usr/kerberos/bin/../tix/dblgen9.res
/usr/kerberos/bin/tix/dblgen9.res
/usr/kerberos/sbin/../bin64/dblgen9.res
/usr/kerberos/sbin/bin64/dblgen9.res
/usr/kerberos/sbin/../dblgen9.res
/usr/kerberos/sbin/dblgen9.res
/usr/kerberos/sbin/../java/dblgen9.res
/usr/kerberos/sbin/java/dblgen9.res
/usr/kerberos/sbin/../lib64/dblgen9.res
/usr/kerberos/sbin/lib64/dblgen9.res
/usr/kerberos/sbin/../res/dblgen9.res
/usr/kerberos/sbin/res/dblgen9.res
/usr/kerberos/sbin/../scripts/dblgen9.res
/usr/kerberos/sbin/scripts/dblgen9.res
/usr/kerberos/sbin/../shared/dblgen9.res
/usr/kerberos/sbin/shared/dblgen9.res
/usr/kerberos/sbin/../tix/dblgen9.res
/usr/kerberos/sbin/tix/dblgen9.res
/usr/local/bin/../bin64/dblgen9.res
/usr/local/bin/bin64/dblgen9.res
/usr/local/bin/../dblgen9.res
/usr/local/bin/dblgen9.res
/usr/local/bin/../java/dblgen9.res
/usr/local/bin/java/dblgen9.res
/usr/local/bin/../lib64/dblgen9.res
/usr/local/bin/lib64/dblgen9.res
/usr/local/bin/../res/dblgen9.res
/usr/local/bin/res/dblgen9.res
/usr/local/bin/../scripts/dblgen9.res
/usr/local/bin/scripts/dblgen9.res
/usr/local/bin/../shared/dblgen9.res
/usr/local/bin/shared/dblgen9.res
/usr/local/bin/../tix/dblgen9.res
/usr/local/bin/tix/dblgen9.res
/usr/local/sbin/../bin64/dblgen9.res
/usr/local/sbin/bin64/dblgen9.res
/usr/local/sbin/../dblgen9.res
/usr/local/sbin/dblgen9.res
/usr/local/sbin/../java/dblgen9.res
/usr/local/sbin/java/dblgen9.res
/usr/local/sbin/../lib64/dblgen9.res
/usr/local/sbin/lib64/dblgen9.res
/usr/local/sbin/../res/dblgen9.res
/usr/local/sbin/res/dblgen9.res
/usr/local/sbin/../scripts/dblgen9.res
/usr/local/sbin/scripts/dblgen9.res
/usr/local/sbin/../shared/dblgen9.res
/usr/local/sbin/shared/dblgen9.res
/usr/local/sbin/../tix/dblgen9.res
/usr/local/sbin/tix/dblgen9.res
/usr/sbin/../bin64/dblgen9.res
/usr/sbin/bin64/dblgen9.res
/usr/sbin/../dblgen9.res
/usr/sbin/dblgen9.res
/usr/sbin/../java/dblgen9.res
/usr/sbin/java/dblgen9.res
/usr/sbin/../lib64/dblgen9.res
/usr/sbin/lib64/dblgen9.res
/usr/sbin/../res/dblgen9.res
/usr/sbin/res/dblgen9.res
/usr/sbin/../scripts/dblgen9.res
/usr/sbin/scripts/dblgen9.res
/usr/sbin/../shared/dblgen9.res
/usr/sbin/shared/dblgen9.res
/usr/sbin/../tix/dblgen9.res
/usr/sbin/tix/dblgen9.res
> For each of the following directories (in v8):
> . (provided current directory is not /)
> same directory as the executable (if known)
> $SYBASE
> each component of $PATH
> each component of $LD_LIBRARY_PATH
> $ASDIR
That's the reason why the list is so extremely long. But following the
Linux Standard Base, all of these locations are wrong. The only
directory of this list confirming partially is /lib64. But even this
directory is reserved for system internal libs. External libraries
belong to /usr/lib64/<extension-name>/... And after all: Why does that
For me it seems, that Sybase wants to support Linux, but doesn't want to
follow the system standards. So it does everything within a sort of
sandbox/island. This makes it hard to integrate e.g. client libs. I
don't know of any other big database vendor like PostgreSQL, Informics,
Mysql etc. that requires environment variables to be set. Another bad
example is Oracle.
Why did Sybase manage to include everything for the JDBC driver within a
single .jar file, while it scatters the C libs and dependencies through
dozends of files and directories?
Kind regards
Marten
Ray Ruvinskiy [Sybase iAnywhere]
Where do you think SQL Anywhere should be looking for the .res file? It
is possible that we've overlooked an LSB-sanctioned location. If so, we
could add it to a future version of SQL Anywhere. We can't change 8.0.2,
though.
The SQL Anywhere default installation directory is under /opt.
Generally, software packages that are installed under /opt have a
self-contained directory structure similar to SQL Anywhere's.
The SQL Anywhere install does not scatter libraries and dependencies in
dozens of locations. 32-bit libraries are installed under $SQLANY/lib32,
while 64-bit libraries are installed under $SQLANY/lib64. The resources
file, which is the matter at hand here, is placed inside $SQLANY/res.
(Prior to version 10, the environment variable was $ASANY instead of
$SQLANY).
However, when attempting to locate files, we do look in many locations,
in an attempt to make a strong effort to find files that exist without
relying on either the SQLANY/ASANY environment variables or
PATH/LD_LIBRARY_PATH. In version 11, we became more selective about
where to look for files. For instance, we no longer look for files in
the PATH or the LD_LIBRARY_PATH.
Ray
Ray Ruvinskiy [Sybase iAnywhere]
*resource* files in the PATH or the LD_LIBRARY_PATH." (We certainly
still look there for libraries and executables.)
Ray
Marten Lehmann
> Where do you think SQL Anywhere should be looking for the .res file?
I think this .res file simply doesn't fit into the typical
ldconfig/dlopen library model. No matter which directory SQL Anywhere
was installed to, the .so libs should work completely on its own. All I
want to do to make a librabry work is to put its path to ld.so.conf, run
ldconfig and use it. No setting of env-variables. The content of .res is
not that big, so maybe this should just be incorporated into the client
libs (libdbodbc & co.). Then, if dlopen of dbodbc succeeds, everything
else will succeed, too, no runtime errors due to missing .res files any
longer. And btw.: Maybe libdbodbc.so should be renamed to libasaodbc.so
or similar, since dbodbc is so generic, that naming conflicts with other
odbc-libs occur.
Kind regards
Marten