Fix the build logic for LLVM libcxx #21792

ararslan · 2017-05-11T04:17:30Z

With this change, libc++ and libc++abi build for me. Without it I was getting errors since -lc++ -lc++abi was passed in too soon.

staticfloat · 2017-05-11T22:41:08Z

deps/llvm.mk

+LLVM_LDFLAGS += -Wl,-R$(build_libdir)
+LLVM_CXXFLAGS += -I$(build_includedir)
+LLVM_CPPFLAGS += -I$(build_includedir)
+LLVM_CFLAGS += -I$(build_includedir)


Do we really have to add -I$(build_includedir) to all of them? Can't we just put it into CPPFLAGS? 🐼

We probably don't need it in all of them, I was just playing it safe because FreeBSD sucks at figuring out where to search for things, plus I figured it wouldn't hurt. I'll try paring it down to just CPPFLAGS.

As an aside, what's the difference between CPPFLAGS and CXXFLAGS?

CPP stands for C PreProcessor, not C Plus Plus. CXX on the other hand, is C++, but with the + symbols turned on their side.

What on God's Green Earth were the programmers thinking.

staticfloat · 2017-05-11T22:43:19Z

deps/llvm.mk

+LLVM_CXXFLAGS += -I$(build_includedir)
+LLVM_CPPFLAGS += -I$(build_includedir)
+LLVM_CFLAGS += -I$(build_includedir)
+LLVM_LIBCXX_FLAGS := -lc++ -lc++abi


Since these are just LDFLAGS, can we stick them onto LLVM_LDFLAGS right here? If you don't want to do that, then let's named them LLVM_LIBCXX_LDFLAGS to make it explicit that these are linker flags.

Ah, reading further on ahead, we keep them separate so we can bootstrap libcxx without having it link to itself. Nevermind this then. I would just add the LD into the name to make it easy to understand what it is right off the bat.

I should probably add a comment regarding why the flags are separate further up here in the file.

staticfloat · 2017-05-11T22:44:43Z

deps/llvm.mk

+else
+BUILT_UNWIND :=
+endif
+


Are these values actually used anywhere?

Ack! Yes, the change that includes the use accidentally got lost while I was trying to separate out the changes I made to get FreeBSD working into separate PRs. Thanks!

tkelman · 2017-05-12T00:29:48Z

deps/llvm.mk

+ifeq ($(BUILD_CUSTOM_LIBCXX),1)
+LLVM_LDFLAGS += -Wl,-R$(build_libdir)
+LLVM_CPPFLAGS += -I$(build_includedir)
+# We don't want to link to libc++ while trying to build it, so if we defined these


why if? isn't this describing what you're doing?

Yes? It's just how I worded the rationale. I can change it if it's confusing.

tkelman · 2017-05-12T00:31:24Z

deps/llvm.mk

-$(LLVM_SRC_DIR)/projects/libcxx/.git/HEAD: | $(LLVM_SRC_DIR)/projects/libcxx/.git/HEAD
-$(LLVM_SRC_DIR)/projects/libcxxabi: $(LLVM_LIBCXXABI_TAR) | $(LLVM_SRC_DIR)/source-extracted
+$(LLVM_SRC_DIR)/projects/libcxx/.git/HEAD: | $(LLVM_SRC_DIR)/projects/libcxx
+$(LLVM_SRC_DIR)/projects/libcxxabi: $(LLVM_LIBCXXABI_TAR) | $(LLVM_SRC_DIR)/source-extracted $(BUILD_UNWIND)


ararslan · 2017-05-12T18:54:00Z

@staticfloat Looking better now?

tkelman · 2017-05-12T18:57:38Z

deps/llvm.mk

 ifeq ($(USEICC),1)
 LIBCXX_EXTRA_FLAGS := -Bstatic -lirc -Bdynamic
 endif

