Add libcxxStdenv attribute to recent llvm package sets #19859

shlevy · 2016-10-25T14:30:16Z

No description provided.

shlevy · 2016-10-25T14:30:43Z

@bzizou You should be able to directly reference llvmPackages_38.libcxxStdenv with this patch.

mention-bot · 2016-10-25T14:30:44Z

@shlevy, thanks for your PR! By analyzing the history of the files in this pull request, we identified @Ralith, @andrewrk and @acowley to be potential reviewers.

shlevy · 2016-10-25T14:31:18Z

@copumpkin I think this removed darwin-unfriendly bits from libcxxStdenv, not sure how you guys are setting up to use libc++.

shlevy · 2016-10-25T14:31:27Z

Refs #19834

copumpkin · 2016-10-25T14:34:28Z

@shlevy I think we just do it via extraBuildInputs on the stdenv. Perhaps I should switch to the extraPackages approach you use here.

https://github.com/NixOS/nixpkgs/blob/master/pkgs/stdenv/darwin/default.nix#L280-L290

bzizou · 2016-10-25T15:22:21Z

@shlevy : thank you! With that patch, I'ts now easy to reproduce the problem with boost:

Build ok:

boost160libcxx37 = callPackage ../development/libraries/boost/1.60.nix {
    stdenv = llvmPackages_37.libcxxStdenv;
};

Build NOT ok:

boost160libcxx38 = callPackage ../development/libraries/boost/1.60.nix {
    stdenv = llvmPackages_38.libcxxStdenv;
};

Same errors as here: boost160libcxx.out.txt

copumpkin · 2016-10-25T15:26:51Z

@bzizou perhaps diff that log against my successful build of 1.6 on darwin? http://hydra.nixos.org/build/42510536/nixlog/2/raw

bzizou · 2016-10-25T15:43:16Z

In a nix-shell -A boost160libcxx38, I can reproduce one of the errors during the build.
As far as I can understand, the problem is that the $NIX_CXXSTDLIB_COMPILE flag seems to be not passed to compiler options.

This command fails:

[nix-shell:~/tmp/nix_irods/boost_1_60_0]$ "clang++" -c -x c++ -O3 -Wno-inline -Wall -pthread -fPIC -m64  -DBOOST_ALL_NO_LIB=1 -DBOOST_CHRONO_DYN_LINK=1 -DBOOST_CONTEXT_DYN_LINK=1 -DBOOST_COROUTINES_DYN_LINK=1 -DBOOST_COROUTINES_SOURCE -DBOOST_DISABLE_ASSERTS -DBOOST_SYSTEM_DYN_LINK=1 -DBOOST_SYSTEM_NO_DEPRECATED -DBOOST_THREAD_BUILD_DLL=1 -DBOOST_THREAD_POSIX -DBOOST_THREAD_USE_DLL=1 -DNDEBUG -I"." -o "bin.v2/libs/coroutine/build/clang-linux-3.8.1/release/threading-multi/posix/stack_traits.o" "libs/coroutine/src/posix/stack_traits.cpp" In file included from libs/coroutine/src/posix/stack_traits.cpp:19:
/nix/store/m3azisclqx55zb40lsa4kmsfnw1g7mm9-libc++-3.8.1/include/c++/v1/cmath:309:9: error: no member named 'signbit' in the global namespace
using ::signbit;
      ~~^
/nix/store/m3azisclqx55zb40lsa4kmsfnw1g7mm9-libc++-3.8.1/include/c++/v1/cmath:310:9: error: no member named 'fpclassify' in the global namespace; did you mean '__fpclassify'?
using ::fpclassify;
      ~~^
/nix/store/50xb5gyw4klzn6vwri1w30d1dv4iyjah-glibc-2.24-dev/include/bits/mathcalls.h:364:20: note: '__fpclassify' declared here
__MATHDECL_1 (int, __fpclassify,, (_Mdouble_ __value))
                   ^
