2021-05-18

<__monty__> Actually, maybe it doesn't. I changed the bootstrap-tools used when building these bootstrap-tools, so it's probably still rebuilding LLVM 11... >.<

2021-05-17

<__monty__> thefloweringash: If I update non-ARM darwin stdenv to LLVM 11 can I drop the finalLLVM_Packages stuff or does it serve a further purpos?

2021-05-16

<__monty__> I'm working on bringing it to LLVM 11.
<{^_^}> https://github.com/NixOS/nixpkgs/pull/85151 (by LnL7, 1 year ago, open): [WIP] llvm 9 update
<thefloweringash> there's been a lot of changes to llvm recently and I've lost track of them. they seem to be heading in the right direction though
<__monty__> thefloweringash: So I've finally managed to run analyse-stdenv. I'm seeing llvm 7.1.0 in stage 3 and stage4. This means it was built using that stage's stdenv, not that that stage required it, right?
<__monty__> Ok, so I've been building bootstrap-tools over and over. Commenting out the allowedRequisites and now setting it to []. And it looks like llvm 7.1.0 doesn't appear until stage4. That means it must be introduced there, right?
<__monty__> qyliss: Can I bounce some observations off of you? Re the LLVM 7 dependency of bootstrap-tools.

2021-04-18

<thefloweringash> __monty__: for example, if you changed the default llvm package set version used by darwin, you also have to inject the bootstrap tools into that version. even if the versions don't match.
<thefloweringash> __monty__: there is definitely some careful cycle breaking in the llvm package set around compiler-rt, libcxx and libcxxabi. in regular darwin it's done via the stdenv bootstrap stages. (cross is a different story)

2021-04-17

<__monty__> Anyone familiar with make-bootstrap-tools.nix. I'm having trouble understanding why changing the LLVM version of the stdenv would change the evaluation of the bootstrap-tools build.

2021-04-07

<__monty__> LnL: Hmm, so I've merged your LLVM bump branch into mine, plan to bump further to LLVM 11. Running into problems with all the bootstrap tools though, like fetchurl and zlib. They use `stdenv.cc` which is set to `/dev/null` in the darwin stdenv stage 0.
<plumm> LnL llvm 12 soon

2021-04-06

<__monty__> Hmm, the error doesn't seem to occurr with clang 10. So I guess bumping LLVM is a good next step.
<LnL> updating llvm would be good anyway, so if that's the issue here it's something that could be done first and integrated separately before the rest
<__monty__> Thanks, I'll look into it a bit more tonight and then look into updating LLVM as a next step tomorrow.
<{^_^}> #85151 (by LnL7, 51 weeks ago, open): [WIP] llvm 9 update
<LnL> FYI for an llvm update, I have a branch that got pretty far along for that

2021-02-04

<{^_^}> #85151 (by LnL7, 42 weeks ago, open): [WIP] llvm 9 update
<LnL> thefloweringash: there's a draft with some of the llvm changes I already worked on

2021-01-09

<clever> does `which $CC` differ from another llvm?
<clever> maybe its still clang7, but a diff llvm behind the scenes?

2020-11-30

<stephank> Might try building llvm using one of the nixpkgs derivations with overrides for the swift branch.
<stephank> Well managed to work around it, but now running into actual issues with the Swift build and its custom LLVM / Clang dependency. It appears it depends on some specific rev between LLVM 9 and 10 and the cmake-generated config.h from the LLVM build tree. So this approach is starting to look like a dead end. :/

2020-11-29

<stephank> Meh, was trying a different approach to Swift. It's essentially a cmake project with a wrapper to combine it with llvm, cmake, etc. So I was trying to build Swift by itself. Made some progress but Swift 5.3 seems to rely on a newer libobjc, 779.1 at least. :/
<LnL> ideally we'd reuse our existing llvm builds, I would assume swift doesn't use forked versions
<stephank> It shouldn't be much different from the regular llvm compiler-rt, but the build is way different. I'm using xcbuild to solve all the autodetection the Swift build system does, and it's probably passing flags down to compiler-rt. I wonder if stuff like TargetConditionals.h is normally resolved to the SDK, but the SDK here is the stub.

