I think the only place for 32-bit these days is
for netbooks and embedded stuff.
Most computers sold today (desktops and laptops) run 32-bit OSes. It is
actually still rare to find 64-bit OSes installed. We focused on
Windows first because we have more customers who run Windows than Linux
(by far), and the types of applications which we believe will get the
most benefit from a 64-bit LabVIEW include drivers which we do not
support on Linux. We do hope to expand our 64-bit support to other
platforms in the future, though.
In the meantime there
are various approaches to solving your problem. One is to install or
build a 32-bit .so to do what you want to do. I don't know much about
unixODBC, but the only DBMS I've used on Linux (MySQL) actually uses a
TCP/IP interface, so even the command-line client is really just making
a network connection to the server. If that's the case then a 32-bit .so
should work just as well, even if connecting to a 64-bit server process.
Another
approach (much harder) is to do what Firefox did to support 32-bit
plugins in 64-bit Firefox: make a 32-bit .so that launches a 64-bit
process which loads the 64-bit .so and communicates with your 32-bit
.so using any form of inter-process communication you want (file I/O,
named pipes,TCP/IP, etc.). It's not ideal, but it works.
You
could also skip the 32-bit .so and implement the same logic in LabVIEW
itself, or you can figure out how myODBC works under the hood to
communicate with the server and implement that protocol directly in
LabVIEW.
None of those are fun to implement, but they can be done.
Thank you.
