Ports and WITH_LIBCPLUSPLUS

[Dimitry Andric]

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.