[Bug 160570] build failure with ICU 75

https://bugs.documentfoundation.org/show_bug.cgi?id=160570 Bug 160570 depends on bug 158108, which changed state. Bug 158108 Summary: Build failure with ICU 74 https://bugs.documentfoundation.org/show_bug.cgi?id=158108 What|Removed |Added

[Bug 158108] Build failure with ICU 74

https://bugs.documentfoundation.org/show_bug.cgi?id=158108 Rene Engelhard changed: What|Removed |Added Resolution|--- |FIXED Status|NEW

[Bug 160570] build failure with ICU 75

https://bugs.documentfoundation.org/show_bug.cgi?id=160570 Buovjaga changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED

[Bug 160570] build failure with ICU 75

https://bugs.documentfoundation.org/show_bug.cgi?id=160570 Rene Engelhard changed: What|Removed |Added Whiteboard||target:24.8.0 --- Comment #5

[Bug 158108] Build failure with ICU 74

https://bugs.documentfoundation.org/show_bug.cgi?id=158108 Rene Engelhard changed: What|Removed |Added Whiteboard||target:24.8.0 --- Comment #8

[Bug 160570] build failure with ICU 75

https://bugs.documentfoundation.org/show_bug.cgi?id=160570 --- Comment #4 from Rene Engelhard --- done. reported it here since the ICU 74 one was also here -- You are receiving this mail because: You are the assignee for the bug.

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

[Bug 160570] build failure with ICU 75

https://bugs.documentfoundation.org/show_bug.cgi?id=160570 Buovjaga changed: What|Removed |Added CC||ilmari.lauhakangas@libreoff

[Bug 160570] build failure with ICU 75

https://bugs.documentfoundation.org/show_bug.cgi?id=160570 Rene Engelhard changed: What|Removed |Added See Also||https://bugs.documentfounda

[Bug 158108] Build failure with ICU 74

https://bugs.documentfoundation.org/show_bug.cgi?id=158108 Rene Engelhard changed: What|Removed |Added See Also||https://bugs.documentfounda

[Bug 160570] build failure with ICU 75

https://bugs.documentfoundation.org/show_bug.cgi?id=160570 --- Comment #2 from Rene Engelhard --- In googling for the error I saw https://listarchives.libreoffice.org/global/dev/2012/msg05518.html ff. and the committed

[Bug 160570] build failure with ICU 75

https://bugs.documentfoundation.org/show_bug.cgi?id=160570 --- Comment #1 from Rene Engelhard --- ICU 75.1 rc1 that is but I doubt there will be behaviour changes until its final so we need to do something about that anyways -- You are receiving this mail because: You are the assignee for the

[Bug 160570] build failure with ICU 75

https://bugs.documentfoundation.org/show_bug.cgi?id=160570 Rene Engelhard changed: What|Removed |Added Blocks||149092 Referenced Bugs:

[Bug 160570] build failure with ICU 75

https://bugs.documentfoundation.org/show_bug.cgi?id=160570 Rene Engelhard changed: What|Removed |Added Summary|build failure with ICU 75.1 |build failure with ICU 75

[Bug 158108] Build failure with ICU 74

: https://bugs.documentfoundation.org/show_bug.cgi?id=160570 [Bug 160570] build failure with ICU 75.1 -- You are receiving this mail because: You are the assignee for the bug.

[Bug 160570] build failure with ICU 75.1

: https://bugs.documentfoundation.org/show_bug.cgi?id=158108 [Bug 158108] Build failure with ICU 74 -- You are receiving this mail because: You are the assignee for the bug.

[Bug 160570] build failure with ICU 75.1

https://bugs.documentfoundation.org/show_bug.cgi?id=160570 Rene Engelhard changed: What|Removed |Added See Also||https://bugs.documentfounda

[Bug 158108] Build failure with ICU 74

https://bugs.documentfoundation.org/show_bug.cgi?id=158108 Rene Engelhard changed: What|Removed |Added See Also||https://bugs.documentfounda

[Bug 160570] New: build failure with ICU 75.1

