Re: Libetonyek build failure with Boost >=1.81

Hi, Am 11.07.24 um 18:20 schrieb Leo Famulari: As reported on the Document Foundation bug tracker, Boost >= 1.81 breaks compilation of libetonyek: Indeed. I remember talking to our boost maintainer when the boost 1.81 upgrade was imminent 1.5 years ago. You are late to the party ;) I confi

Re: Libetonyek build failure with Boost >=1.81

On 13/07/2024 19:17, Leo Famulari wrote: ... Where can I find the file 'autogen.input'? It doesn't appear in my copy of the LibreOffice 7.6.7.2 source code, not even after I try to build it. It's an optional file, if you don't see it in the main LO dir, it means you don't use it so you don't

Re: Libetonyek build failure with Boost >=1.81

Julien Nabet wrote: > Could you provide the autogen.input you use? > > I'm on Debian testing which uses Boost 1.83 but when checking > config.log, I see: > > configure:33360: checking which boost to use > configure:34711: result: internal > > and internal Boost used is 1.85 version. Where can

Re: Libetonyek build failure with Boost >=1.81

On Fri, Jul 12, 2024 at 04:53:23PM +1000, Christoph Willing wrote: > > If your distro still somehow manages to provide libetonyek, you might > > try to build with autogen option `--with-system-libetonyek` as a > > workaround. > > Hi Leo, > > Your build of libetonyek will succeed if you fully upgr

Re: Libetonyek build failure with Boost >=1.81

Hello, Could you provide the autogen.input you use? I'm on Debian testing which uses Boost 1.83 but when checking config.log, I see: configure:33360: checking which boost to use configure:34711: result: internal and internal Boost used is 1.85 version. Julien

Re: Libetonyek build failure with Boost >=1.81

On 2024-07-11 18:20, Leo Famulari wrote: As reported on the Document Foundation bug tracker, Boost >= 1.81 breaks compilation of libetonyek: https://bugs.documentfoundation.org/show_bug.cgi?id=152569 I confirm the problem persists with Boost 1.83.0. There are bunch of duplicate symbol errors l

Libetonyek build failure with Boost >=1.81

As reported on the Document Foundation bug tracker, Boost >= 1.81 breaks compilation of libetonyek: https://bugs.documentfoundation.org/show_bug.cgi?id=152569 I confirm the problem persists with Boost 1.83.0. There are bunch of duplicate symbol errors like this (full log attached): -- [...]

build failure with ICU 75 (and 74), breakiterator (again)

Hi, Debian experimental just got ICU 75 and I tried it to look what breaks now :) Indeed it breaks again for breakiterator rules: [build BRK] CustomTarget/i18npool/breakiterator/sent.brk S=/home/rene/LibreOffice/git/master && I=$S/instdir && W=$S/workdir && /usr/bin/genbrk -r $S/i18npool/so

Re: 32 bit build failure (smb, narrowing)

Hello, Sorry for the delay, end of last week has been a bit hectic... I see you already made a fix. Thanks a lot! Regards. On Friday, 8 March 2024 08:23:29 CET Rene Engelhard wrote: > Hi, > > see > https://buildd.debian.org/status/fetch.php?pkg=libreoffice&arch=i386&ver=4%3 > A24.2.2~rc1-1&sta

Re: 32 bit build failure (smb, narrowing)

On 3/8/24 08:23, Rene Engelhard wrote: see https://buildd.debian.org/status/fetch.php?pkg=libreoffice&arch=i386&ver=4%3A24.2.2~rc1-1&stamp=1709881487&raw=1: /<>/sal/osl/unx/file.cxx: In function ‘void osl_file_adjustLockFlags(const rtl::OString&, int*, sal_uInt32*)’: /<>/sal/osl/unx/file.cxx:7

Re: 32 bit build failure (smb, narrowing)

Hi, Am 08.03.24 um 08:23 schrieb Rene Engelhard: Can you have a look, please? I had a brief one, but that is a simple define which shoudln't break. Then the switch does     switch (aFileStatFs.f_type) { which uses     struct statfs aFileStatFs; So it probably is a type difference in the

32 bit build failure (smb, narrowing)

Hi, see https://buildd.debian.org/status/fetch.php?pkg=libreoffice&arch=i386&ver=4%3A24.2.2~rc1-1&stamp=1709881487&raw=1: /<>/sal/osl/unx/file.cxx: In function ‘void osl_file_adjustLockFlags(const rtl::OString&, int*, sal_uInt32*)’: /<>/sal/osl/unx/file.cxx:71:26: error: narrowing conversion

Re: build failure in cmis_content.cxx

