Re: build failure in cmis_content.cxx

[Michael Stahl]

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/libreoffice-upstream-bundled/label/mt-snow-02-brq/include/curlinit.hxx:
 In function ‘void InitCurl_easy(CURL*)’:
/home/jenkins/workspace/libreoffice-upstream-bundled/label/mt-snow-02-brq/include/curlinit.hxx:28:30:
 error: ‘GetCABundleFile’ was not declared in this scope
28 | char const* const path = GetCABundleFile();
   |  ^~~


3aca2d9776a871f15009a1aa70628ba3a03ee147 is bad
0156cba6e34026f8fa0f2912e503378a5ec2208d is good
(no bisecting yet)

Is it a known issue? All libs except zlib, openssl and boost are
bundled, "make distclean" before every build.


so you have SYSTEM_OPENSSL=TRUE and SYSTEM_CURL=

i didn't expect anyone to try that since it doesn't make a lot of sense 
so the #ifdefs don't cope with it... can you send a patch to replace

- !defined(SYSTEM_OPENSSL)
+ !defined(SYSTEM_OPENSSL)||!defined(SYSTEM_CURL)
or change your build config to use system curl?

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

[alice]

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 -d output is available:
> https://img.ayaya.dev/Ii6L84rHzXfv
>
> i would assume this is a recent bug in the build system, as afaict the 
> relevant
> part of the length of the argument list there in that log is about 800k.
> meanwhile:
>
> $ getconf ARG_MAX # glibc
> 2097152
> $ getconf ARG_MAX # musl
> 131072
>
> and that has not changed for a long time for either (afaik). so, it would have
> to be something changed since 7.3.7.2 (which builds fine).
>
> i also reproduced this on latest master (around
> d3a5a97f77378421f17b1fa43d0b88dde8bc686a) without any system libraries or 
> fancy
> configure arguments (just default ./configure), so i don't think any other
> information is necessary, aside from it being with make 4.4.

this actually seems to only happen with a controlling terminal - building in
e.g. a CI job works fine. strange. but i guess the issue isn't that bad in
that case.

Re: Build failure with gpgme-1.18.0

[Sam James]

> 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 logs in that patch, so
>> there's a record? I'll then look into it.
>> 
>> Cheers,
>> 
>> -- Thorsten
> 
> I don't have a gerrit account so some notes here:
> 
> I had tried to remove these lines 12564-12567 from configure.ac to pass the 
> configure check.
> 

Please share a diff of what you removed. You can't simply remove the 
AC_CHECK_LIB
line with no other changes because GPGMEPP_LIBS will then be blank.

> https://cgit.freedesktop.org/libreoffice/core/tree/configure.ac?h=libreoffice-7-4-0#n12564
> 
> This leads to this build error later:
> [snip]
> I can give your patch a try in 7.4.x later
> 

Best,
sam

> -Andy
> Arch Linux



signature.asc
Description: Message signed with OpenPGP

Re: Build failure with gpgme-1.18.0

[Andreas Radke]

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 it.
> 
> Cheers,
> 
> -- Thorsten

I don't have a gerrit account so some notes here:

I had tried to remove these lines 12564-12567 from configure.ac to pass the 
configure check.

https://cgit.freedesktop.org/libreoffice/core/tree/configure.ac?h=libreoffice-7-4-0#n12564

This leads to this build error later:


[build CXX] idl/source/prj/command.cxx
/usr/bin/ld: /tmp/cccDZPYB.ltrans9.ltrans.o: in function 
`comphelper::DocPasswordHelper::decryptGpgSession(com::sun::star::uno::Sequence
 > const&)':
:(.text+0x796e): undefined reference to `GpgME::initializeLibrary()'
/usr/bin/ld: :(.text+0x7980): undefined reference to 
`GpgME::checkEngine(GpgME::Protocol)'
/usr/bin/ld: :(.text+0x7998): undefined reference to 
`GpgME::Context::createForProtocol(GpgME::Protocol)'
/usr/bin/ld: :(.text+0x79be): undefined reference to 
`GpgME::Context::setArmor(bool)'
/usr/bin/ld: :(.text+0x7a6e): undefined reference to 
`GpgME::Data::Data(char const*, unsigned long, bool)'
/usr/bin/ld: :(.text+0x7a7e): undefined reference to 
`GpgME::Data::Data()'
/usr/bin/ld: :(.text+0x7a9f): undefined reference to 
`GpgME::Context::decrypt(GpgME::Data const&, GpgME::Data&)'
/usr/bin/ld: :(.text+0x7aac): undefined reference to 
`GpgME::Data::seek(long, int)'
/usr/bin/ld: :(.text+0x7adb): undefined reference to 
`GpgME::Data::read(void*, unsigned long)'
/usr/bin/ld: :(.text+0x7e09): undefined reference to 
`GpgME::Error::isCanceled() const'
/usr/bin/ld: :(.text+0x7e25): undefined reference to 
`GpgME::Error::isCanceled() const'
/usr/bin/ld: :(.text+0x7ee0): undefined reference to 
`GpgME::Data::seek(long, int)'
/usr/bin/ld: :(.text+0x7f33): undefined reference to 
`GpgME::Data::read(void*, unsigned long)'
/usr/bin/ld: /tmp/cccDZPYB.ltrans13.ltrans.o: in function 
`comphelper::OStorageHelper::CreateGpgPackageEncryptionData()':
:(.text+0x750e): undefined reference to 
`GpgME::checkEngine(GpgME::Protocol)'
/usr/bin/ld: :(.text+0x7526): undefined reference to 
`GpgME::Context::createForProtocol(GpgME::Protocol)'
/usr/bin/ld: :(.text+0x754c): undefined reference to 
`GpgME::Context::setArmor(bool)'
/usr/bin/ld: :(.text+0x765d): undefined reference to 
`GpgME::Context::key(char const*, GpgME::Error&, bool)'
/usr/bin/ld: :(.text+0x76ec): undefined reference to 
`GpgME::Data::Data(char const*, unsigned long, bool)'
/usr/bin/ld: :(.text+0x7703): undefined reference to 
`GpgME::Data::Data()'
/usr/bin/ld: :(.text+0x7735): undefined reference to 
`GpgME::Context::encrypt(std::vector > 
const&, GpgME::Data const&, GpgME::Data&, GpgME::Context::EncryptionFlags)'
/usr/bin/ld: :(.text+0x7742): undefined reference to 
`GpgME::Data::seek(long, int)'
/usr/bin/ld: :(.text+0x776b): undefined reference to 
`GpgME::Data::read(void*, unsigned long)'
/usr/bin/ld: :(.text+0x77c9): undefined reference to 
`GpgME::Data::seek(long, int)'
/usr/bin/ld: :(.text+0x780e): undefined reference to 
`GpgME::Data::read(void*, unsigned long)'
/usr/bin/ld: :(.text+0x80a1): undefined reference to 
`GpgME::Error::isCanceled() const'
/usr/bin/ld: :(.text+0x84ed): undefined reference to 
`GpgME::Error::isCanceled() const'
collect2: error: ld returned 1 exit status
make[1]: *** 
[/build/libreoffice-fresh/src/libreoffice-7.4.0.3/comphelper/Library_comphelper.mk:20:
 
/build/libreoffice-fresh/src/libreoffice-7.4.0.3/instdir/program/libcomphelper.so]
 Error 1
make[1]: *** Waiting for unfinished jobs
make: *** [Makefile:289: build] Error 2
==> ERROR: A failure occurred in build().


I can give your patch a try in 7.4.x later

-Andy
Arch Linux


pgpPtGKtWc4M6.pgp
Description: Digitale Signatur von OpenPGP

Re: Build failure with gpgme-1.18.0

[Thorsten Behrens]

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 seems to have worked fine for us in Gentoo by exporting
> the cache variable.
> 
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 it.

Cheers,

-- Thorsten


signature.asc
Description: PGP signature

Re: Build failure with gpgme-1.18.0

[Sam James]

> 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 uses to detect [0]
>> gpgme:
>> 
> The reason for that was some kde distro packages shipping their own
> copy of gpgmepp. I've got no insight what's the current story there,
> but plausibly we can get away with dropping that test now?
> 

Did some digging as I hadn't heard of this but I wanted to be sure,
and it looks like it goes back to https://gerrit.libreoffice.org/c/core/+/34130/
and 
https://github.com/LibreOffice/core/commit/aceba1e1af7ba63d29f35022741d3c764df63983.

I don't see a reference to a bug there so I can't check a distro
in particular, but gpgme hasn't depended on KDE libs for a long while,
so I think we're good as-is to just drop it.

