Issue 69877 - regcomp.exe does not load library from current path
Summary: regcomp.exe does not load library from current path
Alias: None
Product: udk
Classification: Code
Component: code (show other issues)
Version: current
Hardware: All All
: P3 Trivial (vote)
Target Milestone: OOo 2.2
Assignee: chne
QA Contact: issues@udk
Keywords: oooqa
Depends on:
Blocks: 63712
  Show dependency tree
Reported: 2006-09-26 13:59 UTC by hjs
Modified: 2008-05-16 03:33 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description hjs 2006-09-26 13:59:00 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 ""
and maybe more.
Comment 1 hjs 2006-09-26 13:59:56 UTC
Comment 2 jsc 2006-10-18 08:58:48 UTC
Comment 3 jsc 2006-10-25 12:30:09 UTC
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.
Comment 4 jsc 2006-11-13 12:23:27 UTC
adapt target
Comment 5 jsc 2006-11-21 09:36:43 UTC
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 ./ 
and having in the registry only. This works fine for registration
and later in the runtime environment as well. 
Comment 6 clippka 2006-11-22 10:05:14 UTC
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?
Comment 7 jsc 2006-11-22 10:23:07 UTC
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
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 ./
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. 
Comment 8 clippka 2006-11-22 11:00:00 UTC
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

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
Comment 9 jsc 2006-12-04 17:00:34 UTC
change owner for verifying

jsc -> cn: you can check it with 
regcomp -register -r test.rdb -wop -c ./
The regview output of the test.rdb should show "" instead of
Comment 10 chne 2006-12-11 11:54:48 UTC
cn->jsc: is that correct?
regcomp -register -r test.rdb -wop -c ./
register component './' in registry 'test.rdb' succesful!
Comment 11 chne 2006-12-11 12:20:51 UTC
ok, not the output of regcomp but regview is important => ok
Comment 12 ace_dent 2008-05-16 03:33:57 UTC
This Issue is 'Verified' and not updated in 1yr+, so Closing.
A Closed Issue is a Happy Issue (TM).

Cleaning-up and Closing old Issues as part of:
~ The Grand Bug Squash, pre v3 ~