https://bugs.documentfoundation.org/show_bug.cgi?id=160570 Bug ID: 160570 Summary: build failure with ICU 75.1 Product: LibreOffice Version: 24.8.0.0 alpha0+ Master Hardware: All OS: All Status: UNCONFIRMED

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=i386=4%3 >

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=i386=4%3A24.2.2~rc1-1=1709881487=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:

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=i386=4%3A24.2.2~rc1-1=1709881487=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 of ‘4283649346’

[Bug 158108] Build failure with ICU 74

https://bugs.documentfoundation.org/show_bug.cgi?id=158108 --- Comment #7 from Eike Rathke --- Over the years (even decades now) we added specific rules for certain languages that were either not handled by ICU or handled differently and didn't suit what users expected. While technically

[Libreoffice-bugs] [Bug 158108] Build failure with ICU 74

https://bugs.documentfoundation.org/show_bug.cgi?id=158108 --- Comment #6 from taichi <20001...@ymail.ne.jp> --- (In reply to Eike Rathke from comment #5) > Well, fine, but what does that actually _mean_ for our line break rules? > > Adding Khaled to Cc, maybe he knows as he touched >

[Libreoffice-bugs] [Bug 158108] Build failure with ICU 74

https://bugs.documentfoundation.org/show_bug.cgi?id=158108 BogdanB changed: What|Removed |Added Blocks||149092 CC|

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

[Libreoffice-bugs] [Bug 158108] Build failure with ICU 74

https://bugs.documentfoundation.org/show_bug.cgi?id=158108 --- Comment #5 from Eike Rathke --- Well, fine, but what does that actually _mean_ for our line break rules? Adding Khaled to Cc, maybe he knows as he touched i18npool/source/breakiterator/data/line.txt recently. IMHO it's now time to

[Libreoffice-bugs] [Bug 158108] Build failure with ICU 74

https://bugs.documentfoundation.org/show_bug.cgi?id=158108 --- Comment #4 from taichi <20001...@ymail.ne.jp> --- (In reply to Eike Rathke from comment #3) > (In reply to Natanael Copa from comment #0) > > This appears to have been removed in ICU in this commit: > >

[Libreoffice-bugs] [Bug 158108] Build failure with ICU 74

https://bugs.documentfoundation.org/show_bug.cgi?id=158108 --- Comment #3 from Eike Rathke --- (In reply to Natanael Copa from comment #0) > This appears to have been removed in ICU in this commit: > https://github.com/unicode-org/icu/commit/ > 84e47620692be90950d090f2f4722494b020ad96 Oh great,

[Libreoffice-bugs] [Bug 158108] Build failure with ICU 74

https://bugs.documentfoundation.org/show_bug.cgi?id=158108 --- Comment #2 from Natanael Copa --- (In reply to Julien Nabet from comment #1) > There's a patch which needs some tweaks here: > https://gerrit.libreoffice.org/c/core/+/158749 The comment there shows that they bumped into same genbrk

[Libreoffice-bugs] [Bug 158108] Build failure with ICU 74

https://bugs.documentfoundation.org/show_bug.cgi?id=158108 Julien Nabet changed: What|Removed |Added CC||20001...@ymail.ne.jp,

[Libreoffice-bugs] [Bug 158108] Build failure with ICU 74

https://bugs.documentfoundation.org/show_bug.cgi?id=158108 Robert Großkopf changed: What|Removed |Added Component|Base|LibreOffice -- You are

[Libreoffice-bugs] [Bug 158108] New: Build failure with ICU 74

https://bugs.documentfoundation.org/show_bug.cgi?id=158108 Bug ID: 158108 Summary: Build failure with ICU 74 Product: LibreOffice Version: 7.6.2.1 release Hardware: All OS: All Status: UNCONFIRMED

[Libreoffice-bugs] [Bug 156210] Build failure with gcc-11

https://bugs.documentfoundation.org/show_bug.cgi?id=156210 Buovjaga changed: What|Removed |Added Resolution|--- |MOVED Status|UNCONFIRMED

[Libreoffice-bugs] [Bug 156210] Build failure with gcc-11