On 10/11/2023 09:35, Dan Horák wrote: Hi, our CI is getting a build failure in the master branch caused by change from yesterday ... In file included from /home/jenkins/workspace/libreoffice-upstream-bundled/label/mt-snow-02-brq/ucb/source/ucp/cmis/cmis_content.cxx:59: /home/jenkins/workspace

build failure in cmis_content.cxx

Hi, our CI is getting a build failure in the master branch caused by change from yesterday ... In file included from /home/jenkins/workspace/libreoffice-upstream-bundled/label/mt-snow-02-brq/ucb/source/ucp/cmis/cmis_content.cxx:59: /home/jenkins/workspace/libreoffice-upstream-bundled/label/mt

Re: build failure on musl libc (linux) since 7.4

On Thu Jan 5, 2023 at 7:19 AM CET, alice wrote: > starting from 7.4, building libreoffice fails with something like > > > [AWK] CustomTarget/postprocess/registry/fcfg_langpack_en-US.list > [CFG] registry > make[1]: /bin/sh: Argument list too long > > > a more full (still trimmed; it's huge) make

build failure on musl libc (linux) since 7.4

starting from 7.4, building libreoffice fails with something like [AWK] CustomTarget/postprocess/registry/fcfg_langpack_en-US.list [CFG] registry make[1]: /bin/sh: Argument list too long a more full (still trimmed; it's huge) make -d output is available: https://img.ayaya.dev/Ii6L84rHzXfv i wo

Master build failure on macOS Arm M1 in liblangtag

Hi all, After a long hiatus, I've decided to try my hand again at building LO for Mac aarch64 on a MacMini (from config.log, host='aarch-apple-darwin21.6.0'). I've set up the lode build environment, and am using the default autogen.sh configuration values (whatever they might be), i.e. no t

Re: Build failure with gpgme-1.18.0

> On 22 Aug 2022, at 13:15, Andreas Radke wrote: > > Am Mon, 22 Aug 2022 11:37:35 +0200 > schrieb Thorsten Behrens : > >> Hi, >> >> Sam James wrote: >> [...] >> [...] >> Up for removal: >> - https://gerrit.libreoffice.org/c/core/+/138667 >> >> Andreas, if you could perhaps paste your error l

Re: Build failure with gpgme-1.18.0

Am Mon, 22 Aug 2022 11:37:35 +0200 schrieb Thorsten Behrens : > Hi, > > Sam James wrote: > [...] > [...] > Up for removal: > - https://gerrit.libreoffice.org/c/core/+/138667 > > Andreas, if you could perhaps paste your error logs in that patch, so > there's a record? I'll then look into i

Re: Build failure with gpgme-1.18.0

Hi, Sam James wrote: > > On 16 Aug 2022, at 20:23, Andreas Radke wrote: > > > > Removing that configure check isn't enough. I've posted some > > build log messages a few days ago to #libreoffice-dev. I've moved to > > internal gpgme/libgpg-error/libassuan until a fix is available. > > > > It s

Re: Build failure with gpgme-1.18.0

> On 16 Aug 2022, at 09:04, Thorsten Behrens wrote: > > Hi Sam, > > Sam James wrote: >> gpgme-1.18.0 dropped a bunch of internal symbols, >> including progress_callback (see e.g. callbacks.h >> which has a comment at the top saying it's internal). >> >> Unfortunately, this is what LibreOffice

Re: Build failure with gpgme-1.18.0

> On 16 Aug 2022, at 20:23, Andreas Radke wrote: > > Removing that configure check isn't enough. I've posted some > build log messages a few days ago to #libreoffice-dev. I've moved to > internal gpgme/libgpg-error/libassuan until a fix is available. > It seems to have worked fine for us in G

Re: Build failure with gpgme-1.18.0

Removing that configure check isn't enough. I've posted some build log messages a few days ago to #libreoffice-dev. I've moved to internal gpgme/libgpg-error/libassuan until a fix is available. -Andy Arch Linux pgp991mhvqpvy.pgp Description: Digitale Signatur von OpenPGP

Re: Build failure with gpgme-1.18.0

Hi Sam, Sam James wrote: > gpgme-1.18.0 dropped a bunch of internal symbols, > including progress_callback (see e.g. callbacks.h > which has a comment at the top saying it's internal). > > Unfortunately, this is what LibreOffice uses to detect [0] > gpgme: > The reason for that was some kde distr

Build failure with gpgme-1.18.0

Hi, gpgme-1.18.0 dropped a bunch of internal symbols, including progress_callback (see e.g. callbacks.h which has a comment at the top saying it's internal). Unfortunately, this is what LibreOffice uses to detect [0] gpgme: ``` # progress_callback is the only func with plain C linkage # checking

Re: libreoffice-7.4.0.0.beta1 build failure on MacOS Monterey 12.4

I was able to edit ~/.gitconfig, setting the following: [transfer]¬ ▸ fsckobjects = false That caused the clones to work. Now I issue: make check 2>&1 | tee build.log and wait overnite. The build exited with: [_RUN_] Chart2XShapeTest::testFdo75075 warn:sfx.doc:71300:2422449:sfx2/sour

Re: libreoffice-7.4.0.0.beta1 build failure on MacOS Monterey 12.4

Hi Tim, On Tue, Jul 5, 2022 at 9:43 PM Tim Daley wrote: > So I should use the github repo? If so, that fails, too: whether the github repo or from https://git.libreoffice.org/core doesn't matter (github is a readonly mirror) But git now is overly picky (or otherwise put: at the time the reposit

Re: libreoffice-7.4.0.0.beta1 build failure on MacOS Monterey 12.4

Hmmm, looks like I get the same problem when I run the setup using the install at https://wiki.documentfoundation.org/Development/lode. Here's the end of the process: ./setup --dev --force ... Check directory 'mirrors' ... : Created Cloning into bare repository 'core.git'... remote: Counting obje

Re: libreoffice-7.4.0.0.beta1 build failure on MacOS Monterey 12.4

On 5.7.2022 22.42, Tim Daley wrote: On Tue, Jul 5, 2022 at 11:50 AM Rene Engelhard > wrote: Hi, Am 05.07.22 um 16:06 schrieb Christian Lohmaier: > Fatal: > /Users/tim.daley/AixNPanes/libreoffice-7.4.0.0.beta1/schema/libreoffice/OpenDocument-v1.3+li

Re: libreoffice-7.4.0.0.beta1 build failure on MacOS Monterey 12.4

So I should use the github repo? If so, that fails, too: gh repo clone LibreOffice/core Cloning into 'core'... remote: Enumerating objects: 5821827, done. remote: Counting objects: 100% (761/761), done. remote: Compressing objects: 100% (482/482), done. error: object 657924e4d73d6d501c9a3ceaf62e29

Re: libreoffice-7.4.0.0.beta1 build failure on MacOS Monterey 12.4

Hi *, Christian Lohmaier wrote: > I don't remember the reason why they were added to the ignore list, > maybe Thorsten remembers... > Yes, they're a problem to have e.g. for Debian. Cheers, -- Thorsten signature.asc Description: PGP signature

Re: libreoffice-7.4.0.0.beta1 build failure on MacOS Monterey 12.4

Hi, Am 05.07.22 um 16:06 schrieb Christian Lohmaier: Fatal: /Users/tim.daley/AixNPanes/libreoffice-7.4.0.0.beta1/schema/libreoffice/OpenDocument-v1.3+libreoffice-manifest-schema.rng: file does not exist Guess you're using a tarball to build - the schema files are not added to the tarballs. h

Re: libreoffice-7.4.0.0.beta1 build failure on MacOS Monterey 12.4

On Tue, Jul 5, 2022 at 3:56 PM Tim Daley wrote: > > I'm getting the following failure trying to build. > > Apparently you now need to set special privileges (in your plist?) to > set/unset DYLD_LIBRARY_PATH. Suggestions on where and how to do this? > Fatal: /Users/tim.daley/AixNPanes/libreoffic

libreoffice-7.4.0.0.beta1 build failure on MacOS Monterey 12.4

I'm getting the following failure trying to build. Apparently you now need to set special privileges (in your plist?) to set/unset DYLD_LIBRARY_PATH. Suggestions on where and how to do this? [_RUN_] ScFiltersTest::testTdf137576_Measureline /Users/tim.daley/AixNPanes/libreoffice-7.4.0.0.beta1/

Re: build failure mac cross-compiling

On 16/02/2022 12:40, Xisco Fauli wrote: I use a macbook M1 to create the bisect repositories with this autogen: --host=x86_64-apple-macos --build=x86_64-apple-macos --disable-werror --disable-odk --with-package-format=dmg --disable-online-update Since https://cgit.freedesktop.org/libreoffice/c

Re: Daily builds build failure

On 21/02/2022 10:24, Xisco Fauli wrote: [1] https://ci.libreoffice.org/job/lo_daily_tb_mac/ (as an aside, I wonder why the failures of that bot are not sent to )

Re: Daily builds build failure

On 21/02/2022 14:18, Olivier Hallot wrote: Patch has been merged to fix that, but IMO it needs a translation cycle... https://gerrit.libreoffice.org/c/core/+/130169 I had manually fixed the broken content in the translations repo with

Re: Daily builds build failure

Hello Kevin, As far as I can see, it didn't affect the bisect repositories, see https://ci.libreoffice.org/job/lo_bibisect_win32_7_4/ Regards On 21/2/22 14:08, Kevin Suo wrote: It is working now on today's master, which has the commit you have mentioned. It also means that our bibisect rep

Re: Daily builds build failure

Hello, Yes, it does. I noticed it right after I sent the email, retriggered the daily build and new daily builds are already available for win and mac. Regards On 21/2/22 11:56, Miklos Vajna wrote: Hi Xisco, On Mon, Feb 21, 2022 at 10:24:24AM +0100, Xisco Fauli wrote: Currently mac [1]

Re: Daily builds build failure

Patch has been merged to fix that, but IMO it needs a translation cycle... https://gerrit.libreoffice.org/c/core/+/130169 Olivier Em 21/02/2022 06:24, Xisco Fauli escreveu: Hello, Currently mac [1] and windows [2] daily builds fail with /usr/bin/sh: line 1: 51209 Segmentation fault PATH="/h

Re: Daily builds build failure

It is working now on today's master, which has the commit you have mentioned. It also means that our bibisect repo can not be used to bisect the commits in the following range: b8d6af27156faecb831c16afdc52dd630b641a9d..56c4445a8060d8ef6aec78f54ea28f4d7e5a8aa7 56c4445a8060 (Fail Executable_ul

Re: Daily builds build failure

Hi Xisco, On Mon, Feb 21, 2022 at 10:24:24AM +0100, Xisco Fauli wrote: > Currently mac [1] and windows [2] daily builds fail with > > /usr/bin/sh: line 1: 51209 Segmentation fault > PATH="/home/tdf/jenkins/daily_workspace/tb/build_master/instdir/program:/home/tdf/jenkins/daily_workspace/tb/bui

Re: Daily builds build failure

My Fedora 34 builds are also affected. Based on my build log, it started from the following commit: f0117eefa7d1b35e747546fd7d7a28126ebff0b7 I used the following in autogen.input: --with-lang=zh-CN zh-TW --disable-odk --without-fonts --without-help --without-helppack-integration --without-mysp

Daily builds build failure

Hello, Currently mac [1] and windows [2] daily builds fail with /usr/bin/sh: line 1: 51209 Segmentation fault PATH="/home/tdf/jenkins/daily_workspace/tb/build_master/instdir/program:/home/tdf/jenkins/daily_workspace/tb/build_master/instdir/program:$PATH" $W/LinkTarget/Executable/ulfex.exe -i $

build failure mac cross-compiling

Hello Jan-marek, all, I use a macbook M1 to create the bisect repositories with this autogen: --host=x86_64-apple-macos --build=x86_64-apple-macos --disable-werror --disable-odk --with-package-format=dmg --disable-online-update Since https://cgit.freedesktop.org/libreoffice/core/commit/?id=453

Re: Build failure on Linux (libeot)

Hi Julien, Am 30.12.21 um 10:12 schrieb Julien Nabet: On pc Debian x86-64 with master sources updated today (dee44fe48ffa928ca3ef56152a7666412894f3ec) + make clean (because Debian testing has upgraded from llvm11 to llvm13) including a call to autogen.sh, I got: clang: error: no such file or

Re: [RESOLVED] Re: LO build failure in Windows 10 (No C-89 compiler found in libassuan part)

Hi Julien, Julien Nabet wrote: > I confirm that it works now with last autoconf version retrieved on Cygwin > package manager. > Cool - was annoyed myself, with the manual downgrading. ;) > Thank you Thorsten! > Kudos to Cloph and Jmux, who suggested the fix on IRC. Cheers, -- Thorsten sign

[RESOLVED] Re: LO build failure in Windows 10 (No C-89 compiler found in libassuan part)

After 1bb0e177124d5d6661b72df6c7d848fb23639652 author    Thorsten Behrens     2021-12-28 17:22:29 +0100 committer    Thorsten Behrens     2021-12-28 21:14:58 +0100 commit    1bb0e177124d5d6661b72df6c7d848fb23639652 (patch) tree    257fbb13364b2f5f565ed5d1ad7e859f8e3c096e parent    cfbcbb605dba

Re: LO build failure in Windows 10 (No C-89 compiler found in libassuan part)

On 27/12/2021 21:58, Hossein Nourikhah wrote: Hello, On 27.12.2021 18:46, Jan-Marek Glogowski wrote: Am 27.12.21 um 18:30 schrieb Julien Nabet: On Win10, I updated my local repo after some weeks and it fails with: And you updated Cygwin... checking how to run the C preprocessor... C:/cygwi

Re: LO build failure in Windows 10 (No C-89 compiler found in libassuan part)

Hello, On 27.12.2021 18:46, Jan-Marek Glogowski wrote: Am 27.12.21 um 18:30 schrieb Julien Nabet: On Win10, I updated my local repo after some weeks and it fails with: And you updated Cygwin... checking how to run the C preprocessor... C:/cygwin/home/serva/lode/dev/core/workdir/LinkTarget/E

Re: LO build failure in Windows 10 (No C-89 compiler found in libassuan part)

Am 27.12.21 um 18:30 schrieb Julien Nabet: On Win10, I updated my local repo after some weeks and it fails with: And you updated Cygwin... checking how to run the C preprocessor... C:/cygwin/home/serva/lode/dev/core/workdir/LinkTarget/Executable/gcc-wrapper.exe -E configure: error: No C-89

Workaround for LO build failure with clang

Hello, On pc Debian x86-64 testing updated today, I got a build failure with master sources updated today: In file included from /home/julien/lo/libreoffice/chart2/source/tools/ChartModelHelper.cxx:25: In file included from /home/julien/lo/libreoffice/chart2/source/inc

Re: Build failure on x86 linux: undefined reference to `__atomic_load'

On Wed, 13 Oct 2021 at 18:50, Luke Benes wrote: > I can successfully build LO on i686 with > LDFLAGS="-latomic" > > > external/clew/Library_clew.mk looks like a good example of stuff that adds library paths, see the gb_Library_add_libs command there

Re: Build failure on x86 linux: undefined reference to `__atomic_load'

On 13/10/2021 18:49, Luke Benes wrote: I can successfully build LO on i686 with LDFLAGS="-latomic" This is overkill. I think patch is needed for the cuckoo module that you added in https://cgit.freedesktop.org/libreoffice/core/commit/?id=3749d9af3745 for IA-32 clang. I attempted to do this but

Re: Build failure on x86 linux: undefined reference to `__atomic_load'

Noel, I can successfully build LO on i686 with LDFLAGS="-latomic" This is overkill. I think patch is needed for the cuckoo module that you added in https://cgit.freedesktop.org/libreoffice/core/commit/?id=3749d9af3745 for IA-32 clang. I attempted to do this but I'm not family with how this patc

Re: Build failure on x86 linux: undefined reference to `__atomic_load'

Rene, > Or clang needs -latomic and gcc not. Yes, it does. Looks like a known bug in clang: https://bugs.llvm.org/show_bug.cgi?id=45785 Building with "-DCMAKE_CXX_FLAGS=-latomic", resolves the undefined reference to `__atomic_load' and allows the build to complete successfully. However, it caus

Re: Build failure on x86 linux: undefined reference to `__atomic_load'

Hi, Am 16.09.21 um 01:48 schrieb Luke Benes: > Thanks for helping me to try to reproduce this. I'm building with clang-14. > Are you building with gcc? Yes. gcc 10 (as of yet), as I wrote :) > I've confirmed that when I built libcuckoo from > https://github.com/efficient/libcuckoo with clang,

Re: Build failure on x86 linux: undefined reference to `__atomic_load'

Thanks for helping me to try to reproduce this. I'm building with clang-14. Are you building with gcc? I've confirmed that when I built libcuckoo from https://github.com/efficient/libcuckoo with clang, I get a similar failure to the initial failure. When I build it with gcc-11, the build is succ

Re: Build failure on x86 linux: undefined reference to `__atomic_load'

Hi, Am 15.09.21 um 02:34 schrieb Luke Benes: > [DEP] LNK:Library/libsvllo.so > [LNK] Library/libsvllo.so > /usr/lib/gcc/i586-suse-linux/11/../../../../i586-suse-linux/bin/ld: > /core/workdir/CxxObject/svl/source/misc/sharedstringpool.o: in function > `libcuckoo::cuckoohash_map<_rtl_uString*, std

Re: Build failure on x86 linux: undefined reference to `__atomic_load'

Hi, Am 15.09.21 um 02:34 schrieb Luke Benes: > undefined reference to `__atomic_load' Probably you need to add -latomic to the link command line... Regards, Rene

Build failure on x86 linux: undefined reference to `__atomic_load'

Noel, After commit 3749d9af3745c0eaff7239e379578e4e2af89e9d tdf#130795 use concurrent hashmap in SharedStringPool On both OpenSUSE Tumbleweed and Arch 32, I see the build failure below. Would you like any additional debugging info? -Luke [DEP] LNK:Library/libsvllo.so [LNK] Library

Re: Build Failure on OpenSUSE Tumbleweed after distro upgrade: `NSSUTIL_3.59' not found

On 17.06.21 12:54, Stephan Bergmann wrote: On 17/06/2021 11:41, Michael Stahl wrote: ... perhaps like this: first JVM loads /usr/lib64/libnss3.so via nssLibraryDirectory, then some LO library is loaded that is linked to libnss3util.so and finds program/libnssutil3.so via RPATH, then JVM loads

Re: Build Failure on OpenSUSE Tumbleweed after distro upgrade: `NSSUTIL_3.59' not found

This was resolved after a distro update of openSUSE Tumbleweed 20210709-0 -> 20210725-0 which updated: mozilla-nss-3.64 -> mozilla-nss-3.66 I no longer need "--with-system-nss" -Luke ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org

Re: Build failure, Error: no matching function for call on x86 Linux

Hi, Am 16.07.21 um 09:33 schrieb Rene Engelhard: > Am 16.07.21 um 09:03 schrieb Luke Benes: >> Yes, a 'make check' passes with "stack_guard_gap=1" kernel parameter for the >> java bug and clang 12. > clang > > > "Of course" I use gcc here. (Except for skia where the build system > chooses cla

Re: Build failure, Error: no matching function for call on x86 Linux

Hi, Am 16.07.21 um 09:33 schrieb Rene Engelhard: > [...] The uicheck which prompted by for my linked fix > is > https://ci.debian.net/data/autopkgtest/unstable/i386/libr/libreoffice/13632639/log.gz > (has also the junit dbaccess_complex segfault.) Sorry, wrong link. That one actually is the one

Re: Build failure, Error: no matching function for call on x86 Linux

Hi, Am 16.07.21 um 09:03 schrieb Luke Benes: > Yes, a 'make check' passes with "stack_guard_gap=1" kernel parameter for the > java bug and clang 12. clang "Of course" I use gcc here. (Except for skia where the build system chooses clang if present and I follow.) (Since with clang, even a

Re: Build failure, Error: no matching function for call on x86 Linux

or gcc i686. -Luke From: Rene Engelhard Sent: Friday, July 16, 2021 1:20 AM To: Luke Benes; Libreoffice Dev List Subject: Re: Build failure, Error: no matching function for call on x86 Linux Hi, Am 15.07.21 um 15:10 schrieb Luke Benes: > Build succeeds now and tests

Re: Build failure, Error: no matching function for call on x86 Linux

Hi, Am 15.07.21 um 15:10 schrieb Luke Benes: > Build succeeds now and tests pass on Arch 32. Thanks! Tests pass? uicheck does with two patches not upstream[1], but junit crashes with segfault and then other mosly off-by one cppunit test failures here which are i386 only. Regards, Rene [1] h

Re: Build failure, Error: no matching function for call on x86 Linux

Rene fixed this issue with: https://cgit.freedesktop.org/libreoffice/core/commit/?id=51754ca5349d Build succeeds now and tests pass on Arch 32. Thanks! ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/l

Re: Build Failure on OpenSUSE Tumbleweed after distro upgrade: `NSSUTIL_3.59' not found

On 17/06/2021 11:41, Michael Stahl wrote: ... perhaps like this: first JVM loads /usr/lib64/libnss3.so via nssLibraryDirectory, then some LO library is loaded that is linked to libnss3util.so and finds program/libnssutil3.so via RPATH, then JVM loads libnss3util.so but since a shared object wit

Re: Build Failure on OpenSUSE Tumbleweed after distro upgrade: `NSSUTIL_3.59' not found

On 17/06/2021 11.24, Michael Stahl wrote: On 12/06/2021 13.49, Jan-Marek Glogowski wrote: Hi Luke, Am 12.06.21 um 02:31 schrieb Luke Benes: Builds are now failing on the rolling distro OpenSUSE Tumbleweed After the latest update, both gcc and clang builds and both both x86-64 and i686 archi

Re: Build Failure on OpenSUSE Tumbleweed after distro upgrade: `NSSUTIL_3.59' not found

On 12/06/2021 13.49, Jan-Marek Glogowski wrote: Hi Luke, Am 12.06.21 um 02:31 schrieb Luke Benes: Builds are now failing on the rolling distro OpenSUSE Tumbleweed After the latest update, both gcc and clang builds and both both x86-64 and i686 architectures fail. Seems to be caused by caus

Re: Build Failure on OpenSUSE Tumbleweed after distro upgrade: `NSSUTIL_3.59' not found

Hi Luke, Am 12.06.21 um 02:31 schrieb Luke Benes: Builds are now failing on the rolling distro OpenSUSE Tumbleweed After the latest update, both gcc and clang builds and both both x86-64 and i686 architectures fail. Seems to be caused by caused by: java.io.IOException: /core/instdir/pr

Build Failure on OpenSUSE Tumbleweed after distro upgrade: `NSSUTIL_3.59' not found

Builds are now failing on the rolling distro OpenSUSE Tumbleweed After the latest update, both gcc and clang builds and both both x86-64 and i686 architectures fail. Seems to be caused by caused by: java.io.IOException: /core/instdir/program/libnssutil3.so: version `NSSUTIL_3.59' not f

Re: Build failure, Error: no matching function for call on x86 Linux

those int values being passed into makeAny should be sal_uInt32, judging by the definition of that UNO command ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice

Build failure, Error: no matching function for call on x86 Linux

Mert, After commit https://cgit.freedesktop.org/libreoffice/core/commit/?id=67277595902d Unit tests for .uno:MoveShapeHandle command Fails with the error below on both Arch 32 and OpenSUSE i686. Any idea why this would fail on 32-bit linux? -Luke [CXX] sd/qa/unit/tiledrendering/tiledrend

[SOLVED] Re: Build failure in connectivity/evoab2 [loplugin:refcounting]

Hello Stephan, I cherry-picked your patch and I confirm LO builds now. Thank you! Julien -- Sent from: http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http

Re: Build failure in connectivity/evoab2 [loplugin:refcounting]

"loplugin:refcounting (--enable-evolution2)" ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice

Build failure in connectivity/evoab2 [loplugin:refcounting]

Hello, On pc Debian x86-64 with master sources updated today, I got: [CXX] connectivity/source/drivers/firebird/Column.cxx /home/julien/lo/libreoffice/connectivity/source/drivers/evoab2/NDriver.cxx:106:23: error: cppu::OWeakObject subclass 'connectivity::evoab::OEvoabConnection' being managed via

Re: build failure on ubuntu 18.04

On 05.12.2020 5:07, chris...@eagle.ca wrote: Now I'm off to figure out what's going on with the .png export subsystem in writer. (Can't seem to create a .png without the transparency channel.) Most possibly related to https://git.libreoffice.org/core/+/bf021c369f2306ee507da9bd3cc4cd10ac5d234c.

build failure on ubuntu 18.04

Hi all, The command: sudo apt-get install libx11-xcb-dev resolved the build problem I identified earlier. I'll try to familiarize myself with the skia build system, but it may take a while, so a dev with more experience may want to implement the fix in the build system. Now I'm off to fig

Re: build failure on ubuntu 18.04

On 03.12.2020 22:50, chris...@eagle.ca wrote: <-snip-> [CXX] sal/rtl/math.cxx [CXX] workdir/UnpackedTarball/skia/tools/sk_app/unix/VulkanWindowContext_unix.cpp [CXX] workdir/UnpackedTarball/skia/third_party/skcms/skcms.cpp /home/ron/libreoffice/workdir/UnpackedTarball/skia/tools/sk_app/unix/Vul

build failure on ubuntu 18.04

Hi all, I'm a newbie on the libreoffice front, and I'm tracking down a bug that I've discovered in writer. Rather than posting a symptom-only bug, I've been trying to build a debug version of libreoffice 7.0.0, but the build keeps failing with the message as follows: <-snip-> [CXX] sal/rtl/

Re: build failure on ubuntu 18.04

Try: sudo apt-get install libx11-xcb-dev For some reason, the wiki was just massively paired down with stuff like this removed. https://wiki.documentfoundation.org/index.php?title=Development/Linux_Build_Dependencies In the case of dependencies, less is not more. _

Re: New Unit Test for tdf#130960 causing Build Failure on i686

Hi again, On 15/5/20 16:11, Xisco Fauli wrote: > Hello Rene, > > Thanks for providing all the information. > > I think this is a bug and it seems to be Calc only. We have a similar > test for Writer < > https://opengrok.libreoffice.org/xref/core/sw/qa/uitest/writer_tests/trackedChanges.py?r=be14c1

Re: New Unit Test for tdf#130960 causing Build Failure on i686

Hello Rene, Thanks for providing all the information. I think this is a bug and it seems to be Calc only. We have a similar test for Writer < https://opengrok.libreoffice.org/xref/core/sw/qa/uitest/writer_tests/trackedChanges.py?r=be14c1b0&mo=6384#160> and it doesn't fail. For now, I'll modify t

Re: New Unit Test for tdf#130960 causing Build Failure on i686

On Fri, May 15, 2020 at 10:37:20AM +0200, Xisco Fauli wrote: > If I remember well, this is the same problem Rene mentioned in IRC one > day, which is related to the timezone. Yes, it is. > @Rene, do you have any update on this ? I pointed that issue out at April, 17: 12:43 < _rene_> uhm. 12:43

Re: New Unit Test for tdf#130960 causing Build Failure on i686

Hello Luke, If I remember well, this is the same problem Rene mentioned in IRC one day, which is related to the timezone. @Rene, do you have any update on this ? On 14/5/20 20:52, Luke Benes wrote: > After https://cgit.freedesktop.org/libreoffice/core/commit/?id=4a581f12e0d0 > tdf#130960: Ad

New Unit Test for tdf#130960 causing Build Failure on i686

After https://cgit.freedesktop.org/libreoffice/core/commit/?id=4a581f12e0d0 tdf#130960: Add UItest The UI test is failing on test_tdf131907 (trackedChanges.CalcTrackedChanges) Xisco, Do you need any additional debugging info? Any idea why this would fail on i686? Thanks -Luke build l

Re: i686 Linux build failure error: no viable conversion from 'xmlDocUniquePtr'

On 08.05.2020 14:13, Luke Benes wrote: > On Arch linux 32, I'm seeing the following build failure > > [CXX] sd/qa/unit/export-tests.cxx > /core/sd/qa/unit/export-tests.cxx:1284:15: error: no viable conversion from > 'xmlDocUniquePtr' (aka 'unique_ptr<_

i686 Linux build failure error: no viable conversion from 'xmlDocUniquePtr'

On Arch linux 32, I'm seeing the following build failure [CXX] sd/qa/unit/export-tests.cxx /core/sd/qa/unit/export-tests.cxx:1284:15: error: no viable conversion from 'xmlDocUniquePtr' (aka 'unique_ptr<_xmlDoc, xmlDocDeleter>') to 'xmlDocPtr'

[SOLVED] Re: Build failure with fatal error: officecfg/Setup.hxx: No such file or directory

Fixed with: diff --git a/framework/Library_fwm.mk b/framework/Library_fwm.mk index 7c979f5a3c5d..c671daab0b9b 100644 --- a/framework/Library_fwm.mk +++ b/framework/Library_fwm.mk @@ -21,6 +21,10 @@ $(eval $(call gb_Library_Library,fwm)) $(eval $(call gb_Library_set_componentfile,fwm,framework/ut

Build failure with fatal error: officecfg/Setup.hxx: No such file or directory

Hello, I'm giving a try at tdf#46037 "Clean up uses of comphelper/configurationhelper.hxx" I've already submitted 2 patches but I got a pb with a file. Just adding #include in framework/source/jobs/helponstartup.cxx I got this build failure: /home/julien/lo/libreoffice/f

Re: build failure on i686: error: invalid conversion and no matching function

Stephan's patch, https://gerrit.libreoffice.org/#/c/83912/ fixes the build. Christian, Issues like this, are a reminder that we still need to get an x86 Jenkin's Bot setup. The latency in our previous communications was discouraging and then life took over. I'll have some free time over the hol

Re: build failure on i686: error: invalid conversion and no matching function

On 27/11/2019 14:20, Luke Benes wrote: https://cgit.freedesktop.org/libreoffice/core/commit/?id=278a365c68e0 Related: tdf#126043 use fastest png compression ratio Does actually hurt:) It's causing the following error on x86 builds: "Blind fix for 32

build failure on i686: error: invalid conversion and no matching function

Caolán, https://cgit.freedesktop.org/libreoffice/core/commit/?id=278a365c68e0 Related: tdf#126043 use fastest png compression ratio Does actually hurt:) It's causing the following error on x86 builds: [CXX] vcl/unx/gtk3/gtk3gtkinst.cxx /core/include/cppu/unotype.hxx: In instantiation of ‘stat

Re: Build failure with clang on older CPU :Illegal instruction

I confirmed that git bisect identified the wrong commit, probably because I didn't run a `make clean` between builds. Also confirmed that Tomaž's patch https://gerrit.libreoffice.org/#/c/82422/ allows a successful build on older CPUs. Superb job tracking down and fixing this issue despite my bad

Re: Build failure with clang on older CPU :Illegal instruction

Hi, On 11. 11. 19 09:46, Luboš Luňák wrote: The guilty commit is actually https://cgit.freedesktop.org/libreoffice/core/commit/?id=f43f9b99603736a4d54f550052509eb5f4d04b45 . The INTRINSICS_CXXFLAGS variable is misdesigned or misused. What happens is that a source file gets unconditionally

Re: Build failure with clang on older CPU :Illegal instruction

On Monday 11 of November 2019, Luke Benes wrote: > Noel, > > After > https://cgit.freedesktop.org/libreoffice/core/commit/?id=09f77e8ed51fc64fcc >c6a14e87eed48b2f15a28d loplugin:unusedmethods The guilty commit is actually https://cgit.freedesktop.org/libreoffice/core/commit/?id=f43f9b99603736a4d

Build failure with clang on older CPU :Illegal instruction

Noel, After https://cgit.freedesktop.org/libreoffice/core/commit/?id=09f77e8ed51fc64fccc6a14e87eed48b2f15a28d     loplugin:unusedmethods Clang 7 on KDE Neon x86-64, and clang 10-git on openSUSE Tumbleweed i686 is failing with  [CUT] tools_test Illegal instruction (core dumped) It looks like /

  1   2   3   4   5   6   >