When trying to build moz on (then DEV300m0-based) CWS sb83, Eric
informed me about a build breaker in module sc. The reason is that a
vanilla configured build sets ENABLE_VBA (and Sun-Hamburg setsolar does
not enable that, so the problem had slipped me), but the resulting
vbaobj extension library had only ever worked by luck, and now does not
even build any longer on Mac OS X. To work around this, I have
completely disabled building that extension library on Mac OS X for now.
For background information, the below is quoted from a mail thread
between Noel, Andreas, and me (and I hope Noel and Andreas do not mind I
post this here).
-Stephan
Hi Noel,
The problem is how a shared library contained in an extension finds
the OOo libraries it depends on. It has only ever been guaranteed
(though maybe not been widely known) that such a shared library finds
the URE libraries (essent. sal, salhelper, cppu, cppuhelper). If such
a library depends on non-URE libraries (like vcl) and does find them
at runtime, that is by luck (see below). (Non-OOo libraries an
extension library might depend on, like additional libraries the
extension brings with itself, or system libraries, are yet another
matter, out of scope here.) Now, the shared library contained in the
oovbaapi.oxt does link against non-URE libraries, so is prone to
failing luck.
- Before the integration of CWS sb83, all OOo libraries (URE and
non-URE) are in a single directory together with all launching
executables (soffice). Extension libraries, on the other hand, get
installed into some distant, rather randomly located directory. --
Since Windows and Mac OS X (by default) look for libraries next to
the running executable, extension libraries happen to find all OOo
libraries. -- Linux and Solaris do not look next to the running
executable, so the extension works there only if all OOo libraries it
needs happen to already be loaded into the process (and the OOo code
guarantees that for just the few URE libs, not the rest).
- After the integration of CWS sb83, the OOo libraries and
executables will be spread across different directories, the URE libs
in one directory, the other OOo libs in a second directory, and the
launching executables in yet a third directory. (And the extension
libraries continue to be installed into their remote directories.) --
Since Windows also looks in the PATH for libraries, and the first two
directories will be in the PATH, extension libraries will continue
to happen to find all OOo libraries there. -- For Linux and Solaris,
the situation will remain largely unchanged: extension libraries will
be guaranteed to find the URE libraries, and will only find other OOo
libraries if they happen to be already loaded into the process. --
For Mac OS X, the situation is that an extension library finds the
URE libraries if it was built with the SHLnRPATH=OXT setting, and
that it does not find other OOo libraries at all. So what I did on
CWS sb83 was to add SHLnRPATH=OXT to all extension libraries I was
aware of (incl. now the shared library contained in oovbaapi.oxt).
Decided for yourself how you want to proceed with oovbaapi.oxt: Since
it links against non-URE libs, it has always only worked by luck
(more or less stable luck, depending on platform), and continues to
only work by luck (zero luck now on Mac OS X). The only clean
solutions I see would be to drop the extension, change it from an
extension to an integral part of OOo, or change it to not link
against non-URE libs.
-Stephan
Noel Power wrote:
Hi Stephan,
Andreas asked me about the oxt mentioned below and I promised to
find out whether it was ok to remove it or not ( but forgot until
now ). So, currently our thinking is that it is a good thing to
keep the extension and *not* remove it, maybe we can change the
default ( which is to built vba as an extension ). The rationale
for keeping it is simple, we wish to keep the flexibility to
deliver this feature purely as an extension ( in truth it is an
extension anyway but currently delivered as a pre-registered
component ) Currently some users ( e.g. system builders [1] ) do
deliver the extension. I hope this doesn't cause you problems, if
so, and I can do anything to help make it easier for whatever you
are doing ( which I admit I don't understand - because I was too
lazy to read the link below ) please let me know and I will do what
I can
Noel
[1] recently it appears in ooo-build at least the the build for
extension is broken and I will have to fix it :-( Andreas Bregas
wrote:
Hi Noel,
do you agree that oovbaapi.oxt isn't needed any more and could
you take care of removing it from ooo build or contact Stephan
concerning this?
Regards
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
