Ports and WITH_LIBCPLUSPLUS

[Andreas Nilsson]

On Sun, Feb 3, 2013 at 2:28 PM, Dimitry Andric <dim at freebsd.org> wrote:

> 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 didn't save the output for successful packages, but looking through just
the files gives libcpp.built at same URL.

>
> 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+


Sounds good :) Perhaps something like
if (( CLANG_IS_CC || CC==clang ) && WITH_LIBCPLUSPLUS )
CXXFLAGS+=-stdlib=libc++
endif
could be added to correct mk-file

>
>
>
>  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++/<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++
>
Wouldn't CXX=CC -stdlib=libc++ be more appropriate, as cc is for c and CC
for c++, or have that convention gone away?


>
> The -std=c++11 flag should only have to be specified in CXXFLAGS.  I
> don't think it has any influence on linking.
>

My adding them to LDFLAGS comes from
https://wiki.freebsd.org/NewC++Stackwhere it says "Add -stdlib=libc++
to your compile and link flags..." It
actually made a bunch of the qt4- packages build, they wouldn't without it.

I guess a wiki page tracking the failing packages would be good, but I
couldn't get the hang of creating a page there :(

Best regards
Andreas