Date: Sun, 03 Feb 2013 14:28:26 +0100 From: Dimitry Andric <dim@FreeBSD.org> To: Andreas Nilsson <andrnils@gmail.com>, FreeBSD Stable Mailing List <freebsd-stable@freebsd.org> Subject: Re: Ports and WITH_LIBCPLUSPLUS Message-ID: <510E65FA.4040900@FreeBSD.org> In-Reply-To: <CAPS9%2BSsKqM%2B0Zo71LRxTfUPVOBhUaCTqrXDuHv30e76EH7YWCw@mail.gmail.com> References: <CAPS9%2BSsKqM%2B0Zo71LRxTfUPVOBhUaCTqrXDuHv30e76EH7YWCw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2013-02-03 11:39, Andreas Nilsson wrote: > I wanted to try the new c++ stuff, ie clang-3.2, libc++ and libcxxrt, so I > used poudriere to build a jail setup for that ( WITH_LIBCPLUSPLUS=yes in > src.conf, CXXFLAGS+=-stdlib=libc++ and libsupc++.so.1 libcxxrt.so.1 in > libmap.conf ), and started to build my normal set of packages ( see > desktop.list ). Please note that I also have WITH_NEW_XORG=yes and > WITH_KMS=yes, as well as using the devel xorg repo. > > First Great work for moving FreeBSD towards a more modern c++ world! > > Results: > Some stuff works, some don't ;) Some may be due to clang and not just > libc++. Here is a list of packages that fails: > > audio/libofa > databases/akonadi > devel/binutils > devel/kBuild > devel/libftdi > devel/libplist > devel/qca > devel/qt4-qdbusviewer > devel/qt4-script > emulators/qemu-devel > graphics/cairo > graphics/graphite2 > graphics/libfpx > graphics/opencv-core > graphics/podofo > graphics/vigra > lang/sbcl > math/cln > net-im/libmsn > net-p2p/libtorrent > net/hupnp > net/ns3 > net/xmlrpc-c-devel > science/openbabel > security/pinentry > sysutils/fusefs-kmod > sysutils/synergy > textproc/clucene > x11/nvidia-driver Thanks for trying this out. Is there also a list of ports that *do* compile (and hopefully run) successfully? :-) I expect there will be quite a few ports that are very difficult to get building and running properly with libc++. Some programs rely on undocumented (or half-documented) libstdc++ internals, or on behaviour specific to libstdc++. Also, it would not suprise me if there are programs that even depend on a very specific version of libstdc++, and its accompanying version of gcc. In short, we need some sort of system to specify the general C++ library to use by default (e.g. in make.conf or ports.conf), and for ports that only work with a very specific version, a variable similar to USE_GCC, for example: USE_LIBSTDCXX=4.6+ > where at least ns3 can be ignored ( I created that port myself ). I think > nvidia-driver and fusefs-kmod now fails due to -stdlib=libc++ in LDFLAGS, > normally fusefs-kmod just fails install-phase due to missing pkg-message > file. > > I saved the workdirs for poudriere, and they are available at > http://benriach.widell.net/~andrnils/libc++/ , both as individual tarballs > and one tarball that includes all the others. There is also the lists of > packages I try to build, as well as the ones that fails. > > > One general question: How am I supposed to include -stdlib=libc++ in > LDFLAGS just for c++? Having -stdlib=libc++ in LDFLAGS causes c compiles to > fail linking with "ld: unrecognized option '-stdlib=libc++'" This is as yet an unsolved problem, as LDFLAGS is the same for both C and C++ link jobs. I think the easiest way would be to set your CXX variable to: CXX=cc -stdlib=libc++ The -std=c++11 flag should only have to be specified in CXXFLAGS. I don't think it has any influence on linking.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?510E65FA.4040900>