[Cuis-dev] ODBC error

Jon Raiford raiford at labware.com
Thu Oct 24 10:19:38 PDT 2024


I had a quick look at this on my M1 MBP.

I did the following:

* git clone Cuis-Smalltalk-Dev
* git clone Cuis DatabaseSupport
* modified the launch script as you described below
* run the script: ./RunCuisOnMacTerminal.sh
* open a workspace
* doIt: Feature require: ‘ODBC’
* printIt: ODBCConnection new sqlAllocEnv   => a SQLHENV .

If I remove the DYLD_LIBRARY_PATH from the launch script then I get the module not found error.

Based on your info below, your homebrew lib path is /usr/local/lib and libodbc.dylib exists in the directory, which is the moduleName defined in ODBCLibrary class>>moduleName.

That all looks correct.

What do you get if you run this from the command line?

%  otool -L /usr/local/lib/libodbc.dylib


Jon

From: Mark Volkmann <r.mark.volkmann at gmail.com>
Date: Tuesday, October 22, 2024 at 7:32 PM
To: Jon Raiford <raiford at labware.com>
Cc: Discussion of Cuis Smalltalk <cuis-dev at lists.cuis.st>
Subject: Re: [Cuis-dev] ODBC error
See my replies inline below.

On Tue, Oct 22, 2024 at 3:56 PM Jon Raiford <raiford at labware.com<mailto:raiford at labware.com>> wrote:
What exactly do you mean by not working? Is it not able to open the shared library? Or it is not able to connect to a database? The first thing that happens is allocating the environment by either calling SQLAllocHandle() (current versions of ODBC) or SQLAllocEnv() (old versions of ODBC).

I'll describe what I have tried below, but I'm not claiming that I have finished investigating this. It's just my progress so far.

1. Run the Homebrew command "brew install unixodbc" to install the ODBC dynamic library.


That gives me the following files in /usr/local/lib:


libodbc.2.dylib
libodbc.a
libodbc.dylib
libodbccr.2.dylib
libodbccr.a
libodbccr.dylib
libodbcinst.2.dylib
libodbcinst.a
libodbcinst.dylib


2. Run the command "brew install sqliteodbc" to install the SQLite-specific shared library.


That gives me the file /usr/local/lib/libsqlite3odbc.dylib
I'm not certain I need this file, but I reference it below.


3. Create the file /usr/local/etc/odbc.ini containing the following which refers to a dynamic library that exists and SQLite database file that exists.

[TodoDSN]
Description = SQLite ODBC Driver
Driver = /usr/local/lib/libsqlite3odbc.dylib
Database = /Users/volkmannm/Documents/dev/lang/smalltalk/Cuis-Smalltalk-Dev-UserFiles/todos.db
Timeout = 2000
4. Clone the GitHub repository at https://github.com/Cuis-Smalltalk/DatabaseSupport.git<https://github.com/Cuis-Smalltalk/DatabaseSupport.git> into the same directory that holds the Cuis-Smalltalk-Dev directory.

5. Change the file RunCuisOnMacTerminal.sh to the following:

export DYLD_LIBRARY_PATH="$(brew --prefix)/lib:${DYLD_LIBRARY_PATH}"
./CuisVM.app/Contents/MacOS/Squeak CuisImage/Cuis?.?-????.image -u

5. Run that script.

6. Open a "File List", navigate to the DatabaseSupport directory, select ODBC.pck.st<http://ODBC.pck.st>, and click "install package".

7. Open a Workspace and evaluate the following:

conn := ODBCConnection dsn: 'TodoDSN' user: '' password: ''.
This gives the error "External module not found".  See the attached screenshot.

I don’t have an easy way to test that old ODBC code at the moment, but it should be easy enough to find the library class. It is a subclass of ExternalLibrary. From there you can find the alloc call and walk back through senders to figure out how it is called. From there you can see the order things are called.

I only see one subclass of ExternalLibrary and it is ODBCLibrary. I think the alloc call you are referring to is the one in the attached screenshot, but I haven't been able to determine which external module it can't find. The line that fails is:

<cdecl: int16 'SQLAllocEnv' (SQLHENV*)>

One annoying thing to note is that you cannot use the debugger to step through an FFI call. It will always say there is an invalid module or something like that. I’ve spoken to Eliot about this and we should be able to get it fixed at some point. But for now just put a self halt after the call and then look at the return code.

Arranging a call would be difficult at the moment. I’m already burning the candle at both ends so not much time unfortunately.

I understand.

--
R. Mark Volkmann
Object Computing, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20241024/e760d30e/attachment-0001.htm>


More information about the Cuis-dev mailing list