Hi Rohit, > I am trying to register the library (.so) file for the example skeleton > sdbc driver using "regcomp" tool into the services.rdb file. When I try > to register the shared library in "connection/unxlngi6.pro/lib
I suppose you mean "connectivity/unxlngi6.pro/lib" here, i.e. the local output tree of the "connectivity" module? > <http://unxlngi6.pro/lib>" directory it fails giving > "CannotRegisterImplementationException" exception. > > However during the build process this library is copied into > 'solver//330/unxlngi6.pro <http://unxlngi6.pro>" directory and when I > try to register this file it succeeds ! > > Could anyone tell me what changes happen to the library files during > build process when they are copied into the solver directory? I suppose this is a LD_LIBRARY_PATH problem: your library is probably linked against other libraries from URE (the UNO runtime environment), which, in a complete build, also reside in $SOLVER/330/unxlngi6.pro/lib. So, if your library resides there, too, and your LD_LIBRARY_PATH contains ".", then loading the lib succeeds. Loading the lib in the local output tree doesn't succeed, since the loader doesn't find the URE libs there. To verify this, try "ldd <lib_name>" to see which libs your actual lib needs, and whether the loader finds them. > My problem is that the my sdbc driver library is supposed to implement > com.sun.star.sdbc.Driver service but when I register it from solver it > is implementing some strange services like > "com.sun.star.comp.svl.PathService" and > "com.sun.star.uno.util.numbers.SvNumberFormatterServiceObject" hence I > am wondering if something is changing the library during the build process. This means that you don't export the proper symbols from your library, which most probably means your map file is wrong. Look into an other driver's makefile.mk, search for a directive referring to a file component.map, and copy this for your driver. Background: since your driver doesn't export the necessary "component_*" functions, which are looked by by the UNO component registration process, those functions are taken from another (random) library which your actual library links to. And those other functions, in your case obviously originating from the libsvl* library, write their very UNO component information. Note that what you're doing is a component with so-called active registration, which is deprecated. Passive registration is to be preferred nowadays, it means that instead of adding (active) code to your library which describes the UNO components it exports, you place an XML file near your lib, and describe the components therein. See http://wiki.services.openoffice.org/wiki/Passive_Component_Registration for details. This completely avoids the regcomp stuff, though at the moment, I am not sure how to integrate those passive registration into the build/deployment process. I think you can learn from other modules here, too - VCL comes to mind, look into vcl/util/vcl.component, and how it is used. HTH Ciao Frank -- ----------------------------------------------------------------- To unsubscribe send email to dev-unsubscr...@dba.openoffice.org For additional commands send email to sy...@dba.openoffice.org with Subject: help
