Apache OpenOffice (AOO) Bugzilla – Issue 69877
regcomp.exe does not load library from current path
Last modified: 2008-05-16 03:33:57 UTC
--- snip --- if you call regcomp.exe -register -r services.rdb -c somelib.dll in your office/program directory, regcomp.exe loads somelib.dll from its own directory and not the current directory. This is something developers often stumble upon since they often only copy theire changed dll to the office/program directory and don't deliver them, leaving them with an old dll beeing registered. --- snap --- same or similar is true for unxlngi6. but just copying the binary doesn't work. seems that not only the regcomp binary is involved but also "shlibloader.uno.so" and maybe more.
.
accepted
change target to 2.x After a discussion with SB we decided to move this task to a later target because the fix will need some deeper investigation and has to be tested carefully. A fix will defintiely change the bahaviour and we have to check everything. The regcomp tool itself does more or less nothing and delegate it to an implementation registration service, and changing the implementation of this service has impact on the office as well.
adapt target
fixed on cws jsc15 The problem is that the implementation doesn't care of the search algorithm to find a library. The impl. simply uses osl_loadModule and it depends on the PATH or LD_LIBRARY_PATH and the system dependent search algorithm where the referenced library is searched. In case of windows the system searches near the executable first and not in the current working dir. I don't want to break any existing functionality and decided to introduce a new option -wop (without path) which allows to specify a full qualified or relative path/url to a component but register the pure library or jar name only. This new option allows to register libraries with for example ./mylib.uno.so and having mylib.uno.so in the registry only. This works fine for registration and later in the runtime environment as well.
this issue was mainly written because an incompatible build in binfilter project always breaks until you deliver the project by hand. Is this now fixed also?
jsc -> cl: i think so. If i have understand the problem correct. The problem was that you are in the office/program dir of a local office installation and have tried to register the binfilter lib with regcomp -register -r service.rdb -c liblegacy_binfilters680si.so regcomp has searched the library over the PATH/LD_LIBRARY_PATH and not in current working directoy (found it besides regcomp first -> solver output tree). Now you simply register the lib regcomp -register -r service.rdb -wop -c ./liblegacy_binfilters680si.so The library is taken from the current office program dir and only the name is registered. Should work in your scenario and don't break any older use cases. Please let me know if this is not sufficient for you.
cl->jsc: no, that is also a problem that if you register dll by hand you had to deliver them. I don't see an improvement here, if you had forgotten to deliver your dll prior to using regcomp, you may also forget to use -wop. So my opinion is, please break behavior (for regcomp.exe only), I don't thing there is any to break. The problem with the binfilter project is that inside the binfilter project a rdb is created using regcomp and the dll's created in binfilter. As you can see, currently it registers the binfilter dll's from the solver, not from the project. And this happens before the binfilter project is delivered. We should fix this in the same cws as this is the main reason this issue was reported
change owner for verifying jsc -> cn: you can check it with regcomp -register -r test.rdb -wop -c ./mytestlib.so The regview output of the test.rdb should show "mytestlib.so" instead of "./mytestlib.so"
cn->jsc: is that correct? regcomp -register -r test.rdb -wop -c ./acceptor.uno.so register component './acceptor.uno.so' in registry 'test.rdb' succesful!
ok, not the output of regcomp but regview is important => ok
This Issue is 'Verified' and not updated in 1yr+, so Closing. A Closed Issue is a Happy Issue (TM). Regards, Andrew Cleaning-up and Closing old Issues as part of: ~ The Grand Bug Squash, pre v3 ~