Apache OpenOffice (AOO) Bugzilla – Issue 17187
use system mozilla ... (patch)
Last modified: 2008-05-16 03:32:49 UTC
The attached patch allows the use of an installed system mozilla instead of the included zip-files (with their concomitant ABI problems on most currentl Linux platforms). Ken - can you approve the configure stuff ? I've tested this with mozilla-1.3.1, and mozilla-1.4.x - and of course, it should work with the 1.0.X snapshot you have in the build tree [ the untouched path ]; so this should build on most systems out there. May I commit ?
Created attachment 7902 [details] use the system mozilla if instructed.
Martin - I guess this is peripherally build/process related too. [ and hello again Frank :-].
adding dependency to meta bug 17159 (tracking OOo-Moz-AB integration) hello again Michael :) This sounds like great stuff - indeed a very nice surprise this morning :). Getting this into the tree would be great, and certainly a lot of the porters would like to hear this ... Some questions came to my mind after looking at the patch: * what happens at runtime which such an OOo version? At least, I suppose, the pre-requisite is that the Mozilla is in the LD_LIBRARY_PATH (resp. PATH, in Windows). Does this reliably work? IIRC, we had problems when initializing XPCom while it's libraries did not reside in the directory of the process executable. It failed to initialize properly then. Is this still the case with newer Mozilla versions? * also about the runtime behaviour: We currently have the problem that there is at least one patch to Mozilla which is strictly necessary: see issue 6883. The short justification, as far as the problem has been understood, is that the LDAP access is heavily asynchonous, and doesn't like OOo's multi-thread access very well. Especially since the threads which may call from OOo into Mozilla code do not have an own Mozilla event queue, while the LDAP code makes heavy use of proxy objects delegating calls between threads. Seeing this, I wonder if LDAP connections still work when using a pre-installed Mozilla? * In moz/zippped, you do not deliver *runtime.zip anymore. This means you should also remove the respective item from the scp project. There, the runtime file is added to the installation set, which would fail now. So please also adjust scp/source/office/files.scp. * It seems that the most changes you did in mozab are adjustments to changed method signatures. This raises the question what happens if a user has Mozilla 1.5 installed, where the signatures may have changed, again. I assume it would simply break the build. I suggest adding code to the configure script which verifies the found Mozilla version. * I am not Ken, but nevertheless tried to understand the configure patch :) Being paranoid: would it be good to add a check that setting the MOZILLA_* variables in the configure script succeeded? At the moment, it seems to me that simply the presence of "--with-mozilla" results in setting the variables, even if there's something wrong in the env. Just an idea. * forgive me, but I have to ask this: Does this also work on Windows? :)) Despite all this nitpicking stuff :), thanks for your engagement in this!
Hi Frank; Thanks for the great response :-) sorry I'm being slow - we just had our first baby arrive. Anyhow, I have a few spare seconds: * at run-time we use the system xpcom and nspr etc. libraries which by definition are in the system path; at least - I'm assuming so: my ldd shows: [michael@server lib]$ ldd libmozabdrv2.so libcppu.so.3 => /opt/OpenOffice/openoffice/build/RC2_030714/solver/645/unxlngi4.pro/lib/libcppu.so.3 (0x40076000) .... libxpcom.so => /usr/lib/libxpcom.so (0x404c8000) libpthread.so.0 => /lib/tls/libpthread.so.0 (0x405a2000) libdl.so.2 => /lib/libdl.so.2 (0x405b0000) libm.so.6 => /lib/tls/libm.so.6 (0x405b4000) .... libc.so.6 => /lib/tls/libc.so.6 (0x42000000) libplds4.so => /usr/lib/libplds4.so (0x4074b000) libplc4.so => /usr/lib/libplc4.so (0x4074e000) libnspr4.so => /usr/lib/libnspr4.so (0x40753000) Which seems to be adequate; I'm hoping the system xpcom library will be able to locate any other components necessary; indeed, it's hopeful that a strings on /usr/lib/libxpcom.so shows pointers to the right bits in /usr/lib/mozilla-1.4/foo. * wrt. Mozilla patching; I think we have to 'assume' that the system mozilla is one that provides the behavior we are expecting; having said that, I didn't realize we had to patch mozilla - I'll look into chasing that in Mozilla land if I can. Either way, I like to think of that as our Mozilla build engineer's problem at Ximian ;-) The same is true of the RedHat setup I think. * I'll have a poke at the scp shortly to stop installing the stuff; * wrt. mozilla 1.5 - we currently use inequalities to do version checks, so unless mozilla 1.5 changes the ABI yet again, the code should work fine with it - I think that's prolly the best way to go; presumably (initially at least) 1.5.N will have the same ABI as 1.4.N - so God willing the compiler will catch any changes subsequently anyway for us. [ it did that quite nicely for the 1.3 and 1.4 bits so far ]. * the configure script bits are quite robust; the PKG_CONFIG_CHECK macro hides a number of things - such as a fatal error if the right mozilla bits are not found; so I think that's not so much of a problem. * Yes this will work on windows - at least; it's possible the --with-mozilla option is Unix specific [ although there's no need for it to be ]; however - as you can see, both in the Sun build system case, and the missing --with-mozilla case, no code paths are changed - so what worked before will continue to work :-). Having said that, I don't see why it shouldn't work on Win32 - I just don't have a box to hand. So ... I guess that just leaves the scp/ fixes for people who use --with-mozilla; [ generally I ignore thousands of obscure, and unfixable scp errors at install anyway ]. Finally - I havn't really tested this in anger; since I have no mozilla addressbook, nor LDAP source - I'm just happy to see the component compiler happily, link in, and show up in the connectivity dialog - so it's possible there will need to be further bug-fixing pwrt. #6883. Either way - getting this into the main-line will shrink my outstanding patch-set further, and also shrink other Linux distributor's patch-sets eg. RedHat has some nasty mess to do this, and Mandrake just totally bins the Mozilla bits (as did we in our 1.0.3 packages) - so it'd be great to get this into 1.1 ASAP. Thanks Frank.
Michael, first congratulations for your latest achievement :) about issue 6883: The problem with the patch for this is that it definately does not make sense to apply it to a regular Mozilla installation - it would produce other bugs there. At the moment, we simply are in a situation that at runtime, OOo will not properly work with an unpatched Mozilla, but a patched Mozilla will not work properly in a context other than OOo. From what you said I understand that you're not sure if OOo, when compiled with this switch, still offers all the address book functionality. As I tried to outline, I even doubt that this is possible currently, because of issue 6883, which will either break Mozilla (when applied) or OOo (when not applied). (side note: 6883 does not even contain the full patch: Recently, we discovered a bug which prevented the report wizard to run on a LDAP data source. The fix for this streched the fix for 6883 even more into a direction which is incompatible with Mozilla.) I have to admit that because of this, I have some belly ache with the patch in the current shape. Even if we say it's in the responsibility of the Linux distributors to use or not use this patch, I fear that we will get distros compiled with this switch, where the LDAP access in OOo will not work. And I am _pretty_ sure that a lot of people will blame OOo for this. I would rather like to consider this patch here an (important!) part of the bigger picture, namely as an important pre-requisite for issue 11424 ("remove the need for pre-compiled Mozilla tarballs from OOo build environment"). If you say that with a pre-installed Mozilla, OOo LDAP access (and MozillaAB access) works properly - which I strongly doubt to be possible currently -, then I withdraw my concerns. In the current shape, I think the patch is only half the way - please convince me of the opposite :).
Depend on 6883
since we're required to have a reasonable target if possible, I set this to 2.0
only my option on this issue: Even though the 6883 issue can be fixed. I donot prefer this way. Until we can get agreement of an stable ABI (not only API, but also binary compatible) between SO/OO, it would not work well in this way. We may be bogged between many verions of mozilla releases and builds using different CPP compiler. I prefer the mozilla new module IPC for profile sharing. That is to say, OO-mozab is actually an XPcom/MOZ instance, and other mozillas are other instance, and they can run at the same time and commuicate with each other.
Hi Gilbert, Right - having spent some more time on this; and read through the changes you've made to Mozilla - and the impossibility of merging this level of brokenness up-stream; I think the only really feasible approach is to bin Mozilla integration in our patches. I'm just really sad that this also kills LDAP support - which is something we need. It'd be really nice if there was a separate LDAP backend. But then again, from our perspective Evolution's Wombat will soon be exporting a thread-safe, IPC mechanism for LDAP/Exchange/Novell etc. client usage - which is the way we're hoping to go. So - I'll work up a new patch that adds a configure option to completely disable the Mozilla work. Thanks.
Michael, you should probably coordinate this with Wind Li then - he is currently working on issue 11424, which includes configuring the OOo build for using and building different Mozilla version. I think "disable Mozilla DB integration completely" can be considered a special case of issue 11424 ....
accepting, to get rid of the automatic "you have undealt issues" mails from IZ
change subcomponent to 'none'
targeting this to "Later" for the moment - as long as at least issue 6883 is not solved, it does not make sense to have this lingering on 2.0.
Hi, issue 6883 is marked as fixed now. Would you reconsider your decision regarding the target milestone? Greetings, Stefan
Michael, can you please update your patch, once CWS mozab04 has been integrated? mozab04 features a fix for issze 6883, and issue 28398, which will both affect this patch here. When your patch is up-to-date (or you say it's not necesary to update it), I'm willing to check it in. Thanks. (BTW: the state of mozab04 can be seen in EIS: http://eis.services.openoffice.org/EIS2/servlet/GuestLogon)
well - our existing patch is quite simply, and just bins the mozilla code - which is all we are really interested in. As I said, I don't believe it's possible to use the system mozilla - due to the hacked-up locking situation, and long-term we want to switch to using the evolution-data-server approach, which is much more pleasant.
What is the current status of mozilla? Please update issue.
Ken - this targets the rather dead & festering 1.1.x branch; The problem with system-mozilla in 680 is that it's libxmlsecurity tries to use 1 API method that isn't exported by any shipping system mozilla. We circumvent this in ooo-build by cut/paste of a big chunk of mozilla code into our build - not really suitable for up-stream though - who don't think having huge chunks of mozilla binary in cvs is a serious bug :-) The cut/paste patch is ~90k lines.
mozilla 1.7.5 (nss 3.9.3) does now export PK11_GetCertFromPrivateKey. So system-mozilla now will work. I took caolans older patches and updated them (to m67 currenty). To be attached. I'll commit this to the newly created cws_src680_systemmozilla soon. Reassign to me.
Created attachment 21142 [details] system-mozilla patch against m67
committed to cws_src680_systemmozilla
Created attachment 21712 [details] add mozilla lib path to LD_LIBRARY_FLAGS for registration if necessary
cmc->rene: the above patch might be necessary if you compile without openldap and with system-mozilla on a system where libldap50 is not in /usr/lib e.g. fedora where its in e.g. /usr/lib/mozilla-1.5/. Thus at component registration time libldap50 cannot be found unless something like the above hack is in place. I'll be building with openldap so I don't need it or really care :-), but it might bite someone.
fs->rene: thinking about it, I am a little bit unhappy that with the changes, the possibility to build OOo completely *without* Mozilla got lost. I know that Mozilla is required for XML security, but what about the following 1. --with-system-mozilla => no address book support, but xmlsec and LDAP configuration backend 2. --disable-mozilla => no address book support, no xmlsec, no LDAP configuration backend 3. --enable-mozilla (using pre-compiled mozilla, or the feature from issue 11424) => address book support, plus xmlsec, plus LDAP configuration backend (Not sure whether the Mozilla plugin is also a client of our Mozilla libs, it probably should also be listed above) AFAIK, nearly everything for this is already there, except that when disabling Mozilla, we would need to disable xmlsec, too (which in real is issue 38418). I don't insist on this, since I don't know the effort, I ust wonder whether we should *that easily* loose the capability to build completely without Mozilla (which might be desirable sometimes).
will think/look.
rene->caolan: thanks, committed
rene->fs: I think I have a patch working to make --disable-mozilla working again. Unfortunately I have no clue about how to remove the menu item and buttons from the UI ;-) Can you help? The current patch is at http://people.debian.org/~rene/openoffice.org/reanimate-disable-mozilla.diff
> I think I have a patch working to make --disable-mozilla working again ah, that's great! > Unfortunately I have no clue about how to remove the menu item and buttons from > the UI ;-) Ehm, bear with me - which menu items/buttons?
File->Digital Signatures... And the "Digital Signature..." button in the Properties. And some digital signature UI stuff I eventually didn't see yet :-)
ah .... The menu items are defined in configuration files: sw/uiconfig/*/menubar/menubar.xml sc/uiconfig/*/menubar/menubar.xml sd/uiconfig/*/menubar/menubar.xml (look for uno:Signature therein) The respective status bar item is nearby, in the statusbar.xml files The place for hiding/disabling the respective items at runtime is in sfx2/source/doc/objserv.cxx for the menu item, and in <I_dont_know> for the status bar item. The file properties dialog is implemented in sfx2/source/dialog/dinfdlg.*. Out of my head, I cannot imagine straight-forward solutions for removing the signature functionality from those places at compile time. I suppose we need to do this at runtime (for instance by checking the availability of the com.sun.star.security.DocumentDigitalSignatures service and disabling/removing the items). However, I suggest doing this separately then, and not in the course of this issue here.
FIXED in cws systemmozilla
looks good :)
It integrated in OOo2.0 time line (m90), therefore I correct the target milestone to OOo2.0.
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 ~