Change:
NIX_CFLAGS_COMPILE = lib.optionals stdenv.isDarwin [ "-fno-common" ] ++ lib.optionals enableOpenCL [ "-UPIPE_SEARCH_DIR" "-DPIPE_SEARCH_DIR="${placeholder "opencl"}/lib/gallium-pipe"" <del> # Work around regression from https://github.com/NixOS/nixpkgs/pull/210004 # TODO(trofi): remove "--sysroot=/" </del> ]; passthru = {

Discussion:
llvm-tblgen can not find Confirmed that g++/clang++ can generate correct minimal C++ binary (with libstdc++), but recently llvm-tblgen breaks. Steps to reproduce the behavior: recent nixpkgs/nixos-unstable the llvm-project LLVM Revision: Flags: Compile LLVM successfully as before Please run and paste the result.
According to some of my local tests, is important to reproduce. BFD linker gives me other warnings:
CC
Reduced repro:
Working fine with following shell.
Confirmed that this regression was introduced between and
I made a nix flake that reproduces this problem:
CC maintainers:
Does branch work for you? Chances are it is fixed by
Happy to test whether the current staging-next branch nixpkgs would solve the issue. However, after I switch to staging-next, lld14 and clang14 need to compile a lot of packages when I tried to enter shell. Is there any way to speed up the compilation? The solutions I think of are: increase the number of parallel compilations? , looking for binaryCache for staging-next? compiles the required dependencies almost sequentially, and a lot of time is spent on "configuring xx, checking for xxx" on a single core. Is there any way to increase the scale of parallelism? (I've set big-parallel option).
should increase job parallelism. should increase build parallelism within a job. If you want to build less you can sync to latest commit hydra already built for . For looks like is reasonably complete.
Thanks! Confirmed that the problem has been solved in .

Steps to reproduce the behavior: to build from source Please run and paste the result.
cc maintainers
Can you check if is working? Looks very close to the regression fixed in (did not get to yet).
is there a cache for that branch? using with that started building the world
does have an incomplete cache. If you are accessing at inopportunate time you might catch a few rebuilds. You can pick a specific commit from with most builds done. Most recent it yesterday's
that commit did not fix the issue
edit: scratch that, tried a fresh build. works now
Closing since it sounds like this was fixed by the merge of . Happy to reopen if I'm mistaken.

Hi, I created a minimal demonstrator for my problem: (not main branch but , to also build with nixos 22.11) This minimal C++ app includes and links against opencv4. Building this flake using works just fine and the resulting app works. Running and then doing results in link errors: With nixpkgs on 22.11, both nix build and nix develop work. Steps to reproduce the behavior: out reproducer repo , works nix shell using and run: , get mentioned error messages flake input to nixpkgs 22.11 step 1 & 2 and see that they work I would expect to not get these linker errors after upgrading to nixpkgs master If applicable, add screenshots to help explain your problem. Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result.
Hi :wave: Could you try building your flake with nixpkgs from the staging branch ? There are some changes that I've made to this package which are not yet merged into master , maybe it'll help. Also, I'm not very knowledgeable how c++ linking/compiling works, but from the look of this error messages it seems that dependencies of opencv - such as openmp, gstreamer, opencl, etc are missing from the environment. What if you add them explicitly, probably through opencv4.buildInputs ? P. S. Maintainers listed for this package seems to be not active anymore (they've never responded me from the last october till today)
I just finished bisecting nixpkgs: The commit breaks it for me. do you have any insights on that? I am trying staging now following your suggestion and will report back.
With dynamic linking, this should never be necessary. If it works with explicit linking against these deps, I would still consider this a bug.
Yeah, my apologies for the breakage. That change was reverted for a very similar reason in and is in now. Can you try that one instead? That hopefully should not be too many rebuilds on you.
Oh yes, thank you for pointing me to that, I try that branch.
It's already all in the binary cache, so that was quick. This resolved my problem, thank you!