WINE not communicating with unixODBC

Open forum for end-user questions about Wine. Before asking questions, check out the Wiki as a first step.
Forum Rules
Locked
Razorwings18
Level 2
Level 2
Posts: 14
Joined: Fri Jan 08, 2010 3:19 pm

WINE not communicating with unixODBC

Post by Razorwings18 »

In a Debian Lenny I've installed WINE 1.1.35, unixODBC (plus unixODBC-bin and -dev), libmyodbc.


PROBLEM: Drivers (or DSNs) set up in unixODBC (via /etc/odbcinst.ini) do not work. Connection cannot be established from VB6 application, and drivers do not show in the WINE ODBC Control Panel -> Drivers tab.
Testing the connection using $ isql DSNNAME works perfectly.
Trying to connect (to MySQL of course) from WINE using the VB6 application either via a DSN or DSN-less connection gives the same result - error: "Provider cannot be found. It may not be properly installed"


NOTICE!!: Following the same steps for unixODBC, libmyodbc and setup procedure works FLAWLESSLY in the TESTING server. This is the PRODUCTION server.


STEPS FOLLOWED FOR INSTALLATION:
* Starting with a properly installed WINE 1.1.35 - apps in it are connecting to an MSSQL 2000 properly using OLE DB DSN-Less connections.
odbc32 is properly set to INTERNAL in the LIBRARIES tab of WINECFG.

1. Installed the current MySQL Connector/ODBC for Windows from WINE ($ wine msiexec /i mysql-connector-odbc-5.1.6-win32.msi)
2. Installed unixODBC, libmyodbc (unixODBC unixODBC-bin unixODBC-dev libmyodbc via Synaptic)
3. Set up the ODBC Driver within unixODBC
--- Edit /etc/odbcinst.ini

Code: Select all

[{MySQL ODBC 5.1 Driver}]
Description = {MySQL ODBC 5.1 Driver}
Driver = /usr/lib/odbc/libmyodbc.so
UsageCount = 1
4. Run the VB6 app. Code:

Code: Select all

Private oConn As ADODB.Connection
Private IPServidor As String
Private NombreBase As String

Private Sub Command1_Click()
    Dim oRS As ADODB.Recordset
    
    Set oConn = New ADODB.Connection
    
    oConn.CursorLocation = adUseClient
    oConn.Open "Driver={MySQL ODBC 5.1 Driver};" & _
           "Server=192.168.0.5;" & _
           "Port=3306;" & _
           "Option=131072;" & _
           "Stmt=;" & _
           "Database=mydatabase_dbo;" & _
           "Uid=root;" & _
           "Pwd=mypassword"
    
    Set oRS = New ADODB.Recordset

    oRS.Open "SELECT * FROM DENOMINACIONESLISTA", oConn
    MsgBox oRS.Fields(1)
    oRS.Close
    
    oConn.Close
    Set oRS = Nothing
    Set oConn = Nothing
End Sub

IT WORKS IN TESTING: As I said, following these steps in the TESTING server worked perfectly. Whatsmore, all unixODBC drivers I set up there for testing purposes (by changing the Driver name in odbcinst.ini) appear in the DRIVERS tab of the WINE ODBC Control Panel ($~>wine control). This does not happen in PRODUCTION.
The only apparent difference between TESTING and PRODUCTION is that TESTING is i386 while PRODUCTION is AMD64. Other than that, TESTING has FreeTDS installed (from back when I was trying to use unixODBC to connect to MSSQL) while PRODUCTION doesn't.
All other libraries seem to be the same version in both servers.

When the app is executed via WINE, the following debug information is displayed in PRODUCTION, different from what is displayed in TESTING:

Code: Select all

err:ole:apartment_getclassobject DllGetClassObject returned error 0x80004005
err:ole:create_server class {c8b522cb-5cf3-11ce-ade5-00aa0044773d} not registered
fixme:ole:CoGetClassObject CLSCTX_REMOTE_SERVER not supported
err:ole:CoGetClassObject no class object {c8b522cb-5cf3-11ce-ade5-00aa0044773d} could be created for context 0x17