-$(LLVM_SRC_DIR)/projects/libcxx: $(LLVM_LIBCXX_TAR) | $(LLVM_SRC_DIR)/source-extracted
+# These libraries require unwind.h from the libunwind dependency


this isn't supposed to be using llvm's version of libunwind?

Probably I don't think it matters; I'm not sure where LLVM puts its unwind.h, plus it builds fine for me both with libunwind and with the system's unwind.h.

ararslan · 2017-05-13T00:18:12Z

@jlbuild !flags=BUILD_CUSTOM_LIBCXX=1 !nuke

jlbuild · 2017-05-13T00:18:12Z

Status of `4bcdea1` builds:

Builder Name	Nuke	Build	Download
linux32	COMPLETE	ERRORED	N/A
linux64	COMPLETE	ERRORED	N/A
linuxaarch64	COMPLETE	ERRORED	N/A
linuxarmv7l	COMPLETE	ERRORED	N/A
linuxppc64le	COMPLETE	ERRORED	N/A
osx64	COMPLETE	ERRORED	N/A
win32	CANCELED	N/A	N/A
win64	COMPLETE	ERRORED	N/A

ararslan · 2017-05-13T01:03:34Z

The patchelf build is failing claiming that the C compiler can't create executables... I would think this shouldn't affect patchelf, since we're only passing the libc++ flags to LLVM.

ararslan · 2017-05-13T22:25:14Z

deps/llvm.mk

 $(LLVM_BUILD_DIR)/libcxxabi-build/lib/libc++abi.so.1.0: $(LLVM_BUILD_DIR)/libcxxabi-build/Makefile $(LLVM_SRC_DIR)/projects/libcxxabi/.git/HEAD
 	$(MAKE) -C $(LLVM_BUILD_DIR)/libcxxabi-build
+	# The installed headers are not needed after building and can interfere with other dependencies
+	# FIXME: Find a better way to address this
+	-rm -rf $(build_includedir)/c++


Does anyone know of a better way to accomplish this?

ararslan · 2017-05-18T04:35:43Z

@jlbuild !flags=BUILD_CUSTOM_LIBCXX=1 !nuke

jlbuild · 2017-05-18T04:35:46Z

Status of `de05560` builds:

Builder Name	Nuke	Build	Download
linux32	COMPLETE	ERRORED	N/A
linux64	COMPLETE	ERRORED	N/A
linuxaarch64	CANCELED	N/A	N/A
linuxarmv7l	COMPLETE	ERRORED	N/A
linuxppc64le	COMPLETE	ERRORED	N/A
osx64	COMPLETE	ERRORED	N/A
win32	CANCELED	N/A	N/A
win64	CANCELED	N/A	N/A

staticfloat · 2017-05-18T16:11:49Z

I don't think I've ever actually seen an Error 77 from make. That's interesting.

Looking at the config.log from patchelf, GCC is choking on -stdlib=libc++:

configure:2856: checking whether the C compiler works
configure:2878: gcc -march=pentium4 -m32 -mfpmath=sse  -L/buildworker/worker/package_linux32/build/usr/lib -lc++abi -stdlib=libc++ -lc++ conftest.c  >&5
gcc: error: unrecognized command line option '-stdlib=libc++'
configure:2882: $? = 1
configure:2920: result: no

@ararslan do you have docker on any of your local machines?

ararslan · 2017-05-18T16:23:08Z

Ah, because we can't set that flag until after we've built libc++. Hmmmmmm...

No, I don't have Docker installed. Should be available from Homebrew on my Mac, but I don't know how to use it.

staticfloat · 2017-05-18T16:24:17Z

Ah, because we can't set that flag until after we've built libc++. Hmmmmmm...

Do you need patchelf to install libc++? If not, I would just set a dependency on libc++ for patchelf, conditional on you building libc++, of course.

ararslan · 2017-05-18T16:28:10Z

Do you need patchelf to install libc++?

Don't think so.

If not, I would just set a dependency on libc++ for patchelf, conditional on you building libc++, of course.