In file included from libs/coroutine/src/posix/stack_traits.cpp:19:
/nix/store/m3azisclqx55zb40lsa4kmsfnw1g7mm9-libc++-3.8.1/include/c++/v1/cmath:311:9: error: no member named 'isfinite' in the global namespace
using ::isfinite;
      ~~^
/nix/store/m3azisclqx55zb40lsa4kmsfnw1g7mm9-libc++-3.8.1/include/c++/v1/cmath:314:9: error: no member named 'isnormal' in the global namespace
using ::isnormal;
      ~~^
/nix/store/m3azisclqx55zb40lsa4kmsfnw1g7mm9-libc++-3.8.1/include/c++/v1/cmath:315:9: error: no member named 'isgreater' in the global namespace
using ::isgreater;
      ~~^
/nix/store/m3azisclqx55zb40lsa4kmsfnw1g7mm9-libc++-3.8.1/include/c++/v1/cmath:316:9: error: no member named 'isgreaterequal' in the global namespace
using ::isgreaterequal;
      ~~^
/nix/store/m3azisclqx55zb40lsa4kmsfnw1g7mm9-libc++-3.8.1/include/c++/v1/cmath:317:9: error: no member named 'isless' in the global namespace
using ::isless;
      ~~^
/nix/store/m3azisclqx55zb40lsa4kmsfnw1g7mm9-libc++-3.8.1/include/c++/v1/cmath:318:9: error: no member named 'islessequal' in the global namespace
using ::islessequal;
      ~~^
/nix/store/m3azisclqx55zb40lsa4kmsfnw1g7mm9-libc++-3.8.1/include/c++/v1/cmath:319:9: error: no member named 'islessgreater' in the global namespace
using ::islessgreater;
      ~~^
/nix/store/m3azisclqx55zb40lsa4kmsfnw1g7mm9-libc++-3.8.1/include/c++/v1/cmath:320:9: error: no member named 'isunordered' in the global namespace
using ::isunordered;
      ~~^
/nix/store/m3azisclqx55zb40lsa4kmsfnw1g7mm9-libc++-3.8.1/include/c++/v1/cmath:321:9: error: no member named 'isunordered' in the global namespace
using ::isunordered;
      ~~^
11 errors generated.

This one works (just added $NIX_CXXSTDLIB_COMPILE) :

[nix-shell:~/tmp/nix_irods/boost_1_60_0]$ "clang++" $NIX_CXXSTDLIB_COMPILE -c -x c++ -O3 -Wno-inline -Wall -pthread -fPIC -m64  -DBOOST_ALL_NO_LIB=1 -DBOOST_CHRONO_DYN_LINK=1 -DBOOST_CONTEXT_DYN_LINK=1 -DBOOST_COROUTINES_DYN_LINK=1 -DBOOST_COROUTINES_SOURCE -DBOOST_DISABLE_ASSERTS -DBOOST_SYSTEM_DYN_LINK=1 -DBOOST_SYSTEM_NO_DEPRECATED -DBOOST_THREAD_BUILD_DLL=1 -DBOOST_THREAD_POSIX -DBOOST_THREAD_USE_DLL=1 -DNDEBUG -I"." -o "bin.v2/libs/coroutine/build/clang-linux-3.8.1/release/threading-multi/posix/stack_traits.o" "libs/coroutine/src/posix/stack_traits.cpp"

[nix-shell:~/tmp/nix_irods/boost_1_60_0]$

It's just the path to the libcxx includes that is missing. Why does it occurs with clang > 3.7 ?

[nix-shell:~/tmp/nix_irods/boost_1_60_0]$ echo $NIX_CXXSTDLIB_COMPILE
-isystem /nix/store/m3azisclqx55zb40lsa4kmsfnw1g7mm9-libc++-3.8.1/include/c++/v1

@copumpkin : thank you for the log, you have warnings that I don't have and vice versa. Unfortunately, your log does not show compilation commands like in my log (I think they are dumped only when errors occurs)

