Hi Stephan,

On Thursday 01 of November 2007, Stephan Bergmann wrote:

> No idea what linkoo is and what exactly you mean with "symbol link
> libraries," but maybe your problems are related to what I explained to
> my colleagues in a Sun-Hamburg-internal mail just yesterday:

solenv/bin/linkoo is a nice script that links libraries and resources from the 
build tree to the installed tree.  It is a great tool for development, 
because you can hack on something [eg. vcl], do 'build' and immediately 
run ./soffice to see the changes.  No delivering, installing, copying around.

> "Removing files from the OOo installation's program directory and
> replacing them with symbolic links to some build tree (Unix) or adding
> some build tree to PATH (Windows) has never worked reliably anyway, and
> no longer works at all since SRC680m234:
>
> - On Unix, replacing program/foo.so with a symbolic link to
> foo-module/unxlngi6.pro/lib/foo.so for example failed when foo.so needs
> bar.so and has an RPATH=$ORIGIN, but bar.so is only present in program,
> not in foo-module/unxlngi6.pro/lib.
>
> - Replacing calls to osl_loadModule with just a file name without path
> with calls to osl_loadModuleRelative (see
> <http://www.openoffice.org/servlets/ReadMsg?list=interface-announce&msgNo=1
>067>) means that the calling and the loaded library indeed have to reside in
> the same directory.
>
> When you want to use some modified file in an OOo installation, there is
> no other reliable way than to physically copy the modified file into the
> installation."

Interesting - but it makes the development a bit more painful ;-)  Please, 
what exactly has changed?  [CWS name & affected files are enough.]  I'm sure 
we could introduce an OOO_DEBUG_LINKS_WORK [or something] env variable that 
would allow linking for the developers again, couldn't we?

Regards,
Jan

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to