Re: Building LO 4.0.4.2 on illumos based OS
Now I noticed the config.log of xmlsec shows the configure switches like this: ./configure --with-pic --disable-shared --disable-crypto-dl --without-libxslt --without-gnutls --without-openssl This is why it's not picking up my system openssl not the other crypto libs. I bet it's trying to build it only with NSS libs, but they're not passed correctly (they resides in /usr/lib/mps in my environment) from base env. Is it absolutely necessary that it builds without those crypto libs? Gabriele. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Building LO 4.0.4.2 on illumos based OS
For now, it's ok to have the build go through, so I can see if I can reach a working LO. Then I'll dig again the NSS problem, and see if I can support it. Now: build reached the install creation phase! But: something went wrong. USAGE: /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/setup_native/scripts/install_create.pl : the start shell script, located next to this perl script : the library file, that is included into the shell script : the target shellscript chmod: cannot access '/sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/workdir/unxsogi.pro/CustomTarget/setup_native/scripts/install': No such file or directory make[2]: *** [/sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/workdir/unxsogi.pro/CustomTarget/setup_native/scripts/install] Error 1 As if the install creation did not pass arguments to the perl script. Actually, I don't want it to create an installer for solaris via packages. What I want is to issue some kind of gmake install to let it place everything inside a prototype area, through classic configure switches. This will let me publish the package in my IPS repository, as for any SunOS 5.11 based system. Any idea how to achieve this? Gabriele. -- Da: Michael Stahl A: Gabriele Bulfon Cc: libreoffice-dev michael.me...@suse.com Rene Engelhard Data: 16 luglio 2013 10.43.01 CEST Oggetto: Re: Building LO 4.0.4.2 on illumos based OS On 16/07/13 08:09, Gabriele Bulfon wrote: Now I noticed the config.log of xmlsec shows the configure switches like this: ./configure --with-pic --disable-shared --disable-crypto-dl --without-libxslt --without-gnutls --without-openssl This is why it's not picking up my system openssl not the other crypto libs. I bet it's trying to build it only with NSS libs, but they're not passed correctly (they resides in /usr/lib/mps in my environment) from base env. Is it absolutely necessary that it builds without those crypto libs? i'm not entirely sure but i think that the ODF encryption support (which is the only use of libxmlsec) on Unixes is implemented by using keys added by Firefox/Thunderbird UI to their user profiles; there is no UI in LO for adding/removing keys. probably only NSS can read the Firefox/Thunderbird key database, so i'm afraid that if you build xmlsec with anything other than NSS it won't work in practice. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Building LO 4.0.4.2 on illumos based OS
Hi, I could set up the correct env to build correctly up to soffice.bin and going on over extensions. I ended up with a problem linking with Xm Motif libraries (a problem inside my distro that I'm solving). I was wandering why Motif libraries are needed by these extension. Is it absolutely necessary? Any way to skip Motif dependencies? Gabriele. Da: Gabriele Bulfon A: Michael Stahl Cc: michael.me...@suse.com libreoffice-dev Data: 9 luglio 2013 18.01.19 CEST Oggetto: Re: Building LO 4.0.4.2 on illumos based OS usually libs should contain not just search paths but also the libraries to be linked, e.g. in config_host.mk with a system nss i get: export NSS_LIBS=$(gb_SPACE)-lssl3 -lsmime3 -lnss3 -lnssutil3 -lplds4 -lplc4 -lnspr4 -lpthread -ldl also i guess only Sun ld knows -R, the GNU ld equivalent is -Wl,-rpath, Well done! With this env the build went on the unopkg.bin! CONFIGURE_ENV += NSS_CFLAGS=-I/usr/include/mps CONFIGURE_ENV += NSS_LIBS=-Wl,-rpath,/usr/lib/mps -L/usr/lib/mps -lssl3 -lsmime3 -lnss3 - lnssutil3 -lplds4 -lplc4 -lnspr4 -lpthread -ldl I prefer to use my userland Makefile options instead of modifying the solaris.mk Now the build is going on.let's wait and see... ;) Gabriele. Ok, it stopped later with this: [build LNK] Executable/pluginapp.bin S=/sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1 O=$S/solver/unxsogi.pro W=$S/workdir/unxsogi.pro mkdir -p $W/LinkTarget/Executable/ /usr/gcc/4.4/bin/g++ -Wl,-z,origin '-Wl,-rpath,$ORIGIN:$ORIGIN/../ure-link/lib' -Wl,-rpath-link,$O/lib -z nodefs $W/CxxObject/extensions/source/plugin/unx/npwrap.o $W/CxxObject/extensions/source/plugin/unx/npnapi.o -Wl,--start-group $O/lib/libplugcon.a -Wl,--end-group -Wl,--no-as-needed -lm -lnsl -lsocket -lXm -lXt -lXext -lX11 -ldl -lgthread-2.0 -lpthread -lglib-2.0 -R/usr/lib -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgdk_pixbuf_xlib-2.0 -lgmodule-2.0 -lpthread -lgdk_pixbuf-2.0 -lgobject-2.0 -lglib-2.0 -R/usr/lib -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lglib-2.0 -luno_sal -o $W/LinkTarget/Executable/pluginapp.bin /usr/gnu/bin/ld: cannot find -luno_sal collect2: ld returned 1 exit status I guess I'm missing a librarynot built? ___LibreOffice mailing listLibreOffice@lists.freedesktop.orghttp://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Building LO 4.0.4.2 on illumos based OS
Thanks! I'll check and try to disable this on my build. Also, it's not about a Solaris general problem, usually Solaris 10/11 have X11 and motif libs correctly configured. It's my own XStreamOS/illumos dev machine that has new X11 and old Motif libs not happy each other. For this, I will build and switch to open-motif shortly. Gabriele. -- Da: Michael Meeks A: Gabriele Bulfon Cc: Michael Stahl libreoffice-dev Data: 15 luglio 2013 10.15.18 CEST Oggetto: Re: Building LO 4.0.4.2 on illumos based OS On Mon, 2013-07-15 at 09:44 +0200, Gabriele Bulfon wrote: I was wandering why Motif libraries are needed by these extension. Is it absolutely necessary? I'm amazed to hear that we link to motif in the modern world; it seems to be only this extension: $W/CxxObject/extensions/source/plugin/unx/npwrap.o $W/CxxObject/extensions/source/plugin/unx/npnapi.o I'd disable this I guess in configure.ac we have: dnl Check for NPAPI interface to plug browser plugins into LibreOffice documents I imagine we should just disable that for Solaris [ for now ]. Quite why we think Mozilla requires motif still I'm not sure I'd be amazed if they still had a hard dep on that. HTH, Michael. -- michael.me...@suse.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Building LO 4.0.4.2 on illumos based OS
I momentarily disabled with this patch (treated SunOS as for iOS and Android). Gabriele. -- Da: Michael Meeks A: Gabriele Bulfon Cc: Michael Stahl libreoffice-dev Data: 15 luglio 2013 10.15.18 CEST Oggetto: Re: Building LO 4.0.4.2 on illumos based OS On Mon, 2013-07-15 at 09:44 +0200, Gabriele Bulfon wrote: I was wandering why Motif libraries are needed by these extension. Is it absolutely necessary? I'm amazed to hear that we link to motif in the modern world; it seems to be only this extension: $W/CxxObject/extensions/source/plugin/unx/npwrap.o $W/CxxObject/extensions/source/plugin/unx/npnapi.o I'd disable this I guess in configure.ac we have: dnl Check for NPAPI interface to plug browser plugins into LibreOffice documents I imagine we should just disable that for Solaris [ for now ]. Quite why we think Mozilla requires motif still I'm not sure I'd be amazed if they still had a hard dep on that. HTH, Michael. -- michael.me...@suse.com sonicle-configure.patch Description: binary/octet-stream ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Building LO 4.0.4.2 on illumos based OS
Ok, I could go over extension by disabling that motif dependent plugin. Now, later, it's trying to build xmlsec1, and looks like it can't find libs I actually have! checking for pkg-config... yes checking for libxslt libraries= 1.0.20... no [I have it, it's 1.1.26] checking for openssl libraries= 0.9.6... no[I have both 0.9.6 and 1.0.0j] checking for NSS... no checking for NSS... no checking for NSS... no checking for NSS... no checking for NSS... no checking for nspr libraries= 4.0... no [I have nspr 4] checking for nss libraries= 3.2... no [I have nss 3.13.5] checking for gnutls libraries= 0.8.1... no[I have 3.1.9] checking for mscrypto libraries... none checking for crypto library... configure: error: At least one crypto library should exist for xmlsec1 I can't find the config.log of this component, this may hold the info I need to solve it. Can you help? gabriele. Da: Gabriele Bulfon A: michael.me...@suse.com Cc: Michael Stahl libreoffice-dev Data: 15 luglio 2013 10.42.52 CEST Oggetto: Re: Building LO 4.0.4.2 on illumos based OS I momentarily disabled with this patch (treated SunOS as for iOS and Android). Gabriele. -- Da: Michael Meeks A: Gabriele Bulfon Cc: Michael Stahl libreoffice-dev Data: 15 luglio 2013 10.15.18 CEST Oggetto: Re: Building LO 4.0.4.2 on illumos based OS On Mon, 2013-07-15 at 09:44 +0200, Gabriele Bulfon wrote: I was wandering why Motif libraries are needed by these extension. Is it absolutely necessary? I'm amazed to hear that we link to motif in the modern world; it seems to be only this extension: $W/CxxObject/extensions/source/plugin/unx/npwrap.o $W/CxxObject/extensions/source/plugin/unx/npnapi.o I'd disable this I guess in configure.ac we have: dnl Check for NPAPI interface to plug browser plugins into LibreOffice documents I imagine we should just disable that for Solaris [ for now ]. Quite why we think Mozilla requires motif still I'm not sure I'd be amazed if they still had a hard dep on that. HTH, Michael. -- michael.me...@suse.com ___LibreOffice mailing listLibreOffice@lists.freedesktop.orghttp://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Building LO 4.0.4.2 on illumos based OS
Yes, I could find it, but it says nothing particular, just that it cannot find the libs. But I'm sure I have them. Any idea? -- Da: Michael Stahl A: Gabriele Bulfon Cc: michael.me...@suse.com libreoffice-dev Data: 15 luglio 2013 15.23.29 CEST Oggetto: Re: Building LO 4.0.4.2 on illumos based OS On 15/07/13 15:07, Gabriele Bulfon wrote: Ok, I could go over extension by disabling that motif dependent plugin. Now, later, it's trying to build xmlsec1, and looks like it can't find libs I actually have! checking for pkg-config... yes checking for libxslt libraries= 1.0.20... no [I have it, it's 1.1.26] checking for openssl libraries= 0.9.6... no [I have both 0.9.6 and 1.0.0j] checking for NSS... no checking for NSS... no checking for NSS... no checking for NSS no checking for NSS... no checking for nspr libraries= 4.0... no [I have nspr 4] checking for nss libraries= 3.2... no [I have nss 3.13.5] checking for gnutls libraries= 0.8.1... no [I have 3.1.9] checking for mscrypto libraries... none checking for crypto library... configure: error: At least one crypto library should exist for xmlsec1 I can't find the config.log of this component, this may hold the info I need to solve it. Can you help? it's in workdir/*/UnpackedTarball/xmlsec/config.log ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Building LO 4.0.4.2 on illumos based OS
I see no switch in global configure to force it to use system xmlsec. How does it decide to install its own? One possibility is that I make and install my own component of xmlsec. Will the build system see it and decide not to build its own? Gabriele. Da: Gabriele Bulfon A: Michael Stahl Cc: michael.me...@suse.com libreoffice-dev Data: 15 luglio 2013 15.36.11 CEST Oggetto: Re: Building LO 4.0.4.2 on illumos based OS Yes, I could find it, but it says nothing particular, just that it cannot find the libs. But I'm sure I have them. Any idea? -- Da: Michael Stahl A: Gabriele Bulfon Cc: michael.me...@suse.com libreoffice-dev Data: 15 luglio 2013 15.23.29 CEST Oggetto: Re: Building LO 4.0.4.2 on illumos based OS On 15/07/13 15:07, Gabriele Bulfon wrote: Ok, I could go over extension by disabling that motif dependent plugin. Now, later, it's trying to build xmlsec1, and looks like it can't find libs I actually have! checking for pkg-config... yes checking for libxslt libraries= 1.0.20... no [I have it, it's 1.1.26] checking for openssl libraries= 0.9.6... no [I have both 0.9.6 and 1.0.0j] checking for NSS... no checking for NSS... no checking for NSS... no checking for NSS no checking for NSS... no checking for nspr libraries= 4.0... no [I have nspr 4] checking for nss libraries= 3.2... no [I have nss 3.13.5] checking for gnutls libraries= 0.8.1... no [I have 3.1.9] checking for mscrypto libraries... none checking for crypto library... configure: error: At least one crypto library should exist for xmlsec1 I can't find the config.log of this component, this may hold the info I need to solve it. Can you help? it's in workdir/*/UnpackedTarball/xmlsec/config.log ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___LibreOffice mailing listLibreOffice@lists.freedesktop.orghttp://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Building LO 4.0.4.2 on illumos based OS
Ok. I see. Problem is, I could easily build, package and install my xmlsec1 component in few minutes, and it did see all the required libs (openssl, and so on). How can I debug why the LO internal configure cannot see the deps? Gabriele. -- Da: Rene Engelhard A: Gabriele Bulfon Cc: Michael Stahl michael.me...@suse.com libreoffice-dev Data: 15 luglio 2013 16.05.26 CEST Oggetto: Re: Building LO 4.0.4.2 on illumos based OS On Mon, Jul 15, 2013 at 03:48:15PM +0200, Gabriele Bulfon wrote: I see no switch in global configure to force it to use system xmlsec. Yes, there is none... How does it decide to install its own? By just doing it unconditionally and everywhere. One possibility is that I make and install my own component of xmlsec. Will the build system see it and decide not to build its own? Nope. It's so heavily patched that it *might* build but not work afaicr. system-xmlsec was once tried by abandonded for that reason. :/ (It's - besides rhino - the only library which is needed internally...) Regards, Rene ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Building LO 4.0.4.2 on illumos based OS
Or maybe I could build the patched xmlsec1 component out of the LO fetched tarball, as a system library (naming it as LO version), then force the LO build not to build that component? Da: Gabriele Bulfon A: Rene Engelhard Cc: michael.me...@suse.com Michael Stahl libreoffice-dev Data: 15 luglio 2013 16.08.16 CEST Oggetto: Re: Building LO 4.0.4.2 on illumos based OS Ok. I see. Problem is, I could easily build, package and install my xmlsec1 component in few minutes, and it did see all the required libs (openssl, and so on). How can I debug why the LO internal configure cannot see the deps? Gabriele. -- Da: Rene Engelhard A: Gabriele Bulfon Cc: Michael Stahl michael.me...@suse.com libreoffice-dev Data: 15 luglio 2013 16.05.26 CEST Oggetto: Re: Building LO 4.0.4.2 on illumos based OS On Mon, Jul 15, 2013 at 03:48:15PM +0200, Gabriele Bulfon wrote: I see no switch in global configure to force it to use system xmlsec. Yes, there is none... How does it decide to install its own? By just doing it unconditionally and everywhere. One possibility is that I make and install my own component of xmlsec. Will the build system see it and decide not to build its own? Nope. It's so heavily patched that it *might* build but not work afaicr. system-xmlsec was once tried by abandonded for that reason. :/ (It's - besides rhino - the only library which is needed internally...) Regards, Rene ___LibreOffice mailing listLibreOffice@lists.freedesktop.orghttp://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Building LO 4.0.4.2 on illumos based OS
A deeper check of the xmlsec1 config.log, shows there are many vars that are empty, not passed by main configure, such as NSS_LIBS and NSS_CFLAGS. These are set up during configure, and I used them to build against system nspr that is in a different location, but are empty in this internal xmlsec1 config.log. Probably I could pass also other libs like OPENSSL_CFLAGS and OPENSSL_LIBS, but I should understand how to pass them. Da: Gabriele Bulfon A: Rene Engelhard Cc: michael.me...@suse.com libreoffice-dev Michael Stahl Data: 15 luglio 2013 16.34.41 CEST Oggetto: Re: Building LO 4.0.4.2 on illumos based OS Or maybe I could build the patched xmlsec1 component out of the LO fetched tarball, as a system library (naming it as LO version), then force the LO build not to build that component? Da: Gabriele Bulfon A: Rene Engelhard Cc: michael.me...@suse.com Michael Stahl libreoffice-dev Data: 15 luglio 2013 16.08.16 CEST Oggetto: Re: Building LO 4.0.4.2 on illumos based OS Ok. I see. Problem is, I could easily build, package and install my xmlsec1 component in few minutes, and it did see all the required libs (openssl, and so on). How can I debug why the LO internal configure cannot see the deps? Gabriele. -- Da: Rene Engelhard A: Gabriele Bulfon Cc: Michael Stahl michael.me...@suse.com libreoffice-dev Data: 15 luglio 2013 16.05.26 CEST Oggetto: Re: Building LO 4.0.4.2 on illumos based OS On Mon, Jul 15, 2013 at 03:48:15PM +0200, Gabriele Bulfon wrote: I see no switch in global configure to force it to use system xmlsec. Yes, there is none... How does it decide to install its own? By just doing it unconditionally and everywhere. One possibility is that I make and install my own component of xmlsec. Will the build system see it and decide not to build its own? Nope. It's so heavily patched that it *might* build but not work afaicr. system-xmlsec was once tried by abandonded for that reason. :/ (It's - besides rhino - the only library which is needed internally...) Regards, Rene ___LibreOffice mailing listLibreOffice@lists.freedesktop.orghttp://lists.freedesktop.org/mailman/listinfo/libreoffice ___LibreOffice mailing listLibreOffice@lists.freedesktop.orghttp://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Building LO 4.0.4.2 on illumos based OS
...I also found that the old README.Solaris mentions a --disable-xmlsec, but the configure script doesn't mention it. Any other way to avoid building xmlsec? Da: Gabriele Bulfon A: Rene Engelhard Cc: michael.me...@suse.com libreoffice-dev Michael Stahl Data: 15 luglio 2013 16.47.25 CEST Oggetto: Re: Building LO 4.0.4.2 on illumos based OS A deeper check of the xmlsec1 config.log, shows there are many vars that are empty, not passed by main configure, such as NSS_LIBS and NSS_CFLAGS. These are set up during configure, and I used them to build against system nspr that is in a different location, but are empty in this internal xmlsec1 config.log. Probably I could pass also other libs like OPENSSL_CFLAGS and OPENSSL_LIBS, but I should understand how to pass them. Da: Gabriele Bulfon A: Rene Engelhard Cc: michael.me...@suse.com libreoffice-dev Michael Stahl Data: 15 luglio 2013 16.34.41 CEST Oggetto: Re: Building LO 4.0.4.2 on illumos based OS Or maybe I could build the patched xmlsec1 component out of the LO fetched tarball, as a system library (naming it as LO version), then force the LO build not to build that component? Da: Gabriele Bulfon A: Rene Engelhard Cc: michael.me...@suse.com Michael Stahl libreoffice-dev Data: 15 luglio 2013 16.08.16 CEST Oggetto: Re: Building LO 4.0.4.2 on illumos based OS Ok. I see. Problem is, I could easily build, package and install my xmlsec1 component in few minutes, and it did see all the required libs (openssl, and so on). How can I debug why the LO internal configure cannot see the deps? Gabriele. -- Da: Rene Engelhard A: Gabriele Bulfon Cc: Michael Stahl michael.me...@suse.com libreoffice-dev Data: 15 luglio 2013 16.05.26 CEST Oggetto: Re: Building LO 4.0.4.2 on illumos based OS On Mon, Jul 15, 2013 at 03:48:15PM +0200, Gabriele Bulfon wrote: I see no switch in global configure to force it to use system xmlsec. Yes, there is none... How does it decide to install its own? By just doing it unconditionally and everywhere. One possibility is that I make and install my own component of xmlsec. Will the build system see it and decide not to build its own? Nope. It's so heavily patched that it *might* build but not work afaicr. system-xmlsec was once tried by abandonded for that reason. :/ (It's - besides rhino - the only library which is needed internally...) Regards, Rene ___LibreOffice mailing listLibreOffice@lists.freedesktop.orghttp://lists.freedesktop.org/mailman/listinfo/libreoffice ___LibreOffice mailing listLibreOffice@lists.freedesktop.orghttp://lists.freedesktop.org/mailman/listinfo/libreoffice ___LibreOffice mailing listLibreOffice@lists.freedesktop.orghttp://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Building LO 4.0.4.2 on illumos based OS
usually libs should contain not just search paths but also the libraries to be linked, e.g. in config_host.mk with a system nss i get: export NSS_LIBS=$(gb_SPACE)-lssl3 -lsmime3 -lnss3 -lnssutil3 -lplds4 -lplc4 -lnspr4 -lpthread -ldl also i guess only Sun ld knows -R, the GNU ld equivalent is -Wl,-rpath, Well done! With this env the build went on the unopkg.bin! CONFIGURE_ENV += NSS_CFLAGS=-I/usr/include/mps CONFIGURE_ENV += NSS_LIBS=-Wl,-rpath,/usr/lib/mps -L/usr/lib/mps -lssl3 -lsmime3 -lnss3 -lnssutil3 -lplds4 -lplc4 -lnspr4 -lpthread -ldl I prefer to use my userland Makefile options instead of modifying the solaris.mk Now the build is going on.let's wait and see... ;) Gabriele. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Building LO 4.0.4.2 on illumos based OS
usually libs should contain not just search paths but also the libraries to be linked, e.g. in config_host.mk with a system nss i get: export NSS_LIBS=$(gb_SPACE)-lssl3 -lsmime3 -lnss3 -lnssutil3 -lplds4 -lplc4 -lnspr4 -lpthread -ldl also i guess only Sun ld knows -R, the GNU ld equivalent is -Wl,-rpath, Well done! With this env the build went on the unopkg.bin! CONFIGURE_ENV += NSS_CFLAGS=-I/usr/include/mps CONFIGURE_ENV += NSS_LIBS=-Wl,-rpath,/usr/lib/mps -L/usr/lib/mps -lssl3 -lsmime3 -lnss3 - lnssutil3 -lplds4 -lplc4 -lnspr4 -lpthread -ldl I prefer to use my userland Makefile options instead of modifying the solaris.mk Now the build is going on.let's wait and see... ;) Gabriele. Ok, it stopped later with this: [build LNK] Executable/pluginapp.bin S=/sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1 O=$S/solver/unxsogi.pro W=$S/workdir/unxsogi.pro mkdir -p $W/LinkTarget/Executable/ /usr/gcc/4.4/bin/g++ -Wl,-z,origin '-Wl,-rpath,$ORIGIN:$ORIGIN/../ure-link/lib' -Wl,-rpath-link,$O/lib -z nodefs $W/CxxObject/extensions/source/plugin/unx/npwrap.o $W/CxxObject/extensions/source/plugin/unx/npnapi.o -Wl,--start-group $O/lib/libplugcon.a -Wl,--end-group -Wl,--no-as-needed -lm -lnsl -lsocket -lXm -lXt -lXext -lX11 -ldl -lgthread-2.0 -lpthread -lglib-2.0 -R/usr/lib -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgdk_pixbuf_xlib-2.0 -lgmodule-2.0 -lpthread -lgdk_pixbuf-2.0 -lgobject-2.0 -lglib-2.0 -R/usr/lib -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lglib-2.0 -luno_sal -o $W/LinkTarget/Executable/pluginapp.bin /usr/gnu/bin/ld: cannot find -luno_sal collect2: ld returned 1 exit status I guess I'm missing a librarynot built? ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Building LO 4.0.4.2 on illumos based OS
hmm... so vcl is supposed to be linked against NSS/NSPR libraries but somehow that doesn't work for you... what is really weird is that it fails on linking the executable, it should really fail when linking vcl library already. can you check that the link command lines use -Wl,-z,defs ? apparently not, try to copy the relevant lines from gbuild/platform/linux.mk to solaris.mk. the other problem is most likely that the libraries from the nss module somehow have hidden visibility (i assume you are not using --with-system-nss?)... if things work PR_Now should be exported like this: nm --defined-only -D -g solver/*/lib/libnspr4.so | grep PR_Now 00039123 T PR_Now you'll have to dig into the external build system there to figure out why it doesn't work, the files are in workdir/*/UnpackedTarball/nss (or if your distro has NSS packages try using --with-system-nss). Several things appear strange to me, so here are some considerations: 1 - Yes, I use system libs for nspr/nss, built by my distro userland 2 - Doing ldd on libvcllo.so shows a lot of lib dependencies, but no mention about nspr nor nss libs 3 - Doing your nm on my system libnspr4.so correctly reveals the output you said 4 - The nspr/nss libs are not under /usr/lib nor /lib in my system, they're all under /usr/lib/mps I tried running gmake under desktop as you requested (had to add the LD_ALTEXEC to force sun ld to run gnu ld instead): sonicle@vbxstreamdev:/sources/userlands/xstream-userland-gate/components/libreoffice/build/i86/desktop$ gmake LD_ALTEXEC=/usr/gnu/bin/ld [build LNK] Executable/unopkg.bin S=/sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1 O=$S/solver/unxsogi.pro W=$S/workdir/unxsogi.pro mkdir -p $W/LinkTarget/Executable/ /usr/gcc/4.4/bin/gcc -Wl,-z,origin '-Wl,-rpath,$ORIGIN:$ORIGIN/../ure-link/lib' -Wl,-rpath-link,$O/lib -Wl,-rpath-link,/lib:/usr/lib -Wl,-z,combreloc -L$O/lib -L/usr/gcc/4.4/lib -L/usr/local/bin -L/usr/dt/lib -L/usr/openwin/lib -Wl,-O1 $W/CObject/desktop/source/pkgchk/unopkg/unopkg_main.o -Wl,--start-group -Wl,--end-group -Wl,--no-as-needed -lm -lnsl -lsocket -lcomphelper -luno_sal -ltllo -lunopkgapp -o $W/LinkTarget/Executable/unopkg.bin /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `PR_Now' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `NSS_CMSMessage_Create' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `CERT_DecodeCertFromPackage' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `NSS_CMSSignedData_AddCertificate' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `NSS_CMSSignerInfo_IncludeCerts' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `NSS_CMSEncoder_Finish' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `NSS_CMSMessage_Destroy' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `NSS_CMSSignedData_AddSignerInfo' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `NSS_CMSSignerInfo_AddSigningTime' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `NSS_CMSEncoder_Start' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `NSS_NoDB_Init' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `HASH_Begin' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `HASH_End' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `NSS_CMSSignedData_Create' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `NSS_CMSMessage_GetContentInfo' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `NSS_CMSSignedData_GetContentInfo'
Re: Building LO 4.0.4.2 on illumos based OS
hmm... so vcl is supposed to be linked against NSS/NSPR libraries but somehow that doesn't work for you... what is really weird is that it fails on linking the executable, it should really fail when linking vcl library already. can you check that the link command lines use -Wl,-z,defs ? apparently not, try to copy the relevant lines from gbuild/platform/linux.mk to solaris.mk. the other problem is most likely that the libraries from the nss module somehow have hidden visibility (i assume you are not using --with-system-nss?)... if things work PR_Now should be exported like this: nm --defined-only -D -g solver/*/lib/libnspr4.so | grep PR_Now 00039123 T PR_Now you'll have to dig into the external build system there to figure out why it doesn't work, the files are in workdir/*/UnpackedTarball/nss (or if your distro has NSS packages try using --with-system-nss). Analyzing better, I've seen my userland component Makefile for libreoffice, contains specific env: CONFIGURE_ENV += NSS_CFLAGS=-I/usr/include/mps CONFIGURE_ENV += NSS_LIBS=-L/usr/lib/mps -R/usr/lib/mps CONFIGURE_ENV += NPAPI_HEADERS_LIBS=-L/usr/lib CONFIGURE_ENV += NPAPI_HEADERS_CFLAGS=-I/usr/include/npapi These are passed on at configure time. But I can't see these linking options on the running link: S=/sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1 O=$S/solver/unxsogi.pro W=$S/workdir/unxsogi.pro mkdir -p $W/LinkTarget/Executable/ /usr/gcc/4.4/bin/gcc -Wl,-z,origin '-Wl,-rpath,$ORIGIN:$ORIGIN/../ure-link/lib' -Wl,-rpath-link,$O/lib -Wl,-rpath-link,/lib:/usr/lib -Wl,-z,combreloc -L$O/lib -L/usr/gcc/4.4/lib -L/usr/local/bin -L/usr/dt/lib -L/usr/openwin/lib -Wl,-O1 $W/CObject/desktop/source/pkgchk/unopkg/unopkg_main.o -Wl,--start-group -Wl,--end-group -Wl,--no-as-needed -lm -lnsl -lsocket -lcomphelper -luno_sal -ltllo -lunopkgapp -o $W/LinkTarget/Executable/unopkg.bin ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Building LO 4.0.4.2 on illumos based OS
Hi Michael, would be a great idea the tinderbox setup. I will send you the link of the XStream Desktop iso as soon as we have it out. BTW, can you help me with this? I really don't know what problem is thismust be something about gnu ld, but I had more experience with Sun ld. Gabriele. On Thursday, 2013-07-04 at 09:32, Gabriele Bulfon wrote: Hi, after long building LO 4.1.0.1 on illumos based OS, I reached this error: [build LNK] Executable/unopkg.bin /usr/gnu/bin/ld: /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/workdir/unxsogi.pro/LinkTarget/Executable/unopkg.bin: hidden symbol `main' in/sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/workdir/unxsogi.pro/CObject/desktop/source/pkgchk/unopkg/unopkg_main.o is referenced byDSO /usr/gnu/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status Any idea? Gabriele. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Building LO 4.0.4.2 on illumos based OS
Hi Gabriele,
On Fri, 2013-07-05 at 08:14 +0200, Gabriele Bulfon wrote:
Hi Michael, would be a great idea the tinderbox setup.
I will send you the link of the XStream Desktop iso as soon as we have
it out.
Wonderful.
BTW, can you help me with this? I really don't know what problem is
thismust be something
about gnu ld, but I had more experience with Sun ld.
...
[build LNK] Executable/unopkg.bin
/usr/gnu/bin/ld:
/sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/workdir/unxsogi.pro/LinkTarget/Executable/unopkg.bin:
hidden symbol `main' in
/sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/workdir/unxsogi.pro/CObject/desktop/source/pkgchk/unopkg/unopkg_main.o
is referenced by DSO
/usr/gnu/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status
Looks like a mis-interaction with some visibility markup - though
clearly getting more output would be good:
cd desktop
make
gives a more verbose make. Try something like the attached; if that
works we should get it into master and -4-1 :-)
HTH,
Michael.
--
michael.me...@suse.com , Pseudo Engineer, itinerant idiot
diff --git a/include/sal/main.h b/include/sal/main.h
index 634b57c..d5c227c 100644
--- a/include/sal/main.h
+++ b/include/sal/main.h
@@ -43,7 +43,7 @@ SAL_DLLPUBLIC void SAL_CALL sal_detail_deinitialize();
#else
#define SAL_MAIN_WITH_ARGS_IMPL \
-int SAL_CALL main(int argc, char ** argv) \
+int SAL_DLLPUBLIC SAL_CALL main(int argc, char ** argv) \
{ \
int ret; \
sal_detail_initialize(argc, argv); \
@@ -53,7 +53,7 @@ int SAL_CALL main(int argc, char ** argv) \
}
#define SAL_MAIN_IMPL \
-int SAL_CALL main(int argc, char ** argv) \
+int SAL_DLLPUBLIC SAL_CALL main(int argc, char ** argv) \
{ \
int ret; \
sal_detail_initialize(argc, argv); \
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Building LO 4.0.4.2 on illumos based OS
Hi Gabriele, On Fri, 2013-07-05 at 08:14 +0200, Gabriele Bulfon wrote: Hi Michael, would be a great idea the tinderbox setup. I will send you the link of the XStream Desktop iso as soon as we have it out. Wonderful. BTW, can you help me with this? I really don't know what problem is thismust be something about gnu ld, but I had more experience with Sun ld. ... [build LNK] Executable/unopkg.bin /usr/gnu/bin/ld: /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/workdir/unxsogi.pro/LinkTarget/Executable/unopkg.bin: hidden symbol`main' in/sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/workdir/unxsogi.pro/CObject/desktop/source/pkgchk/unopkg/unopkg_main.o isreferenced byDSO /usr/gnu/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status Looks like a mis-interaction with some visibility markup - though clearly getting more output would be good: cd desktop make gives a more verbose make. Try something like the attached; if that works we should get it into master and -4-1 :-) HTH, Michael. -- michael.me...@suse.com Here is what I got after applying your patch (causing a lot of rebuilding of previous code). Later I will send you the output of the detail you aksed: [build LNK] Library/libunopkgapp.so [build C ] desktop/source/pkgchk/unopkg/unopkg_main.c [build LNK] Executable/unopkg.bin /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `PR_Now' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `NSS_CMSMessage_Create' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `CERT_DecodeCertFromPackage' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `NSS_CMSSignedData_AddCertificate' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `NSS_CMSSignerInfo_IncludeCerts' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `NSS_CMSEncoder_Finish' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `NSS_CMSMessage_Destroy' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `NSS_CMSSignedData_AddSignerInfo' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `NSS_CMSSignerInfo_AddSigningTime' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `NSS_CMSEncoder_Start' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `NSS_NoDB_Init' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `HASH_Begin' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `HASH_End' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `NSS_CMSSignedData_Create' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `NSS_CMSMessage_GetContentInfo' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `NSS_CMSSignedData_GetContentInfo' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `NSS_CMSSignerInfo_Create' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `NSS_CMSContentInfo_SetContent_SignedData' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `HASH_Update' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `NSS_CMSSignedData_SetDigestValue' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `HASH_Create'
Re: Building LO 4.0.4.2 on illumos based OS
ah sorry the relevant one is gb_Executable__get_rpath I also tried using Sun ld, but looks like options for ld are always gnu-ld ones, so compilation stop much earlier. ...any clue? sure, if you want to use Sun ld you need to change quite a few things in solaris.mk to use different options. -- Michael Stahl | Software Engineer Platform Engineering - Desktop Team Red Hat Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com Progressing in LO build, it reached the connectivity source point and I got this: [build CMP] connectivity/source/drivers/mysql/mysql [build CXX] connectivity/source/drivers/odbcbase/OPreparedStatement.cxx [build CXX] connectivity/source/drivers/odbcbase/OStatement.cxx [build CXX] connectivity/source/drivers/odbcbase/OResultSetMetaData.cxx [build CXX] connectivity/source/drivers/odbcbase/OResultSet.cxx [build CXX] connectivity/source/drivers/odbcbase/OTools.cxx [build CXX] connectivity/source/drivers/odbcbase/ODatabaseMetaDataResultSet.cxx [build CXX] connectivity/source/drivers/odbcbase/ODatabaseMetaData.cxx [build CXX] connectivity/source/drivers/odbcbase/ODriver.cxx [build CXX] connectivity/source/drivers/odbcbase/OConnection.cxx /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/connectivity/source/drivers/odbcbase/OConnection.cxx: In member function 'virtual rtl::OUString connectivity::odbc::OConnection::getCatalog()': /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/connectivity/source/drivers/odbcbase/OConnection.cxx:423: error: invalid conversion from 'sal_Int32*' to 'SQLINTEGER*' make[2]: *** [/sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/workdir/unxsogi.pro/CxxObject/connectivity/source/drivers/odbcbase/OConnection.o] Error 1 Any idea?? Gabriele. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Building LO 4.0.4.2 on illumos based OS
On Sat, Jun 29, 2013 at 16:24:42 CEST, Norbert Thiebaud wrote take a look at Library_cpp_uno.mk and in particular how bridges_SELECTED_BRIDGE is set... from what I read the else ifeq($(CPU),I) line 56 pre-empt the section you want which is lower.. line 143 some re-order of the different if/else section seems in order (to works we need to test from the most particular to the most generic) Norbert Great! I moved the SOLARISI code from line 143 up just before line 56 and it worked ;) Thanx! Gabriele. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Building LO 4.0.4.2 on illumos based OS
take a look at Library_cpp_uno.mk and in particular how bridges_SELECTED_BRIDGE is set... from what I read the else ifeq($(CPU),I) line 56 pre-empt the section you want which is lower.. line 143 some re-order of the different if/else section seems in order (to works we need to test from the most particular to the most generic) Norbert Build goes through for some time, then I got this (I didn't have this on 4.0): [build C ] sal/osl/unx/tempfile.c [build C ] sal/osl/unx/thread.c [build C ] sal/osl/unx/time.c [build C ] sal/osl/unx/util.c [build C ] sal/osl/unx/signal.c [build C ] sal/osl/unx/backtrace.c [build ASM] sal/osl/unx/asm/interlck_x86 [build LNK] Library/libuno_sal.so ERROR: aux-target missing, library deleted, please try running make again make[2]: *** [/sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/workdir/unxsogi.pro/LinkTarget/Library//libuno_sal.so.3] Error 1 Running make again as suggested, repeats the error. Any idea? Gabriele. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Building LO 4.0.4.2 on illumos based OS
Hi, because I need to work on a consolidated tar.gz source version, I'm not using master, so I cannot pull changes at the moment. Can you suggest me what modifications I need? Gabriele. -- Da: Michael Stahl A: Gabriele Bulfon Cc: libreoffice@lists.freedesktop.org Raffaele Fullone Jonathan Adams Data: 1 luglio 2013 13.34.58 CEST Oggetto: Re: Building LO 4.0.4.2 on illumos based OS On 01/07/13 11:03, Gabriele Bulfon wrote: [build LNK] Library/libuno_sal.so ERROR: aux-target missing, library deleted, please try running make again make[2]: *** [/sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/workdir/unxsogi.pro/LinkTarget/Library//libuno_sal.so.3] Error 1 Running make again as suggested, repeats the error. Any idea? apparently the solaris.mk is out of sync with the unxgcc.mk from which it was copied; i've pushed 99a4baf89c470d1e73b4e87fe9adf37a09230a2c to fix the dynamic link command. this duplication needs to be reverted in the long run, solaris.mk should include unxgcc.mk. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Building LO 4.0.4.2 on illumos based OS
On Mon, Jul 1, 2013 at 6:39 AM, Gabriele Bulfon gabriele.bul...@sonicle.com wrote: Hi, because I need to work on a consolidated tar.gz source version, I'm not using master, so I cannot pull changes at the moment. Can you suggest me what modifications I need? http://cgit.freedesktop.org/libreoffice/core/commit/? id=99a4baf89c470d1e73b4e87fe9adf37a09230a2c Thanks Norbert :) it worked great ;) Gabriele. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Building LO 4.0.4.2 on illumos based OS
On Mon, Jul 1, 2013 at 6:39 AM, Gabriele Bulfon gabriele.bul...@sonicle.com wrote: Hi, because I need to work on a consolidated tar.gz source version, I'm not using master, so I cannot pull changes at the moment. Can you suggest me what modifications I need? http://cgit.freedesktop.org/libreoffice/core/commit/?id=99a4baf89c470d1e73b4e87fe9adf37a09230a2c Ok, now I'm stuck again with libreg.so not being resolved: [build LNK] Executable/cppumaker /usr/gnu/bin/ld: warning: libreg.so, needed by /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libunoidl.so, not found (try using -rpath or -rpath-link) I tried using the solaris.mk commented options: @@ -120,6 +120,7 @@ -L$(SYSBASE)/lib \ -L$(SYSBASE)/usr/lib \ -Wl,-z,combreloc \ + -Wl,-rpath-link,$(SYSBASE)/lib:$(SYSBASE)/usr/lib \ $(SOLARLIB) \ ifeq ($(HAVE_LD_HASH_STYLE),TRUE) but no luck, still cannot solve. I also tried using Sun ld, but looks like options for ld are always gnu-ld ones, so compilation stop much earlier. ...any clue? Gabriele. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Building LO 4.0.4.2 on illumos based OS
On 01/07/13 16:43, Michael Stahl wrote: On 01/07/13 14:58, Gabriele Bulfon wrote: [build LNK] Executable/cppumaker /usr/gnu/bin/ld: warning: libreg.so, needed by /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libunoidl.so, not found (try using -rpath or -rpath-link) I tried using the solaris.mk commented options: @@ -120,6 +120,7 @@ -L$(SYSBASE)/lib \ -L$(SYSBASE)/usr/lib \ -Wl,-z,combreloc \ + -Wl,-rpath-link,$(SYSBASE)/lib:$(SYSBASE)/usr/lib \ $(SOLARLIB) \ ifeq ($(HAVE_LD_HASH_STYLE),TRUE) but no luck, still cannot solve. did you try adding it to definition of gb_Library__get_rpath like it's done in unxgcc.mk ? (perhaps just copy that) ah sorry the relevant one is gb_Executable__get_rpath I also tried using Sun ld, but looks like options for ld are always gnu-ld ones, so compilation stop much earlier. ...any clue? sure, if you want to use Sun ld you need to change quite a few things in solaris.mk to use different options. Great suggestions! Path to the solution ;) it went through :) Following your suggestion I found solaris.mk had many more lines about rpath, the ones you pointed, and they were almost all changed from unxgcc.mk into something different. I guess the one who tried to do solaris.mk was using Sun ld instead of Gnu. It's going on building now. ;) Gabriele. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Building LO 4.0.4.2 on illumos based OS
On 28/06/13 12:01, Michel Stahl wrote:
On 28/06/13 07:39, Gabriele Bulfon wrote:
Hi, I moved to 4.1 build from scratch.
Build required me a couple of new system libs (libodfgen and libmwaw)
that I could package easily.
Then, it stops just after the succesful configure:
/sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1//bridges/Module_bridges.mk:28:
*** no bridge selected for build: bailing out.. Stop.
the UNO binary
C++ bridge, which is specific to architecture and
compiler ABI.
i guess you need to tweak the if conditionals in
bridges/Module_bridges.mk to select the appropriate GCC3 bridge for your
platform; there is one in bridges/source/cpp_uno/gcc3_solaris_{intel,sparc}
Hi, I noticed the bridges structure is quite changed from 4.0 and 4.1.
In 4.0 build, it could correctly select the solaris intel bridge.
Looks like 4.1 cannot do it anymore, though I debugged env vars and they look
correctly set to CPU=I and OS=SOLARIS.
Actually I cannot see how that 4.1 mk file is now selecting the bridge,
while in 4.0 there were a lot of if, including solaris specifics.
Can you help me on how to force Module_bridges.mk to use gcc3_solaris_intel?
Another clue: I'm using gcc4.4.7maybe this is annoying it? And if yes, why
4.0 was not?
Thanks again,
Gabriele.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Building LO 4.0.4.2 on illumos based OS
Hi, I moved to 4.1 build from scratch. Build required me a couple of new system libs (libodfgen and libmwaw) that I could package easily. Then, it stops just after the succesful configure: make[1]: Entering directory `/sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1' /usr/gnu/bin/make -j 1 -rsw -f /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/Makefile.gbuild make[2]: Entering directory `/sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1//bridges/Module_bridges.mk:28: *** no bridge selected for build: bailing out. Stop. make[2]: Leaving directory `/sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1' make[1]: *** [build] Error 2 make[1]: Leaving directory `/sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1' gmake: *** [/sources/userlands/xstream-userland-gate/components/libreoffice/build/i86/.built] Error 2 What does it mean? What bridge? Thanks, Gabriele. -- Da: Michael Stahl A: Gabriele Bulfon Cc: libreoffice@lists.freedesktop.org Raffaele Fullone Jonathan Adams Pierre-Eric Pelloux-Prayer Data: 27 giugno 2013 14.04.21 CEST Oggetto: Re: Building LO 4.0.4.2 on illumos based OS On 27/06/13 10:52, Gabriele Bulfon wrote: Hi, I'm working on our Sonicle XStreamOS distro based on illumos kernel. I encountered some problems building LO 4.0..4.2. i'd suggest to try building libreoffice-4-1 branch or master instead, because it should be easier: in the libreoffice-4-0 branch the migration to the new GNU make based build system was still in progress, so you have to get both the new and the old build system to work for you, whereas in libreoffice-4-1 and master there is only one build system. [build LNK] Executable/cppumaker /usr/gnu/bin/ld: warning: libstore.so, needed by /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.0.4.2/solver/unxsogi.pro/lib/libreg.so, not found (try using -rpath or -rpath-link) I can't see why libreg.so can't resolve libstore.so, as they both live in solver/unxsogi.pro/lib : the GNU linker apparently does not automatically use RPATH stored in the .so for finding dependent libraries, and neither uses the -L passed to it for finding dependent libraries. it uses the -L parameters only to find libraries that are explicitly listed on the command line (-lfoo); apparently you have -lreg but not -lstore on the command line. the solution is to use -rpath-link, which is used to find dependent libraries that are not explicitly listed on the command line. git grep finds this, which is commented out for reasons unknown to me: solenv/gbuild/platform/solaris.mk:#JAD#'-Wl,-rpath-link,$(gb_Library_OUTDIRLOCATION)' (iirc Sun ld would search -L directories in this case too so doesn't need -rpath-link.) and ldd shows correct resolutions: ldd uses the RPATH $ORIGIN in the .so hence it has no problems. i am not sure if it would be better to use Sun ld or GNU ld on OpenSolaris; i guess GNU ld has the advantage that it's the same as on GNU/Linux so should make porting easier. by the way here's some links to threads from previous porting efforts http://permalink.gmane.org/gmane.comp.documentfoundation.libreoffice.devel/22798 http://permalink.gmane.org/gmane.comp.documentfoundation.libreoffice.devel/39846 ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Building LO 4.0.4.2 on illumos based OS
Yes, madvise is available in illumos, but probably some build flag is excluding
its definition
from the sys/mman.h, that is full of ifdef about __EXTENSIONS__,
__XOPEN_OR_POSIX, and so on.
I found someone from OpenIndiana solving it by excluding like I did.
Anyway, now I'm stuck with the last problem :(
Gabriele.
--
Da: Riccardo Magliocchetti
A: libreoffice@lists.freedesktop.org
Data: 27 giugno 2013 12.49.12 CEST
Oggetto: Re: Building LO 4.0.4.2 on illumos based OS
Hi Gabriele,
Il 27/06/2013 10:52, Gabriele Bulfon ha scritto:
Hi,
I'm working on our Sonicle XStreamOS distro based on illumos kernel.
[snip]
I stumbled on on error about madvise missing, but I could find a working
patch:
--- libreoffice-4.0.4.2/sal/osl/unx/file.cxxThu Jun 27 09:22:25 2013
+++ libreoffice-4.0.4.2/sal/osl/unx/file.cxxThu Jun 27 09:22:54 2013
@@ -1260,7 +1260,7 @@
OSL_TRACE(
posix_madvise(..., POSIX_MADV_WILLNEED) failed with %d, e);
}
-#elif defined SOLARIS
+#elif defined NOTSOLARIS
if (madvise(static_cast
(p), nLength, MADV_WILLNEED) != 0)
{
OSL_TRACE(madvise(..., MADV_WILLNEED) failed with %d, errno);
basically it disables the call to madvise on my env, then build went on very
long over the tail_build.
That's strange, you should have madvise on illumos per
http://illumos.org/man/3C/madvise . May this be an issue with the libc
in Sonicle XStreamOS?
cheers,
riccardo
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Building LO 4.0.4.2 on illumos based OS
Great answers! Thanx ;) I'm already moving to 4.1, and see if it still have the libstore issue, in that case I'll look for the commented line and re-enable it. BTW, I don't know why, but I was forced to use gnu ld (via the sun ld env LD_ALTEXEC), or LO ld options would not work. Maybe there is something I should say during configure to let it understand I'm in a Solaris-type OS? Gabriele. -- Da: Michael Stahl A: Gabriele Bulfon Cc: libreoffice@lists.freedesktop.org Raffaele Fullone Jonathan Adams Pierre-Eric Pelloux-Prayer Data: 27 giugno 2013 14.04.21 CEST Oggetto: Re: Building LO 4.0.4.2 on illumos based OS On 27/06/13 10:52, Gabriele Bulfon wrote: Hi, I'm working on our Sonicle XStreamOS distro based on illumos kernel. I encountered some problems building LO 4.0..4.2. i'd suggest to try building libreoffice-4-1 branch or master instead, because it should be easier: in the libreoffice-4-0 branch the migration to the new GNU make based build system was still in progress, so you have to get both the new and the old build system to work for you, whereas in libreoffice-4-1 and master there is only one build system. [build LNK] Executable/cppumaker /usr/gnu/bin/ld: warning: libstore.so, needed by /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.0.4.2/solver/unxsogi.pro/lib/libreg.so, not found (try using -rpath or -rpath-link) I can't see why libreg.so can't resolve libstore.so, as they both live in solver/unxsogi.pro/lib : the GNU linker apparently does not automatically use RPATH stored in the .so for finding dependent libraries, and neither uses the -L passed to it for finding dependent libraries. it uses the -L parameters only to find libraries that are explicitly listed on the command line (-lfoo); apparently you have -lreg but not -lstore on the command line. the solution is to use -rpath-link, which is used to find dependent libraries that are not explicitly listed on the command line. git grep finds this, which is commented out for reasons unknown to me: solenv/gbuild/platform/solaris.mk:#JAD#'-Wl,-rpath-link,$(gb_Library_OUTDIRLOCATION)' (iirc Sun ld would search -L directories in this case too so doesn't need -rpath-link.) and ldd shows correct resolutions: ldd uses the RPATH $ORIGIN in the .so hence it has no problems. i am not sure if it would be better to use Sun ld or GNU ld on OpenSolaris; i guess GNU ld has the advantage that it's the same as on GNU/Linux so should make porting easier. by the way here's some links to threads from previous porting efforts http://permalink.gmane.org/gmane.comp.documentfoundation.libreoffice.devel/22798 http://permalink.gmane.org/gmane.comp.documentfoundation.libreoffice.devel/39846 ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