(I've also not seen any workarounds like this in other projects).

Best,
sam


signature.asc
Description: Message signed with OpenPGP

Re: Build failure with gpgme-1.18.0

[Sam James]

> 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 Gentoo by exporting
the cache variable.

Could you be more specific please? I'm not in #libreoffice-dev.


> -Andy
> Arch Linux



signature.asc
Description: Message signed with OpenPGP

Re: Build failure with gpgme-1.18.0

[Andreas Radke]

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

[Thorsten Behrens]

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 distro packages shipping their own
copy of gpgmepp. I've got no insight what's the current story there,
but plausibly we can get away with dropping that test now?

Cheers,

-- Thorsten


signature.asc
Description: PGP signature

Re: build failure mac cross-compiling

[Stephan Bergmann]

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/core/commit/?id=4537886ec1de8beed02c7aea34a50727bc058bbd, 
the build fails with


make[2]: Making `all' in `stubdata'

*** ERROR - configure could not detect your platform
*** see the readme.html
*** or, try copying icu/source/config/mh-linux to mh-unknown
***   and editing it.

see complete log here: https://paste.ee/p/5Dz28

OTOH, it works if I remove the --host/--build flags.


see 
 
"Drop support for $host_os = 'macos*', in addition to 'darwin*'"

Re: Build failure on Linux (libeot)

[Jan-Marek Glogowski]

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 directory: 
'/home/julien/lo/libreoffice/workdir/UnpackedTarball/libeot/.libs/libeot.a'
make[1]: *** [/home/julien/lo/libreoffice/vcl/Library_vcl.mk:20 : 
/home/julien/lo/libreoffice/instdir/program/libvcllo.so] Erreur 1


I attached config.log + autogen.input

Noticing ce54ba96f38b4af3aab1a7064078ee406eb021c6 "Use 
libo_CHECK_SYSTEM_MODULE for eot"


thought you might have some idea to fix this.


Untested, because I have some appointments, but maybe you can test: 
https://gerrit.libreoffice.org/c/core/+/127737


HTH

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

[Noel Grandin]

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'

[Stephan Bergmann]

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 I'm not family with how this 
patching/external system works. If you could give me some tips or something to 
try, I'd be happy to test it out for you.


In RepositoryExternal.mk's !SYSTEM_CPPUNIT definition of 
gb_LinkTarget__use_cuckoo_headers, you'll probably need something like


  $(call gb_LinkTarget_add_libs,$(1),-latomic)

properly if'ed for your specific i686 case.

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

[Luke Benes]

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 
patching/external system works. If you could give me some tips or something to 
try, I'd be happy to test it out for you.  

-Luke

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

[Luke Benes]

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 
causes clang to spam 
clang-12: warning: -latomic: 'linker' input unused 
[-Wunused-command-line-argument]

when building.

-Luke

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

[Rene Engelhard]

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, I get a similar failure to 
> the initial failure. When I build it with gcc-11, the build is successful. 
>
> At this point, it appears to be a bug in clang. 

Or clang needs -latomic and gcc not.


Regards,


Rene

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

[Luke Benes]

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

At this point, it appears to be a bug in clang. 

-Luke


[ 14%] Linking CXX executable hellohash
/usr/bin/ld: CMakeFiles/hellohash.dir/hellohash.cc.o: in function 
`std::atomic::load(std::memory_order) const':
hellohash.cc:(.text._ZNKSt6atomicIdE4loadESt12memory_order[_ZNKSt6atomicIdE4loadESt12memory_order]+0x39):
 undefined reference to `__atomic_load'
clang-14: error: linker command failed with exit code 1 (use -v to see 
invocation)
make[2]: *** [examples/CMakeFiles/hellohash.dir/build.make:97: 
examples/hellohash] Error 1
make[1]: *** [CMakeFiles/Makefile2:358: examples/CMakeFiles/hellohash.dir/all] 
Error 2

$ clang --version
clang version 14.0.0 (https://github.com/llvm/llvm-project.git 
c78ed20784ee7ffb60b0879197e34225325aafd0)
Target: i686-pc-linux-gnu

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

[Rene Engelhard]

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::pair rtl::OUString>, svl::(anonymous namespace)::HashFunction, svl::(anonymous 
> namespace)::EqualsFunction, std::allocator std::pair > >, 4u>::cuckoo_status 
> libcuckoo::cuckoohash_map<_rtl_uString*, std::pair rtl::OUString>, svl::(anonymous namespace)::HashFunction, svl::(anonymous 
> namespace)::EqualsFunction, std::allocator std::pair > >, 
> 4u>::cuckoo_fast_double, 
> std::integral_constant >(unsigned int)':
> sharedstringpool.cxx:(.text+0x14ec): undefined reference to `__atomic_load'
> /usr/lib/gcc/i586-suse-linux/11/../../../../i586-suse-linux/bin/ld: 
> sharedstringpool.cxx:(.text+0x17f6): undefined reference to `__atomic_load'
> clang-12: error: linker command failed with exit code 1 (use -v to see 
> invocation)
> make[1]: *** [/core/svl/Library_svl.mk:20: /core/instdir/program/libsvllo.so] 
> Error 1
> make[1]: *** Waiting for unfinished jobs
> make: *** [Makefile:288: build] Error 2

Hmm, trying to reproduce... It builds for me:

[build DEP] LNK:Library/libsvllo.so
[build LNK] Library/libsvllo.so
S=/home/rene/LibreOffice/git/master && I=$S/instdir && W=$S/workdir && 
mkdir -p $W/Dep/LinkTarget/Library/ && RESPONSEFILE=/tmp/gbuild.rt7Maz
&&
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/program:$I/program"  
$W/LinkTarget/Executable/concat-deps ${RESPONSEFILE} >
$W/Dep/LinkTarget/Library/libsvllo.so.d.tmp && rm -f ${RESPONSEFILE}
mv
/home/rene/LibreOffice/git/master/workdir/Dep/LinkTarget/Library/libsvllo.so.d.tmp
/home/rene/LibreOffice/git/master/workdir/Dep/LinkTarget/Library/libsvllo.so.d
S=/home/rene/LibreOffice/git/master && I=$S/instdir && W=$S/workdir && 
/usr/bin/ccache i686-linux-gnu-g++ -pthread -shared -Wl,-z,noexecstack  
-Wl,-z,origin '-Wl,-rpath,$ORIGIN' -Wl,-rpath-link,$I/program 
-Wl,-z,defs -Wl,-rpath-link,/lib:/usr/lib -Wl,-z,combreloc 
-Wl,--hash-style=gnu  -Wl,-Bsymbolic-functions
-L$W/LinkTarget/StaticLibrary -L$I/sdk/lib  -L$I/program  -L$I/program
-Wl,-z,relro  $W/CxxObject/svl/source/config/asiancfg.o
$W/CxxObject/svl/source/config/cjkoptions.o
$W/CxxObject/svl/source/config/ctloptions.o
$W/CxxObject/svl/source/config/itemholder2.o
$W/CxxObject/svl/source/config/languageoptions.o
$W/CxxObject/svl/source/crypto/cryptosign.o
$W/CxxObject/svl/source/filepicker/pickerhistory.o
$W/CxxObject/svl/source/items/aeitem.o
$W/CxxObject/svl/source/items/cenumitm.o
$W/CxxObject/svl/source/items/cintitem.o
$W/CxxObject/svl/source/items/custritm.o
$W/CxxObject/svl/source/items/flagitem.o
$W/CxxObject/svl/source/items/globalnameitem.o
$W/CxxObject/svl/source/items/grabbagitem.o
$W/CxxObject/svl/source/items/ilstitem.o
$W/CxxObject/svl/source/items/imageitm.o
$W/CxxObject/svl/source/items/intitem.o
$W/CxxObject/svl/source/items/int64item.o
$W/CxxObject/svl/source/items/itemiter.o
$W/CxxObject/svl/source/items/itempool.o
$W/CxxObject/svl/source/items/itemprop.o
$W/CxxObject/svl/source/items/IndexedStyleSheets.o
$W/CxxObject/svl/source/items/itemset.o
$W/CxxObject/svl/source/items/lckbitem.o
$W/CxxObject/svl/source/items/legacyitem.o
$W/CxxObject/svl/source/items/macitem.o
$W/CxxObject/svl/source/items/poolcach.o
$W/CxxObject/svl/source/items/poolio.o
$W/CxxObject/svl/source/items/poolitem.o
$W/CxxObject/svl/source/items/ptitem.o
$W/CxxObject/svl/source/items/rectitem.o
$W/CxxObject/svl/source/items/rngitem.o
$W/CxxObject/svl/source/items/sitem.o
$W/CxxObject/svl/source/items/slstitm.o
$W/CxxObject/svl/source/items/srchitem.o
$W/CxxObject/svl/source/items/stringio.o
$W/CxxObject/svl/source/items/stritem.o
$W/CxxObject/svl/source/items/style.o
$W/CxxObject/svl/source/items/stylepool.o
$W/CxxObject/svl/source/items/visitem.o
$W/CxxObject/svl/source/items/whiter.o
$W/CxxObject/svl/source/misc/PasswordHelper.o
$W/CxxObject/svl/source/misc/adrparse.o
$W/CxxObject/svl/source/misc/documentlockfile.o
$W/CxxObject/svl/source/misc/msodocumentlockfile.o
$W/CxxObject/svl/source/misc/filenotation.o
$W/CxxObject/svl/source/misc/fstathelper.o
$W/CxxObject/svl/source/misc/getstringresource.o
$W/CxxObject/svl/source/misc/gridprinter.o
$W/CxxObject/svl/source/misc/inethist.o
$W/CxxObject/svl/source/misc/inettype.o
$W/CxxObject/svl/source/misc/lngmisc.o
$W/CxxObject/svl/source/misc/lockfilecommon.o
$W/CxxObject/svl/source/misc/ownlist.o
$W/CxxObject/svl/source/misc/sharecontrolfile.o
$W/CxxObject/svl/source/misc/sharedstring.o
$W/CxxObject/svl/source/misc/sharedstringpool.o
$W/CxxObject/svl/source/misc/strmadpt.o
$W/CxxObject/svl/source/misc/urihelper.o
$W/CxxObject/svl/source/notify/SfxBroadcaster.o
$W/CxxObject/svl/source/notify/broadcast.o
$W/CxxObject/svl/source/notify/hint.o
$W/CxxObject/svl/source/notify/isethint.o
$W/CxxObject/svl/source/notify/listener.o

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

[Rene Engelhard]

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

[Michael Stahl]

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 libnss3util.so but since a shared object with that name is 
already loaded it's a no-op.


...or, more likely, first some LO library caused the LO 
program/libnss3util.so to be loaded, and then the JVM loaded 
/usr/lib64/libnss3.so, which likely has a DT_NEEDED of libnss3util.so 
(at least my nss-3.65.0-1.fc34.x86_64 does) and, as you already 
concluded, happily picks up the wrong, already loaded 
program/libnss3util.so


oh yes indeed i mixed up what depends on what...

maybe we should think about defaulting to --with-system-nss on Linux, particularly for release builds; there hasn't been a reason to bundle it in 5 years or so. 


here is a patch to do that:

https://gerrit.libreoffice.org/c/core/+/120388

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

[Luke Benes]

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
https://lists.freedesktop.org/mailman/listinfo/libreoffice

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

[Rene Engelhard]

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 clang if present and I follow.)
Just for completeness: same cppunit test failures (didn't try to the
end, just writing the mail after the mfio one) as before with clang builds.

