lang/clang-devel install fails when DOCS not set
I got this: gmake[1]: Leaving directory `/home/tmp/frontier/ports-svn/head/lang/clang-devel/work/llvm-3.2.r160283/tools/clang/unittests' rmdir: /usr/local/share/doc/clang/html/img: No such file or directory *** Error code 1 Stop in /frontier/ports-svn/head/lang/clang-devel. *** Error code 1 Stop in /frontier/ports-svn/head/lang/clang-devel. Turning on DOCS makes it work. Also, man pages are not usually considered part of DOCS. -- 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: port DNS/UNBOUND
On 20 July 2012 05:07, Sunpoet Hsieh wrote: > 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 > Quite correct, and I've filed such in a PR. http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/170007 Thanks for noticing Alexey! 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: merge apache22 MPM modules on make config
On 2012-07-16 23:58, Marcello Coutinho wrote:
> Hi,
>
> I was having issues with pbi builds and apache22-worker-mpm(It was always
> looking at apache22 build instead of apache22-worker-mpm)
>
> After unifying all apache22-xx-mpm options on apache22 make config, I could
> compile any MPM option using ports or pbi build.
>
> Is it possible to merge it on ports? How can I send you the changes so you
> can test and check if it's ok.
>
> On my freebsd 8.3 amd64, I can compile all options.
>
> I've attached two patch files.
>
> The only extra step is to copy patch files from
> apache22-peruser-mpm/files/ to apache22/files/
Hi Marcello,
I will look into this over the weekend, but I think we should not
copy the files since this is error prone.
We should place the patches in the apache22/files directory or
use something like SLAVE_PATCHES=${.CURDIR}/../apache22-peruser-mpm/files
in apache22 which points toapache22-peruser-mpm/files.
--
Regards,
olli
___
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
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
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"
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: 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: 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: [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 char *test = >> reinterpret_cast(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_cast(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
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: 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: 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: [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 > char *test = reinterpret_cast(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_cast(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: 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: 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: [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=rev&revision=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 char *test = reinterpret_cast(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_cast(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_cast(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_cast(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 Wed, Jul 18, 2012 at 11:39 PM, Chris Rees wrote: > On 19 Jul 2012 01:09, "Robert Huff" 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"
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
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"
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=rev&revision=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"
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: 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 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"
