Re: libreoffice fails to build
On 19 Jul 2012 01:09, Robert Huff roberth...@rcn.com wrote: Doug Barton writes: On a system running: FreeBSD 10.0-CURRENT #0: Wed Jul 18 08:15:22 EDT 2012 amd64 and system clang (3.1), libreoffice 3.5.5 Built cleanly for me last night on r238444. Are you sure your world is current enough to get the latest clang fixes? System and ports were updated (by csup) at 00:01 US Eastern time today. Recent enough? I don't wish to patronise, but you did also make world too, right? Chris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: make failed for editors/libreoffice
2012-07-19 01:49, Jung-uk Kim skrev: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-07-18 18:21:53 -0400, Jung-uk Kim wrote: On 2012-07-18 14:11:46 -0400, Lowell Gilbert wrote: Jung-uk Kim j...@freebsd.org writes: It is not clang's fault actually and I am working on a fix. Please stay tuned. One issue is that different problems have been presenting with very similar symptoms, so that it's hard to help people who need technical assistance. I don't see anything we can do about that, unfortunately. Yes, it is really hard for me to fix all supported releases. :-( Anyway, here is the patch for testing: http://people.freebsd.org/~jkim/libreoffice-clang3.2.diff The patch updated: http://people.freebsd.org/~jkim/libreoffice-clang3.2_2.diff Basically, you need to revert two patches, i.e., patch-solenv__gbuild__platform__unxgcc.mk and patch-solenv__inc__unxgcc.mk. It didn't work for old releases. :-( Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAHS5UACgkQmlay1b9qnVM+5gCdGGuh3dp+tuH5miuQoY+gTey5 nQsAn3754EnZYX86X+IrFpYdlIy5LOMW =qc1O -END PGP SIGNATURE- libreoffice-3.5.5 now builds and install on my system 8.2-RELEASE-p9, with the updated patch. But when I try to start it fails javaPathHelper: not found terminate called after throwing an instance of 'com::sun::star::ucb::InteractiveAugmentedIOException' Thanks /Leslie ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Bug in dns/fpdns
On 07/18/2012 12:06, Greg Rivers wrote: The ports version of dns/fpdns seems to have this[1] bug: $ fpdns ns1.isc-sns.net. Net::DNS::Header::data: no such method at /usr/local/lib/perl5/site_perl/5.16.0/Net/DNS/Fingerprint.pm line 668. [1] https://bugzilla.redhat.com/show_bug.cgi?id=830449 Fixed, thanks! -- Change is hard. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [FYI] C++ compilers vs. __cplusplus (was Re: SV: Re: make failed for editors/libreoffice)
On 2012-07-19 01:34, Jung-uk Kim wrote: While I was tackling LibreOffice build issues, I found something interesting about __cplusplus. Basically, different C++ compilers may have different __cplusplus definitions and it may cause some strangeness. Clang, for example, used to set it to 1 but now it is set to C++ standard value since this commit: http://llvm.org/viewvc/llvm-project?view=revrevision=156113 Yes, this is because gcc started doing the same. Otherwise it becomes rather difficult to distinguish C++98, C++0x and C++11 in your C++ library implementation (in the GNU case, libstdc++ most likely). ... This causes very subtle issues depending on compiler versions and FreeBSD versions. For example, NULL may be defined differently because stable/9 and head have this: #if __cplusplus = 201103L #define NULLnullptr #elif defined(__GNUG__) defined(__GNUC__) __GNUC__ = 4 #define NULL__null #else #if defined(__LP64__) #define NULL(0L) #else #define NULL0 #endif /* __LP64__ */ #endif /* __GNUG__ */ Before that, we had this: #if defined(__GNUG__) defined(__GNUC__) __GNUC__ = 4 #define NULL__null #else #if defined(__LP64__) #define NULL(0L) #else #define NULL0 #endif/* __LP64__ */ #endif/* __GNUG__ */ What a mess... Well, this is what you get when standards progress to include non-standard features (such as gcc's __null) that are already in use, but then subtly change them (calling them nullptr). However, as long as you can hide the #ifdef ugliness in a header, I don't really see the problem. This won't be the last ugly definition either. :) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
port DNS/UNBOUND
Hello!
After port was moved to new NGoptions this is inpossible to compile port
with threads enabled. make always adds --without-pthreads undepended on
setings in make config
At Makefile we have
.if empty(${PORT_OPTIONS:MTHREADS})
CONFIGURE_ARGS+=--without-pthreads
.endif
and resulted configure with THREADS enabled from config.log:
$ ./configure --with-ssl=/usr --disable-gost --disable-ecdsa
--with-libevent=/usr/local --without-pthreads --prefix=/usr/local
I changed this to
.if !${PORT_OPTIONS:MTHREADS}
CONFIGURE_ARGS+=--without-pthreads
.endif
and as result I have not --without-pthreads in configure parameters anymore
and unbound started as multithread program
Could you, please, change the port ?
Thank you
/Alexey
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
SAMBA_PORT= usage different by port.
It seems that the usage of SAMBA_PORT= var has been confused quite a
bit.
SAMBA_PORT= as judged by ports/net/samba* is defined to be net/samba??
while ports/net/samba-libsmbclient defines it as samba??
I found when creating index that no matter which way you define it both
of the two ways will end up indicating failure for different ports
because /usr/ports/samba?? does not exist or /usr/ports/net/net/samba??
does not exist.
Can someone please go through these ports and unify there usage of
SAMBA_PORT.
/usr/ports/net/samba-libsmbclient/Makefile:16:SAMBA_PORT= samba34
/usr/ports/net/samba-libsmbclient/Makefile:19:MASTERDIR=
${.CURDIR}/../${SAMBA_PORT}
/usr/ports/net/samba-nmblookup/Makefile:16:SAMBA_PORT= samba34
/usr/ports/net/samba-nmblookup/Makefile:19:MASTERDIR=
${.CURDIR}/../${SAMBA_PORT}
/usr/ports/net/samba-pdbsql/Makefile:23:SAMBA_PORT?=net/samba34
/usr/ports/net/samba-pdbsql/Makefile:30:SAMBA_WRKSRC!= cd
${PORTSDIR}/${SAMBA_PORT} ${MAKE} -V WRKSRC
/usr/ports/net/samba-pdbsql/Makefile:34:SAMBA_MODULEDIR!= cd
${PORTSDIR}/${SAMBA_PORT} ${MAKE} -V SAMBA_MODULEDIR
/usr/ports/net/samba-pdbsql/Makefile:40:BUILD_DEPENDS+=
${NONEXISTENT}:${PORTSDIR}/${SAMBA_PORT}:configure
/usr/ports/net/samba-smbclient/Makefile:16:SAMBA_PORT= samba36
/usr/ports/net/samba-smbclient/Makefile:21:MASTERDIR=
${.CURDIR}/../${SAMBA_PORT}
/usr/ports/net/samba4-devel/Makefile:7:PORTNAME?=
${SAMBA_PORTNAME}
/usr/ports/net/samba4-devel/Makefile:23:SAMBA_PORTNAME= samba4
/usr/ports/net/samba4-devel/Makefile:25:SAMBA_DISTNAME=
${SAMBA_PORTNAME:S|4$||}-${SAMBA_VERSION:S|.p|pre|:S|.r|rc|:S|.t|tp|:S|.a|alpha|}
/usr/ports/net/samba4-devel/Makefile:26:OPTIONSFILE=
${PORT_DBDIR}/${SAMBA_PORTNAME}/options
/usr/ports/net/samba4-devel/Makefile:187:USE_RC_SUBR=
${SAMBA_PORTNAME}
Thanks
--
- (2^(N-1)) JJH48-ARIN
pgpyZdbgJOsiL.pgp
Description: PGP signature
Re: libreoffice fails to build
On Wed, Jul 18, 2012 at 11:39 PM, Chris Rees utis...@gmail.com wrote: On 19 Jul 2012 01:09, Robert Huff roberth...@rcn.com wrote: Doug Barton writes: On a system running: FreeBSD 10.0-CURRENT #0: Wed Jul 18 08:15:22 EDT 2012 amd64 and system clang (3.1), libreoffice 3.5.5 Built cleanly for me last night on r238444. Are you sure your world is current enough to get the latest clang fixes? System and ports were updated (by csup) at 00:01 US Eastern time today. Recent enough? I don't wish to patronise, but you did also make world too, right? clang (3.1). I think the CLANG in stable as of yesterday is 3.2. So, no, I don't think you are patronizing. I do wish a note had been made in ports/UPDATING that 3.5.5 requires either the latest clang port or a world built yesterday. Actually, the commit to stable was almost exactly two days ago, but with mirror propagation and time zones, I think yesterday is the right answer. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [FYI] C++ compilers vs. __cplusplus (was Re: SV: Re: make failed for editors/libreoffice)
On 2012-07-19 09:21:30 -0400, Dimitry Andric wrote: On 2012-07-19 01:34, Jung-uk Kim wrote: While I was tackling LibreOffice build issues, I found something interesting about __cplusplus. Basically, different C++ compilers may have different __cplusplus definitions and it may cause some strangeness. Clang, for example, used to set it to 1 but now it is set to C++ standard value since this commit: http://llvm.org/viewvc/llvm-project?view=revrevision=156113 Yes, this is because gcc started doing the same. Otherwise it becomes rather difficult to distinguish C++98, C++0x and C++11 in your C++ library implementation (in the GNU case, libstdc++ most likely). Since when Clang started mimicking GCC 4.7? % /usr/local/bin/clang++ -E -x c++ -dM /dev/null | grep __GNUC #define __GNUC_GNU_INLINE__ 1 #define __GNUC_MINOR__ 2 #define __GNUC_PATCHLEVEL__ 1 #define __GNUC__ 4 ;-) This causes very subtle issues depending on compiler versions and FreeBSD versions. For example, NULL may be defined differently because stable/9 and head have this: #if __cplusplus = 201103L #define NULLnullptr #elif defined(__GNUG__) defined(__GNUC__) __GNUC__ = 4 #define NULL__null #else #if defined(__LP64__) #define NULL(0L) #else #define NULL0 #endif /* __LP64__ */ #endif /* __GNUG__ */ Before that, we had this: #if defined(__GNUG__) defined(__GNUC__) __GNUC__ = 4 #define NULL__null #else #if defined(__LP64__) #define NULL (0L) #else #define NULL0 #endif/* __LP64__ */ #endif /* __GNUG__ */ What a mess... Well, this is what you get when standards progress to include non-standard features (such as gcc's __null) that are already in use, but then subtly change them (calling them nullptr). Yes, it is subtle but it can cause a real trouble because NULL can have different types depending on compiler versions and FreeBSD releases. % cat test.cc #include cstddef char *test = reinterpret_castchar *(NULL); % clang++ -c test.cc % clang++ -c -std=gnu++98 test.cc % clang++ -c -std=gnu++0x test.cc % clang++ -c -std=c++98 test.cc % clang++ -c -std=c++0x test.cc test.cc:2:14: error: reinterpret_cast from 'nullptr_t' to 'char *' is not allowed char *test = reinterpret_castchar *(NULL); ^~ 1 error generated. % /usr/local/bin/clang++ -c test.cc % /usr/local/bin/clang++ -c -std=gnu++98 test.cc % /usr/local/bin/clang++ -c -std=gnu++0x test.cc test.cc:2:14: error: reinterpret_cast from 'nullptr_t' to 'char *' is not allowed char *test = reinterpret_castchar *(NULL); ^~ 1 error generated. % /usr/local/bin/clang++ -c -std=c++98 test.cc % /usr/local/bin/clang++ -c -std=c++0x test.cc test.cc:2:14: error: reinterpret_cast from 'nullptr_t' to 'char *' is not allowed char *test = reinterpret_castchar *(NULL); ^~ 1 error generated. When NULL is __null or an integral type, clang does not complain, of course. However, as long as you can hide the #ifdef ugliness in a header, I don't really see the problem. This won't be the last ugly definition either. :) I just wanted to let ports maintainers know about the caveat using different C++ compilers on different FreeBSD releases. Jung-uk Kim ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: libreoffice fails to build
On 2012-07-18 17:46, Robert Huff wrote: ... FreeBSD 10.0-CURRENT #0: Wed Jul 18 08:15:22 EDT 2012 amd64 and system clang (3.1), libreoffice 3.5.5 gets stuck at: ... Making:libuno_sal.so.3 : ERROR: /usr/lib/libstdc++.so.6: version GLIBCXX_3.4.15 required by ../unxfbsd.pro/lib/check_libuno_sal.so.3 not found dmake: Error code 1, while making '../unxfbsd.pro/lib/libuno_sal.so.3' It seems check_libuno_sal.so.3 is linked to a newer version of libstdc++ than the one in /usr/lib. Do you by any chance have one of lang/gcc46, lang/gcc47 or lang/gcc48 installed? If that is the case, something in LibreOffice's build script is picking up the wrong one. Please look carefully at the generated Makefiles. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: libreoffice fails to build
Kevin Oberman writes: I do wish a note had been made in ports/UPDATING that 3.5.5 requires either the latest clang port or a world built yesterday. Actually, the commit to stable was almost exactly two days ago, but with mirror propagation and time zones, I think yesterday is the right answer. Let me be clear: There is at least one person out there who has successfully built LibreOffice 3.5.5 using (system) clang 3.2? Robert Huff ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [FYI] C++ compilers vs. __cplusplus (was Re: SV: Re: make failed for editors/libreoffice)
On 2012-07-19 20:07, Jung-uk Kim wrote: On 2012-07-19 09:21:30 -0400, Dimitry Andric wrote: ... Since when Clang started mimicking GCC 4.7? Most likely since somebody attempted to get the latest GNU libstdc++ building with clang, and bumped into precisely this issue: if __cplusplus has the simple value 1, you can't get libstdc++'s C++0x or C++11 support enabled. % /usr/local/bin/clang++ -E -x c++ -dM /dev/null | grep __GNUC #define __GNUC_GNU_INLINE__ 1 #define __GNUC_MINOR__ 2 #define __GNUC_PATCHLEVEL__ 1 #define __GNUC__ 4 Yeah, that's probably the last gcc version clang is going to lie about, especially since version checking is very fragile. By the way, feature checks are implemented in clang using the __has_feature macro, which is much easier to use than comparing versions: http://clang.llvm.org/docs/LanguageExtensions.html#feature_check ... Well, this is what you get when standards progress to include non-standard features (such as gcc's __null) that are already in use, but then subtly change them (calling them nullptr). Yes, it is subtle but it can cause a real trouble because NULL can have different types depending on compiler versions and FreeBSD releases. % cat test.cc #include cstddef char *test = reinterpret_castchar *(NULL); % clang++ -c test.cc % clang++ -c -std=gnu++98 test.cc % clang++ -c -std=gnu++0x test.cc % clang++ -c -std=c++98 test.cc % clang++ -c -std=c++0x test.cc test.cc:2:14: error: reinterpret_cast from 'nullptr_t' to 'char *' is not allowed char *test = reinterpret_castchar *(NULL); ^~ There is no need for casting at all here. 'nullptr' can implicitly be converted to any pointer type. If you really want to perform the cast, even when it is unnecessary, use static_cast, or a C-style cast. You only need to use reinterpret_cast here, if you want to convert 'nullptr' to any non-pointer type, such as int. Btw, does anybody know *why* the LibreOffice port attempts to compile everything as C++0x or C++11? Is it really using those features? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: port DNS/UNBOUND
Hi Alexy, Can you submit a PR with an appropriate patch? Thanks! ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: libreoffice fails to build
On 2012-07-19 21:06, Robert Huff wrote: ... Let me be clear: There is at least one person out there who has successfully built LibreOffice 3.5.5 using (system) clang 3.2? The version of clang in base is 3.1. I have successfully compiled LibreOffice with it, and it even seemed to run OK, though I didn't test it very thoroughly. There were several other posters which confirmed the same. Apparently in r301038, jkim updated the libreoffice port to use the lang/clang-devel port instead, which is built from a very recent 3.2 snapshot. I have no idea if LO compiles successfully with that. Maybe you found a problem with the clang-devel port. :) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: libreoffice fails to build
On 07/19/2012 12:17, Dimitry Andric wrote: On 2012-07-19 21:06, Robert Huff wrote: ... Let me be clear: There is at least one person out there who has successfully built LibreOffice 3.5.5 using (system) clang 3.2? The version of clang in base is 3.1. I have successfully compiled LibreOffice with it, and it even seemed to run OK, though I didn't test it very thoroughly. There were several other posters which confirmed the same. ... including me. Apparently in r301038, jkim updated the libreoffice port to use the lang/clang-devel port instead, which is built from a very recent 3.2 snapshot. I have no idea if LO compiles successfully with that. Maybe you found a problem with the clang-devel port. :) I'm currently building on 8-stable with clang-devel, so we'll see how that goes. ... and while we're on that topic, IMO it would have been a *lot* better for jkim to have coordinated with brooks to get lang/clang updated to the same level as clang in HEAD (i.e., including the fix for the bug that affects LO) prior to releasing the update for 3.5.5. As it stands right now, this is the sequence for a user on 8-stable: 1. install lang/clang (+ llvm, in all clang steps below) 2. build/install LO 3.5.2 3. uninstall lang/clang 4. install lang/clang-devel 5. build/install LO 3.5.5 ... then assuming lang/clang is fixed down the road ... 6. uninstall lang/clang-devel 7. install lang/clang 8. build/install LO 3.5.N This is exactly the kind of thing that makes people look at the way the ports tree is managed and shake their head in disbelief. Even if lang/clang needed to be upgraded at every new LO release (as it would have this time) tools like portmaster can handle that upgrade in line without any intervention from the user. The procedure above requires at least 2 manual steps that cannot be automated. Doug -- Change is hard. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [FYI] C++ compilers vs. __cplusplus (was Re: SV: Re: make failed for editors/libreoffice)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-07-19 15:09:08 -0400, Dimitry Andric wrote: On 2012-07-19 20:07, Jung-uk Kim wrote: On 2012-07-19 09:21:30 -0400, Dimitry Andric wrote: ... Since when Clang started mimicking GCC 4.7? Most likely since somebody attempted to get the latest GNU libstdc++ building with clang, and bumped into precisely this issue: if __cplusplus has the simple value 1, you can't get libstdc++'s C++0x or C++11 support enabled. % /usr/local/bin/clang++ -E -x c++ -dM /dev/null | grep __GNUC #define __GNUC_GNU_INLINE__ 1 #define __GNUC_MINOR__ 2 #define __GNUC_PATCHLEVEL__ 1 #define __GNUC__ 4 Yeah, that's probably the last gcc version clang is going to lie about, especially since version checking is very fragile. By the way, feature checks are implemented in clang using the __has_feature macro, which is much easier to use than comparing versions: http://clang.llvm.org/docs/LanguageExtensions.html#feature_check Yes, I know. Actually, the real problem is LibreOffice treats Clang as GCC variant and configure script thinks it is gcc 4.2.1:-( configure:7361: checking the GNU C compiler version configure:7385: result: checked (gcc 4.2.1) ... Well, this is what you get when standards progress to include non-standard features (such as gcc's __null) that are already in use, but then subtly change them (calling them nullptr). Yes, it is subtle but it can cause a real trouble because NULL can have different types depending on compiler versions and FreeBSD releases. % cat test.cc #include cstddef char *test = reinterpret_castchar *(NULL); % clang++ -c test.cc % clang++ -c -std=gnu++98 test.cc % clang++ -c -std=gnu++0x test.cc % clang++ -c -std=c++98 test.cc % clang++ -c -std=c++0x test.cc test.cc:2:14: error: reinterpret_cast from 'nullptr_t' to 'char *' is not allowed char *test = reinterpret_castchar *(NULL); ^~ There is no need for casting at all here. 'nullptr' can implicitly be converted to any pointer type. If you really want to perform the cast, even when it is unnecessary, use static_cast, or a C-style cast. You only need to use reinterpret_cast here, if you want to convert 'nullptr' to any non-pointer type, such as int. Feel free to file a LibreOffice PR. ;-) https://www.libreoffice.org/get-help/bug/ Seriously, it is not really easy to correct all upstream bugs, especially huge monsters such as LibreOffice OpenOffice. :-( Btw, does anybody know *why* the LibreOffice port attempts to compile everything as C++0x or C++11? Is it really using those features? It is using some of its features, I guess: ifeq ($(HAVE_CXX0X),TRUE) #Currently, as well as for its own merits, c++11/c++0x mode allows use to use #a template for SAL_N_ELEMENTS to detect at compiler time its misuse gb_CXXFLAGS += -std=c++0x ... I don't know the impact of turning it off, however. Some time ago, I tried to forcefully turning it off but I wasn't able to make it work on all releases at the time. Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAIYdYACgkQmlay1b9qnVP5wQCgrPWXsR5XwPHw2+4hXUdrt80r vS8AnRRHfIHWivxEfOnl11BnBIUFN98J =VdAg -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: libreoffice fails to build
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-07-19 15:32:56 -0400, Doug Barton wrote: On 07/19/2012 12:17, Dimitry Andric wrote: On 2012-07-19 21:06, Robert Huff wrote: ... Let me be clear: There is at least one person out there who has successfully built LibreOffice 3.5.5 using (system) clang 3.2? The version of clang in base is 3.1. I have successfully compiled LibreOffice with it, and it even seemed to run OK, though I didn't test it very thoroughly. There were several other posters which confirmed the same. ... including me. Apparently in r301038, jkim updated the libreoffice port to use the lang/clang-devel port instead, which is built from a very recent 3.2 snapshot. I have no idea if LO compiles successfully with that. Maybe you found a problem with the clang-devel port. :) I'm currently building on 8-stable with clang-devel, so we'll see how that goes. Please don't bother. I *know* it is broken there. ... and while we're on that topic, IMO it would have been a *lot* better for jkim to have coordinated with brooks to get lang/clang updated to the same level as clang in HEAD (i.e., including the fix for the bug that affects LO) prior to releasing the update for 3.5.5. As it stands right now, this is the sequence for a user on 8-stable: 1. install lang/clang (+ llvm, in all clang steps below) 2. build/install LO 3.5.2 3. uninstall lang/clang 4. install lang/clang-devel 5. build/install LO 3.5.5 ... then assuming lang/clang is fixed down the road ... 6. uninstall lang/clang-devel 7. install lang/clang 8. build/install LO 3.5.N This is exactly the kind of thing that makes people look at the way the ports tree is managed and shake their head in disbelief. Even if lang/clang needed to be upgraded at every new LO release (as it would have this time) tools like portmaster can handle that upgrade in line without any intervention from the user. The procedure above requires at least 2 manual steps that cannot be automated. I admit that it was my mistake and assumed clang-devel would be good enough for LibreOffice on 7 8. Sorry for that. Working on fixing it. Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAIZG0ACgkQmlay1b9qnVOzSQCcDvPkR6W5ODT0zKdSr+QwJd20 IVgAoM5vSR//zN3LIWC0+RsHdkdGF1QI =AogE -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: libreoffice fails to build
On 07/19/2012 12:47, Jung-uk Kim wrote: On 2012-07-19 15:32:56 -0400, Doug Barton wrote: On 07/19/2012 12:17, Dimitry Andric wrote: On 2012-07-19 21:06, Robert Huff wrote: ... Let me be clear: There is at least one person out there who has successfully built LibreOffice 3.5.5 using (system) clang 3.2? The version of clang in base is 3.1. I have successfully compiled LibreOffice with it, and it even seemed to run OK, though I didn't test it very thoroughly. There were several other posters which confirmed the same. ... including me. Apparently in r301038, jkim updated the libreoffice port to use the lang/clang-devel port instead, which is built from a very recent 3.2 snapshot. I have no idea if LO compiles successfully with that. Maybe you found a problem with the clang-devel port. :) I'm currently building on 8-stable with clang-devel, so we'll see how that goes. Please don't bother. I *know* it is broken there. Well I don't mind letting the disks spin in the background. :) It did finish building, and the resulting binaries start up, but after opening some documents they crashed. It seems that the presentation module is the culprit. So far the write module seems stable. I can open new documents with all of the modules, it was loading a presentation and trying to get it into slide show mode that caused the crash. I also got this on the command line in case it helps. libreoffice javaPathHelper: not found This is on 8-stable i386, r238128 FWIW. The OPTIONS I have enabled: GTK2=on: GTK2 gui toolkit support JAVA=on: Add java support (XML Filters, macros) SVG=on: SVG image support WEBDAV=on: Enable webdav protocol The version built on HEAD, amd64, with the base clang seems to be more stable, but I admit I haven't thoroughly tested it. From what I can tell there is a test suite that comes with LO, does this get run prior to publishing updates to the port? It would probably be a good step to add if not. Even if lang/clang needed to be upgraded at every new LO release (as it would have this time) tools like portmaster can handle that upgrade in line without any intervention from the user. The procedure above requires at least 2 manual steps that cannot be automated. I admit that it was my mistake and assumed clang-devel would be good enough for LibreOffice on 7 8. Sorry for that. Working on fixing it. I'll repeat here what I said in private e-mail ... I genuinely appreciate the hard work that you folks are doing on this. An office suite is an essential component of a robust desktop solution, so this is critical work, and I'm glad that some very smart people are working on it. :) To the extent that any mistakes have been made, we simply need to learn from them and move on. My intent is not to cast aspersions on anyone's character or abilities, nor should my mail be read that way. If we're not continuously analyzing and improving our processes we will certainly grow stale and die, and I don't want to see that happen. So again, thank you for working on this, and I hope that this report is helpful. Doug -- Change is hard. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: maintainer timeout for FreeBSD commiters
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 18.07.2012 08:37, schrieb Lars Engels: On Tue, Jul 17, 2012 at 05:43:02PM -0500, Mark Linimon wrote: On Wed, Jul 18, 2012 at 12:09:50AM +0200, John Marino wrote: Would it be so bad if all my submitted patches (as a recognized quality contributor with history) just got committed as a passthrough? This has been explored on the mailing lists before, however, we don't technically have a way to do either of the following: - let people commit to just some ports Shouldn't this work with subversion? The problem isn't purely technical. The technical component is easily solved, but there are social and trust issues, and I'm not so sure if there is a middle layer. I think the underlying proposal might expedite the maintenance of a few individual ports in borderline cases, but this middle layer of contributors between submitters and committers is close enough to the committers so that I personally would see it as a needless additional abstraction that just complicates matters for little gain. And then there are issues that aren't bit-sized, but larger, hence they end up in abandoned or formally suspended PRs that contribute to the backlog. Expediting throughput of a few ports isn't going to help those at all, but they form the backlog... -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlAIhFQACgkQvmGDOQUufZWmHwCfapbIdd0kpa6GZ7xnxV+f8gHj 9u4AnjEZV/yExbJILhnro3z8V0xnFPY0 =d29M -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: port DNS/UNBOUND
Hi,
You can use .if empty(PORT_OPTIONS:Mfoo) to check if option foo is
off. Try this:
.if empty(PORT_OPTIONS:MTHREADS)
CONFIGURE_ARGS+=--without-pthreads
.endif
Regards,
sunpoet
On Thu, Jul 19, 2012 at 10:46 PM, Alexey Kouznetsov
ale...@kouznetsov.com wrote:
Hello!
After port was moved to new NGoptions this is inpossible to compile port
with threads enabled. make always adds --without-pthreads undepended on
setings in make config
At Makefile we have
.if empty(${PORT_OPTIONS:MTHREADS})
CONFIGURE_ARGS+=--without-pthreads
.endif
and resulted configure with THREADS enabled from config.log:
$ ./configure --with-ssl=/usr --disable-gost --disable-ecdsa
--with-libevent=/usr/local --without-pthreads --prefix=/usr/local
I changed this to
.if !${PORT_OPTIONS:MTHREADS}
CONFIGURE_ARGS+=--without-pthreads
.endif
and as result I have not --without-pthreads in configure parameters anymore
and unbound started as multithread program
Could you, please, change the port ?
Thank you
/Alexey
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
--
Sunpoet Po-Chuan Hsieh sunpoet at sunpoet.net sunpoet at FreeBSD.org
4096R/CC57E36B 8AD8 68F2 7D2B 0A10 7E9B 8CC0 DC44 247E CC57 E36B
http://people.FreeBSD.org/~sunpoet/pgpkeys.txt
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