MY THOUGHTS: I really feel this is a problem with WINE having problems linking to unixODBC. I know it supposedly uses /usr/lib/libodbc.so to do this. I have checked that the file is in place (it's actually a link to libodbc.so.1.0.0 ) and for differences with TESTING. I found none.


Any help will be appreciated. I've been scratching my head so hard, I've reached the cortex.

(Please do not suggest I update WINE - First, because it IS working fine on TESTING under 1.1.35, and more importantly, because PRODUCTION is working perfectly as it is. I don't want to risk things going south on me over this.)
hellork
Level 3
Level 3
Posts: 82
Joined: Thu Mar 27, 2008 7:13 pm

Re: WINE not communicating with unixODBC

Post by hellork »

The 32-bit /usr/lib/libodbc.so is not interacting with the 64 bit database. Can any 32-bit linux applications using that lib connect to the 64-bit PRODUCTION database? See, I don't know if a 32 bit lib can access the 64-bit database at all--unless it's over a network.
If it is on the same machine, can the 64 bit PRODUCTION database be configured as a server to be accessed over the network loopback address?
Razorwings18
Level 2
Level 2
Posts: 14
Joined: Fri Jan 08, 2010 3:19 pm

Post by Razorwings18 »

Thanks for the reply.

If there were a problem with libodbc.so communicating with the database, my guess is I shouldn't even be able to connect to any database through unixODBC. But as I said, I can $ isql connect to any database, including the one in PRODUCTION just fine.

That is why my guess is the problem is with WINE not recognizing unixODBC somehow.

I can also $ isql connect from other Debian machines to the PRODUCTION database, and can even connect to it from WINE applications run in those machines via WINE -> unixODBC.
Razorwings18
Level 2
Level 2
Posts: 14
Joined: Fri Jan 08, 2010 3:19 pm

Post by Razorwings18 »

UPDATE!

hellork, it seems you were pointed in the right direction. Today I run a $ WINEDEBUG=odbc wine myprogram and got the following output when trying to connect through ODBC.

warn:odbc:ODBC_LoadDriverManager failed to open library "/usr/lib/libodbc.so.1.0.0": /usr/lib/libodbc.so.1.0.0: wrong ELF class: ELFCLASS64

Context:

Code: Select all

err:ole:CoGetClassObject class {6c736db1-bd94-11d0-8a23-00aa00b58e10} not registered
err:ole:CoGetClassObject no class object {6c736db1-bd94-11d0-8a23-00aa00b58e10} could be created for context 0x1
trace:odbc:DllMain Initializing or Finalizing proxy ODBC: 0x7db80000,1,(nil)
trace:odbc:DllMain Loading ODBC...
trace:odbc:ODBC_LoadDriverManager 
warn:odbc:ODBC_LoadDriverManager failed to open library "/usr/lib/libodbc.so.1.0.0": /usr/lib/libodbc.so.1.0.0: wrong ELF class: ELFCLASS64
trace:odbc:SQLAllocEnv 
trace:odbc:SQLAllocEnv Not ready
err:ole:apartment_getclassobject DllGetClassObject returned error 0x80004005
err:ole:create_server class {c8b522cb-5cf3-11ce-ade5-00aa0044773d} not registered
fixme:ole:CoGetClassObject CLSCTX_REMOTE_SERVER not supported
err:ole:CoGetClassObject no class object {c8b522cb-5cf3-11ce-ade5-00aa0044773d} could be created for context 0x17
trace:odbc:DllMain Initializing or Finalizing proxy ODBC: 0x7db80000,0,(nil)
trace:odbc:DllMain Unloading ODBC...
I am guessing what that means is that libodbc.so.1.0.0 is 64-bit, but WINE needs it to be 32-bit?

At least now I know what the problem is, but I don't know where to go from here. Any ideas? Has anyone successfully used WINE+unixODBC in an AMD64 system?
felix
Level 2
Level 2
Posts: 45
Joined: Thu Feb 28, 2008 10:04 am

WINE not communicating with unixODBC

Post by felix »

On Tue, Apr 20, 2010 at 02:49:48PM -0500, Razorwings18 wrote:
UPDATE!

hellork, it seems you were pointed in the right direction.
Today I run a $ WINEDEBUG=odbc wine myprogram and got the
following output when trying to connect through ODBC.

warn:odbc:ODBC_LoadDriverManager failed to open library
"/usr/lib/libodbc.so.1.0.0": /usr/lib/libodbc.so.1.0.0: wrong
ELF class: ELFCLASS64
<snipage>
I am guessing what that means is that libodbc.so.1.0.0 is
64-bit, but WINE needs it to be 32-bit?

At least now I know what the problem is, but I don't know where
to go from here. Any ideas? Has anyone successfully used
WINE+unixODBC in an AMD64 system?
I believe you need to install the 'ia32-libs' package, or at least
that's what it is called on Ubuntu 8.04. I imagine that it's the same
on Debian Lenny, but I can't confirm.

Try 'apt-get install ia32-libs' on the command line, that should install
a number of 32bit libraries, including /usr/lib32/libodbc.so.1.0.0,
although I have to admit some surprise that wine is working at all
if this package isn't installed.

In fact a quick 'apt-cache show wine' output includes the following:
Depends: binfmt-support (>= 1.1.2), ia32-libs (>= 1.6)

So I would have thought that the correct 32bit odbc library would have
already been installed on your system.


Checking the wine_1.1.35~winehq1-1_amd64.deb package up on winehq, it
looks to me like it's built to use the ia32 libraries. Perhaps you
installed the wine_1.1.35~winehq1-1_i386.deb package on the amd64
system, and that doesn't know about the ia32-libs package, and thus that
was installed on your system by default?


--
Darragh

"Nothing is foolproof to a sufficiently talented fool."
Razorwings18
Level 2
Level 2
Posts: 14
Joined: Fri Jan 08, 2010 3:19 pm

Post by Razorwings18 »

Thanks felix, that really helped me.

Sure enough, ia32-libs was installed, but WINE wasn't using its libodbc.so.1.0.0. I pointed WINE to use ia32-libs' library and now the ODBC driver is properly "seen" by WINE.

Now the problem is that the ODBC driver for MySQL, libmyodbc.so, is also installed in its AMD64 version, and that is giving me a wrong ELF class error now.

I'll try to install an i386 version an see what happens, then post the results.
Razorwings18
Level 2
Level 2
Posts: 14
Joined: Fri Jan 08, 2010 3:19 pm

Post by Razorwings18 »

SUCCESS! :D

I used the i386 libmyodbc.so and pointed odbcinst.ini to it in my driver. This still gave me an error with one of libmyodbc.so's dependencies, libmysqlclient_r.so.15, which is part of the libmysqlclient15off package.

So I downloaded that package as well in its i386 version, copied its binary contents to a folder, and pointed to that folder using export LD_LIBRARY_PATH=thatfolder so libmyodbc.so could locate it.

Then I tried my WINE application and it successfully connected and returned a record!


SO TO SUM UP, AFTER A REGULAR unixODBC -> WINE INSTALL, WHAT YOU SHOULD DO TO GET IT WORKING UNDER AMD64 IS:
- Install package ia32-libs (it should be already installed with WINE, though)
- Edit /etc/bash.bashrc
- Add the following line at the end of the file:
export LIB_ODBC_DRIVER_MANAGER=/emul/ia32-linux/usr/lib/libodbc.so.1.0.0

- Download the i386 libmyodbc package
- Extract file libmyodbc.so
- Rename it to something like libmyodbc-i368.so
- Copy it to /usr/lib/odbc
- Edit /etc/odbcinst.ini, and modify the DRIVER line of your driver so it points to the i386 libmyodbc, i.e.:
Driver = /usr/lib/odbc/libmyodbc-i386.so
- Save odbcinst.ini

- Download the i386libmysqlclient15off package
- Extract library files (.so) and symlinks to a folder of your choice, i.e.: /usr/lib/odbc/libmysqlclient-i386
- Edit /etc/bash.bashrc
- At the end of the file, add the following line:
export LD_LIBRARY_PATH=/usr/lib/odbc/libmysqlclient-i386
- Save bash.bashrc and restart

Now the driver should work from WINE in AMD64.

Thanks felix and hellork, I couldn't have got this working without your help.
Razorwings18
Level 2
Level 2
Posts: 14
Joined: Fri Jan 08, 2010 3:19 pm

Post by Razorwings18 »

Sometimes Linux cracks me up :lol:

Just writing this to have it documented in case someone tries to do what I did.

I could execute my application and connect flawlessly to the MySQL database via MyODBC/unixODBC. But it turns out if I created a shortcut on the Desktop and tried to run the app from there, it wouldn't connect to the database!

It turns out when ran from a shortcut, the exports environment variables are not considered by Gnome!

So if you want to create a "shortcut" on your Desktop to run the application on AMD64, you have to actually create a script file instead that looks like this:

Code: Select all

export LD_LIBRARY_PATH=/usr/lib/odbc/libmysqlclient-i386
export LIB_ODBC_DRIVER_MANAGER=/emul/ia32-linux/usr/lib/libodbc.so.1.0.0
cd /home/username/.wine/drive_c/myapp/
wine myapp.exe
And then configure it to run with SH.
vitamin
Moderator
Moderator
Posts: 6605
Joined: Sat Feb 23, 2008 2:29 pm

Post by vitamin »

Razorwings18 wrote:It turns out when ran from a shortcut, the exports environment variables are not considered by Gnome!
That depends where you put them. If you just ran some "export foo" in xterm then of course gnome won't be affected. You need to put them into ~/.bashrc (or other file if you using other shell).
Razorwings18
Level 2
Level 2
Posts: 14
Joined: Fri Jan 08, 2010 3:19 pm

Post by Razorwings18 »

Of course.

It's in /etc/bash.bashrc , and when opening a terminal (under the same user the GNOME desktop is in), the environment variables are there.

Is there anywhere else these variables should be declared for them to be considered by the GNOME Desktop? (specifically under Debian Lenny in my case)
Locked