2020-11-28

<stephank> Feels like the swift derivation builds a whole lot of llvm / clang as part of it. I don't know much about compiler toolchains, and can only guess it's necessary, but feels super wasteful.

2020-11-10

<thefloweringash> According to my search history I’ve looked up that llvm before, but I don’t remember why. I’ll look into it.
<LnL> I'm a bit confused by that one tho, wouldn't expect any of these changes to influence symbols in llvm since we build that ourselves

2020-10-23

<laduke-132> hiya, I'm just using nix-env to install stuff on my mac, for now, and I'm trying to build something with clang+llvm, and it says to use like -DCMAKE_PREFIX_PATH=/path/to/clang+llvm-xxx, but I don't know where that path would be

2020-09-18

<thefloweringash> so it should be possible, but there's no instructions and I got a bit lost in llvm's build setup

2020-09-16

<thefloweringash> something like stage0: proxy libsystem, stage1: binutils+cctools-port+libtapi, stage2: tbd-libsystem, stage3: libc++, libc++abi, stage4: llvm, clang, etc

2020-08-17

<{^_^}> #87583 (by Gaelan, 14 weeks ago, merged): stdenv-darwin: now with 50% less LLVM!
<LnL> I don't know the exact steps but stage1 or 2 will be build a partial llvm environment and then 4 has a full one
<LnL> it's basically linux specific to build llvm with libstdc++ AFAIK
<thefloweringash> I figured that logic was the solution, and was surprised that macos didn't declare itself as using llvm

2020-08-01

<{^_^}> https://github.com/NixOS/nixpkgs/pull/39743 (by Ralith, 2 years ago, merged): llvm: factor out compiler-rt, fix libstdcxxStdenv sanitizer headers

2020-07-16

<qyliss> Do you think going to LLVM 9 is still the way to go, or could it just go to 10?
<qyliss> I don't have any compelling need for it, fwiw. Just noticed how far behind LLVM was and was looking into why.
<{^_^}> #85151 (by LnL7, 13 weeks ago, open): [WIP] llvm 9 update
<qyliss> LnL: if I wanted to do something to help move the default LLVM update along, would the best thing to do be trying to fix the newly broken packages from https://github.com/NixOS/nixpkgs/pull/85151?

2020-05-22

<manveru> it seems to fail because of a failure to build `compiler-rt`, which seems like an llvm thing

2020-05-07

<plumm> I used to be able to build my project (zig) with brew llvm and clang and etc just fine, but I just switched to nix today and this is the last puzzle piece before a successful build

2020-03-31

<LnL> I'd like to run a test eval for llvm 9

2020-03-29

<mbrgm> ok. so llvm 8 is the newest version in nixpkgs?
<LnL> but if you want a different version of llvm you can do that pretty easily

2020-01-15

<Ericson2314> and Matt got the llvm cross stuff in place

2019-12-16

<LnL> I started looking into switching to llvm 9 by default

2019-06-29

<LnL> it's one version behind the last llvm release which is pretty normal and you can configure your build to use clang8 if you want
<patrol02> My `cc --version` shows `Apple LLVM version 10.0.1 (clang-1001.0.46.4)`, but when build with GHC (installed with Nix) it seems to be using `clang version 7.1.0 (tags/RELEASE_710/final)`. And then it errors out. What would be a way to tell it to use `clang` that is available and not the older version that pops up somehow?

2019-06-09

<symphorien> hello, when trying to build nix-du on travis, it seems nix does not build on darwin because it uses <experimental/optional> which was removed in llvm 7: https://travis-ci.com/symphorien/nix-du/jobs/205969660#L1063

2018-12-16

<scribbler> llvm
<scribbler> dsymutil: soon going away once it goes into LLVM (this one is fake anyway)

