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:

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

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

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

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

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

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

86. -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 pass on Ar

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]

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

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

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

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

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:

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

[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

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

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

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

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.

[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

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

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

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

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

Re: Build failure with latest ICU 64.1

On Samstag, 30. März 2019 09:25:24 CET Andreas Sturmlechner wrote: > On Freitag, 29. März 2019 13:50:01 CET Miklos Vajna wrote: > > Can you see if the attached patch helps? If so, we can get it merged > > upstream. > > Thanks, it does help, but it seems the real issue is in ICU - Gentoo xmlsec >

Re: Build failure with latest ICU 64.1

On Freitag, 29. März 2019 13:50:01 CET Miklos Vajna wrote: > Can you see if the attached patch helps? If so, we can get it merged > upstream. Thanks, it does help, but it seems the real issue is in ICU - Gentoo xmlsec maintainer has filed a PR upstream and I'm rebuilding LO again:

Re: Build failure with latest ICU 64.1

On Freitag, 29. März 2019 13:50:01 CET Miklos Vajna wrote: > Can you see if the attached patch helps? If so, we can get it merged > upstream. Thanks, it does help, but it seems the real issue is in ICU - Gentoo xmlsec maintainer has filed a PR upstream and I'm rebuilding LO again:

Re: Build failure with latest ICU 64.1

Hi, On Fri, Mar 29, 2019 at 12:43:41PM +0100, Andreas Sturmlechner wrote: > (this is from system-xmlsec-1.2.27) Can you see if the attached patch helps? If so, we can get it merged upstream. Thanks, Miklos From d0c7516dd97599fb59d8616e8adf94f19ec48de1 Mon Sep 17 00:00:00 2001 From: Miklos

Re: Build failure with latest ICU 64.1

On Friday, 29 March 2019 at 11:51, Stephan Bergmann wrote: > > In file included from > > /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/include/g++-v8/memory:64, > > from /usr/include/unicode/localpointer.h:45, > > from /usr/include/unicode/uenum.h:23, > >

Re: Build failure with latest ICU 64.1

On 29/03/2019 11:14, Andreas Sturmlechner wrote: [build CXX] xmlsecurity/source/xmlsec/biginteger.cxx S=/var/tmp/portage/app-office/libreoffice-6.2.1.2/work/libreoffice-6.2.1.2 && I=$S/instdir && W=$S/workdir && mkdir -p $W/CxxObject/xmlsecurity/source/xmlsec/

Re: build failure: AppFileName should be set to something after SVMain!

On 03/10/2018 16:27, Terrence Enger wrote: [GAL] education warn:vcl:23225:23225:vcl/source/app/svapp.cxx:237: AppFileName should be set to something after SVMain! Bootstrap exception 'component context fails to supply service com.sun.star.ucb.UniversalContentBroker of type

Re: Build failure with current master on MacOS

On Wed, 2017-08-16 at 21:13 +0200, Michael Stahl wrote: > > i was thinking that LODE was supposed to install everything > automagically but i don't have a Mac ... gettext was added to the lode and it "just works". Updating lode and rerunning its setup will add gettext for anyone who had already

Re: Build failure with current master on MacOS

On Mon, Jul 24, 2017 at 3:33 PM, Alexander Thurgood wrote: > Le 24/07/2017 à 15:16, Michael Stahl a écrit : > >> (here "fixed" means you'll get an error message from configure instead >> that tells you to install gettext) >> > > At least the message is explicit enough ;-)

Re: Build failure with current master on MacOS

On 08/02/2017 03:12 PM, Christian Lohmaier wrote: On Tue, Jul 25, 2017 at 1:18 PM, Tor Lillqvist wrote: But we have traditionally strongly advised against polluting one's build environment on macOS with Homebrew and similar. Has this changed? No, has not changed. Homebrew, Fink,

Re: Build failure with current master on MacOS

Hi *, On Tue, Jul 25, 2017 at 1:18 PM, Tor Lillqvist wrote: > >> GNU gettext package is available in Homebrew. >> > > But we have traditionally strongly advised against polluting one's build > environment on macOS with Homebrew and similar. Has this changed? No, has not changed.

Re: Build failure with current master on MacOS

Hi Alex, Alexander Thurgood píše v Út 25. 07. 2017 v 13:26 +0200: > Apparently. Or rather, there appears to be some creep in the general > direction of adding further build dependencies to one's environment. Another possibility would be to add gettext to external/ for macOS & build it as part

Re: Build failure with current master on MacOS

Le 25/07/2017 à 13:18, Tor Lillqvist a écrit : > > GNU gettext package is available in Homebrew. > > > But we have traditionally strongly advised against polluting one's build > environment on macOS with Homebrew and similar. Has this changed? > Apparently. Or rather, there appears to

Re: Build failure with current master on MacOS

> GNU gettext package is available in Homebrew. > > But we have traditionally strongly advised against polluting one's build environment on macOS with Homebrew and similar. Has this changed? --tml ___ LibreOffice mailing list

Re: Build failure with current master on MacOS

Hi, GNU gettext package is available in Homebrew. https://brew.sh/ Shinnok > On 24 Jul 2017, at 16:29, Caolán McNamara wrote: > >> On Mon, 2017-07-24 at 15:24 +0200, Alexander Thurgood wrote: >>> Le 24/07/2017 à 15:16, Michael Stahl a écrit : >>> (how one would best

Re: Build failure with current master on MacOS

Le 24/07/2017 à 16:29, Caolán McNamara a écrit : Thanks for the headsup ! Alex ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Build failure with current master on MacOS

Michael Stahl-2 wrote > ... > this should be fixed on master with commit > 8c9ed261cb9201774943e438cf5394c1dcfa8c49 I confirm building works for me now. Just some remarks about MacOs build and run: 1) soffice bin seems to be in a different location: here's the result of find . -name "soffice*"

Re: Build failure with current master on MacOS

On Mon, 2017-07-24 at 15:24 +0200, Alexander Thurgood wrote: > Le 24/07/2017 à 15:16, Michael Stahl a écrit : > > (how one would best install gettext on MacOS is another question > > that i don't know the answer to; perhaps via LODE ?) > > > > Ok, thanks, but I guess it still means I can't build

Re: Build failure with current master on MacOS

Le 24/07/2017 à 15:16, Michael Stahl a écrit : > (here "fixed" means you'll get an error message from configure instead > that tells you to install gettext) > At least the message is explicit enough ;-) I don't build via LODE, just the standard OSX Terminal.app. It has worked fine (with the

Re: Build failure with current master on MacOS

Le 24/07/2017 à 15:16, Michael Stahl a écrit : > > this should be fixed on master with commit > 68d7faae7d748b6adcf8ba71a5b7ec9d80031c1b > > (here "fixed" means you'll get an error message from configure instead > that tells you to install gettext) > > (how one would best install gettext on

Re: Build failure with current master on MacOS

On 24.07.2017 14:54, Alexander Thurgood wrote: > Le 24/07/2017 à 14:45, Michael Stahl a écrit : > >> what does this say: >> >> grep MSG config_host.mk >> > > Both MSGFMT and MSGUNIQ are undefined. > this should be fixed on master with commit 68d7faae7d748b6adcf8ba71a5b7ec9d80031c1b (here

Re: Build failure with current master on MacOS

Le 24/07/2017 à 14:45, Michael Stahl a écrit : > what does this say: > > grep MSG config_host.mk > Both MSGFMT and MSGUNIQ are undefined. Alex ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org

Re: Build failure with current master on MacOS

On 24.07.2017 11:11, Alexander Thurgood wrote: > Hi all, > > My master build is currently failing after a make clean and fresh git > pull when building MO first in accfr, and now avmediafr - have there > been some recent changes to gettext pushed to master or some other > element of the FR

Re: Build failure with current master on MacOS

Le 24/07/2017 à 13:09, Michael Stahl a écrit : Hi all, >> [PKG] python3 >> /Users/XXX/lo/lode/dev/core/solenv/gbuild/Package.mk:81: *** Something >> depends on package python3 which does not exist.. Stop. >> > > this should be fixed on master with commit >

Re: Build failure with current master on MacOS

On 24.07.2017 11:54, julien2412 wrote: > [PKG] python3 > /Users/XXX/lo/lode/dev/core/solenv/gbuild/Package.mk:81: *** Something > depends on package python3 which does not exist.. Stop. > this should be fixed on master with commit 8c9ed261cb9201774943e438cf5394c1dcfa8c49

Re: Build failure with current master on MacOS

Hello Alex, I hadn't built on MacOs since several weeks so I did these: - updated MacOs to 10.12.6 - uninstalled XCode (which was 7.X.X version) - deleted ~/Library/Developer/XCode remark: I had overlooked this: ~/Library/Caches/com.apple.dt.Xcode (see

Re: BUILD FAILURE

> No Sir, my disk space is absolutely fine. > (No need to call me "sir".) Then there is some other reason, as Markus said, why that one object file is truncated. Might be hard to figure out in retrospect what happened, unless you remember rebooting bluntly, or otherwise interrupting the build.

Re: BUILD FAILURE

No Sir, my disk space is absolutely fine. 20.5 GB Free. On 27-Dec-2016 8:04 PM, "Markus Mohrhard" wrote: > Hey, > > On Tue, Dec 27, 2016 at 3:31 PM, Tamsil Amani wrote: > >> I was trying to build libreoffice on my machine, Ubuntu 16.04, but

Re: BUILD FAILURE

> > > /home/tamsil/libreoffice/workdir/CxxObject/sw/qa/extras/ooxmlexport/ooxmlexport.o: > file not recognized: File truncated > > Disk full? You need tens of gigabytes of disk space to build LibreOffice. (It's counter-productive to try to give an exact number.) --tml

Re: BUILD FAILURE

Hey, On Tue, Dec 27, 2016 at 3:31 PM, Tamsil Amani wrote: > I was trying to build libreoffice on my machine, Ubuntu 16.04, but somehow > don't know why the build fails. > > Commands: > > 1) ./g pull -r : Works OK > > 2) make : Shows failure > > Here is the log. > >

Re: Build failure while experimenting with LTO

On 06/28/2016 12:00 AM, Davide Italiano wrote: but the problem is still there :( BTW, I think this is related to clang because I'm able to reproduce without LTO: $ ./autogen.sh CC=~/work/llvm/build-release/bin/clang CXX=~/work/llvm/build-release/bin/clang++ --enable-dbgutil --without-java

Re: Build failure while experimenting with LTO

On Sun, Jun 26, 2016 at 6:50 PM, Davide Italiano wrote: > On Sun, Jun 26, 2016 at 6:48 PM, Davide Italiano > wrote: >> Hi, >> I'm experimenting a bit with LTO using clang and lld (the new LLVM linker). >> I'm able to build a decent fraction of

Re: Build failure while experimenting with LTO

On Sun, Jun 26, 2016 at 6:48 PM, Davide Italiano wrote: > Hi, > I'm experimenting a bit with LTO using clang and lld (the new LLVM linker). > I'm able to build a decent fraction of libreoffice if I invoke > autogen.sh like this: > > ./autogen.sh

Re: Build Failure on Ubuntu 15.10 after upgradation from 15.04

Hi Varun, On Sat, Dec 5, 2015 at 12:49 AM, Varun Dhall wrote: I am getting some errors while building the latest master on my machine. Actually I have recently upgraded from Ubuntu 15.04 to 15.10 before upgradation everything was working great (7-10 days old

Build for Google Docs (was: Re: Build failure in 4.4 branch with --enable-ext-google-docs on Xubuntu 14.04 amd64: undefined reference to symbol 'dlclose@@GLIBC_2.2.5')

Miklos wrote: On Sun, Jan 25, 2015 at 04:27:12PM +, David Gerard dgerard at gmail.com wrote: I want to write a blog post saying how I did this - before I do so, will there be a problem putting it up with that secret (which is presumably the one in every TDF build)? Should I use another

Re: Build failure in 4.4 branch with --enable-ext-google-docs on Xubuntu 14.04 amd64: undefined reference to symbol 'dlclose@@GLIBC_2.2.5'

Le 26/01/2015 10:49, Miklos Vajna a écrit : Hi Miklos, https://wiki.documentfoundation.org/Development/ReleaseBuilds documents that the gdrive flags are also used for TDF builds, so they are available for the general public. Thanks, but that page references x86 builds for MacOSX and not

Re: Build failure in 4.4 branch with --enable-ext-google-docs on Xubuntu 14.04 amd64: undefined reference to symbol 'dlclose@@GLIBC_2.2.5'

On Mon, Jan 26, 2015 at 05:16:14PM +0100, Alexander Thurgood alex.thurg...@gmail.com wrote: Thanks, but that page references x86 builds for MacOSX and not x86_64. Is it still applicable for our 64bit OSX releases ? Norbert, am I right that just a simple x86 - 64bit rename is needed at

Re: Build failure in 4.4 branch with --enable-ext-google-docs on Xubuntu 14.04 amd64: undefined reference to symbol 'dlclose@@GLIBC_2.2.5'

On Mon, Jan 26, 2015 at 11:22 AM, Miklos Vajna vmik...@collabora.co.uk wrote: On Mon, Jan 26, 2015 at 05:16:14PM +0100, Alexander Thurgood alex.thurg...@gmail.com wrote: Thanks, but that page references x86 builds for MacOSX and not x86_64. Is it still applicable for our 64bit OSX releases ?

Re: Build failure in 4.4 branch with --enable-ext-google-docs on Xubuntu 14.04 amd64: undefined reference to symbol 'dlclose@@GLIBC_2.2.5'

On Mon, Jan 26, 2015 at 10:16 AM, Alexander Thurgood alex.thurg...@gmail.com wrote: Le 26/01/2015 10:49, Miklos Vajna a écrit : Hi Miklos, https://wiki.documentfoundation.org/Development/ReleaseBuilds documents that the gdrive flags are also used for TDF builds, so they are available for

Re: Build failure in 4.4 branch with --enable-ext-google-docs on Xubuntu 14.04 amd64: undefined reference to symbol 'dlclose@@GLIBC_2.2.5'

Hi Alex, https://wiki.documentfoundation.org/Development/ReleaseBuilds documents that the gdrive flags are also used for TDF builds, so they are available for the general public. Regards, Miklos signature.asc Description: Digital signature ___

Re: Build failure in 4.4 branch with --enable-ext-google-docs on Xubuntu 14.04 amd64: undefined reference to symbol 'dlclose@@GLIBC_2.2.5'

Hi David, On Sun, Jan 25, 2015 at 04:27:12PM +, David Gerard dger...@gmail.com wrote: I want to write a blog post saying how I did this - before I do so, will there be a problem putting it up with that secret (which is presumably the one in every TDF build)? Should I use another one? If

Re: Build failure in 4.4 branch with --enable-ext-google-docs on Xubuntu 14.04 amd64: undefined reference to symbol 'dlclose@@GLIBC_2.2.5'

Le 26/01/2015 10:04, Miklos Vajna a écrit : Hi Miklos, See here on how to obtain your own ID: https://developers.google.com/drive/web/about-auth So, just to further my understanding of the practicalities involved, if I want to use Google Docs/Drive CMIS integration on Mac, or Linux, for

Re: Build failure in 4.4 branch with --enable-ext-google-docs on Xubuntu 14.04 amd64: undefined reference to symbol 'dlclose@@GLIBC_2.2.5'

On 17 December 2014 at 12:10, Andras Timar tima...@gmail.com wrote: On Wed, Dec 17, 2014 at 12:35 PM, David Gerard dger...@gmail.com wrote: [making LO connect to Google Drive reliably] So I need to ... literally compile my credentials into LO? How do the Windows builds of 4.3 and 4.4beta1

Re: Build failure in 4.4 branch with --enable-ext-google-docs on Xubuntu 14.04 amd64: undefined reference to symbol 'dlclose@@GLIBC_2.2.5'

Hi, On Wed, Dec 17, 2014 at 10:26 AM, David Gerard dger...@gmail.com wrote: (originally filed as Bug 87293, but I was redirected here) I am attempting to build with the Google Drive connection: ./autogen.sh --enable-ext-google-docs --with-gdrive-client-secret ; make --enable-ext-google-docs

Re: Build failure in 4.4 branch with --enable-ext-google-docs on Xubuntu 14.04 amd64: undefined reference to symbol 'dlclose@@GLIBC_2.2.5'

Andras Timar wrote: --enable-ext-google-docs enables the obsolete Google Docs extension, you don't need that. For the built-in Google Drive support via CMIS you need --with-gdrive-client-secret and --with-google-drive-client-id. Of course, you need to register with Google first, and pass

Re: Build failure in 4.4 branch with --enable-ext-google-docs on Xubuntu 14.04 amd64: undefined reference to symbol 'dlclose@@GLIBC_2.2.5'

On Wed, Dec 17, 2014 at 12:35 PM, David Gerard dger...@gmail.com wrote: Andras Timar wrote: --enable-ext-google-docs enables the obsolete Google Docs extension, you don't need that. For the built-in Google Drive support via CMIS you need --with-gdrive-client-secret and

Re: Build failure in 4.4 branch with --enable-ext-google-docs on Xubuntu 14.04 amd64: undefined reference to symbol 'dlclose@@GLIBC_2.2.5'

On 17 December 2014 at 12:10, Andras Timar tima...@gmail.com wrote: On Wed, Dec 17, 2014 at 12:35 PM, David Gerard dger...@gmail.com wrote: So I need to ... literally compile my credentials into LO? How do the Windows builds of 4.3 and 4.4beta1 work? Are you saying they have someone's

Re: Build failure in 4.4 branch with --enable-ext-google-docs on Xubuntu 14.04 amd64: undefined reference to symbol 'dlclose@@GLIBC_2.2.5'

I'll need to back port that into the 4.4 branch soon - this is something distributions that enable --as-needed by default for ld will get. In other words, only Debian based distros will see it :-) Chris On Thursday, December 18, 2014, David Gerard dger...@gmail.com wrote: On 17 December 2014

Re: build failure in [build SAX]

On 10/13/2014 06:29 AM, Terrence Enger wrote: on debian-wheezy 64-bit. This is my first time using parameters CXXFLAGS=-std=c++11 --disable-gstreamer --enable-gstreamer-0-10. By the way, you should not need to specify CXXFLAGS=-std=c++11, configure should figure out that it needs to use

[solved] Re: build failure in [build SAX]

Thanks to the good folks on IRC, my build is proceeding. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: build failure, clock_gettime undefined, linking libavmedialo.so

Hi, On Fri, May 16, 2014 at 03:19:21PM +0100, Tamas Zolnai wrote: On Friday, May 16, 2014 15:00 BST, Terrence Enger ten...@iseries-guru.com wrote: My build of commit 48eccfb, fetched around 2014-05-16 00:57 UTC, is failing with messages: [build LNK] Library/libavmedialo.so

Re: build failure, clock_gettime undefined, linking libavmedialo.so

On Friday, May 16, 2014 15:00 BST, Terrence Enger ten...@iseries-guru.com wrote: Zolnai, My build of commit 48eccfb, fetched around 2014-05-16 00:57 UTC, is failing with messages: [build LNK] Library/libavmedialo.so

Re: build failure, clock_gettime undefined, linking libavmedialo.so

On Fri, 2014-05-16 at 21:12 +0100, Tamas Zolnai wrote: On Friday, May 16, 2014 20:38 BST, Terrence Enger ten...@iseries-guru.com wrote: On Fri, 2014-05-16 at 15:19 +0100, Tamas Zolnai wrote: On Friday, May 16, 2014 15:00 BST, Terrence Enger ten...@iseries-guru.com wrote: [snip]

Re: build failure in [build GAL] arrows

Hi, On 17 June 2013 03:19, Terrence Enger ten...@iseries-guru.com wrote: Hi, I have two successive failures building master, each at the step [build GAL] arrows. The first was an incremental build of commit 843735f pulled today (Sunday) around 00:45 UCT, which failed with ... ... Among

Re: Build failure of Gallery on Mac OSX in gengal.bin on master

On Sun, May 19, 2013 at 3:58 AM, Alexander Thurgood alex.thurg...@gmail.com wrote: Hi all, Since yesterday, I have been geting a build failure on OSX 10.8 in gengal.bin with the following, even after a make clean and fresh pull from master : yes gengal does not work on Mac I pushed a patch

Re: Build failure on master with OSX - datetime.hxx

Le 20/04/13 12:09, Jonathan Aquilina a écrit : Still failing for me in dbconversion.cxx:42 : error : integer constant is too large for 'long' type Alex ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org

Re: Build failure on master with OSX - datetime.hxx

On Mon, Apr 22, 2013 at 09:29:45AM +0200, Alexander Thurgood wrote: Still failing for me in dbconversion.cxx:42 : error : integer constant is too large for 'long' type Should have been fixed by commit 693d25f8a601ee3738a396fbd8a9b838f19e39c9 Author: Norbert Thiebaud nthieb...@gmail.com Date:

  1   2   >