Simon Brouwer wrote:
Hi Stephan,
Stephan Bergmann schreef:
Simon Brouwer wrote:
Hi,
I built OOo 2.3.0 on Ubuntu 7.04 and I thought I'd have another try
using linkoo to hack the source according to
http://wiki.services.openoffice.org/wiki/Hacking . However, even the
example on that webpage did not work, as after running linkoo the
libvcl680li.so link in my program directory still points to
libvcl680li.so.1.1 in that same directory and *not* to the corresponding
one in my source tree.
Not sure if the problem you describe is related to it, but see
<http://www.openoffice.org/issues/show_bug.cgi?id=83548> for linkoo's
state.
I think it is something else.
I feared that, too. The foo symlinks to original files renamed foo.1 or
foo.1.1 are there so that product updates on Linux RPM need only include
those files that have actually changed (not used by plain OOo, but at
least by StarOffice). No idea why this causes a problem for you when
using linkoo (and I do not know how linkoo works).
What that issue is about, is that the clever trick of linkoo, replacing
links in the installed_ooo/program directory by symbolic links that
point into the source tree, does not work reliably in some cases. But my
problem is that linkoo does not replace many of those links in the first
place.
By the way, it is said that the only reliable way to test modifications
to the software is to copy all the changed binaries into the
installed_ooo/program directory. Could something be added to the build
scripts that does this, if a certain environment variable is set,
specifying where the binaries have to be copied to? It would not be very
different from what the "deliver" command does, I think.
Sounds doable. Anybody wanting to pick up on this?
-Stephan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