bzizou · 2016-10-25T19:29:15Z

I think that I found something!
I isolated a part of the build to reproduce the problem and I think it has to do with the order of the options.
It looks like clang 3.8 does not act the same way as clang 3.7 regarding the place of the -isystem {libcxx}/include/c++/v1 option

Here is a command issued by the clang wrapper, that fails:

/nix/store/ivxv157mcimqkqyvqkdgmrvz2l18zqjw-clang-3.8.1/bin/clang++ -c -x c++ -O4 -Wno-inline -Wall -pthread -fPIC -m64 -DBOOST_ALL_NO_LIB=1 -DBOOST_CHRONO_DYN_LINK=1 -DBOOST_CONTEXT_DYN_LINK=1 -DBOOST_COROUTINES_DYN_LINK=1 -DBOOST_COROUTINES_SOURCE -DBOOST_DISABLE_ASSERTS -DBOOST_SYSTEM_DYN_LINK=1 -DBOOST_SYSTEM_NO_DEPRECATED -DBOOST_THREAD_BUILD_DLL=1 -DBOOST_THREAD_POSIX -DBOOST_THREAD_USE_DLL=1 -DNDEBUG -I. libs/coroutine/src/posix/stack_traits.cpp -B/nix/store/ivxv157mcimqkqyvqkdgmrvz2l18zqjw-clang-3.8.1/lib -B/nix/store/23vndix3mzcyw84kag06h8fh464g32nq-glibc-2.24/lib/ -idirafter /nix/store/50xb5gyw4klzn6vwri1w30d1dv4iyjah-glibc-2.24-dev/include -idirafter '/nix/store/ivxv157mcimqkqyvqkdgmrvz2l18zqjw-clang-3.8.1/lib/gcc/*/*/include-fixed' -B/nix/store/79rdy3pda2zz8wym9gz6pkrmj5mgv72j-clang-wrapper-3.8.1/bin/ -isystem /nix/store/x16gqmbzj7bfrkd8a7gz2ld4f0k0i5lx-expat-2.2.0-dev/include -isystem /nix/store/mc93jj2wcg0i1kdk54gkcmv80wnj790v-zlib-1.2.8-dev/include -isystem /nix/store/ckninlzl238f017r5alskszpg5jfkf2n-bzip2-1.0.6.0.1-dev/include -isystem /nix/store/50xb5gyw4klzn6vwri1w30d1dv4iyjah-glibc-2.24-dev/include -isystem /nix/store/18ns8aqaglqh7k0fn2cqih8kc29qsryg-python-2.7.12/include -isystem /nix/store/nsf0gr6ns0jqm6a2928c74vz1pshrpbn-icu4c-57.1-dev/include -isystem /nix/store/m3azisclqx55zb40lsa4kmsfnw1g7mm9-libc++-3.8.1/include -isystem /nix/store/gimgjh705p3jlpkccrsxaq3y0n2jbr8l-libc++abi-3.8.1/include -isystem /nix/store/m3azisclqx55zb40lsa4kmsfnw1g7mm9-libc++-3.8.1/include/c++/v1 -O2 -D_FORTIFY_SOURCE=2 -fstack-protector-strong --param ssp-buffer-size=4 -fPIC -fno-strict-overflow -Wformat -Wformat-security -Werror=format-security

If I start the same thing, but with the -isystem flag at the begining, then it works!:

/nix/store/ivxv157mcimqkqyvqkdgmrvz2l18zqjw-clang-3.8.1/bin/clang++ -isystem /nix/store/m3azisclqx55zb40lsa4kmsfnw1g7mm9-libc++-3.8.1/include/c++/v1 -c -x c++ -O4 -Wno-inline -Wall -pthread -fPIC -m64 -DBOOST_ALL_NO_LIB=1 -DBOOST_CHRONO_DYN_LINK=1 -DBOOST_CONTEXT_DYN_LINK=1 -DBOOST_COROUTINES_DYN_LINK=1 -DBOOST_COROUTINES_SOURCE -DBOOST_DISABLE_ASSERTS -DBOOST_SYSTEM_DYN_LINK=1 -DBOOST_SYSTEM_NO_DEPRECATED -DBOOST_THREAD_BUILD_DLL=1 -DBOOST_THREAD_POSIX -DBOOST_THREAD_USE_DLL=1 -DNDEBUG -I. libs/coroutine/src/posix/stack_traits.cpp -B/nix/store/ivxv157mcimqkqyvqkdgmrvz2l18zqjw-clang-3.8.1/lib -B/nix/store/23vndix3mzcyw84kag06h8fh464g32nq-glibc-2.24/lib/ -idirafter /nix/store/50xb5gyw4klzn6vwri1w30d1dv4iyjah-glibc-2.24-dev/include -idirafter '/nix/store/ivxv157mcimqkqyvqkdgmrvz2l18zqjw-clang-3.8.1/lib/gcc/*/*/include-fixed' -B/nix/store/79rdy3pda2zz8wym9gz6pkrmj5mgv72j-clang-wrapper-3.8.1/bin/ -isystem /nix/store/x16gqmbzj7bfrkd8a7gz2ld4f0k0i5lx-expat-2.2.0-dev/include -isystem /nix/store/mc93jj2wcg0i1kdk54gkcmv80wnj790v-zlib-1.2.8-dev/include -isystem /nix/store/ckninlzl238f017r5alskszpg5jfkf2n-bzip2-1.0.6.0.1-dev/include -isystem /nix/store/50xb5gyw4klzn6vwri1w30d1dv4iyjah-glibc-2.24-dev/include -isystem /nix/store/18ns8aqaglqh7k0fn2cqih8kc29qsryg-python-2.7.12/include -isystem /nix/store/nsf0gr6ns0jqm6a2928c74vz1pshrpbn-icu4c-57.1-dev/include -isystem /nix/store/m3azisclqx55zb40lsa4kmsfnw1g7mm9-libc++-3.8.1/include -isystem /nix/store/gimgjh705p3jlpkccrsxaq3y0n2jbr8l-libc++abi-3.8.1/include -isystem /nix/store/m3azisclqx55zb40lsa4kmsfnw1g7mm9-libc++-3.8.1/include/c++/v1 -O2 -D_FORTIFY_SOURCE=2 -fstack-protector-strong --param ssp-buffer-size=4 -fPIC -fno-strict-overflow -Wformat -Wformat-security -Werror=format-security

shlevy · 2016-10-25T19:46:18Z

Ugh that's terrible. @bzizou Can you open up an issue on the llvm tracker with those two command lines?This is almost certainly an llvm bug.

bzizou · 2016-10-26T07:53:34Z

I narrowed the problem and created a little bash script to reproduce the problem outside a specific environment:

#!/usr/bin/env bash
set -x

cd /tmp
cat << EOF > hello.cpp
#include <cmath>
#include <stdio.h>
int main(int argc, char **argv) { printf("hello world\n"); }
EOF

CLANG_37=/nix/store/2ax8111lmn46l3b46vxg94sk92dkya14-clang-3.7.1
CLANG_38=/nix/store/ivxv157mcimqkqyvqkdgmrvz2l18zqjw-clang-3.8.1
LIBCXX_37=/nix/store/wvfsisx6b969z297c3dkb2yikkqxiyfd-libc++-3.7.1
LIBCXX_38=/nix/store/m3azisclqx55zb40lsa4kmsfnw1g7mm9-libc++-3.8.1
GLIBC=/nix/store/23vndix3mzcyw84kag06h8fh464g32nq-glibc-2.24
GLIBC_DEV=/nix/store/50xb5gyw4klzn6vwri1w30d1dv4iyjah-glibc-2.24-dev