Regards,


Rene


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

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

[Rene Engelhard]

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 which has the uicheck already fixed and
where just the junit breakage remains.

The uicheck failure was

==
FAIL: test_resize_object (drawinglayer.ImpressDrawinglayerTest)
--
Traceback (most recent call last):
  File
"/tmp/autopkgtest-lxc.a86_7ziu/downtmp/build.BHI/src/uitest/impress_tests/drawinglayer.py",
line 81, in test_resize_object
    self.assertEqual(9134, document.DrawPages[0].getByIndex(1).Size.Height)
AssertionError: 9134 != 9133

==
FAIL: test_rotate_object (drawinglayer.ImpressDrawinglayerTest)
--
Traceback (most recent call last):
  File
"/tmp/autopkgtest-lxc.a86_7ziu/downtmp/build.BHI/src/uitest/impress_tests/drawinglayer.py",
line 130, in test_rotate_object
    self.assertEqual(9134, document.DrawPages[0].getByIndex(1).Size.Height)
AssertionError: 9134 != 9133

--
Ran 7 tests in 20.516s

FAILED (failures=2)

Regards,


Rene

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

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

[Rene Engelhard]

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 an amd64 build fails its tests miserably here,
just crashes., gcc works fine.)

> I also see the off-by-one gcc test failures.

So it doesn't pass. At least with gcc.


The attachment shows a run (run, fail, run, ..) of the failing
(j|cp)unit tests here. 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.)


Regards,

Rene

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

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

[Luke Benes]

Yes, a 'make check' passes with "stack_guard_gap=1" kernel parameter for the 
java bug and clang 12.

I also see the off-by-one gcc test failures. I think these started with gcc 8 
or 9. We probably have to turn off some floating point math optimization for 
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 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]
https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/-/blob/debian-experimental-7.2/patches/fix-uicheck-tests-on-i386.patch

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

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

[Rene Engelhard]

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]
https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/-/blob/debian-experimental-7.2/patches/fix-uicheck-tests-on-i386.patch

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

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

[Luke Benes]

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/listinfo/libreoffice

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

[Stephan Bergmann]

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 with that name is already 
loaded it's a no-op.


...or, more likely, first some LO library caused the LO 
program/libnss3util.so to be loaded, and then the JVM loaded 
/usr/lib64/libnss3.so, which likely has a DT_NEEDED of libnss3util.so 
(at least my nss-3.65.0-1.fc34.x86_64 does) and, as you already 
concluded, happily picks up the wrong, already loaded program/libnss3util.so


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

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

[Michael Stahl]

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


Seems to be caused by caused by:
  java.io.IOException: /core/instdir/program/libnssutil3.so: 
version `NSSUTIL_3.59' not found (required by /usr/lib64/libnss3.so)


mozilla-nss should provide  libnss3.so(NSS_3.59)
https://opensuse.pkgs.org/tumbleweed/mozilla-x86_64/mozilla-nss-32bit-3.64-1.6.x86_64.rpm.html 



Here is my upgrade log: https://controlc.com/79ec2502
Below is my build log.

If I add, "--with-system-nss" to my autogen.input file, the build 
succeeds without any issue.


Any thoughts has to how to fix this or ideas on the root cause?


So the system lib /usr/lib64/libnss3.so, which is NSS 3.59, picks up 
LO's own /core/instdir/program/libnssutil3.so, which is still at 3.55 
for master...


Debugging that without an openSUSE system was a bit hard... IMHO this 
is a bug in their java-11-openjdk source / java-11-openjdk-headless. 
They provide a patched nss.cfg, on your system in 
/usr/lib64/jvm/java-11-openjdk-11/conf/security/nss.cfg, which sets:


nssLibraryDirectory = /usr/lib64

My one on Debian doesn't.

The result is, that Java now always loads the libnss3.so from that 
directory, instead of using the ld.so search order to find it (man 
ld.so / man dlopen). But LO sets the LD_LIBRARY_PATH, so the ld.so 
will first look for its libraries in /.../instdir/program. And there 
it finds the libnssutil3.so from your build, which is too old and 
misses the NSSUTIL_3.59 symbol, resulting in your error.


I suggest you try, if removing that line helps and then report a bug 
to openSUSE.


uh... that sounds quite awful - did anybody report a bug about this?


actually i'm not sure how this can happen.

oosplash adds the output of "javaldx" to LD_LIBRARY_PATH but nothing 
adds LO's program directory to it.


... 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 with that name is already 
loaded it's a no-op.


maybe we should think about defaulting to --with-system-nss on Linux, 
particularly for release builds; there hasn't been a reason to bundle it 
in 5 years or so.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

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

[Michael Stahl]

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 caused by:
  java.io.IOException: /core/instdir/program/libnssutil3.so: 
version `NSSUTIL_3.59' not found (required by /usr/lib64/libnss3.so)


mozilla-nss should provide  libnss3.so(NSS_3.59)
https://opensuse.pkgs.org/tumbleweed/mozilla-x86_64/mozilla-nss-32bit-3.64-1.6.x86_64.rpm.html 



Here is my upgrade log: https://controlc.com/79ec2502
Below is my build log.

If I add, "--with-system-nss" to my autogen.input file, the build 
succeeds without any issue.


Any thoughts has to how to fix this or ideas on the root cause?


So the system lib /usr/lib64/libnss3.so, which is NSS 3.59, picks up 
LO's own /core/instdir/program/libnssutil3.so, which is still at 3.55 
for master...


Debugging that without an openSUSE system was a bit hard... IMHO this is 
a bug in their java-11-openjdk source / java-11-openjdk-headless. They 
provide a patched nss.cfg, on your system in 
/usr/lib64/jvm/java-11-openjdk-11/conf/security/nss.cfg, which sets:


nssLibraryDirectory = /usr/lib64

My one on Debian doesn't.

The result is, that Java now always loads the libnss3.so from that 
directory, instead of using the ld.so search order to find it (man ld.so 
/ man dlopen). But LO sets the LD_LIBRARY_PATH, so the ld.so will first 
look for its libraries in /.../instdir/program. And there it finds the 
libnssutil3.so from your build, which is too old and misses the 
NSSUTIL_3.59 symbol, resulting in your error.


I suggest you try, if removing that line helps and then report a bug to 
openSUSE.


uh... that sounds quite awful - did anybody report a bug about this?

maybe we should think about defaulting to --with-system-nss on Linux, 
particularly for release builds; there hasn't been a reason to bundle it 
in 5 years or so.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

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

