Apache OpenOffice (AOO) Bugzilla – Issue 127434
libucpdav1.so: undefined symbol: component_getImplementationEnvironmentExt
Last modified: 2019-02-13 19:14:24 UTC
Using AOO420m1(Build:9800) - Rev. 1797494 Linux localhost.localdomain 4.11.2-1-ARCH #1 SMP PREEMPT Sun May 21 23:14:39 CEST 2017 x86_64 GNU/Linux At runtime, AOO will always crash after 20 - 30 seconds, in both Release and Debug builds. The following last errors can be caught from a Debug build : ... Trace 17971/12: "osl_closeFile(36) => /home/user/fr/openoffice4/program/../program/versionrc" Trace 17971/12: "component path=file:///home/user/fr/openoffice4/program/../program/libucpdav1.so " Trace 17971/12: "error: osl_getAsciiFunctionSymbol failed with /home/user/fr/openoffice4/program/../program/libucpdav1.so: undefined symbol: component_getImplementationEnvironmentExt " loadSharedLibComponentFactory envDcp: gcc3 implName: tar.comp.WebDAVContentProvider libName: file:///home/us Trace 17971/12: "> inserting new mapping: ;gcc3[7f30e3b2f520];gcc3[7f30e3b2f520]" Trace 17971/12: "> revoking mapping ;gcc3[7f30e3b2f520];gcc3[7f30e3b2f520]" Trace 17971/12: "error: osl_getAsciiFunctionSymbol failed with /home/user/fr/openoffice4/program/../program/libucpdav1.so: undefined symbol: component_canUnload " Trace 17971/12: ">>>>> Content::execute: start: command: open, env: present" Trace 17971/12: "SerfSession::Init: serf connection created" Trace 17971/12: "Serf_ConnectSetup" ./soffice : ligne 121 : 17971 Erreur de segmentation (core dumped)"$sd_prog/$sd_binary" "$@" If I rename libucpdav1.so to anything else, AOO is stable. Of course, functionalities like WebDAV and whatever else get missing.
After disabling 'Look for updates', AOO is stable. It will crash when trying to open a file via WebDAV.
None of the above misbehavior happens if AOO is configured with the '--with-system-serf' flag. The version of serf automatically downloaded during the build is much outdated and does not use openssl-1.1, which is default on Arch. When using system serf, AOO is stable and files can be opened via WebDAV.
While we are evaluating the update to the latest Serf version, can you retest with the 4.2x branch? Does this issue still persist? Thanks.
It seems that 'svn update' pulled in 4.5 branch (I suppose) and the build process stopped in pyuno. Don't know how to select 4.2 branch with svn. And don't know yet how to build pyuno, so I can't test this topic's subject. Anyway, here's stdout for pyuno failure, though unrelated, in case you might point me to a simple solution : ****************************************************************************** build --from pyuno build -- version: 1775979 ============= Building module pyuno ============= Entering /home/arc/src/aoo/main/pyuno/prj cd .. && make -s -r -j1 debug=true && make -s -r deliverlog [ build LNK ] Library/pyuno.so /usr/bin/ld: /home/arc/src/aoo/main/solver/450/unxlngx6.pro/workdir/CObject/pyuno/source/module/pyuno_dlopenwrapper.o: in function `initpyuno': pyuno_dlopenwrapper.c:(.text+0x29): undefined reference to `dladdr' /usr/bin/ld: pyuno_dlopenwrapper.c:(.text+0xba): undefined reference to `dlopen' /usr/bin/ld: pyuno_dlopenwrapper.c:(.text+0xe4): undefined reference to `dlsym' collect2: error: ld returned 1 exit status make: *** [/home/arc/src/aoo/main/solenv/gbuild/LinkTarget.mk:292: /home/arc/src/aoo/main/solver/450/unxlngx6.pro/workdir/LinkTarget/Library/pyuno.so] Error 1 dmake: Error code 2, while making 'all' 1 module(s): pyuno need(s) to be rebuilt Reason(s): ERROR: error 65280 occurred while making /home/arc/src/aoo/main/pyuno/prj When you have fixed the errors in that module you can resume the build by running: build --from pyuno ****************************************************************************** Regards.
This was fixed just yesterday, please svn update and try again. (In reply to SET from comment #4) > It seems that 'svn update' pulled in 4.5 branch (I suppose) and the build > process stopped in pyuno. Don't know how to select 4.2 branch with svn. And > don't know yet how to build pyuno, so I can't test this topic's subject. > > Anyway, here's stdout for pyuno failure, though unrelated, in case you > might point me to a simple solution : > > ***************************************************************************** > * > build --from pyuno > build -- version: 1775979 > > > ============= > Building module pyuno > ============= > > Entering /home/arc/src/aoo/main/pyuno/prj > > cd .. && make -s -r -j1 debug=true && make -s -r deliverlog > [ build LNK ] Library/pyuno.so > /usr/bin/ld: > /home/arc/src/aoo/main/solver/450/unxlngx6.pro/workdir/CObject/pyuno/source/ > module/pyuno_dlopenwrapper.o: in function `initpyuno': > pyuno_dlopenwrapper.c:(.text+0x29): undefined reference to `dladdr' > /usr/bin/ld: pyuno_dlopenwrapper.c:(.text+0xba): undefined reference to > `dlopen' > /usr/bin/ld: pyuno_dlopenwrapper.c:(.text+0xe4): undefined reference to > `dlsym' > collect2: error: ld returned 1 exit status > make: *** [/home/arc/src/aoo/main/solenv/gbuild/LinkTarget.mk:292: > /home/arc/src/aoo/main/solver/450/unxlngx6.pro/workdir/LinkTarget/Library/ > pyuno.so] Error 1 > dmake: Error code 2, while making 'all' > > 1 module(s): > pyuno > need(s) to be rebuilt > > Reason(s): > > ERROR: error 65280 occurred while making /home/arc/src/aoo/main/pyuno/prj > > When you have fixed the errors in that module you can resume the build by > running: > > build --from pyuno > ***************************************************************************** > * > > Regards.
The component_* symbols are definitely exported from that library: $ nm -D libucpdav1.so |grep ' T ' 000000000004b8e8 T _fini 000000000000ea98 T _init 000000000000f988 T component_getFactory 000000000000f978 T component_getImplementationEnvironment AFAICT that component_getImplementationEnvironmentExt symbol was never exported from any ucb library. Why would system serf make a difference? Our main/RepositoryExternal.mk is not particularly revealing. Please provide the output of "ldd" and "nm -D" on your libucpdav1.so with internal serf.
(In reply to Peter from comment #3) > While we are evaluating the update to the latest Serf version, can you > retest with the 4.2x branch? Does this issue still persist? > > Thanks. After a new 'svn update', AOO no longer crashes when let still, and when opening a WebDAV file. However, if the file is modified and saved, the remote file is simply zeroed. That has always been the case, and is probably another issue. Thanks.
Created attachment 86640 [details] ldd nm on libucpdav1.so with internal serf
(In reply to damjan from comment #6) > ... Please provide the output of "ldd" and "nm -D" > on your libucpdav1.so with internal serf. Please attachement #86640