synth always rebuilds devel/libc++ because it fails dependency check. According to synth's author something is wrong with the port: https://forums.freebsd.org/threads/54690/page-25#post-312097 make -V BUILD_DEPENDS clang-devel: not found make: "/usr/ports/Mk/Uses/compiler.mk" line 69: warning: "clang-devel --version" returned non-zero status make: "/usr/ports/Mk/Uses/compiler.mk" line 120: warning: "clang++-devel -### /dev/null 2>&1" returned non-zero status llvm-config-devel:/usr/ports/devel/llvm-devel /usr/local/bin/cmake:/usr/ports/devel/cmake ninja:/usr/ports/devel/ninja
Over to maintainer.
Eh, which version of FreeBSD is this? And why is the port attempting to build with clang-devel? Did you set CC? Please provide more information.
My system: $ uname -a FreeBSD bclinton 10.3-PRERELEASE FreeBSD 10.3-PRERELEASE #0 r296434: Sun Mar 6 12:37:08 PST 2016 toor@bclinton:/usr/obj/usr/src/sys/GENERIC amd64 Compiler: default, no CC is set. Port reports this dependency: make -V BUILD_DEPENDS /usr/local/bin/cmake:/usr/ports/devel/cmake while pkg doesn't list any dependencies: # pkg info libc++ libc++-208080 Name : libc++ Version : 208080 Installed on : Sun Mar 6 20:28:30 2016 PST Origin : devel/libc++ Architecture : freebsd:10:x86:64 Prefix : /usr/local Categories : devel Licenses : Maintainer : dim@FreeBSD.org WWW : http://libcxx.llvm.org/ Comment : LLVM C++ standard library with c++11 support Shared Libs provided: libc++.so.1 Annotations : repo_type : binary repository : FreeBSD Flat size : 7.58MiB Description : libc++ is a new implementation of the C++ standard library made by the llvm project targeting C++11. WWW: http://libcxx.llvm.org/ I think this is what trips synth.
Why on earth is your ports tree trying to use the devel/libc++ port, when you are on FreeBSD 10.3-PRELEASE? This release has libc++ in the base system, and the port should use that instead...
Dear Dimitry, I must confess I have no idea why synth is complaining about libc++. I didn't install libc++ port or anything like that. I just tried to relay thoughts from John Marino, the author of synth, on this problem. Maybe you could contact each other directly to sort it out? Meanwhile I'll supply your answer (if you don't mind) in FreeBSD forums where people are discussing synth and John is actively involved.
Here is reply from kpa: Some ports depend on newer libc++ than is available on the base system, same thing as with clang/llvm where the base system ones are not enough. The whole thread is here: https://forums.freebsd.org/threads/55359/page-2#post-314074 Hope this helps.
Dimitry, the last time we spoke about this, I said I would try to fix the port. I never got around to it, but I'll work on this today. With a quick glance I think I see the problem. I need to test it on freebsd though (which is mainly why I didn't get to it; I've been in DF the whole time)
(In reply to Andrew from comment #6) > Here is reply from kpa: > > Some ports depend on newer libc++ than is available on the base system, same > thing as with clang/llvm where the base system ones are not enough. Ehm, the libc++ port is *older* than the libc++ in the base system. So this is an incorrect line of reasoning? > The whole thread is here: > > https://forums.freebsd.org/threads/55359/page-2#post-314074 > > Hope this helps. I just tried building the synth port on FreeBSD 10, and it works out of the box for me... It doesn't depend on libc++ at all, but pulls in gcc6-aux to get an ADA compiler. Oh and ncurses, apparently. But not much more.
A commit references this bug: Author: marino Date: Tue Mar 8 12:48:51 UTC 2016 New revision: 410612 URL: https://svnweb.freebsd.org/changeset/ports/410612 Log: devel/libc++: specific libcxxrt LIB_DEPENDS conditionally The libcxxrt was unconditionally specified, but pkg(8) would not register it on FreeBSD 10+ because the libcxxrt.so requirement of the specification was satisfied by the base libraries. As a result, Synth would rebuild the libc++ each time becaues there were more dependency requirements in the port Makefile than the resulting package, leading Synth to consider the package obsolete. Since there are already existence tests for setting flags, the solution is trivial: move LIB_DEPENDS definition inside the conditional blocks. The resulting package is the same everywhere, and Synth is happy too. PR: 207756 Submitted by: Andrew Terekhov Discussed with: dim@, bapt@ (no conclusion, I fixed it myself) Changes: head/devel/libc++/Makefile
(In reply to Dimitry Andric from comment #8) > I just tried building the synth port on FreeBSD 10, and it works out of the box > for me... It doesn't depend on libc++ at all, but pulls in gcc6-aux to get an > ADA compiler. Oh and ncurses, apparently. But not much more. Dimitry, From your responses, I got the idea you never understood what the problem actually was. I just committed a fix. I test it with synth, poudriere (freebsd 9 jail) and poudriere (FreeBSD 10 jail). It's working as expected now and you can see the changes were minimal. I think you can close the PR; the issue is resolved.
(In reply to John Marino from comment #10) > (In reply to Dimitry Andric from comment #8) > > I just tried building the synth port on FreeBSD 10, and it works out of the box > > for me... It doesn't depend on libc++ at all, but pulls in gcc6-aux to get an > > ADA compiler. Oh and ncurses, apparently. But not much more. > > Dimitry, > From your responses, I got the idea you never understood what the problem > actually was. I just committed a fix. I'm happy that it is fixed, but I still don't understand why this bug was about libc++ being pulled in by synth, on FreeBSD 10. It isn't, at least not on the FreeBSD 10 instance I tested on. Now that I see your change to the libc++ port, I think I do understand what the problem was, e.g. it unconditionally did a LIB_DEPENDS, while the existince of /usr/lib/libcxxrt.so wasn't even tested yet.
it was pulled in by something, but that doesn't even matter. You can build and install it as a standalone port if you wish, and the same problem would exist. I know you've been thinking it would never be a dependency, but it has been for multiple people so I think that idea isn't correct. Something must be using it unconditionally. What went on is that if you make -V LIB_DEPENDS, you'd seee cxxrt as a dependency, always, regardless of platform. However, internally the dependency wouldn't be registered because the requirement was satistfied. Some people might say that's how it should work, and that there was no problem. I'd rather that the LIB_DEPENDS and RUN_DEPENDS get pushed 1:1 into the package so they can be directly compared.