[Jan-Marek Glogowski]

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/program/libnssutil3.so: version 
`NSSUTIL_3.59' not found (required by /usr/lib64/libnss3.so)

mozilla-nss should provide  libnss3.so(NSS_3.59)
https://opensuse.pkgs.org/tumbleweed/mozilla-x86_64/mozilla-nss-32bit-3.64-1.6.x86_64.rpm.html

Here is my upgrade log: https://controlc.com/79ec2502
Below is my build log.

If I add, "--with-system-nss" to my autogen.input file, the build succeeds 
without any issue.

Any thoughts has to how to fix this or ideas on the root cause?


So the system lib /usr/lib64/libnss3.so, which is NSS 3.59, picks up 
LO's own /core/instdir/program/libnssutil3.so, which is still at 3.55 
for master...


Debugging that without an openSUSE system was a bit hard... IMHO this is 
a bug in their java-11-openjdk source / java-11-openjdk-headless. They 
provide a patched nss.cfg, on your system in 
/usr/lib64/jvm/java-11-openjdk-11/conf/security/nss.cfg, which sets:


nssLibraryDirectory = /usr/lib64

My one on Debian doesn't.

The result is, that Java now always loads the libnss3.so from that 
directory, instead of using the ld.so search order to find it (man ld.so 
/ man dlopen). But LO sets the LD_LIBRARY_PATH, so the ld.so will first 
look for its libraries in /.../instdir/program. And there it finds the 
libnssutil3.so from your build, which is too old and misses the 
NSSUTIL_3.59 symbol, resulting in your error.


I suggest you try, if removing that line helps and then report a bug to 
openSUSE.


HTH
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

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

[Noel Grandin]

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]

[julien2412]

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
https://lists.freedesktop.org/mailman/listinfo/libreoffice

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

[Stephan Bergmann]

 "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

[Mike Kaganski]

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.



--
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: build failure on ubuntu 18.04

[Mike Kaganski]

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/VulkanWindowContext_unix.cpp:19:10:
fatal error: X11/Xlib-xcb.h: No such file or directory
#include 
^~~~
compilation terminated.
/home/ron/libreoffice/solenv/gbuild/LinkTarget.mk:347: recipe for target
'/home/ron/libreoffice/workdir/GenCxxObject/UnpackedTarball/skia/tools/sk_app/unix/VulkanWindowContext_unix.o'
failed
make[1]: ***
[/home/ron/libreoffice/workdir/GenCxxObject/UnpackedTarball/skia/tools/sk_app/unix/VulkanWindowContext_unix.o]
Error 1
make[1]: *** Waiting for unfinished jobs
Makefile:282: recipe for target 'build' failed
make: *** [build] Error 2 

My autogen.sh command looks like this: 


./autogen.sh --enable-debug
--x-includes=/snap/gnome-3-34-1804/36/usr/include/ 


The file Xlib-xcb.h exists in the directory in the X11 directory which
in turn is a child of the one listed in the --x-includes path indicated
above. The file permission is 0644 for the .h file, owner is root. 


On 04.12.2020 1:54, Luke Benes wrote:

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.


The problem that Ron sees is clearly related to the rarely-used (and 
thus not thoroughly tested) --x-includes configuration, which obviously 
is not passed to the newly added skia external. It is a bug that needs 
fixing, and has nothing to do with using old or new wiki instructions 
(where the updated wiki article was discussed and approved on IRC, and 
is a clear improvement over old build-dep way, which results in actual 
problems when newbies report that dependencies installed that way don't 
work with master because of their versions are for older LO versions 
bundled with the distros).


Ron, that looks like a great opportunity for a first contribution to LO! 
:-) You are welcome to join #libreoffice-dev, and discuss any questions 
related to how to change the makefiles of skia to pass the correct 
information there.


--
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: build failure on ubuntu 18.04

[Luke Benes]

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. 
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

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

[julien2412]

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/util/fwm))
 
+$(eval $(call gb_Library_use_custom_headers,fwm,\
+   officecfg/registry \
+))
+
 $(eval $(call gb_Library_set_include,fwm,\
 -I$(SRCDIR)/framework/inc \
 -I$(SRCDIR)/framework/source/inc \

Sorry for the noise



--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

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

[Luke Benes]

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 holiday season to dedicate to 
this project. Will you be available and do you still have a VM dedicated for 
this per the ESC decision?

-Luke
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

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

[Stephan Bergmann]

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-bit builds"

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

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

[Luke Benes]

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 bisect. Thanks 
Tomaž and Luboš!

-Luke
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

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

[Tomaž Vajngerl]

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 compiled with whatever configure
finds to be the most advanced instruction set, and then the code from the
compiled source gets executed unconditionally, without a runtime check. A
runtime check is necessary, as flags like -mavx2 allow the compiler to use
newer instructions even for source code that doesn't explicitly use them.

  Looking at tools/qa/cppunit/test_cpuid.cxx, it seems that it doesn't need any
special CXXFLAGS, as it doesn't use them. And if it does need them, then
those parts need to be split to one source file per instruction set, each
compiled with its matching CXXFLAGS, and then another source file (compiled
normally) needs to call them only after doing a runtime check. See the
description of -mavx2 etc. in 'man gcc' and see 'git grep SSE2 sc/' for an
example.


Right, the test is quite naive and use of INTRINSICS_CXXFLAGS doesn't 
make sense here as it tests the runtime detection only, which is not 
dependent on the compiler flags (it just reports what the CPU supports). 
Probably this was needed in the past because compile and runtime 
detection was mixed with compile time detection, so if the compiler 
flags didn't return support for an instruction set, then runtime 
detection wasn't even performed, but this is not the case with the 
latest code anymore.


I fixed this problem with the test with [1] patch and I'll make a proper 
test at a later date to demonstrate how this is supposed to work.


[1] https://gerrit.libreoffice.org/#/c/82422/

Regards, Tomaž

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

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

[Luboš Luňák]

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

 The INTRINSICS_CXXFLAGS variable is misdesigned or misused. What happens is 
that a source file gets unconditionally compiled with whatever configure 
finds to be the most advanced instruction set, and then the code from the 
compiled source gets executed unconditionally, without a runtime check. A 
runtime check is necessary, as flags like -mavx2 allow the compiler to use 
newer instructions even for source code that doesn't explicitly use them.

 Looking at tools/qa/cppunit/test_cpuid.cxx, it seems that it doesn't need any 
special CXXFLAGS, as it doesn't use them. And if it does need them, then 
those parts need to be split to one source file per instruction set, each 
compiled with its matching CXXFLAGS, and then another source file (compiled 
normally) needs to call them only after doing a runtime check. See the 
description of -mavx2 etc. in 'man gcc' and see 'git grep SSE2 sc/' for an 
example.

> 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)
[...]
> Thread 1 (Thread 0x7f90ea199740 (LWP 8225)):
> #0  0x7f90e824f538 in CppUnit::TestSuiteFactory<(anonymous
> namespace)::CpuInstructionSetSupport>::makeTest() () at
> /core/workdir/LinkTarget/CppunitTest/libtest_tools_test.so #1 
> 0x7f90e9d66f3b in
> CppUnit::TestFactoryRegistry::addTestToSuite(CppUnit::TestSuite*) () at
> /core/workdir/UnpackedTarball/cppunit/src/cppunit/.libs/libcppunit-1.14.so.
>0 #2  0x7f90e9d66e67 in CppUnit::TestFactoryRegistry::makeTest() () at
> /core/workdir/UnpackedTarball/cppunit/src/cppunit/.libs/libcppunit-1.14.so.
>0 #3  0x004042a9 in (anonymous
> namespace)::ProtectedFixtureFunctor::run() const () #4  0x004035be
> in main ()
>
>
> Error: a unit test failed, please do one of:
>
> make CppunitTest_tools_test CPPUNITTRACE="gdb --args"
> ...
> $ cat /proc/cpuinfo
> model name  : Intel(R) Core(TM) i7 CPU 920  @ 2.67GHz
>
> Newer CPU's like my Broadwell Core i3 Processors have no issue with the
> same distros.

-- 
 Luboš Luňák
 l.lu...@collabora.com
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Build failure with latest ICU 64.1

[Andreas Sturmlechner]

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
> maintainer has filed a PR upstream and I'm rebuilding LO again:
> 
> https://github.com/unicode-org/icu/pull/572

Indeed, fixing ICU with the above patch made LO build successfully again, no 
need for xmlsec changes.

Regards,
Andreas



___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Build failure with latest ICU 64.1

[Andreas Sturmlechner]

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:

https://github.com/unicode-org/icu/pull/572

Regards,
Andreas


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Build failure with latest ICU 64.1

[Andreas Sturmlechner]

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:

https://github.com/unicode-org/icu/pull/572

Regards,
Andreas



___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Build failure with latest ICU 64.1

[Miklos Vajna]

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 Vajna 
Date: Fri, 29 Mar 2019 13:47:12 +0100
Subject: [PATCH] base64: move start of C++ guard below includes

Resolves problems around building against newer ICU, see
.
---
 include/xmlsec/base64.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/xmlsec/base64.h b/include/xmlsec/base64.h
index 36d8a493..7e13862f 100644
--- a/include/xmlsec/base64.h
+++ b/include/xmlsec/base64.h
@@ -11,15 +11,15 @@
 #ifndef __XMLSEC_BASE64_H__
 #define __XMLSEC_BASE64_H__
 
-#ifdef __cplusplus
-extern "C" {
-#endif /* __cplusplus */
-
 #include 
 
 #include 
 #include 
 
+#ifdef __cplusplus
+extern "C" {
+#endif /* __cplusplus */
+
 /**
  * XMLSEC_BASE64_LINESIZE:
  *
-- 
2.16.4



signature.asc
Description: Digital signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Build failure with latest ICU 64.1

[Andreas Sturmlechner]

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,
> >   from /usr/include/unicode/ucnv.h:53,
> >   from /usr/include/libxml2/libxml/encoding.h:31,
> >   from /usr/include/libxml2/libxml/parser.h:810,
> >   from /usr/include/libxml2/libxml/globals.h:18,
> >   from /usr/include/libxml2/libxml/threads.h:35,
> >   from /usr/include/libxml2/libxml/xmlmemory.h:218,
> >   from /usr/include/libxml2/libxml/tree.h:1307,
> 
> smells like any of the above files is #include'ed from within an extern 
> "C" block?

Indeed, /usr/include/xmlsec1/xmlsec/base64.h has:

#ifdef __cplusplus
extern "C" {
#endif /* __cplusplus */

#include 

#include 


(this is from system-xmlsec-1.2.27)

Regards,
Andreas



___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Build failure with latest ICU 64.1

[Stephan Bergmann]

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/ $W/Dep/CxxObject/xmlsecurity/source/xmlsec/ 
&& cd /var/tmp/portage/app-office/libreoffice-6.2.1.2/work/libreoffice-6.2.1.2 &&
x86_64-pc-linux-gnu-g++ -DBOOST_ERROR_CODE_HEADER_ONLY -DBOOST_SYSTEM_NO_DEPRECATED -DCPPU_ENV=gcc3 -DLINUX -DNDEBUG 
-DOSL_DEBUG_LEVEL=0 -DUNIX -DUNX -DX86_64 -D_PTHREADS -D_REENTRANT   -DXMLSEC_NO_XSLT -DXSECXMLSEC_DLLIMPLEMENTATION 
-DXSECGPG_DLLIMPLEMENTATION  -DSYSTEM_LIBXML  -DSYSTEM_XMLSEC  -DXMLSEC_CRYPTO_NSS  -DSYSTEM_NSS  -DSYSTEM_NSS   
-fvisibility=hidden-Wall -Wno-missing-braces -Wnon-virtual-dtor -Wendif-labels -Wextra -Wundef -Wunreachable-code 
-Wunused-macros -finput-charset=UTF-8 -fmessage-length=0 -fno-common -pipe  -Wduplicated-cond -Wlogical-op 
-Wshift-overflow=2 -Wunused-const-variable=1 -Wno-cast-function-type -fvisibility-inlines-hidden 
-fstack-protector-strong -fPIC -Wshadow -Woverloaded-virtual -std=gnu++2a   -DEXCEPTIONS_ON -fexceptions 
-fno-enforce-eh-specs -march=native -mtune=native -O2 -pipe   -DLIBO_INTERNAL_ONLY  -c 
$S/xmlsecurity/source/xmlsec/biginteger.cxx -o $W/CxxObject/xmlsecurity/source/xmlsec/biginteger.o  -I$S/include  
-I/usr/lib64/icedtea8/include -I/usr/lib64/icedtea8/include/linux -I$S/config_host  -I$S/xmlsecurity/inc 
-I$S/xmlsecurity/source/gpg -I$S/xmlsecurity/source/xmlsec -I$W/UnpackedTarball/xmlsec/include  
-I$W/CustomTarget/officecfg/registry -I$W/UnoApiHeadersTarget/udkapi/normal -I$W/UnoApiHeadersTarget/offapi/normal 
-I/usr/include   -I/usr/include/gpgme++   -isystem /usr/include/libxml2   -DXMLSEC_CRYPTO_NSS=1 
-D__XMLSEC_FUNCTION__=__func__ -DXMLSEC_NO_SIZE_T -DXMLSEC_NO_AES=1 -DXMLSEC_NO_GOST=1 -DXMLSEC_NO_GOST2012=1 
-DXMLSEC_DL_LIBLTDL=1 -isystem /usr/include/xmlsec1 -isystem /usr/include/libxml2 -isystem /usr/include/nss -isystem 
/usr/include/nspr   -isystem /usr/include/nss -isystem /usr/include/nspr   -isystem /usr/include/nss -isystem 
/usr/include/nspr
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,
  from /usr/include/unicode/ucnv.h:53,
  from /usr/include/libxml2/libxml/encoding.h:31,
  from /usr/include/libxml2/libxml/parser.h:810,
  from /usr/include/libxml2/libxml/globals.h:18,
  from /usr/include/libxml2/libxml/threads.h:35,
  from /usr/include/libxml2/libxml/xmlmemory.h:218,
  from /usr/include/libxml2/libxml/tree.h:1307,


smells like any of the above files is #include'ed from within an extern 
"C" block?



  from /usr/include/xmlsec1/xmlsec/base64.h:18,
  from 
/var/tmp/portage/app-office/libreoffice-6.2.1.2/work/libreoffice-6.2.1.2/xmlsecurity/inc/xmlsec-wrapper.h:32,
  from 
/var/tmp/portage/app-office/libreoffice-6.2.1.2/work/libreoffice-6.2.1.2/xmlsecurity/source/xmlsec/biginteger.cxx:23:
/usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/include/g++-v8/bits/stl_construct.h:72:3:
 error: template with C linkage
template
^~~~

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

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

[Stephan Bergmann]

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 
com.sun.star.ucb.XUniversalContentBroker'


That "Bootstrap exception" line looks more related to the failure than 
the AppFileName warning.  For some reason, the process cannot create 
that UCB service, either because it's missing from the services.rdb 
passed to the process, or because there's some issue loading the 
relevant library.  First thing, did you try `make clean`?



 make[1]: *** [/home/terry/lo_hacking/git/libo6/solenv/gbuild/Gallery.mk:58:
/home/terry/lo_hacking/git/libo6/workdir/Gallery/diagrams.done] Error 1


(and from the "[GAL] education" vs. "workdir/Gallery/diagrams.done" 
mismatch it smells that you're making with parallelism, but without -O, 
which garbles the output from parallel build jobs, and can make it 
unnecessarily hard to decipher build failures)

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Build failure with current master on MacOS

[Caolán McNamara]

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 pulled
lode before the changeover. It might be worth mentioning that gettext
is only needed if --with-lang is used, so ./configure && make doesn't
need it, so most developers probably *don't * need it, but adding that
info the build instructions seemed likely to be more confusing than
not.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Build failure with current master on MacOS

[Norbert Thiebaud]

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 ;-)
>
> I don't build via LODE, just the standard OSX Terminal.app.

The 'standard'  , without any build dep does not have the right make,
the right doxygen, the rigth autoconf/autogen, does not have cmake or
ant or junit...

lode is merely a few line of bash that mostly take care of that.
and lo's configure.ac is lode aware to automatically pick the 'right'
stuff in that case, so that you do not _have_ to pollute your path and
other things.

Norbert
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Build failure with current master on MacOS

[Stephan Bergmann]

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, darwinports of whatever they are called  pollute the
environment, can cause broken builds.
If you use homebrew or other systems like that you're on your own.


What I use is a from-source installation of MacPorts, configured with 
--prefix=... and --with-no-root-privileges so that it doesn't pollute 
the system, and then explicitly pointing LO to whatever is needed from 
that MacPorts installation, e.g. by setting MSGFMT=... and MSGUNIQ=... 
in autogen.input.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Build failure with current master on MacOS

[Christian Lohmaier]

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.
Homebrew, Fink, darwinports of whatever they are called  pollute the
environment, can cause broken builds.
If you use homebrew or other systems like that you're on your own.

ciao
Christian
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Build failure with current master on MacOS

[Jan Holesovsky]

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 of the normal build, but no idea if that is the lesser
evil? :-)

All the best,
Kendy

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Build failure with current master on MacOS

[Alexander Thurgood]

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 be some creep in the general
direction of adding further build dependencies to one's environment.

As I experienced yesterday in a separate incident, seeking to try out
mariadb and a few other gnome/gtk resources, before removing it all
again, installing virtually anything from HomeBrew pollutes your LO-dev
environment with pkgconfig foo which autogen.sh then promptly tells you
to remove or alter your path settings. So, still incompatible with LO's
build environment and I would still recommend against using HomeBrew.


Alex







___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Build failure with current master on MacOS

[Tor Lillqvist]

> 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
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Build failure with current master on MacOS

[Shinnok]

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 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 with localized
>> version until that is sorted. Where did this new requirement come
>> from ?
> 
> This is new since Friday with the gettext change over. The ".src and
> .ui gettext migration" emails are on that topic, though I guess they
> don't spell out that it means that gettext has to be installed to build
> the .mo files.
> 
> lode was updated to pull in the gettext packages on windows and macosx
> so those using lode can just re-run the lode setup to pull in the
> necessary extras. I've updated the https://wiki.documentfoundation.org/
> Development/BuildingOnMac#Minimal_Setup with the manual howto for
> gettext (similar to the preexisting autoconf/automake dependencies),
> though most people probably don't build locally with translations.
> ___
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/libreoffice
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Build failure with current master on MacOS

[Alexander Thurgood]

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

[julien2412]

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*" in instdir:
./LibreOffice6.0_SDK/examples/DevelopersGuide/ScriptingFramework/ScriptSelector/ScriptSelector/soffice.gif
./LibreOfficeDev.app/Contents/MacOS/soffice
./LibreOfficeDev.app/Contents/Resources/config/soffice.cfg
./LibreOfficeDev.app/Contents/Resources/sofficerc
./LibreOfficeDev.app/Contents/user/config/soffice.cfg

2) still have these logs on console regularly:
warn:sal.osl.pipe:16183:1:sal/osl/unx/pipe.cxx:384: shutdown() failed:
Socket is not connected
warn:sal.osl.pipe:16183:3:sal/osl/unx/pipe.cxx:420: accept() failed:
Software caused connection abort
warn:sal.osl:16183:9:sal/osl/unx/socket.cxx:931: undefined address

3) bunch of these kind of logs:
CoreData: warning: dynamic accessors failed to find @property implementation
(according to forums, it seems a pure MacOs bug, not LO related)

Julien



--
View this message in context: 
http://nabble.documentfoundation.org/Build-failure-with-current-master-on-MacOS-tp4218848p4218943.html
Sent from the Dev mailing list archive at Nabble.com.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Build failure with current master on MacOS

[Caolán McNamara]

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 with localized
> version until that is sorted. Where did this new requirement come
> from ?

This is new since Friday with the gettext change over. The ".src and
.ui gettext migration" emails are on that topic, though I guess they
don't spell out that it means that gettext has to be installed to build
the .mo files.

lode was updated to pull in the gettext packages on windows and macosx
so those using lode can just re-run the lode setup to pull in the
necessary extras. I've updated the https://wiki.documentfoundation.org/
Development/BuildingOnMac#Minimal_Setup with the manual howto for
gettext (similar to the preexisting autoconf/automake dependencies),
though most people probably don't build locally with translations.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Build failure with current master on MacOS

[Alexander Thurgood]

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 odd exception) for years (since LO began,
in fact).

The day I am forced (as in, because everything forces the user in that
direction) to set up a specific environment to get LO to build on Mac is
the day I stop building LO on Mac. In that case, we become no better
than HomeBrew or ports, or any other similar project. Oh well, such is
progress :-)


Alex


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Build failure with current master on MacOS

[Alexander Thurgood]

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 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 with localized
version until that is sorted. Where did this new requirement come from ?


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]

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 "fixed" means you'll get an error message from configure instead
that tells you to install gettext)

(how one would best install gettext on MacOS is another question that i
don't know the answer to; perhaps via LODE ?)

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Build failure with current master on MacOS

[Alexander Thurgood]

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
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Build failure with current master on MacOS

[Michael Stahl]

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 language support that could have led to these
> failures. I see the following message just before the failure :
> 
> interim-update-for-gettext : processing
> /core/translations/source/fr/accessibility
> 
> interim-update-for-gettext : merging
> /core/translations/source/fr/accessibility/source/helper.po
> 
> 
> and similar messages in avmedia, but also :
> 
> sh --force-po command not found

that is odd:

$(MSGUNIQ) --force-po $@.po | $(MSGFMT) - -o $@)

do you have an empty MSGUNIQ variable?

what does this say:

grep MSG config_host.mk


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Build failure with current master on MacOS

[Alexander Thurgood]

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
> 8c9ed261cb9201774943e438cf5394c1dcfa8c49

Yes, saw that too this morning, but that isn't the same problem I'm
experiencing as I pulled again after that and still with a make clean,
make, I'm getting the same failure as I reported in accfr.mo and
avmediafr.mo.


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]

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

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Build failure with current master on MacOS

[julien2412]

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
https://macpaw.com/how-to/uninstall-xcode-on-macos/https://stackoverflow.com/questions/31011062/how-to-completely-uninstall-xcode-and-clear-all-settings)
- installed last XCode (8.3.3)
- runned "ccache -C"
- updated local repos : translations, dictionnaires, helpcontent in addition
of core
- runned "/opt/bin/make clean && ./autogen.sh && /opt/bin/make" (since
default make is still 3.81, I used a more recent version 4.X)

Nevertheless, I also got an error but different from yours:
  [XSL] CustomTarget/officecfg/registry/officecfg/ucb/Store.hxx
[C  ] external/clew/source/clew.c
[OCC] apple_remote/source/KeyspanFrontRowControl.m
[OCC] apple_remote/source/AppleRemote.m
[OCC] apple_remote/source/RemoteControl.m
[OCC] apple_remote/source/RemoteControlContainer.m
[OCC] apple_remote/source/GlobalKeyboardDevice.m
[OCC] apple_remote/source/HIDRemoteControlDevice.m
[OCC] apple_remote/source/MultiClickRemoteBehavior.m
[OCC] apple_remote/source/RemoteMainController.m
[PKG] python3
/Users/XXX/lo/lode/dev/core/solenv/gbuild/Package.mk:81: *** Something
depends on package python3 which does not exist..  Stop.

Indeed, I don't install Python 3 only 2.6 and 2.7 versions, but is it
necessary now to have version 3 ? (it wasn't before)

Julien



--
View this message in context: 
http://nabble.documentfoundation.org/Build-failure-with-current-master-on-MacOS-tp4218848p4218850.html
Sent from the Dev mailing list archive at Nabble.com.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: BUILD FAILURE

[Tor Lillqvist]

> 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. Anyway, simply remove it and run 'make'
again.

--tml
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: BUILD FAILURE

[Tamsil Amani]

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
>> somehow don't know why the build fails.
>>
>> Commands:
>>
>> 1) ./g pull -r  : Works OK
>>
>> 2) make  : Shows failure
>>
>> Here is the log.
>>
>>  *
>> .
>> .
>> .
>> [LNK] CppunitTest/libtest_sw_ooxmlexport.so
>> [DEP] LNK:CppunitTest/libtest_sw_ooxmlexport2.so
>> [LNK] CppunitTest/libtest_sw_ooxmlexport2.so
>> /home/tamsil/libreoffice/workdir/CxxObject/sw/qa/extras/ooxmlexport/ooxmlexport.o:
>> file not recognized: File truncated
>> collect2: error: ld returned 1 exit status
>> /home/tamsil/libreoffice/solenv/gbuild/LinkTarget.mk:468: recipe for
>> target 
>> '/home/tamsil/libreoffice/workdir/LinkTarget/CppunitTest/libtest_sw_ooxmlexport.so'
>> failed
>> make[1]: *** 
>> [/home/tamsil/libreoffice/workdir/LinkTarget/CppunitTest/libtest_sw_ooxmlexport.so]
>> Error 1
>> make[1]: *** Waiting for unfinished jobs
>> Makefile:256: recipe for target 'build' failed
>> make: *** [build] Error 2
>>
>>
>
> So an earlier build left behind some zero sized files. Do you still have
> enough space on the disk or did one of your earlier builds get interrupted
> (CTRL+C is fine as that calls some cleanup).
>
> Regards,
> Markus
>
>
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: BUILD FAILURE

[Tor Lillqvist]

>
>
> /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
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: BUILD FAILURE

[Markus Mohrhard]

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.
>
>  *
> .
> .
> .
> [LNK] CppunitTest/libtest_sw_ooxmlexport.so
> [DEP] LNK:CppunitTest/libtest_sw_ooxmlexport2.so
> [LNK] CppunitTest/libtest_sw_ooxmlexport2.so
> /home/tamsil/libreoffice/workdir/CxxObject/sw/qa/extras/ooxmlexport/ooxmlexport.o:
> file not recognized: File truncated
> collect2: error: ld returned 1 exit status
> /home/tamsil/libreoffice/solenv/gbuild/LinkTarget.mk:468: recipe for
> target '/home/tamsil/libreoffice/workdir/LinkTarget/
> CppunitTest/libtest_sw_ooxmlexport.so' failed
> make[1]: *** [/home/tamsil/libreoffice/workdir/LinkTarget/
> CppunitTest/libtest_sw_ooxmlexport.so] Error 1
> make[1]: *** Waiting for unfinished jobs
> Makefile:256: recipe for target 'build' failed
> make: *** [build] Error 2
>
>

So an earlier build left behind some zero sized files. Do you still have
enough space on the disk or did one of your earlier builds get interrupted
(CTRL+C is fine as that calls some cleanup).

Regards,
Markus
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Build failure while experimenting with LTO

[Stephan Bergmann]

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 --without-help --without-myspell-dicts

[build EPK] fonts_carlito
[build EPK] fonts_dejavu
[build EPK] fonts_gentium
[build EPK] fonts_liberation
[build EPK] fonts_liberation_narrow
[build EPK] fonts_libertineg
[build EPK] fonts_opensans
[build EPK] fonts_ptserif
[build EPK] fonts_sourcecode
[build EPK] fonts_sourcesans
[build UPK] a8c2c5b8f09e7ede322d5c602ff6a4b6-mythes-1.2.4.tar.gz
[build MOD] poppler
/home/davide/lto_experiments/libreoffice/external/redland/ExternalPackage_raptor.mk:21:
*** file 
/home/davide/lto_experiments/libreoffice/workdir/UnpackedTarball/raptor/src/.libs/libraptor2-lo.so.0.0.0
does not exist in the tarball.  Stop.


Did you "make clean" before trying without lto?  What's the result of 
"make redland.clean && make redland", does it create that

workdir/UnpackedTarball/raptor/src/.libs/libraptor2-lo.so.0.0.0?
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Build failure while experimenting with LTO

[Davide Italiano]

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 libreoffice if I invoke
>> autogen.sh like this:
>>
>> ./autogen.sh CC=~/work/llvm/build-release/bin/clang
>> CXX=~/work/llvm/build-release/bin/clang++
>> AR=~/work/llvm/build-release/bin/llvm-ar RANLIB=/usr/bin/true
>> LDFLAGS="-fuse-ld=lld" CFLAGS="-flto" CXXFLAGS="-flto" --without-java
>> --without-help --without-myspell-dicts --disable-liblangtag
>> --with-system-curl --with-system-lcms2
>>
>> (please note that as long as I'm using the LLVM tools I don't need
>> plugin(s) as binutils does).
>>
>> I set up my PATH so that ld symlinks to lld.
>>
>> $ ld --version
>> LLD 3.9 (https://llvm.org/svn/llvm-project/lld/trunk 273771)
>>
>> After some librabries/executables are built/linked successfully I hit
>> the following:
>>
>> [build DEP] LNK:Library/libbiblo.so
>> [build LNK] Library/libbiblo.so
>> /home/davide/lto_experiments/libreoffice/external/coinmp/ExternalPackage_coinmp.mk:31:
>> *** file 
>> /home/davide/lto_experiments/libreoffice/workdir/UnpackedTarball/coinmp/Cbc/src/.libs/libCbc.so.3.8.8
>> does not exist in the tarball.  Stop.
>> make[1]: *** Waiting for unfinished jobs
>> Makefile:254: recipe for target 'build' failed
>> make: *** [build] Error 2
>> ```
>>
>> $ find . -name "libCbc.so*"
>> $
>>
>> So I decided to build libCbc by myself going in the correct directory
>> and invoking make:
>>
>> $ cd ./workdir/UnpackedTarball/coinmp/Cbc/ && ./configure && make
>> [...]
>>
>> but still the build fails with the same error.
>> Any ideas why the library is not built? Is this a bug in LLVM or in
>> the build system?
>>
>> As a side note, I'm able to finish successfully a non-LTO build with 
>> clang+lld.
>>
>> Thanks!
>>
>> --
>> Davide
>
> Also, FWIW this is the revision I'm at:
>
> commit 63f15b36f7a196edb20ce7a0aba6f6b3d28dd652
> Author: Ashod Nakashian 
> Date:   Sun Jun 12 22:04:50 2016 -0400
>
> --
> Davide