I'll give that a shot. Thanks!

ararslan · 2017-05-18T18:15:38Z

I still have to wait until after patchelf is built to add in -stdlib=libc++ though, right? I'm not sure what the best way is to ensure that flags are defined only after something is built.

staticfloat · 2017-05-18T18:20:25Z

Okay, looking into this further, what I was proposing actually exists. It appears that patchelf is set to depend on LIBCXX_DEPENDENCY, ~~but it's set as a parallel dependency, which I don't think is right. Get rid of the | and see if things start working.~~ This is totally false.

ararslan · 2017-05-18T18:38:08Z

@jlbuild !flags=BUILD_CUSTOM_LIBCXX=1 !nuke

staticfloat · 2017-05-18T18:40:03Z

Also, if you do end up installing docker (just use the installer from the docker website), you can recreate this locally by running:

docker run -ti staticfloat/julia_workerbase_centos6_9:x64

That will open up a shell within the same build environment as what the @jlbuild workers are using, running locally on your machine, so you can git clone julia, and make it with the same compilers and whatnot.

vtjnash · 2017-05-18T19:59:41Z

deps/patchelf.mk

@@ -9,7 +9,7 @@ $(SRCDIR)/srccache/patchelf-$(PATCHELF_VER)/source-extracted: $(SRCDIR)/srccache
 	touch -c $(SRCDIR)/srccache/patchelf-$(PATCHELF_VER)/configure # old target
 	echo 1 > $@

-$(BUILDDIR)/patchelf-$(PATCHELF_VER)/build-configured: $(SRCDIR)/srccache/patchelf-$(PATCHELF_VER)/source-extracted | $(LIBCXX_DEPENDENCY)
+$(BUILDDIR)/patchelf-$(PATCHELF_VER)/build-configured: $(SRCDIR)/srccache/patchelf-$(PATCHELF_VER)/source-extracted $(LIBCXX_DEPENDENCY)


we shouldn't need to rebuild patchelf anytime LIBCXX_DEPENDENCY is rebuilt (| means that it only depends on existence, not timestamp)

Oh shoot, sorry, my bad. I just realized I have always misunderstood what the | means in Makefiles.

Ah, thanks for the correction. I put that change in a separate commit, so I'll just rebase out that one commit. Do you have a better idea for how to deal with this, @vtjnash?

staticfloat · 2017-05-18T23:08:17Z

Jameson is right, | does not mean parallel dependency, it means order-only dependency, which should work.

Furthermore, the error from gcc is not one of a missing library; it's the gcc actually doesn't take the -stdlib option. I think on Linux, you need to not add that flag. Check out this SO answer.

jlbuild · 2017-05-18T23:09:34Z

Status of `283e2bf` builds:

Builder Name	Nuke	Build	Download
linux32	COMPLETE	ERRORED	N/A
linux64	COMPLETE	ERRORED	N/A
linuxaarch64	PENDING	N/A	N/A
linuxarmv7l	COMPLETE	ERRORED	N/A
linuxppc64le	COMPLETE	ERRORED	N/A
osx64	COMPLETE	ERRORED	N/A
win32	PENDING	N/A	N/A
win64	PENDING	N/A	N/A

jlbuild · 2017-05-19T18:45:06Z

Status of `6694ee0` builds:

Builder Name	Nuke	Build	Download
linux32	COMPLETE	ERRORED	N/A
linux64	COMPLETE	ERRORED	N/A
linuxaarch64	COMPLETE	ERRORED	N/A
linuxarmv7l	COMPLETE	ERRORED	N/A
linuxppc64le	COMPLETE	ERRORED	N/A
osx64	COMPLETE	ERRORED	N/A
win32	CANCELED	N/A	N/A
win64	COMPLETE	ERRORED	N/A

ararslan · 2017-05-19T23:18:57Z

I had a thought. We restrict USE_LIBCPP to cases with USECLANG—would it make sense to restrict BUILD_CUSTOM_LIBCXX to USECLANG as well?