https://bugs.documentfoundation.org/show_bug.cgi?id=156210 QA Administrators changed: What|Removed |Added Whiteboard| QA:needsComment| -- You are receiving this

[Libreoffice-bugs] [Bug 156210] Build failure with gcc-11

https://bugs.documentfoundation.org/show_bug.cgi?id=156210 raal changed: What|Removed |Added CC||hoss...@libreoffice.org,

[Libreoffice-bugs] [Bug 156210] Build failure with gcc-11

https://bugs.documentfoundation.org/show_bug.cgi?id=156210 QA Administrators changed: What|Removed |Added Whiteboard|| QA:needsComment -- You

[Libreoffice-bugs] [Bug 156210] New: Build failure with gcc-11

https://bugs.documentfoundation.org/show_bug.cgi?id=156210 Bug ID: 156210 Summary: Build failure with gcc-11 Product: LibreOffice Version: 7.5.4.2 release Hardware: Other OS: Linux (All) Status: UNCONFIRMED

[Libreoffice-bugs] [Bug 152994] Daily Screenshot Build failure

https://bugs.documentfoundation.org/show_bug.cgi?id=152994 Caolán McNamara changed: What|Removed |Added Resolution|--- |FIXED Status|NEW

[Libreoffice-bugs] [Bug 152994] Daily Screenshot Build failure

https://bugs.documentfoundation.org/show_bug.cgi?id=152994 --- Comment #5 from Commit Notification --- Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/65596d7062ac4edadeef84cc335a585ffa942fe0 tdf#152994 actually

[Libreoffice-bugs] [Bug 152994] Daily Screenshot Build failure

https://bugs.documentfoundation.org/show_bug.cgi?id=152994 Commit Notification changed: What|Removed |Added Whiteboard||target:7.6.0 -- You are

[Libreoffice-bugs] [Bug 152994] Daily Screenshot Build failure

https://bugs.documentfoundation.org/show_bug.cgi?id=152994 --- Comment #3 from Xisco Faulí --- This is the command used by jenkins to execute the build: ${LODE_HOME}/bin/tb_slave_wrapper --branch=MASTER --os=Windows --screenshots --clean --distro-config=screenshot_win

[Libreoffice-bugs] [Bug 152994] Daily Screenshot Build failure

https://bugs.documentfoundation.org/show_bug.cgi?id=152994 --- Comment #2 from Caolán McNamara --- Locally on my windows box make CppunitTest_chart2_dialogs_test works fine, so: I think the failing machine is a 32bit windows build from the log, maybe that's relevant to the problem. What's the

[Libreoffice-bugs] [Bug 152994] Daily Screenshot Build failure

https://bugs.documentfoundation.org/show_bug.cgi?id=152994 Xisco Faulí changed: What|Removed |Added Ever confirmed|0 |1 Keywords|

[Libreoffice-bugs] [Bug 152994] New: Daily Screenshot Build failure

https://bugs.documentfoundation.org/show_bug.cgi?id=152994 Bug ID: 152994 Summary: Daily Screenshot Build failure Product: LibreOffice Version: 7.5.0.0 alpha1+ Hardware: All OS: All Status: UNCONFIRMED

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

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

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

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

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

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

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

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

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

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

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

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: >

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

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.

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:

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

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

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

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

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

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 >

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

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

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

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

[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   

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...

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...

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

[Libreoffice-bugs] [Bug 142442] Build failure with gcc-11

https://bugs.documentfoundation.org/show_bug.cgi?id=142442 Xisco Faulí changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Libreoffice-bugs] [Bug 142442] Build failure with gcc-11

https://bugs.documentfoundation.org/show_bug.cgi?id=142442 Aron Budea changed: What|Removed |Added Blocks||126862 Referenced Bugs:

[Libreoffice-bugs] [Bug 142442] Build failure with gcc-11

https://bugs.documentfoundation.org/show_bug.cgi?id=142442 Mike Kaganski changed: What|Removed |Added See Also||https://bugs.documentfounda

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

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

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

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

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*,

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

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

  1   2   3   4   5   6   7   >