clang/musl/linux?

clang/musl/linux?

[Jon Chesterfield]

[-- Attachment #1: Type: text/plain, Size: 548 bytes --]

I'm interested in using a toolchain containing clang, musl and the llvm C++
stack from a glibc linux host. There is some patchy documentation on doing
this which suggests it is possible with some relatively minor patches. Most
of the links are from a few years ago.

Does anyone on this list use a similar setup today? If so, does it work for
you?

Essentially I'm hoping for guidance on whether the end result of the cmake
hackery would be stable enough to use as my daily toolchain, before
grinding through the inevitable plumbing.

Thanks!

Jon

[-- Attachment #2: Type: text/html, Size: 763 bytes --]

Re: clang/musl/linux?

[Dmitry Golovin]

07.08.2018, 16:19, "Jon Chesterfield" <jonathanchesterfield@gmail.com>:
> I'm interested in using a toolchain containing clang, musl and the llvm C++ stack from a glibc linux host. There is some patchy documentation on doing this which suggests it is possible with some relatively minor patches. Most of the links are from a few years ago.
>
> Does anyone on this list use a similar setup today? If so, does it work for you?
>
> Essentially I'm hoping for guidance on whether the end result of the cmake hackery would be stable enough to use as my daily toolchain, before grinding through the inevitable plumbing.
>
> Thanks!
>
> Jon

Unfortunately, it's not possible to build mainline linux with clang right now. Currently most efforts on patching the kernel are combined in this repo: https://github.com/ClangBuiltLinux/linux (it is also not ready to be compiled yet).

You can also check my GNU-free toolchain as a starting point: https://github.com/tpimh/ngtc
It uses musl, clang, lld and libcxx with very little patching.

Regards,
Dmitry

Re: clang/musl/linux?

[Fāng-ruì Sòng]

[-- Attachment #1: Type: text/plain, Size: 1337 bytes --]

On Tue, Aug 7, 2018 at 6:38 AM Dmitry Golovin <dima@golovin.in> wrote:

> 07.08.2018, 16:19, "Jon Chesterfield" <jonathanchesterfield@gmail.com>:
> > I'm interested in using a toolchain containing clang, musl and the llvm
> C++ stack from a glibc linux host. There is some patchy documentation on
> doing this which suggests it is possible with some relatively minor
> patches. Most of the links are from a few years ago.
> >
> > Does anyone on this list use a similar setup today? If so, does it work
> for you?
> >
> > Essentially I'm hoping for guidance on whether the end result of the
> cmake hackery would be stable enough to use as my daily toolchain, before
> grinding through the inevitable plumbing.
> >
> > Thanks!
> >
> > Jon
>
> Unfortunately, it's not possible to build mainline linux with clang right
> now. Currently most efforts on patching the kernel are combined in this
> repo: https://github.com/ClangBuiltLinux/linux (it is also not ready to
> be compiled yet).
>
> You can also check my GNU-free toolchain as a starting point:
> https://github.com/tpimh/ngtc
> It uses musl, clang, lld and libcxx with very little patching.
>
> Regards,
> Dmitry
>

Has anyone tried building llvm+musl on regular glibc-based Linux
distributions (not Alpine, ...)? I would like to test (ninja check-all) if
I know the instructions.

[-- Attachment #2: Type: text/html, Size: 1917 bytes --]

Re: clang/musl/linux?

[Dmitry Golovin]

31.08.2018, 09:30, "Fāng-ruì Sòng" <emacsray@gmail.com>:
> On Tue, Aug 7, 2018 at 6:38 AM Dmitry Golovin <dima@golovin.in> wrote:
>> 07.08.2018, 16:19, "Jon Chesterfield" <jonathanchesterfield@gmail.com>:
>>> I'm interested in using a toolchain containing clang, musl and the llvm C++ stack from a glibc linux host. There is some patchy documentation on doing this which suggests it is possible with some relatively minor patches. Most of the links are from a few years ago.
>>>
>>> Does anyone on this list use a similar setup today? If so, does it work for you?
>>>
>>> Essentially I'm hoping for guidance on whether the end result of the cmake hackery would be stable enough to use as my daily toolchain, before grinding through the inevitable plumbing.
>>>
>>> Thanks!
>>>
>>> Jon
>>
>> Unfortunately, it's not possible to build mainline linux with clang right now. Currently most efforts on patching the kernel are combined in this repo: https://github.com/ClangBuiltLinux/linux (it is also not ready to be compiled yet).
>>
>> You can also check my GNU-free toolchain as a starting point: https://github.com/tpimh/ngtc
>> It uses musl, clang, lld and libcxx with very little patching.
>>
>> Regards,
>> Dmitry
>
> Has anyone tried building llvm+musl on regular glibc-based Linux distributions (not Alpine, ...)? I would like to test (ninja check-all) if I know the instructions.

There should not be any problems building LLVM and musl on glibc-based distro. The reason why I'm building on Alpine is that I want my llvm and clang to be linked against musl (this is what I need patches for). On a glibc-based distro no patches are needed and you can use musl-clang wrapper to produce binaries linked against musl.

Regards,
Dmitry
 

Re: clang/musl/linux?

[Luca Barbato]

On 31/08/2018 09:19, Dmitry Golovin wrote:
> There should not be any problems building LLVM and musl on glibc-based distro. The reason why I'm building on Alpine is that I want my llvm and clang to be linked against musl (this is what I need patches for). On a glibc-based distro no patches are needed and you can use musl-clang wrapper to produce binaries linked against musl.

Another way is using this
https://wiki.gentoo.org/wiki/Clang
with
http://distfiles.gentoo.org/experimental/amd64/musl/

It shouldn't have problems but I did not test it lately.

lu

Re: clang/musl/linux?

[Jon Chesterfield]

[-- Attachment #1: Type: text/plain, Size: 1471 bytes --]

I'm still working on this, off and on. I want to assemble a C++ toolchain
that depends on the Linux kernel but nothing else from the distribution.
Otherwise I'd use alpine.

Most of the difficulty has been in working around assumptions made by the
cmake scripts in LLVM. They are subtle to configure.

Combining libunwind, libcxxabi and libc++ into a single library makes
linking significantly simpler. Also makes setting rpath simpler.

crti,crtn,crtbegin,crtend can be empty files. Don't use crtbegin from bsd.

Tools like clang, lld have dependencies on other libraries. zlib, curses
etc. Disabling these in the cmake files broke apparently unrelated things.
My next step is to debug that or start building the supporting libraries.

Musl itself has caused me no problems in any of the above.

Cheers

Jon

On Fri, 31 Aug 2018, 09:29 Luca Barbato, <lu_zero@gentoo.org> wrote:

> On 31/08/2018 09:19, Dmitry Golovin wrote:
> > There should not be any problems building LLVM and musl on glibc-based
> distro. The reason why I'm building on Alpine is that I want my llvm and
> clang to be linked against musl (this is what I need patches for). On a
> glibc-based distro no patches are needed and you can use musl-clang wrapper
> to produce binaries linked against musl.
>
> Another way is using this
> https://wiki.gentoo.org/wiki/Clang
> with
> http://distfiles.gentoo.org/experimental/amd64/musl/
>
> It shouldn't have problems but I did not test it lately.
>
> lu
>
>

[-- Attachment #2: Type: text/html, Size: 2348 bytes --]

Re: clang/musl/linux?

[Dmitry Golovin]

Combining libunwind, libcxxabi and libc++ into a single library is a great idea! How exactly did you achieve this? What cmake options did you use?

This is how I worked around crtbegin/crtend problem: https://github.com/tpimh/ngtc/blob/f5a210846c349dd7c6a565593568c610e9c3a6d7/root/patch/musl-02-dummy-crts.patch

Maybe you would be interested in bundling your toolchain with netbsd-curses and miniz as lightweight alternatives to ncurses and libz (don't know if they will create more problems then solve, though). 

Regards,
Dmitry

31.08.2018, 14:30, "Jon Chesterfield" <jonathanchesterfield@gmail.com>:
> I'm still working on this, off and on. I want to assemble a C++ toolchain that depends on the Linux kernel but nothing else from the distribution. Otherwise I'd use alpine.
>
> Most of the difficulty has been in working around assumptions made by the cmake scripts in LLVM. They are subtle to configure.
>
> Combining libunwind, libcxxabi and libc++ into a single library makes linking significantly simpler. Also makes setting rpath simpler.
>
> crti,crtn,crtbegin,crtend can be empty files. Don't use crtbegin from bsd.
>
> Tools like clang, lld have dependencies on other libraries. zlib, curses etc. Disabling these in the cmake files broke apparently unrelated things. My next step is to debug that or start building the supporting libraries.
>
> Musl itself has caused me no problems in any of the above.
>
> Cheers
>
> Jon
>
> On Fri, 31 Aug 2018, 09:29 Luca Barbato, <lu_zero@gentoo.org> wrote:
>> On 31/08/2018 09:19, Dmitry Golovin wrote:
>>> There should not be any problems building LLVM and musl on glibc-based distro. The reason why I'm building on Alpine is that I want my llvm and clang to be linked against musl (this is what I need patches for). On a glibc-based distro no patches are needed and you can use musl-clang wrapper to produce binaries linked against musl.
>>
>> Another way is using this
>> https://wiki.gentoo.org/wiki/Clang
>> with
>> http://distfiles.gentoo.org/experimental/amd64/musl/
>>
>> It shouldn't have problems but I did not test it lately.
>>
>> lu

Re: clang/musl/linux?

[Jon Chesterfield]

[-- Attachment #1: Type: text/plain, Size: 5792 bytes --]

Combing them wasn't my idea but it definitely simplifies the rest of the
system. I think it's meant to work out of the box, but on llvm 6 release at
least it needs some handholding. There's a description of the method and
the bash script I'm running below.

Your crt* workaround looks sound. It's a bit sad to create files that lld
wants but doesn't need. I'm doing the same.

I'll look at miniz and netbsd-curses, thanks. Certainly worth a try.

Cheers!

Jon

libc++ has working support for bundling a libcxxabi.a into the
shared/static library. That worked for me building the libraries separately
or simultaneously.

libcxxabi has cmake options that suggests it can incorporate libunwind.
That didn't work for me, either building separately or together.

Strategy is therefore:
- put all the source directories next to each other
- compile libunwind.a
- combine libcxxabi.a
- merge into an archive (misleadingly) called libcxxabi.a
- point libc++ to that external archive and let cmake merge it with libc++

The cmake uses a python script to merge static archives which also does a
degree of looking around the filesystem for them. Merging archives robustly
is remarkably tedious if the objects could have the same name. gnu ar and
llvm-ar both know how to do this safely via mri scripts.

buildcxxlib() {
    CC=$1
    CFLAGS=$2
    CXX=$3
    CXXFLAGS=$4
    INSTALL=$5
    BUILD=$6
    COMPILER_RT=$7

    COMMON_FLAGS="-DLLVM_PATH=$SRC/llvm
    -DLLVM_MAIN_SRC_DIR=$SRC/llvm
    -DCMAKE_ASM_COMPILER=$CC
    -DCMAKE_C_COMPILER=$CC
    -DCMAKE_C_FLAGS=$CFLAGS \
    -DCMAKE_CXX_COMPILER=$CXX \
    -DCMAKE_CXX_FLAGS=$CXXFLAGS \
    -DCMAKE_BUILD_TYPE=Release"

echo "make libunwind"
mkdir -p "$BUILD/libunwind" && cd "$BUILD/libunwind"
cmake $COMMON_FLAGS \
    -DCMAKE_INSTALL_PREFIX=$INSTALL \
    -DLIBUNWIND_USE_COMPILER_RT=$COMPILER_RT \
    -DLIBUNWIND_ENABLE_STATIC=ON \
    -DLIBUNWIND_ENABLE_SHARED=OFF \
    $SRC/llvm/projects/libunwind
make -j `nproc` install
cd ../..

echo "make libcxxabi"
mkdir -p "$BUILD/libcxxabi" && cd "$BUILD/libcxxabi"
#     -DLIBCXXABI_ENABLE_STATIC_UNWINDER doesnt seem to be implemented
cmake $COMMON_FLAGS \
    -DCMAKE_INSTALL_PREFIX=$INSTALL \
    -DLIBCXXABI_USE_COMPILER_RT=$COMPILER_RT \
    -DLIBCXXABI_USE_LLVM_UNWINDER=ON \
    -DLIBCXXABI_ENABLE_STATIC=ON \
    -DLIBCXXABI_ENABLE_SHARED=OFF \
    $SRC/llvm/projects/libcxxabi
make -j `nproc` install
cd ../..

echo "Combine libunwind and libcxxabi into a single static library"
mkdir -p $INSTALL/tmp
echo "create $INSTALL/lib/libunwindc++abi.a
addlib $INSTALL/lib/libunwind.a
addlib $INSTALL/lib/libc++abi.a
save
end" | llvm-ar -M
rm $INSTALL/lib/libunwind.a $INSTALL/lib/libc++abi.a
mv $INSTALL/lib/libunwindc++abi.a $INSTALL/lib/libc++abi.a
rm -rf $INSTALL/tmp

echo "make libcxx"
# Setting rpath here could be useful for letting libc++ find libc
mkdir -p "$BUILD/libcxx" && cd "$BUILD/libcxx"
cmake $COMMON_FLAGS \
    -DCMAKE_INSTALL_PREFIX=$INSTALL \
    -DLIBCXX_USE_COMPILER_RT=$COMPILER_RT \
    -DLLVM_TARGETS_TO_BUILD="$TARGETS" \
    -DLIBCXX_ENABLE_STATIC=ON \
    -DLIBCXX_ENABLE_SHARED=ON \
    -DLIBCXX_CXX_ABI="libcxxabi" \
    -DLIBCXX_CXX_ABI_INCLUDE_PATHS=$SRC/llvm/projects/libcxxabi/include \
    -DLIBCXX_ENABLE_EXPERIMENTAL_LIBRARY=OFF \
    -DLIBCXX_ENABLE_STATIC_ABI_LIBRARY=ON \
    -DLIBCXX_CXX_ABI_LIBRARY_PATH=$BUILD/install/lib \
    -DCMAKE_INSTALL_RPATH="$BUILD/install/lib" \
        $SRC/llvm/projects/libcxx
make -j `nproc` install
cd ../..

rm $INSTALL/lib/libc++abi.a
}

On Fri, Aug 31, 2018 at 12:50 PM Dmitry Golovin <dima@golovin.in> wrote:

> Combining libunwind, libcxxabi and libc++ into a single library is a great
> idea! How exactly did you achieve this? What cmake options did you use?
>
> This is how I worked around crtbegin/crtend problem:
> https://github.com/tpimh/ngtc/blob/f5a210846c349dd7c6a565593568c610e9c3a6d7/root/patch/musl-02-dummy-crts.patch
>
> Maybe you would be interested in bundling your toolchain with
> netbsd-curses and miniz as lightweight alternatives to ncurses and libz
> (don't know if they will create more problems then solve, though).
>
> Regards,
> Dmitry
>
> 31.08.2018, 14:30, "Jon Chesterfield" <jonathanchesterfield@gmail.com>:
> > I'm still working on this, off and on. I want to assemble a C++
> toolchain that depends on the Linux kernel but nothing else from the
> distribution. Otherwise I'd use alpine.
> >
> > Most of the difficulty has been in working around assumptions made by
> the cmake scripts in LLVM. They are subtle to configure.
> >
> > Combining libunwind, libcxxabi and libc++ into a single library makes
> linking significantly simpler. Also makes setting rpath simpler.
> >
> > crti,crtn,crtbegin,crtend can be empty files. Don't use crtbegin from
> bsd.
> >
> > Tools like clang, lld have dependencies on other libraries. zlib, curses
> etc. Disabling these in the cmake files broke apparently unrelated things.
> My next step is to debug that or start building the supporting libraries.
> >
> > Musl itself has caused me no problems in any of the above.
> >
> > Cheers
> >
> > Jon
> >
> > On Fri, 31 Aug 2018, 09:29 Luca Barbato, <lu_zero@gentoo.org> wrote:
> >> On 31/08/2018 09:19, Dmitry Golovin wrote:
> >>> There should not be any problems building LLVM and musl on glibc-based
> distro. The reason why I'm building on Alpine is that I want my llvm and
> clang to be linked against musl (this is what I need patches for). On a
> glibc-based distro no patches are needed and you can use musl-clang wrapper
> to produce binaries linked against musl.
> >>
> >> Another way is using this
> >> https://wiki.gentoo.org/wiki/Clang
> >> with
> >> http://distfiles.gentoo.org/experimental/amd64/musl/
> >>
> >> It shouldn't have problems but I did not test it lately.
> >>
> >> lu
>

[-- Attachment #2: Type: text/html, Size: 7608 bytes --]

Re: clang/musl/linux?

[Khem Raj]

HI Jon

You can build a musl+clang SDK using yocto and then install it on a
linux/glibc host
see

https://himvis.com/clang-based-cross-sdk-with-openembedded-framework/

if you runinto issues let me know. If you want to use upcoming clang-7
use clang-7.0 branch of meta-clang repo. default on master is 6.0.1 as
of now.
On Tue, Aug 7, 2018 at 6:19 AM Jon Chesterfield
<jonathanchesterfield@gmail.com> wrote:
>
> I'm interested in using a toolchain containing clang, musl and the llvm C++ stack from a glibc linux host. There is some patchy documentation on doing this which suggests it is possible with some relatively minor patches. Most of the links are from a few years ago.
>
> Does anyone on this list use a similar setup today? If so, does it work for you?
>
> Essentially I'm hoping for guidance on whether the end result of the cmake hackery would be stable enough to use as my daily toolchain, before grinding through the inevitable plumbing.
>
> Thanks!
>
> Jon