ararslan · 2017-05-20T01:11:04Z

@jlbuild !flags=BUILD_CUSTOM_LIBCXX=1 !nuke

jlbuild · 2017-05-20T01:11:07Z

Status of `f8210fb` builds:

Builder Name	Nuke	Build	Download
linux32	COMPLETE	ERRORED	N/A
linux64	COMPLETE	ERRORED	N/A
linuxaarch64	COMPLETE	ERRORED	N/A
linuxarmv7l	COMPLETE	ERRORED	N/A
linuxppc64le	COMPLETE	ERRORED	N/A
osx64	COMPLETE	ERRORED	N/A
win32	CANCELED	N/A	N/A
win64	CANCELED	N/A	N/A

staticfloat · 2017-05-20T23:12:01Z

deps/llvm.mk

-$(LLVM_SRC_DIR)/projects/libcxx/.git/HEAD: | $(LLVM_SRC_DIR)/projects/libcxx/.git/HEAD
-$(LLVM_SRC_DIR)/projects/libcxxabi: $(LLVM_LIBCXXABI_TAR) | $(LLVM_SRC_DIR)/source-extracted
+$(LLVM_SRC_DIR)/projects/libcxx/.git/HEAD: | $(LLVM_SRC_DIR)/projects/libcxx
+$(LLVM_SRC_DIR)/projects/libcxxabi: $(LLVM_LIBCXXABI_TAR) | $(LLVM_SRC_DIR)/source-extracted $(BUILT_UNWIND)


This causes a make BUILD_CUSTOM_LIBCXX=1 -C deps get-llvm to actually build libunwind, which is a no-no. We need to depend on libunwind for when we actually build libcxx, but not when we check the source out. Let's move this dependency down to the target that invokes cmake just below this.

staticfloat · 2017-05-21T00:56:13Z

So I was playing around with this this afternoon. First of all, to play around with this in Docker, I suggest you use the following Dockerfile:

FROM staticfloat/julia_workerbase_centos6_9:x64

RUN mkdir /src/julia
WORKDIR /src/julia

# Clone @ararslan's branch of Julia, manually storing the details about the
# branch_head.json so that if a new commit gets pushed the docker cache is
# invalidated from here on out
ADD https://api.github.com/repos/JuliaLang/julia/git/refs/heads/aa/libcxx /branch_head.json
RUN git clone -b aa/libcxx https://github.com/JuliaLang/julia .

# Do some steps here first like downloading our prerequisites so that
# they are cached within Docker layers and not getting redownloaded
# every time we try to build LLVM
RUN make BUILD_CUSTOM_LIBCXX=1 -C deps -j3 get-llvm

RUN make MARCH=x86-64 BUILD_CUSTOM_LIBCXX=1 -C deps -j3 install-llvm
#RUN make MARCH=x86-64 BUILD_CUSTOM_LIBCXX=1 -C deps install-patchelf

The last line is commented out, but after running docker build -t libcxx_test . in the directory where you have saved this file as Dockerfile, if you run docker run -ti libcxx_test you will launch a shell into a Julia checkout with LLVM (and libcxx) built. If you then run make MARCH=x86-64 BUILD_CUSTOM_LIBCXX=1 -C deps install-patchelf, you'll get a bunch of errors:

