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'