I refreshed to:

commit 04136c95c5be30004e627f2866fe6ecea60a04f1
Author: Muhammet Kara 
Date:   Fri Jun 17 15:24:19 2016 +0300

Move accessibility relations to .ui files, Part 10: tdf#87026

$ ~/work/llvm/build-release/bin/clang --version
clang version 3.9.0 (trunk 273841) (llvm/trunk 273938)

$ ~/work/llvm/build-release/bin/clang++ --version
clang version 3.9.0 (trunk 273841) (llvm/trunk 273938)

clang is upstream clang + the patch for abi_attribute.

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 --without-help --without-myspell-dicts

[build EPK] fonts_carlito
[build EPK] fonts_dejavu
[build EPK] fonts_gentium
[build EPK] fonts_liberation
[build EPK] fonts_liberation_narrow
[build EPK] fonts_libertineg
[build EPK] fonts_opensans
[build EPK] fonts_ptserif
[build EPK] fonts_sourcecode
[build EPK] fonts_sourcesans
[build UPK] a8c2c5b8f09e7ede322d5c602ff6a4b6-mythes-1.2.4.tar.gz
[build MOD] poppler
/home/davide/lto_experiments/libreoffice/external/redland/ExternalPackage_raptor.mk:21:
*** file 
/home/davide/lto_experiments/libreoffice/workdir/UnpackedTarball/raptor/src/.libs/libraptor2-lo.so.0.0.0
does not exist in the tarball.  Stop.

