Created attachment 151389 [details] FreeBSD-specific diff against libc++ trunk r224926 Since I intend to update libc++ in base to trunk r224926, it would seem nice to also update the libc++ port this same version. The diff I'm currently using against trunk r224926 is attached. If you like I can also look at completely updating the port itself, but I guess bapt will know what to do. :)
bapt gave back the port to ports@, so if you can provide a full patch, that would be helpful.
Currently, the full tarball is hosted at http://files.etoilebsd.net/libc++/, according to the Makefile. Is there anywhere in the FreeBSD network where we can host our own tarball, maybe?
There was a recent flurry of commits from ehaupt where he changed MASTER_SITES to LOCAL/ehaupt. See https://lists.freebsd.org/pipermail/svn-ports-all/2015-January/082463.html and follow-ups. portmgr allowed him to selfhost on freefall. And I found quite a few at freefall:~ehaupt/public_distfiles/. So you can probably do the same ?
It was clusteradm@, not portmgr@. Ups.
Created attachment 151641 [details] Update devel/libc++ port to upstream trunk r224926 Okay, here is an update of the port to use upstream trunk r224926. Other changes: * Set first master site to my own server, second site LOCAL/dim * Update files/extra-libmissing to apply to this new revision * Apply FreeBSD-specific patches which are also in head * Cleanup and sort pkg-plist Please note that I did upload the tarball (libc++-224926.tar.xz) to ~dim/public_distfiles on freefall, but I cannot seem to download it through the ports framework (yet?): => Attempting to fetch http://distcache.FreeBSD.org/local-distfiles/dim/libc++-224926.tar.xz fetch: http://distcache.FreeBSD.org/local-distfiles/dim/libc++-224926.tar.xz: Not Found => Attempting to fetch http://distcache.us-east.FreeBSD.org/local-distfiles/dim/libc++-224926.tar.xz fetch: http://distcache.us-east.FreeBSD.org/local-distfiles/dim/libc++-224926.tar.xz: Not Found => Attempting to fetch http://distcache.eu.FreeBSD.org/local-distfiles/dim/libc++-224926.tar.xz fetch: http://distcache.eu.FreeBSD.org/local-distfiles/dim/libc++-224926.tar.xz: Not Found => Attempting to fetch http://distcache.us-west.FreeBSD.org/local-distfiles/dim/libc++-224926.tar.xz fetch: http://distcache.us-west.FreeBSD.org/local-distfiles/dim/libc++-224926.tar.xz: Not Found => Attempting to fetch http://distcache.FreeBSD.org/ports-distfiles/libc++-224926.tar.xz fetch: http://distcache.FreeBSD.org/ports-distfiles/libc++-224926.tar.xz: Not Found => Couldn't fetch it - please try to retrieve this Do I need to tell clusteradm@ to sync this file, or will it happen automatically at some point?
The distfile is now available on the distcache servers.
(In reply to Dimitry Andric from comment #5) clusteradm@ pointed me to https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/book.htm l#slow-sources which says: If a convenient and reliable place to put the distfile cannot be found, we can “house” it ourselves on ftp.FreeBSD.org; however, this is the least-preferred solution. The distfile must be placed into ~/public_distfiles/ of someone's freefall account. Ask the person who commits the port to do this. This person will also set MASTER_SITES to MASTER_SITE_LOCAL and MASTER_SITE_SUBDIR to their freefall username.
(In reply to Kurt Jaeger from comment #7) Yes, I've set my own website as the first in the MASTER_SITES list, and the public distfiles location as the second. For now, this will probably be good enough. Unfortunately llvm.org does not have a mechanism to download a tarball or zipfile from a specific Subversion path and revision, otherwise I would have preferred that as the first master site, obviously.
poudriere builds went fine, see http://people.freebsd.org/~pi/logs/devel__libc++-10x-1421440571.txt http://people.freebsd.org/~pi/logs/devel__libc++-93a-1421440571.txt http://people.freebsd.org/~pi/logs/devel__libc++-84i-1421440571.txt The port is a BUILD_DEPEND for only three ports: graphics/rawtherapee math/parmetis multimedia/aegisub but it's also mentioned in Mk/Uses/compiler.mk. So maybe an exp-run is needed before it can be committed ?
Less than 15 ports depend on it, I think you can test it yourself without requesting on exp-run
Now that both head, stable/10 and stable/9 have the latest libc++ merged, I think this port should also be updated. I've done a few limited tests on the port myself, but I haven't rebuilt all c++11-libs ports with lang/gcc. Do we really need to do that?
I'm testing this
A commit references this bug: Author: bdrewery Date: Tue Apr 7 17:52:36 UTC 2015 New revision: 383525 URL: https://svnweb.freebsd.org/changeset/ports/383525 Log: Dim has an update in testing. PR: 196536 Changes: head/devel/libc++/Makefile
(In reply to Dimitry Andric from comment #11) This update never happened (yet) and it has been well over 1.5 years (about 18 months) since the proposed patch attachment. https://svnweb.freebsd.org/base/stable/10/contrib/libc%2B%2B/ shows the most recent change as: MFC r280864: Pull in r233552 from upstream libc++ trunk (by Eric Fiselier): … https://svnweb.freebsd.org/base/stable/9/contrib/libc%2B%2B/ agrees. So it would seem that r224926 is no longer likely to be the desired target if the devel/libc++ port is updated. But, with more vintages now of devel/llvm* (llvm39 exists and llvm-devel is tied to 4.0) and lang/clang* as well as lang/gcc* to potentially mix and match with this port and C++14 and C++17(?) standards now existing, does having and updating just one devel/libc++ cover things well? Should the name of this port be changed do to something to indicate what vintage of C++'s library that it targets or otherwise delimit what it is expected to span (such as clang or gcc compiler vintages)? Should the pkg-descr be more explicit about eliminating some combinations? FreeBSD 9.3-RELEASE expected EOL is 2016-Dec-31 according to https://www.freebsd.org/security/ . As this port was for 9.x because of its lack of a system libc++ will this potential update expire with the 9.3 EOL when it happens? (As it is not mentioned in pkg-descr I'm not sure how much this port was meant to cover TARGET_ARCH's for which gcc 4.2.1 and its library continues to be the system compiler/library combination on 10.x, 11.x, and 12.x [so far], such as various tier 2 architectures.) Should this port effectively freeze and only be fixed when some port that depends on it is broken because of a devel/libc++ problem on what is/was a 9.x Tier 1 context? Is it worth the effort to have a known status for, say, the various clang vintages over various TARGET_ARCH's, including documenting lack of more modern library content (some post-C++11 material) when used with more modern clang's that target more modern C++ vintages? (When using more recent versions of lang/clang* the 10.3 and 11.0 system libc++'s can also have the incompleteness type of issue for more modern C++ library content than is associated with the system compiler vintage. Of course some 10.x and 11.x architectures do not have a system libc++. Also true of 12.0-CURRENT as stands.) If truly targeting FreeBSD 9.x only: It would seem that this limited-purpose port may be approaching its own end-time for any sort of active updating and it has survived as-is for some time.
(In reply to Mark Millard from comment #14) ... > So it would seem that r224926 is no longer likely to be the desired target > if the devel/libc++ port is updated. Nope, this patch and port is now very much outdated. > Should the name of this port be changed do to something to indicate what > vintage of C++'s library that it targets or otherwise delimit what it is > expected to span (such as clang or gcc compiler vintages)? Should the > pkg-descr be more explicit about eliminating some combinations? The only purpose of this port was to be able to compile ports which specifically require gcc against libc++, if the base system did not have it already. So basically for FreeBSD <= 9.x. > FreeBSD 9.3-RELEASE expected EOL is 2016-Dec-31 according to > https://www.freebsd.org/security/ . As this port was for 9.x because of its > lack of a system libc++ will this potential update expire with the 9.3 EOL > when it happens? Yes, this is also why it doesn't make sense to update this port anymore. It would in fact be easier to enable building libc++ by default for stable/9, at the cost of having to build clang in addition to gcc during the crosstools stage of buildworld. > (As it is not mentioned in pkg-descr I'm not sure how much this port was > meant to cover TARGET_ARCH's for which gcc 4.2.1 and its library continues > to be the system compiler/library combination on 10.x, 11.x, and 12.x [so > far], such as various tier 2 architectures.) Those arches can just keep on using libstdc++, like they always did. > (When using more recent versions of lang/clang* the 10.3 and 11.0 system > libc++'s can also have the incompleteness type of issue for more modern C++ > library content than is associated with the system compiler vintage. I'm sorry, but I failed to parse this sentence. Which incompleteness issue are you referring to?
(In reply to Dimitry Andric from comment #15) For the status of this port: Understood. Seems reasonable and the notes make it clear. As for your question about the "incompleteness issue" I was trying to be more generic about the future but may be I can use some actual, current examples from http://libcxx.llvm.org/cxx1z_status.html : (I've assumed that, for example, the 11.0 system libc++ is based on libc++ 3.8 to match clang 3.8.0. I could be wrong.) Example libc++ 4.0 additions that have been completed for C++17 (c++1z): N4387 LWG improving pair and tuple p0084r2 LWG Emplace Return Type p0254r2 LWG Integrating std::string_view and std::string p0295r0 LWG Adopt Selected Library Fundamentals V2 Components for C++17 p0392r0 LWG Adapting string_view by filesystem paths Example libc++ 3.9 additions that have been completed for C++17 (c++1z) : P0156R0 LWG Variadic lock_guard(rev 3) P0033R1 LWG Re-enabling shared_from_this P0005R4 LWG Adopt not_fn from Library Fundamentals 2 for C++17 P0152R1 LWG constexpr atomic::is_always_lock_free P0185R1 LWG Adding [nothrow-]swappable traitsComplete P0253R1 LWG Fixing a design mistake in the searchers interface P0025R0 LWG An algorithm to "clamp" a value between a pair of boundary values P0030R1 LWG Proposal to Introduce a 3-Argument Overload to std::hypot P0272R1 LWG Give std::string a non-const .data() member function P0077R2 LWG is_callable, the missing INVOKE related trait p0163r0 LWG shared_ptr::weak_type p0337r0 LWG Delete operator= for polymorphic_allocator p0346r1 LWG A <random> Nomenclature Tweak p0358r1 LWG Fixes for not_fn (I'm deliberately ignoring Post C++14 Technical Specifications.) (I do not claim to know which ones above might require a post-3.8.0 clang compiler to enable.) Some of this may not be in the system libc++'s (10.3 and/or 11.0). devel/llvm39 has shown up. I assume that lang/clang39 will as well at some point (or that llvm39 is to be used directly to build clang). devel/llvm-devel is based on 4.0 of clang. I assume that lang/clang40 will show up at some point (or that llvm40 is to be used directly to build clang). It is not clear that the 10.3 or 11.0 system libc++ can gain all the above items at the same time that the matching compilers might become available in ports. (12.0 has more options for such things at this stage.) But take these as just examples, where going forward there might be more examples as, say, libc++ 4 progresses.
(In reply to Dimitry Andric from comment #15) Looks like this [Bugzilla 196536 for updating devel/libc++] can be closed (for being overcome by events: it no longer exists). [I can not change the status of 196536 .]