# Works:
$CLANG_37/bin/clang++ -B$GLIBC/lib/ -L$GLIBC/lib/ hello.cpp -isystem $GLIBC_DEV/include -isystem $LIBCXX_37/include/c++/v1

# Fails:
$CLANG_38/bin/clang++ -B$GLIBC/lib/ -L$GLIBC/lib/ hello.cpp -isystem $GLIBC_DEV/include -isystem $LIBCXX_38/include/c++/v1

# Works:
$CLANG_38/bin/clang++ -B$GLIBC/lib/ -L$GLIBC/lib/ hello.cpp -isystem $LIBCXX_38/include/c++/v1 -isystem $GLIBC_DEV/include

I'm going to open an issue on llvm tracker...

bzizou · 2016-10-26T08:10:28Z

I'm wondering if it's really an llvm bug... or a feature. Maybe clang_37 didn't respect the order of the include paths declarations and clang_38 now does. It looks logical to load the c++ includes before the glibc ones...

shlevy · 2016-10-26T09:39:17Z

Unless there's a conflicting include in one vs the other, this definitely seems like a bug to me. the isystem doesn't say "load these includes", it says "when looking for includes, look here". If something isn't found in an earlier path, it should just be looked up later.

bzizou · 2016-10-26T09:53:33Z

But it's probably a conflicting include... The error occurs when loading the cmath include:

In file included from hello.cpp:1:
/nix/store/m3azisclqx55zb40lsa4kmsfnw1g7mm9-libc++-3.8.1/include/c++/v1/cmath:309:9: error: no member named 'signbit' in the global namespace; did you mean '__signbit'?
using ::signbit;
      ~~^
/nix/store/50xb5gyw4klzn6vwri1w30d1dv4iyjah-glibc-2.24-dev/include/bits/mathcalls.h:368:20: note: '__signbit' declared here
__MATHDECL_1 (int, __signbit,, (_Mdouble_ __value))
                   ^
In file included from hello.cpp:1:
/nix/store/m3azisclqx55zb40lsa4kmsfnw1g7mm9-libc++-3.8.1/include/c++/v1/cmath:310:9: error: no member named 'fpclassify' in the global namespace; did you mean '__fpclassify'?
using ::fpclassify;
      ~~^
/nix/store/50xb5gyw4klzn6vwri1w30d1dv4iyjah-glibc-2.24-dev/include/bits/mathcalls.h:364:20: note: '__fpclassify' declared here
__MATHDECL_1 (int, __fpclassify,, (_Mdouble_ __value))
                   ^
In file included from hello.cpp:1:
/nix/store/m3azisclqx55zb40lsa4kmsfnw1g7mm9-libc++-3.8.1/include/c++/v1/cmath:311:9: error: no member named 'isfinite' in the global namespace
using ::isfinite;
      ~~^
/nix/store/m3azisclqx55zb40lsa4kmsfnw1g7mm9-libc++-3.8.1/include/c++/v1/cmath:314:9: error: no member named 'isnormal' in the global namespace
using ::isnormal;
      ~~^
/nix/store/m3azisclqx55zb40lsa4kmsfnw1g7mm9-libc++-3.8.1/include/c++/v1/cmath:315:9: error: no member named 'isgreater' in the global namespace
using ::isgreater;
      ~~^
/nix/store/m3azisclqx55zb40lsa4kmsfnw1g7mm9-libc++-3.8.1/include/c++/v1/cmath:316:9: error: no member named 'isgreaterequal' in the global namespace
using ::isgreaterequal;
      ~~^
/nix/store/m3azisclqx55zb40lsa4kmsfnw1g7mm9-libc++-3.8.1/include/c++/v1/cmath:317:9: error: no member named 'isless' in the global namespace
using ::isless;
      ~~^
/nix/store/m3azisclqx55zb40lsa4kmsfnw1g7mm9-libc++-3.8.1/include/c++/v1/cmath:318:9: error: no member named 'islessequal' in the global namespace
using ::islessequal;
      ~~^