Any ideas on how to debug this?

Thanks!

--
Davide
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Build failure while experimenting with LTO

[Davide Italiano]

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 CC=~/work/llvm/build-release/bin/clang
> CXX=~/work/llvm/build-release/bin/clang++
> AR=~/work/llvm/build-release/bin/llvm-ar RANLIB=/usr/bin/true
> LDFLAGS="-fuse-ld=lld" CFLAGS="-flto" CXXFLAGS="-flto" --without-java
> --without-help --without-myspell-dicts --disable-liblangtag
> --with-system-curl --with-system-lcms2
>
> (please note that as long as I'm using the LLVM tools I don't need
> plugin(s) as binutils does).
>
> I set up my PATH so that ld symlinks to lld.
>
> $ ld --version
> LLD 3.9 (https://llvm.org/svn/llvm-project/lld/trunk 273771)
>
> After some librabries/executables are built/linked successfully I hit
> the following:
>
> [build DEP] LNK:Library/libbiblo.so
> [build LNK] Library/libbiblo.so
> /home/davide/lto_experiments/libreoffice/external/coinmp/ExternalPackage_coinmp.mk:31:
> *** file 
> /home/davide/lto_experiments/libreoffice/workdir/UnpackedTarball/coinmp/Cbc/src/.libs/libCbc.so.3.8.8
> does not exist in the tarball.  Stop.
> make[1]: *** Waiting for unfinished jobs
> Makefile:254: recipe for target 'build' failed
> make: *** [build] Error 2
> ```
>
> $ find . -name "libCbc.so*"
> $
>
> So I decided to build libCbc by myself going in the correct directory
> and invoking make:
>
> $ cd ./workdir/UnpackedTarball/coinmp/Cbc/ && ./configure && make
> [...]
>
> but still the build fails with the same error.
> Any ideas why the library is not built? Is this a bug in LLVM or in
> the build system?
>
> As a side note, I'm able to finish successfully a non-LTO build with 
> clang+lld.
>
> Thanks!
>
> --
> Davide

Also, FWIW this is the revision I'm at:

commit 63f15b36f7a196edb20ce7a0aba6f6b3d28dd652
Author: Ashod Nakashian 
Date:   Sun Jun 12 22:04:50 2016 -0400

--
Davide
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Build Failure on Ubuntu 15.10 after upgradation from 15.04

[Maxim Monastirsky]

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 master 
+ 15.04) with no errors.



There is an incompatible ABI change in GCC 5's libstdc++. I suggest to 
do "make clean" and full rebuild (7-10 days old master most likely will 
require ~full rebuild anyway).


Maxim

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

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')

[David Gerard]

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 one? If so, how do I obtain another one?

Even if it's not hard to get the TDF secret from the binaries, it's not
fair to advertise them. The more widely it's known, the more probable
that someone will reuse it in some nasty application, then the
TDF-registered app ID will get shut down, making LibreOffice users sad.
See here on how to obtain your own ID:
https://developers.google.com/drive/web/about-auth
If you write a blog post about this topic, that's great, but I guess
best to not mention any ID explicitly, they are kind of a secret anyway.


OK, I'll do it that way :-)


- d.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

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'

[Alexander Thurgood]

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 x86_64.
Is it still applicable for our 64bit OSX releases ?

Alex


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

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 Vajna]

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
https://wiki.documentfoundation.org/Development/ReleaseBuilds#Mac_x86,
or you use different switches?

Thanks,

Miklos


signature.asc
Description: Digital signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

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'

[Norbert Thiebaud]

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 ?

 Norbert, am I right that just a simple x86 - 64bit rename is needed at
 https://wiki.documentfoundation.org/Development/ReleaseBuilds#Mac_x86,
 or you use different switches?

s/x86/Intel/ should be enough. As I said the reason we mention x86 is
to distinguish with ppc... it has never been a 32/64 bits issue.

Norbert
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

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'

[Norbert Thiebaud]

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 the general public.


 Thanks, but that page references x86 builds for MacOSX and not x86_64.

So?

 Is it still applicable for our 64bit OSX releases ?

why on earth not ?

(for the record the reason mac has a x qualifier on this page is to
distinguish with ppc. there is not distinction betwen the 32 and 64
bits intel setup except of course 32 vs 64 bits)
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

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 Vajna]

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
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

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 Vajna]

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 so, how do I obtain another one?

Even if it's not hard to get the TDF secret from the binaries, it's not
fair to advertise them. The more widely it's known, the more probable
that someone will reuse it in some nasty application, then the
TDF-registered app ID will get shut down, making LibreOffice users sad.

See here on how to obtain your own ID:

https://developers.google.com/drive/web/about-auth

If you write a blog post about this topic, that's great, but I guess
best to not mention any ID explicitly, they are kind of a secret anyway.

Regards,

Miklos


signature.asc
Description: Digital signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

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'

[Alex Thurgood]

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
myself, I have to build LO with credentials that I've obtained according
to the link you posted above ? Not really an accessible feature then, as
in, broadly accessible to the public, is it ?

Note that I'm not criticizing, but trying to understand why, from a
marketing perspective, we tout a feature that actually isn't available
in the builds we deliver publicly for platforms other than Windows, or
perhaps have I completely misunderstood how it works ?


Alex




___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

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'

[David Gerard]

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 work? Are you saying
 they have someone's credentials actually compiled into them?

 Yes. For TDF builds TDF credentials are compiled in. But it is not
 used for anything else, but to identify the application with Google
 Drive. It is not a personal thing.


I now have a build that connects reasonably reliably, using this line:

./autogen.sh --with-gdrive-client-secret=GYWrDtzyZQZ0_g5YoBCC6F0I
--with-gdrive-client-id=457862564325.apps.googleusercontent.com;
make


That's the TDF secret. 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 so, how do I obtain another one?

(also, will this stop working when Google stops doing OAuth2?)


- d.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

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]

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 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 real, existing id and secret to autogen.sh.

E.g. (these are fake data)

./autogen.sh --with-gdrive-client-secret=ldhfagfxqkjewgfzutghdgfqw
--with-google-drive-client-id=326483264627629736-23432432sfdgfdsgfds.apps.googleusercontent.com

Best regards,
Andras
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

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'

[David Gerard]

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 real, existing id and secret to autogen.sh.
 E.g. (these are fake data)
 ./autogen.sh --with-gdrive-client-secret=ldhfagfxqkjewgfzutghdgfqw
--with-google-drive-client-id=326483264627629736-23432432sfdgfdsgfds.apps.googleusercontent.com



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 credentials actually compiled into them?


(Chris Sherlock and I are busy tracking down the build error, by the
way. So this is all leading to useful things, if not in the GDrive bit
:-) )


- d.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

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]

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
 --with-google-drive-client-id. Of course, you need to register with
 Google first, and pass real, existing id and secret to autogen.sh.
 E.g. (these are fake data)
 ./autogen.sh --with-gdrive-client-secret=ldhfagfxqkjewgfzutghdgfqw
 --with-google-drive-client-id=326483264627629736-23432432sfdgfdsgfds.apps.googleusercontent.com



 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 credentials actually compiled into them?

Yes. For TDF builds TDF credentials are compiled in. But it is not
used for anything else, but to identify the application with Google
Drive. It is not a personal thing.

Best regards,
Andras
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

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'

[David Gerard]

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 credentials actually compiled into them?

 Yes. For TDF builds TDF credentials are compiled in. But it is not
 used for anything else, but to identify the application with Google
 Drive. It is not a personal thing.


That's not entirely clear to me, but OK ... it's clearly a very
experimental feature.

(I tracked down what originally led me to think that Google Drive via
CMIS was a properly-supported feature:
http://standardsandfreedom.net/index.php/2014/02/01/libreoffice42/
But with the 4.2, we also have some nice and immediately actionnable
features that will appeal specifically to the enterprise market:
Integration of the CMIS stack allowing you connect to document
repositories on SharePoint, Nuxeo, Tibco, Alfresco, Google Drive and
many other CMS ... Of course, a marketing blog isn't development. But
others have gained this impression, e.g. to the point of filing Ubuntu
bugs expecting the feature to work:
https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1389936
Some clarification of its status may be appropriate ...)

The original build problem appears to be fixed in master by
http://cgit.freedesktop.org/libreoffice/core/commit/vcl/Executable_icontest.mk?id=6e7da281c22a62ae39799b2736885e54c388caf2
- I tried that fix and it fixed my build problem, so presumably that
should go back to 4.4 branch as well (Chris Sherlock is looking into
this).


- d.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

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'

[Chris Sherlock]

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 at 12:10, Andras Timar tima...@gmail.com
 javascript:; wrote:
  On Wed, Dec 17, 2014 at 12:35 PM, David Gerard dger...@gmail.com
 javascript:; 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 credentials actually compiled into them?

  Yes. For TDF builds TDF credentials are compiled in. But it is not
  used for anything else, but to identify the application with Google
  Drive. It is not a personal thing.


 That's not entirely clear to me, but OK ... it's clearly a very
 experimental feature.

 (I tracked down what originally led me to think that Google Drive via
 CMIS was a properly-supported feature:
 http://standardsandfreedom.net/index.php/2014/02/01/libreoffice42/
 But with the 4.2, we also have some nice and immediately actionnable
 features that will appeal specifically to the enterprise market:
 Integration of the CMIS stack allowing you connect to document
 repositories on SharePoint, Nuxeo, Tibco, Alfresco, Google Drive and
 many other CMS ... Of course, a marketing blog isn't development. But
 others have gained this impression, e.g. to the point of filing Ubuntu
 bugs expecting the feature to work:
 https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1389936
 Some clarification of its status may be appropriate ...)

 The original build problem appears to be fixed in master by

 http://cgit.freedesktop.org/libreoffice/core/commit/vcl/Executable_icontest.mk?id=6e7da281c22a62ae39799b2736885e54c388caf2
 - I tried that fix and it fixed my build problem, so presumably that
 should go back to 4.4 branch as well (Chris Sherlock is looking into
 this).


 - d.
 ___
 LibreOffice mailing list
 LibreOffice@lists.freedesktop.org javascript:;
 http://lists.freedesktop.org/mailman/listinfo/libreoffice

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: build failure in [build SAX]

[Stephan Bergmann]

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 -std=c++11 all by itself.


Stephan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

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

[Terrence Enger]

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

[David Tardon]

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
  
  /home/terry/lo_hacking/git/libo2/workdir/LinkTarget/StaticLibrary/libcollada2gltf.a(GLTF-Open3DGC.o):
   In function `o3dgc::Timer::Tic()':
  
  /home/terry/lo_hacking/git/libo2/workdir/UnpackedTarball/collada2gltf/dependencies/o3dgc/src/o3dgc_common_lib/inc/o3dgcTimer.h:115:
   undefined reference to `clock_gettime'
 I google it and find that:
 http://stackoverflow.com/questions/2418157/ubuntu-linux-c-error-undefined-reference-to-clock-gettime-and-clock-settim
 It suggests to link -lrt library.
 So you can try to add these lines:
 ifeq ($(OS),LINUX)
 $(eval $(call gb_Library_add_libs,collada2gltf,\
   -lrt \
 ))
 endif
 to the external/collada2gltf/StaticLibrary_collada2gltf.mk file.

This will not work. The extra library is needed at the place(s) where
collada2gltf.a is _used_. The attached patch should do that.

D.
From 8e1800c467ab44edea5f2e0055bbbfc8253d2ff7 Mon Sep 17 00:00:00 2001
From: David Tardon dtar...@redhat.com
Date: Sun, 18 May 2014 12:42:37 +0200
Subject: [PATCH] fix linking with collada2gltf lib

Change-Id: I3628c41803a2a0432354c8fcb9e090b53ebef4f1
---
 RepositoryExternal.mk | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/RepositoryExternal.mk b/RepositoryExternal.mk
index 6e2d19b..6c9b787 100644
--- a/RepositoryExternal.mk
+++ b/RepositoryExternal.mk
@@ -3148,6 +3148,12 @@ $(call gb_LinkTarget_set_include,$(1),\
 $(call gb_LinkTarget_use_static_libraries,$(1),\
collada2gltf \
 )
+
+ifeq ($(OS),LINUX)
+$(call gb_LinkTarget_add_libs,$(1),\
+   -lrt \
+)
+endif
 endef
 
 endif
-- 
1.9.0

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

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

[Tamas Zolnai]

 
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
 
 /home/terry/lo_hacking/git/libo2/workdir/LinkTarget/StaticLibrary/libcollada2gltf.a(GLTF-Open3DGC.o):
  In function `o3dgc::Timer::Tic()':
 
 /home/terry/lo_hacking/git/libo2/workdir/UnpackedTarball/collada2gltf/dependencies/o3dgc/src/o3dgc_common_lib/inc/o3dgcTimer.h:115:
  undefined reference to `clock_gettime'
 
 /home/terry/lo_hacking/git/libo2/workdir/LinkTarget/StaticLibrary/libcollada2gltf.a(GLTF-Open3DGC.o):
  In function `o3dgc::Timer::Toc()':
 
 /home/terry/lo_hacking/git/libo2/workdir/UnpackedTarball/collada2gltf/dependencies/o3dgc/src/o3dgc_common_lib/inc/o3dgcTimer.h:119:
  undefined reference to `clock_gettime'
 
 I notice that the files downloaded by `make fetch` were:
 
 collada2gltf-master-6258611a6a.tar.bz2
 libpng-1.5.18.tar.gz
 OpenCOLLADA-master-6509aa13af.tar.bz2
 
 If I am reading things correctly, the first of these was introduced
 by:
 
 commit d575917016f65a7322817a8e13ec25c52d18a600
 Author: Zolnai Tamás tamas.zol...@collabora.com
 Date:   Thu Apr 10 13:37:38 2014 +0200
 
 Introduce Collada2gltf external library
 
 Change-Id: I157f175ee6ea719e98ba45133f53cb4d2c3045bb
 
 
 Suggestions welcome.

Hi Terry,

I didn't get the same error while building.
I google it and find that:
http://stackoverflow.com/questions/2418157/ubuntu-linux-c-error-undefined-reference-to-clock-gettime-and-clock-settim
It suggests to link -lrt library.
So you can try to add these lines:
ifeq ($(OS),LINUX)
$(eval $(call gb_Library_add_libs,collada2gltf,\
-lrt \
))
endif
to the external/collada2gltf/StaticLibrary_collada2gltf.mk file.

I hope it helps.

Best regards,
Tamás
 
 
 

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

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

[Terrence Enger]

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]

/home/terry/lo_hacking/git/libo2/workdir/UnpackedTarball/collada2gltf/dependencies/o3dgc/src/o3dgc_common_lib/inc/o3dgcTimer.h:115:
 undefined reference to `clock_gettime'
  [snip]
  
   Hi Terry,
   
   I didn't get the same error while building.
  
  Hmm.  My system is debian-wheezy, which perhaps is more conservative
  than most Linux distros.
  
   I google it and find that:
   http://stackoverflow.com/questions/2418157/ubuntu-linux-c-error-undefined-reference-to-clock-gettime-and-clock-settim
   It suggests to link -lrt library.
   So you can try to add these lines:
   ifeq ($(OS),LINUX)
   $(eval $(call gb_Library_add_libs,collada2gltf,\
 -lrt \
   ))
   endif
   to the external/collada2gltf/StaticLibrary_collada2gltf.mk file.
   
   I hope it helps.
  
  That did the job.  My build is continuing.

Uh-oh.  I do not know what I was looking at when I wrote that.  The
link just failed the same way.  And that was after `make clean`. 
OTOH, I see that you added those lines earlier in the file than I did

Meanwhile I accomplished the link by typing the command at the command
line, including -lrt.

I am sorry for having given you false encouragement.
Terry.
 
 Great, then I push it to master to avoid this problem.
 
 Regards,
 Tamás
  
 
 


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: build failure in [build GAL] arrows

[Matúš Kukan]

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 recent commits, 9555b5b Add gengal to RepositoryFixes and
 autoinstall it. catches my eye because it shares the string gengal
 with the first error message.

Indeed, sorry for this, there was missing dependency hopefully fixed with
http://cgit.freedesktop.org/libreoffice/core/commit/?id=94b6882b80c91d2daf5e317e9d79d3d2a1c6572bfix
gengal dependencies

Best,

Matus
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

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

[Norbert Thiebaud]

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 to disable it by default

Norbert
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

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

[Alexander Thurgood]

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
http://lists.freedesktop.org/mailman/listinfo/libreoffice

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

[Lionel Elie Mamane]

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:   Sat Apr 20 17:31:26 2013 -0500

connectivity: use LL qualifier for int64 contants

Change-Id: Iaafbd62920c2b695c5810766d143a01c288e813f


If not, let us know.


-- 
Lionel
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice