Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | ODBC with libiodbc (ODBC lib on UNIX) doesn't work | ||||||
---|---|---|---|---|---|---|---|
Product: | Base | Reporter: | issues@www <issues> | ||||
Component: | code | Assignee: | ocke.janssen | ||||
Status: | CLOSED FIXED | QA Contact: | issues@www <issues> | ||||
Severity: | Trivial | ||||||
Priority: | P4 | CC: | issues | ||||
Version: | 619 | ||||||
Target Milestone: | --- | ||||||
Hardware: | PC | ||||||
OS: | Linux, all | ||||||
Issue Type: | DEFECT | Latest Confirmation in: | --- | ||||
Developer Difficulty: | --- | ||||||
Attachments: |
|
Description
issues@www
2001-02-22 19:23:18 UTC
Changing Priority to P4, it's not that important.... I've downloaded the OO static 619 source, and traced the library loading to a function in sal/osl/unx/module.c, line 301: if (pszModuleName) { #ifndef NO_DL_FUNCTIONS void* pLib = dlopen(pszModuleName, rtld_mode ); #ifdef DEBUG if( ! pLib ) fprintf( stderr, "osl_loadModule: cannot load module %s pszModuleName, dlerror() ); #endif return ((oslModule)pLib); #endif } return NULL; Is there a precompiled build for my architecture with the DEBUG flag *enabled* available? It would be enlightening to see what library name is there after the various string conversion routines that precede this, and what kind of error dlerror() gives. I'll also try doing the dlopen with the libodbc in one a test program and see whether it fails too. I hope this helps you somewhat! -Malte No, we don't have debug versions of libraries available by default. For one thing, a debug version of the whole OpenOffice is so big you are just going to run out of memory unless you have it on the order of ~ 2GB or so. If you downloaded teh source you can recompile the library as debug by following all the build instructions untill the point twhere you would do a dmake (after bootstrap). Then do: cd sal rm -rf $INPATH dmake debug="true" the library built will be with bith debug defined to true and with debug symbols so you will be able to see where and what goes amiss. Thanks for your comments Sander, I will try to free some (*cough*) hard drive space and compile the beastie :), though this could take a day or two... In the meantime, I've written a small test program, and compiled with gcc-2.95.3 and the -ldl flag, it works as it should: --cut-- #include <stdio.h> #include <dlfcn.h> int main() { void *pLib = NULL; printf("Now attempting to link to libodbc.so...\n"); pLib = dlopen("libodbc.so", RTLD_NOW); if (pLib == NULL) /* should be equivalent to: if (!pLib) */ printf("cannot load libodbc.so with error:\n%s\n", dlerror() ); else { printf("loading libodbc.so succeeded!\n"); printf("dlclose gave back: %d\n", dlclose(pLib)); } return; } --cut-- The output: -- mcornils@wh36-b407:/usr/home/mcornils/dev/c$ ./a.out Now attempting to link to libodbc.so... loading libodbc.so succeeded! dlclose gave back: 0 mcornils@wh36-b407:/usr/home/mcornils/dev/c$ -- hmm, strange. Well, I hope I can use the output from the debug build, otherwise I'll have to dig deeper in /dba/dbaccess/source/ui/dlg, especially the various OOdbc* classes... Thanks so far! -Malte the wise thing probably is to make a copy of libsal in the openoffice program directory, recompile *only* sal (takes around 10 minutes at most) and then copy the new, debug version of libsal to teh program directory and start the program under a debugger. > the wise thing probably is to make a copy of libsal in the openoffice program
> directory, recompile *only* sal (takes around 10 minutes at most) and then
> copy the new, debug version of libsal to teh program directory and start the
> program under a debugger.
ahh, after I read the build requirements (3 Gig hdd space) I was rather sad that
this bug would have to wait until I bought a new drive.. That problem out of the
way, I'll try to do this now. If I encounter further problems, I'll let you know
by adding further comments here (if that is acceptable).
Thanks!
-Malte
Actually, general build issues are better discussed in the dev@tools.openoffice.org list. See also http://www.openoffice.org/dev_docs/source/build_linux.html for general build docs for linux. Dirk: Ocke is properally the best who can help you. Malte if you need some additional help for fixing this bug, please contact Ocke. Dirk: Ocke is properally the best who can help you. Malte if you need some additional help for fixing this bug, please contact Ocke. Ocke is reponsible for that part of code. with a link odbclib.so -> libodbc.so the connection should work Hi Ocke, thanks for the suggestion; I've tried symlinking libodbc.so to odbclib.so, but I still get the same error. (BTW: is namelib.so the standard under Solaris, or why is this different to SO5.2?) My test program works fine: -- #include <stdio.h> #include <dlfcn.h> int main() { void *pLib = NULL; printf("Now attempting to link to odbclib.so...\n"); pLib = dlopen("odbclib.so", RTLD_NOW); if (pLib == NULL) /* equivalent to: if (!pLib) */ printf("cannot load odbclib.so with error:\n%s\n", dlerror() ); else { printf("loading odbclib.so succeeded!\n"); printf("dlclose gave back: %d\n", dlclose(pLib)); } return; } -- Output: mcornils@wh36-b407:/usr/home/mcornils/dev/c$ ./a.out Now attempting to link to odbclib.so... loading odbclib.so succeeded! dlclose gave back: 0 mcornils@wh36-b407:/usr/home/mcornils/dev/c$ -- I will try debugging this following your advice, but it will be a few days; if you have any other ideas not involving a debug build which I will do then, I'd love to hear them though :-) -Malte #8-) I have finally (!) succeeded in making a debug build of the sal library, and I guess I have found the problem. Opening the library gives: --cut!-- osl_loadModule : lib to load : [libodbc.so] osl_getsymbol: cannot get Symbol SQLAllocHandle for reason: /home/mcornils/openoffice60/program/libsal2.so: undefined symbol: SQLAllocHandle osl_getsymbol: cannot get Symbol SQLFreeHandle for reason: /home/mcornils/openoffice60/program/libsal2.so: undefined symbol: SQLFreeHandle osl_getsymbol: cannot get Symbol SQLSetEnvAttr for reason: /home/mcornils/openoffice60/program/libsal2.so: undefined symbol: SQLSetEnvAttr --cut!-- and a search on the first one reveals that it's an ODBC 3.0 function. However, my ODBC library (libiodbc) does not support ODBC 3.0 functions, only ODBC 2.5. A search for the SQLAllocHandle symbol fails, while lots of older ODBC functions are there. So this might a) be a bug in OO's ODBC handling that breaks backwards-compatibility [1] or b) mean that ODBC 3.0 is simply needed in OpenOffice and I need to either fix up libiodbc (now if I had a clue :)) or get a different ODBC library like unixodbc. It would be cool if it were a) and you could fix the problem somehow; in any case I'd be really grateful for your take on this. Thanks for enduring for so long, Yours Malte #8-) [1] since I couldn't find any reference on OO's requirements being ODBC 3.0, I have also reopened this issue. Oh, and BTW, the unstable development version of libiodbc (3.0.4beta) which I'm using now works. Cool. -Malte #8-) Hi, now the dba sites say that ODBC version 3.0 is supported. Regards, Ocke Created attachment 412 [details]
libodbc.so MUST be located in /usr/lib, /usr/local/lib doest not work (BUG)
Hi, fixed in OOo 1.0 Ocke Closing now. change subcomponent to 'none' |