/nix/store/m3azisclqx55zb40lsa4kmsfnw1g7mm9-libc++-3.8.1/include/c++/v1/cmath:319:9: error: no member named 'islessgreater' in the global namespace
using ::islessgreater;
      ~~^
/nix/store/m3azisclqx55zb40lsa4kmsfnw1g7mm9-libc++-3.8.1/include/c++/v1/cmath:320:9: error: no member named 'isunordered' in the global namespace
using ::isunordered;
      ~~^
/nix/store/m3azisclqx55zb40lsa4kmsfnw1g7mm9-libc++-3.8.1/include/c++/v1/cmath:321:9: error: no member named 'isunordered' in the global namespace
using ::isunordered;
      ~~^
/nix/store/m3azisclqx55zb40lsa4kmsfnw1g7mm9-libc++-3.8.1/include/c++/v1/cmath:327:9: error: no member named 'abs' in the global namespace; did you mean 'fabs'?
using ::abs;
      ~~^
/nix/store/50xb5gyw4klzn6vwri1w30d1dv4iyjah-glibc-2.24-dev/include/bits/mathcalls.h:181:14: note: 'fabs' declared here
__MATHCALLX (fabs,, (_Mdouble_ __x), (__const__));
             ^
12 errors generated.

I asked an account to fill a bug report on llvm tracker (https://llvm.org/bugs/enter_bug.cgi), but no answer for now...

shlevy · 2016-10-26T10:10:18Z

Amazing, you need manual intervention to post a bug 😮

bzizou · 2016-10-26T10:16:17Z

Well, I think it's a conflict with math.h: cmath calls math.h. With clang 3.7, it probably loads math.h from the same directory as the calling include, so the libcxx version. With 3.8, it loads the math.h that is searched in the order of the command line paths, so it loads the math.h from the glibc...

shlevy · 2016-10-26T10:20:26Z

Hmm, it seems strange that libc++ has its own math.h. I wonder if that's a bug that's gone unnoticed because usually people use libc++ on OS X and maybe their libc just doesn't come with a math.h any more? It definitely doesn't seem right, I'd open the bug for that and see.

bzizou · 2016-10-26T10:25:08Z

But it has... since 3.8!!! Here we are!

bzizou@bart:~/git/irods]$ ls -l /nix/store/m3azisclqx55zb40lsa4kmsfnw1g7mm9-libc++-3.8.1/include/c++/v1/math.h
-r--r--r-- 1 root root 45701 Jan  1  1970 /nix/store/m3azisclqx55zb40lsa4kmsfnw1g7mm9-libc++-3.8.1/include/c++/v1/math.h

[bzizou@bart:~/git/irods]$ ls -l /nix/store/wvfsisx6b969z297c3dkb2yikkqxiyfd-libc++-3.7.1/include/c++/v1/math.h
ls: cannot access '/nix/store/wvfsisx6b969z297c3dkb2yikkqxiyfd-libc++-3.7.1/include/c++/v1/math.h': No such file or directory

bzizou · 2016-10-26T10:35:00Z

llvm-mirror/libcxx@4faa394

shlevy · 2016-10-26T10:42:17Z

Ah! libc++'s math.h has #include_next <math.h>. So it should come first.

bzizou · 2016-10-26T11:39:09Z

OK, then, so there's no bug into llvm... it's normal when we use "-isystem".
This threads explains why: http://stackoverflow.com/questions/37218953/isystem-on-a-system-include-directory-causes-errors
So, I tested replacing -isystem by -I into $NIX_CXXSTDLIB_COMPILE, and guess what... boost compiles like a charm...

shlevy · 2016-10-26T11:48:54Z

isystem is still semantically correct here, we just want to ensure it comes before the glibc headers.

bzizou · 2016-10-26T12:11:29Z

I didn't say that -isystem is not correct.
But in that case, it seems to cause cmath to load the bad math.h header, because of the #include_next that is also probably semantically correct for llvm developpers... But I'm not a C expert...
What do you suggest?

