[gentoo-musl] [GSoC] native-clang: daily report 07/01

[gentoo-musl] [GSoC] native-clang: daily report 07/01

[Lei Zhang]

Plan for today:
- write ebuild for NetBSD's crtbegin/end
- write ebuild for libc++abi

Progress:
- write ebuild for crtbegin/end

libc++abi's situation is a bit complicated. To configure it, you need
the specify paths to libc++ and LLVM's source. libc++ has a similar
issue: it also needs to know the path to LLVM's source. Actually
libc++'s ebuild maintainer wrote a Makefile to circumvent its cmake
system, which works without knowing LLVM's source path. I guess libc++
doesn't really need LLVM's source; it's just some quirk of their cmake
system.

But I can't tell yet if libc++abi really needs libc++ or LLVM's
source. If not, perhaps I can write a Makefile just like libc++'s;
otherwise, maybe I need to keep LLVM's source somewhere after
installing it.

Although libc++, libc++abi, etc support out-of-tree build, it looks to
me they're not decoupled from LLVM enough as they're supposed to be.
Sigh...


Lei

[gentoo-musl] Re: [GSoC] native-clang: daily report 07/01

[Lei Zhang]

2016-07-01 23:42 GMT+08:00 Lei Zhang <zhanglei.april@gmail.com>:
> Plan for today:
> - write ebuild for NetBSD's crtbegin/end
> - write ebuild for libc++abi
>
> Progress:
> - write ebuild for crtbegin/end
>
> libc++abi's situation is a bit complicated. To configure it, you need
> the specify paths to libc++ and LLVM's source. libc++ has a similar
> issue: it also needs to know the path to LLVM's source. Actually
> libc++'s ebuild maintainer wrote a Makefile to circumvent its cmake
> system, which works without knowing LLVM's source path. I guess libc++
> doesn't really need LLVM's source; it's just some quirk of their cmake
> system.
>
> But I can't tell yet if libc++abi really needs libc++ or LLVM's
> source. If not, perhaps I can write a Makefile just like libc++'s;
> otherwise, maybe I need to keep LLVM's source somewhere after
> installing it.

It turns out libc++abi doesn't really need LLVM's source, but *does*
depend on libc++'s headers. I managed to write a Makefile for it to
circumvent cmake, providing libc++'s headers can be found somewhere.

The problem is: lib++ is supposed be built after libc++abi. My thought:
- if libc++ is already installed (e.g. against libcxxrt), installing
libc++abi has no impact on libc++
- otherwise, installing libc++abi also installs libc++, and libc++
will be configured against libc++abi

Or alternatively: replace libcxxrt with libc++abi in portage repo, and
always install libc++ and libc++abi together, just as clang and LLVM
do.

Which makes sense more?


Lei

[gentoo-musl] Re: [GSoC] native-clang: daily report 07/01

[Lei Zhang]

2016-07-04 17:55 GMT+08:00 Luca Barbato <lu_zero@gentoo.org>:
> On 04/07/16 11:03, Lei Zhang wrote:
>> Or alternatively: replace libcxxrt with libc++abi in portage repo, and
>> always install libc++ and libc++abi together, just as clang and LLVM
>> do.
>>
>> Which makes sense more?
>
> The libc++ + libc++abi is less nice but probably more straightforward.

Actually the current ebuild for libc++ supports both libcxxrt and
libsupc++ (part of libstdc++) as the ABI library. Which one to use is
controlled by USE flag "libcxxrt". If libc++ is already installed
without this flag, installing libcxxrt afterwards will have no impact,
which is similar to my first proposal.

Perhaps we could add another USE flag "libc++abi"; which one of the
three ABI libraries to use is then controlled by users.


Lei