2018-09-18

<copumpkin> and then I'm astounded that I did any of the pure darwin stdenv back in the day when I didn't know better and had 3 LLVM+clang rebuilds per bootstrap and each of them took this long

2018-09-17

<copumpkin> LnL: as of LLVM 7, llvm-dsymutil is considered almost entirely equivalent to dsymutil :)

2018-09-16

<copumpkin> anyone notice that SDL2 somehow builds llvm 3.9, then llvm 6, then actually SDL2 on darwin, despite having llvm 5 in the stdenv 🤔

2018-09-13

<LnL> heh, llvm copy pasta

2018-09-11

<LnL> 10.12 and llvm got stuck last night so I had to cancel/restart some stuff :/

2018-09-08

<copumpkin> anyway, another couple of hours to do LLVM+clang and we'll know
<copumpkin> whoa, final stdenv is building now, llvm and so on

2018-09-07

<copumpkin> looks like our bootstrap tools are still on LLVM 5

2018-07-31

<ejpcmac> LnL: In this case the binaries can be different if LLVM has some new optimizations

2018-07-27

<LnL> I'm just going to remove it, people can use llvm-manpages/clang-manpages, and this isn't the first time it caused problems
<johnw> self: super: { llvm = super.llvm.overrideAttrs (attrs: { man = null; }); }
<johnw> i'll have to make an overlay for llvm
<johnw> clang and llvm
<LnL> only llvm?
<LnL> do you have llvm or llvm-manpages in systemPackages?

2018-06-15

<matthewbauer> Maybe there needs to be a definition for LLVM based stuff

2018-03-19

<Sonarpulse> which is what LLVM calls it

2018-03-03

<dtz> llvm 6 hype hype

2018-02-20

<dtz> But hey maybe if we fix all the failures we can kick off an eval with LLVM 6 and everything will work and we can have our cake and eat it too :P
<acowley> Out of curiosity, are there plans in motion regarding moving to a newer clang in the stdenv given the impending LLVM 6?

2018-02-12

<contrapumpkin> although apple uses weird clang+llvm combo source trees so maybe not
<dtz> no, they have some changes --certainly to LLVM and I believe to clang as well

2018-02-09

<acowley> So I just had something a little weird happen: I compiled a program with -fsanitize=address, and the executable came out with a link to /nix/store/***-llvm-4.0.1-lib/lib/libclang_rt.asan_osx_dynamic.dylib which doesn't exist. I used install_name_tool to replace it with llvm-4.0.1/lib/clang/4.0.1/lib/darwin/libclang_rt.asan_osx_dynamic.dylib and the executable worked.

2018-02-07

<LnL> oh btw, we should also get llvm-5 (or 6) in before for 18.03 https://hydra.nixos.org/eval/1430526?filter=&compare=1431608&full=#tabs-now-fail

2018-02-01

<dtz> soon we can all live in {gcc,llvm}x{cross,native}x<platforms> harmony together!
<dtz> speaking of which, cancels weekly rebuild-using-latest-LLVM job to alleviate some build pressure lol
<dtz> okay. My ALLVM fork is a bit old BUT I regularly build all-the-things with LLVM 4, 5, and recently 6 haha so either I've seen it or it's an issue I'll have to solve when I update xD

2018-01-31

<Sonarpulse> dtz: need those LLVM fixes in that commit :D
<mitchty> dhess: i poked around a bit more last night at core files, this weeks fun is learning cmm, stg, and more llvm shenanigans, i did find out this morning that I can get further by not building haddock docs

2018-01-09

<acowley> I think the issue of people needing to juggle multiple simultaneous installations of LLVM is going to become more and more of a thing over the next year

2018-01-08

<the-kenny> so rust forked llvm for some reason. not sure if they got their patches into upstream. Let me check
<LnL> it's not like we only have a single version of llvm
<LnL> wait what, it builds llvm itself?
<pikajude> it builds llvm and then itself