shlevy · 2016-10-26T12:16:38Z

We should ensure libc++'s isystem comes before glibc's. This will probably require a stdenv rebuild as NIX_CXXSTDLIB_COMPILE is handled in the cc wrapper. I'll open the PR and get hydra going.

shlevy · 2016-10-26T12:17:36Z

@copumpkin Any problem with putting NIX_CXXSTDLIB_COMPILE before the rest of the NIX_CFLAGS_COMPILE flags?

copumpkin · 2016-10-26T12:18:37Z

I don't think so. You're going to get a full hydra build of the change before the merge to see if it breaks OSX? If not I can probably test it on my local Mac later.

shlevy · 2016-10-26T12:20:55Z

Wait, I'm confused. @bzizou Where did the isystem ${glibc.dev}/include come from? The cc-wrapper uses idirafter ${libc_dev}/include should should do the right thing here.

shlevy · 2016-10-26T12:21:26Z

Oh, I bet it's the cc wrapper setup hook finding the include dir, hmm.

bzizou · 2016-10-26T12:23:07Z

@shlevy : I got the isystem ${glibc.dev}/include when doing a bash -x on the clang++ wrapper...

shlevy · 2016-10-26T12:23:40Z

Yeah, checking now and working on a fix.

shlevy · 2016-10-26T12:35:06Z

@bzizou Do you have a nixpkgs branch with boost160libcxx38 defined?

bzizou · 2016-10-26T12:38:37Z

@shlevy : no, but it's as simple as:

boost160libcxx38 = callPackage ../development/libraries/boost/1.60.nix { 
    stdenv = llvmPackages_38.libcxxStdenv;                                 
};

bzizou · 2016-10-26T12:43:58Z

actually, I have a branch ;-) https://github.com/bzizou/nixpkgs/tree/irods4.2_libcxx_test

shlevy · 2016-10-26T13:34:47Z

Ah! This is because we have libiconv in buildInputs, which on linux is an alias for glibc. There used to be an easy solution for this, but I signed off on its removal 😮 #6166. The short-term solution is to not include libiconv in build inputs on linux, will open an issue for the long term solution.

bzizou · 2016-10-26T13:54:49Z

For the short term, Is there a way to override this or do we have to modify the boost package?

bzizou · 2016-10-26T13:56:30Z

OK, I found it: libiconv = null;seems to do the job! right?

bzizou · 2016-10-26T13:58:33Z

Well, if I understand, libiconv = null; in the override, the package will not build under Darwin?

shlevy · 2016-10-26T14:00:09Z

@bzizou See the logic where libiconv is set in all-packages.nix globally, you should use the same logic to set it to null or not.

bzizou · 2016-10-26T14:00:50Z

OK, sorry, so it's libiconv if stdenv.isDarwin then libiconv else null; right?

shlevy · 2016-10-26T14:03:25Z

libiconv = if crossSystem != null then
    (if crossSystem.libc == "glibc" then null
      else if crossSystem.libc == "libSystem" then darwin.libiconv
      else libiconvReal)
    else if stdenv.isGlibc then null
    else if stdenv.isDarwin then darwin.libiconv
    else libiconvReal;

bzizou · 2016-10-26T15:10:58Z

Amazing! Very proud to be a NIX contributor! I finally managed to make iRods packages without modifications to boost and avro-c++. Thank you very much @shlevy @copumpkin for your precious help!

copumpkin · 2016-10-26T15:43:25Z

Yeah 3.8 added a bunch of include_next calls that were painful for a while. For me it caused a bunch of pain a while back due to a bug in the cc-wrapper. Not sure if this is similar...

On Oct 26, 2016, at 06:42, Shea Levy notifications@github.com wrote:

Ah! libc++'s math.h has #include_next . So it should come first.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

copumpkin · 2016-10-26T15:46:57Z