g++ -march=x86-64 -m64 -Wall -g -O2  -L/src/julia/usr/lib -lc++abi -lc++ -nostdinc++ -nodefaultlibs -lm -lc -lgcc_s -lgcc -o patchelf patchelf.o
patchelf.o: In function `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::append(char const*)':
/usr/local/include/c++/7.1.0/bits/basic_string.h:1221: undefined reference to `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_append(char cons
t*, unsigned long)'
patchelf.o: In function `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_check_length(unsigned long, unsigned long, char const*) const':
/usr/local/include/c++/7.1.0/bits/basic_string.h:296: undefined reference to `std::__throw_length_error(char const*)'
patchelf.o: In function `void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*>(char const*, char const*, std::forward_ite
rator_tag)':
...

This is because patchelf is accessing the wrong headers. The following patch helps a lot:

$ git diff
diff --git a/Make.inc b/Make.inc
index 05ef56699c..8c0df8248f 100644
--- a/Make.inc
+++ b/Make.inc
@@ -1065,6 +1065,7 @@ endif
 # Custom libcxx
 ifeq ($(BUILD_CUSTOM_LIBCXX),1)
 LDFLAGS += -L$(build_libdir)
+CXXFLAGS += -nostdinc++ -I$(build_includedir)/c++/v1
 CXXLDFLAGS += -L$(build_libdir) -lc++abi -lc++
 ifeq ($(USECLANG),1)
 CXXLDFLAGS += -stdlib=libc++
diff --git a/deps/patchelf.mk b/deps/patchelf.mk
index 066fc2ebd8..cc54f212d0 100644
--- a/deps/patchelf.mk
+++ b/deps/patchelf.mk
@@ -12,7 +12,7 @@ $(SRCDIR)/srccache/patchelf-$(PATCHELF_VER)/source-extracted: $(SRCDIR)/srccache
 $(BUILDDIR)/patchelf-$(PATCHELF_VER)/build-configured: $(SRCDIR)/srccache/patchelf-$(PATCHELF_VER)/source-extracted | $(LIBCXX_DEPENDENCY)
        mkdir -p $(dir $@)
        cd $(dir $@) && \
-       $(dir $<)/configure $(CONFIGURE_COMMON) LDFLAGS="$(CXXLDFLAGS)" CPPFLAGS="$(CPPFLAGS)"
+       $(dir $<)/configure $(CONFIGURE_COMMON) LDFLAGS="$(CXXLDFLAGS)" CPPFLAGS="$(CPPFLAGS)" CXXFLAGS="$(CXXFLAGS)"
        echo 1 > $@

 $(BUILDDIR)/patchelf-$(PATCHELF_VER)/build-compiled: $(BUILDDIR)/patchelf-$(PATCHELF_VER)/build-configured

But we now get errors such as the following:

[buildworker@d8ea9d46e38f julia]$ make MARCH=x86-64 BUILD_CUSTOM_LIBCXX=1 -C deps clean-patchelf; make MARCH=x86-64 BUILD_CUSTOM_LIBCXX=1 -C deps install-patchelf
...
g++ -march=x86-64 -m64 -Wall -nostdinc++ -I/src/julia/usr/include/c++/v1  -L/src/julia/usr/lib -lc++abi -lc++ -nostdinc++ -nodefaultlibs -lm -lc -lgcc_s -lgcc -o patchelf patchelf.o
patchelf.o: In function `readFile(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >)':
patchelf.cc:(.text+0x439): undefined reference to `stat'
patchelf.o: In function `ElfFile<Elf32_Ehdr, Elf32_Phdr, Elf32_Shdr, unsigned int, unsigned int, Elf32_Dyn, Elf32_Sym>::modifyRPath(ElfFile<Elf32_Ehdr, Elf32_Phdr, Elf32_Shdr, unsigned int, unsigned int, Elf32_Dyn, Elf32_Sym>::RPathOp, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >)':
patchelf.cc:(.text._ZN7ElfFileI10Elf32_Ehdr10Elf32_Phdr10Elf32_Shdrjj9Elf32_Dyn9Elf32_SymE11modifyRPathENS5_7RPathOpENSt3__112basic_stringIcNS7_11char_traitsIcEENS7_9allocatorIcEEEE[_ZN7ElfFileI10Elf32_Ehdr10Elf32_Phdr10Elf32_Shdrjj9Elf32_Dyn9Elf32_SymE11modifyRPathENS5_7RPathOpENSt3__112basic_stringIcNS7_11char_traitsIcEENS7_9allocatorIcEEEE]+0xf85): undefined reference to `stat'
patchelf.o: In function `ElfFile<Elf64_Ehdr, Elf64_Phdr, Elf64_Shdr, unsigned long, unsigned long, Elf64_Dyn, Elf64_Sym>::modifyRPath(ElfFile<Elf64_Ehdr, Elf64_Phdr, Elf64_Shdr, unsigned long, unsigned long, Elf64_Dyn, Elf64_Sym>::RPathOp, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >)':
patchelf.cc:(.text._ZN7ElfFileI10Elf64_Ehdr10Elf64_Phdr10Elf64_Shdrmm9Elf64_Dyn9Elf64_SymE11modifyRPathENS5_7RPathOpENSt3__112basic_stringIcNS7_11char_traitsIcEENS7_9allocatorIcEEEE[_ZN7ElfFileI10Elf64_Ehdr10Elf64_Phdr10Elf64_Shdrmm9Elf64_Dyn9Elf64_SymE11modifyRPathENS5_7RPathOpENSt3__112basic_stringIcNS7_11char_traitsIcEENS7_9allocatorIcEEEE]+0xfa8): undefined reference to `stat'
collect2: error: ld returned 1 exit status

This is because the linker invocation is all wrong; we're specifying the input (patchelf.o) after the libraries we want to link in (-lc, in particular). See here for more on linker invocation ordering. If you manually try to link and put -lc at the end, then it works, and patchelf is linked against the proper libc++.so (which it can't find yet, but that's expected, because it's going to be put in the same directory as libc++.so):

[buildworker@d8ea9d46e38f julia]$ cd deps/scratch/patchelf-0.9/src/
[buildworker@d8ea9d46e38f src]$ g++ -march=x86-64 -m64 -Wall -nostdinc++ -I/src/julia/usr/include/c++/v1  -L/src/julia/usr/lib -lc++abi -lc++ -nostdinc++ -nodefaultlibs -lm -lc -lgcc_s -lgcc -o patchelf patchelf.o -lc
[buildworker@d8ea9d46e38f src]$ ldd ./patchelf
        linux-vdso.so.1 =>  (0x00007fff4bd74000)
        libc++abi.so.1 => not found
        libc++.so.1 => not found
        libm.so.6 => /lib64/libm.so.6 (0x00007fd6a7f87000)
        libc.so.6 => /lib64/libc.so.6 (0x00007fd6a7bf3000)
        libgcc_s.so.1 => /usr/local/lib64/libgcc_s.so.1 (0x00007fd6a79db000)
        /lib64/ld-linux-x86-64.so.2 (0x0000556914dce000)

ararslan · 2017-06-01T17:09:16Z

Okay, so as it stands on master, this flag works neither with Clang nor with GCC. I have no idea how to get the GCC flags into the proper order to get it working on GCC. I'd like to propose that for now we restrict BUILD_CUSTOM_LIBCXX to USECLANG=1, in keeping with USE_LIBCPP. Should someone familiar with GCC find themselves in need of this functionality, they can submit a PR that removes the USECLANG restriction along with their fixes.

Does this seem reasonable?

ararslan · 2017-06-05T21:42:49Z

Some flag we're passing on macOS is keeping it from building there. So far I've only been able to get this to work on FreeBSD, which is an interesting reversal.

ararslan · 2017-06-06T21:04:33Z

My only use case for this is to get Julia building on FreeBSD. Allow me to revise my proposal: I think we should

Ensure this still works on FreeBSD
Restrict to Clang
Make it clear that the flag may not work in all cases
Merge this and hope someone else wants to fix the other cases

tkelman · 2017-06-07T00:31:25Z

as long as this PR doesn't make the flag work any worse on non freebsd

tkelman · 2017-06-07T00:34:20Z

deps/patchelf.mk

@@ -12,7 +12,7 @@ $(SRCDIR)/srccache/patchelf-$(PATCHELF_VER)/source-extracted: $(SRCDIR)/srccache
 $(BUILDDIR)/patchelf-$(PATCHELF_VER)/build-configured: $(SRCDIR)/srccache/patchelf-$(PATCHELF_VER)/source-extracted | $(LIBCXX_DEPENDENCY)
 	mkdir -p $(dir $@)
 	cd $(dir $@) && \
-	$(dir $<)/configure $(CONFIGURE_COMMON) LDFLAGS="$(CXXLDFLAGS)" CPPFLAGS="$(CPPFLAGS)"
+	$(dir $<)/configure $(CONFIGURE_COMMON) LDFLAGS="$(CXXLDFLAGS)" CPPFLAGS="$(CPPFLAGS)" CXXFLAGS="$(CXXFLAGS)"


does this need cxxflags or do you need to be splitting cxxflags from cppflags better?

This was part of something I was trying for getting GCC to work. I still need go through and clean up the changes and commits.

ararslan · 2017-06-07T03:45:19Z

Okay, cleaned up the changes and successfully rebuilt on FreeBSD.

ararslan · 2017-06-07T05:18:07Z

64-bit Windows failure is unrelated, so AFAICT this is good to go.

tkelman · 2017-06-07T05:59:02Z

Make.inc

@@ -1069,8 +1069,14 @@ endif
 # Custom libcxx
 ifeq ($(BUILD_CUSTOM_LIBCXX),1)
 LDFLAGS += -L$(build_libdir)
-CXXLDFLAGS += -L$(build_libdir) -lc++abi -stdlib=libc++ -lc++
-CPPFLAGS += -I$(build_includedir)/c++/v1


where'd this go then?

Including those headers makes the other dependencies, e.g. OpenBLAS, fail to build.

tkelman · 2017-06-07T08:36:26Z

Make.inc

+CXXLDFLAGS += -stdlib=libc++
+else
+ifeq ($(USEGCC),1)
+$(error BUILD_CUSTOM_LIBCXX is currently only supported with Clang. Try setting BUILD_CUSTOM_LIBCXX=0)


we're sure this limitation was the case before?

Technically no, but in practicality I believe so. According to their documentation, libc++/libc++abi supports building on Linux with GCC. However, I don't see how it would be possible for us to build it with GCC given the way our linker flags are set up.

I'm pretty sure this was a functional limitation before. I've never successfully built a custom libcxx with gcc. I tried once when the option was first introduced, but figured that there wasn't much point trying to push it forward since it was most commonly used with clang.

This allows libc++ and libc++abi to be built on FreeBSD. However, these libraries still cannot be built with GCC nor on macOS, though that condition predates this change.

ararslan · 2017-06-09T01:44:52Z

I'd like to get this merged. Are there any further comments?

comments addressed

ararslan · 2017-06-09T23:50:44Z

There have been no further comments and Elliot gave his okay offline, so I'm going to go ahead and merge this. Thanks everyone for your help and feedback!

This allows libc++ and libc++abi to be built on FreeBSD. However, these libraries still cannot be built with GCC nor on macOS, though that condition predates this change. Ref #21792 (cherry picked from commit 90ddad8)

ararslan added the building Build system, or building Julia or its dependencies label May 11, 2017

ararslan requested review from staticfloat and Keno May 11, 2017 04:17

staticfloat previously requested changes May 11, 2017

View reviewed changes

ararslan force-pushed the aa/libcxx branch from a58f35e to 4d054eb Compare May 12, 2017 00:22

tkelman reviewed May 12, 2017

View reviewed changes

ararslan force-pushed the aa/libcxx branch from 4d054eb to 4bcdea1 Compare May 12, 2017 04:00

tkelman reviewed May 12, 2017

View reviewed changes

ararslan commented May 13, 2017

View reviewed changes

ararslan mentioned this pull request May 17, 2017

Workaround for FreeBSD linking to outdated system libs #21788

Merged

ararslan force-pushed the aa/libcxx branch from 4bcdea1 to de05560 Compare May 18, 2017 04:34

ararslan force-pushed the aa/libcxx branch from de05560 to 283e2bf Compare May 18, 2017 18:37

vtjnash reviewed May 18, 2017

View reviewed changes

ararslan force-pushed the aa/libcxx branch from 6694ee0 to 07bb28b Compare May 19, 2017 21:05

ararslan force-pushed the aa/libcxx branch from 07bb28b to f8210fb Compare May 20, 2017 01:10

ararslan requested a review from yuyichao May 20, 2017 19:19

staticfloat reviewed May 20, 2017

View reviewed changes

ararslan force-pushed the aa/libcxx branch from f8210fb to 073da9e Compare May 21, 2017 22:36

tkelman reviewed Jun 7, 2017

View reviewed changes

ararslan force-pushed the aa/libcxx branch 3 times, most recently from 01a26bc to 01e6ac2 Compare June 7, 2017 03:14

tkelman reviewed Jun 7, 2017

View reviewed changes

Update the build logic for LLVM libcxx

5275982

This allows libc++ and libc++abi to be built on FreeBSD. However, these libraries still cannot be built with GCC nor on macOS, though that condition predates this change.

ararslan force-pushed the aa/libcxx branch from 01e6ac2 to 5275982 Compare June 8, 2017 22:49

ararslan merged commit 90ddad8 into master Jun 9, 2017

ararslan deleted the aa/libcxx branch June 9, 2017 23:50

Fix the build logic for LLVM libcxx #21792

Fix the build logic for LLVM libcxx #21792

Conversation

ararslan commented May 11, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

staticfloat May 11, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ararslan commented May 12, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ararslan commented May 13, 2017

jlbuild commented May 13, 2017 • edited Loading

Status of 4bcdea1 builds:

ararslan commented May 13, 2017

Choose a reason for hiding this comment

ararslan commented May 18, 2017

jlbuild commented May 18, 2017 • edited Loading

Status of de05560 builds:

staticfloat commented May 18, 2017

ararslan commented May 18, 2017

staticfloat commented May 18, 2017

ararslan commented May 18, 2017

ararslan commented May 18, 2017

staticfloat commented May 18, 2017 • edited Loading

ararslan commented May 18, 2017

staticfloat commented May 18, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

staticfloat commented May 18, 2017

jlbuild commented May 18, 2017 • edited Loading

Status of 283e2bf builds:

jlbuild commented May 19, 2017 • edited Loading

Status of 6694ee0 builds:

ararslan commented May 19, 2017

ararslan commented May 20, 2017

jlbuild commented May 20, 2017 • edited Loading

Status of f8210fb builds:

Choose a reason for hiding this comment

staticfloat commented May 21, 2017 • edited Loading

ararslan commented Jun 1, 2017

ararslan commented Jun 5, 2017

ararslan commented Jun 6, 2017

tkelman commented Jun 7, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ararslan commented Jun 7, 2017

ararslan commented Jun 7, 2017

Choose a reason for hiding this comment

ararslan Jun 7, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ararslan commented Jun 9, 2017

ararslan commented Jun 9, 2017

staticfloat May 11, 2017 •

edited

Loading

jlbuild commented May 13, 2017 •

edited

Loading

Status of `4bcdea1` builds:

jlbuild commented May 18, 2017 •

edited

Loading

Status of `de05560` builds:

staticfloat commented May 18, 2017 •

edited

Loading

jlbuild commented May 18, 2017 •

edited

Loading

Status of `283e2bf` builds:

jlbuild commented May 19, 2017 •

edited

Loading

Status of `6694ee0` builds:

jlbuild commented May 20, 2017 •

edited

Loading

Status of `f8210fb` builds:

staticfloat commented May 21, 2017 •

edited

Loading

ararslan Jun 7, 2017 •

edited

Loading