On Fri, Jul 28, 2017 at 10:20:33AM +0200, Marc Espie wrote:
> On Fri, Jul 28, 2017 at 06:50:35AM +0200, Sebastien Marie wrote:
> > Hi,
> > 
> > I would like to understand the rationale about the addition of
> > COMPILER_LIBCXX in WANTLIB on lang/rust.
> > 
> > lang/rust is compiled using ports gcc4.9. The c++ library used is
> > libestdc++. And the use of devel/llvm is due linkage with LLVM libraries
> > (base isn't suitable for that: we don't have libLLVM*.so but only
> > clang/clang++).
> > 
> > Previously, the WANTLIB for main was:
> > 
> > rust-1.18.0$ make show=WANTLIB-main
> > estdc++>=17 c m pthread z
> > 
> > 
> > Now, the WANTLIB-main has c++ and c++abi added, and estdc++ is missing:
> 
> Yes, that's definitely not matching what rust does.
> 
> Sthen, you probably want to revert that one, rust *does* want gcc4 from
> ports currently.
> 
> (the fact it's still using MODULES = gcc4 directly is a tell-tale)
> 
> Semarie, on the other hand, on a clang-based architecture, rust is now
> very much on its own. libstdc++ is wildy incompatible with libc++, which
> basically means that you can build rust programs, but you can't link with
> other C++ based software, and vice-versa.

the current dependence to gcc4 is due to devel/llvm (where I think the
WANTLIB changes is wrong too, even if estdc++ isn't missing: the port
still have gcc4 in MODULES).

$ cd /usr/ports/devel/llvm
$ make show=MODULES
devel/cmake  lang/python  gcc4
$ make show=WANTLIB
c++ c++abi pthread c m pthread z estdc++>=17
$ make port-lib-depends-check
Use of each() on hash after insertion without resetting hash iterator results 
in undefined behavior at 
/home/semarie/repos/openbsd/ports/infrastructure/bin/check-lib-depends line 445.

llvm-4.0.1p0(devel/llvm,-main):
Extra:  c++.0 c++abi.0

py-llvm-4.0.1(devel/llvm,-python):
Extra:  clang.5


rustc uses LLVM libraries. The LLVM libraries are using libestdc++, so
rustc *must* use libestdc++.

if devel/llvm switches to use clang, a minimal change is require to
lang/rust to use it (and use libc++ too). it is the direction that we
should take (but please let rust-1.19.0 be pushed in tree before).

thanks.
-- 
Sebastien Marie

Reply via email to