There's still the ongoing mystery of why it works on Darwin :) perhaps it's
because we use extraBuildInputs to inject libcxx?
On Wed, Oct 26, 2016 at 07:39 Bruno Bzeznik notifications@github.com
wrote:

OK, then, so there's no bug into llvm... it's normal when we use
"-isystem".
This threads explains why:
http://stackoverflow.com/questions/37218953/isystem-on-a-system-include-directory-causes-errors
So, I tested replacing -isystem by -I into $NIX_CXXSTDLIB_COMPILE, and
guess what... boost compiles like a charm...

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#19859 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAKP8z_ZU0Ke6LVLn8vq-v-vZjecNONks5q3zvhgaJpZM4KgDpl
.

shlevy · 2016-10-26T15:49:10Z

Because libiconv is not glibc on darwin, so glibc is not added to buildinputs, so we get no isystem flag for the libc (we have the idirafter flag hard-coded into the cc wrapper)

copumpkin · 2016-10-26T15:50:04Z

Yeah, sorry for those last two replies. I sent the emails ages ago and they only just showed up. GitHub weirdness.

Add libcxxStdenv attribute to recent llvm package sets

be02229

shlevy merged commit be02229 into NixOS:master Oct 25, 2016

shlevy self-assigned this Oct 26, 2016

shlevy mentioned this pull request Oct 26, 2016

Libiconv in build inputs leads to subtly broken cflags on Linux #19895

Closed

bzizou mentioned this pull request Oct 26, 2016

avro-c++: added support of libcxx with clang #19832

Closed

7 tasks

bzizou mentioned this pull request Oct 28, 2016

Need to package icommands for NIX irods/irods_client_icommands#2

Closed

rrbutani added the 6.topic: llvm/clang Issues related to llvmPackages, clangStdenv and related label May 27, 2024

Add libcxxStdenv attribute to recent llvm package sets #19859

Add libcxxStdenv attribute to recent llvm package sets #19859

Conversation

shlevy commented Oct 25, 2016

shlevy commented Oct 25, 2016

mention-bot commented Oct 25, 2016

shlevy commented Oct 25, 2016

shlevy commented Oct 25, 2016

copumpkin commented Oct 25, 2016

bzizou commented Oct 25, 2016

copumpkin commented Oct 25, 2016

bzizou commented Oct 25, 2016 • edited Loading

bzizou commented Oct 25, 2016

shlevy commented Oct 25, 2016

bzizou commented Oct 26, 2016 • edited Loading

bzizou commented Oct 26, 2016

shlevy commented Oct 26, 2016

bzizou commented Oct 26, 2016

shlevy commented Oct 26, 2016

bzizou commented Oct 26, 2016

shlevy commented Oct 26, 2016

bzizou commented Oct 26, 2016

bzizou commented Oct 26, 2016

shlevy commented Oct 26, 2016

bzizou commented Oct 26, 2016

shlevy commented Oct 26, 2016

bzizou commented Oct 26, 2016

shlevy commented Oct 26, 2016

shlevy commented Oct 26, 2016

copumpkin commented Oct 26, 2016

shlevy commented Oct 26, 2016

shlevy commented Oct 26, 2016

bzizou commented Oct 26, 2016

shlevy commented Oct 26, 2016

shlevy commented Oct 26, 2016

bzizou commented Oct 26, 2016

bzizou commented Oct 26, 2016

shlevy commented Oct 26, 2016

bzizou commented Oct 26, 2016

bzizou commented Oct 26, 2016

bzizou commented Oct 26, 2016

shlevy commented Oct 26, 2016

bzizou commented Oct 26, 2016

shlevy commented Oct 26, 2016

bzizou commented Oct 26, 2016

copumpkin commented Oct 26, 2016

copumpkin commented Oct 26, 2016

shlevy commented Oct 26, 2016

copumpkin commented Oct 26, 2016

bzizou commented Oct 25, 2016 •

edited

Loading

bzizou commented Oct 26, 2016 •

edited

Loading