| 20 Sep 2021 |
 Alyssa Ross | oh no I'm thinking of gobject-introspection | 15:55:22 |
 John Ericson | the other fun one :) | 15:58:34 |
 Rick (Mindavi) | Still waiting on upstream to review the patches... | 16:01:24 |
| Alyssa Ross | libtool is my second least favourite thing to debug after cmake | 16:44:19 |
| Alyssa Ross | if a cmake-based package doesn't cross-compile i usually just give up | 16:44:47 |
| Rick (Mindavi) | CMake doesn't really have a concept for mixed arch compilation | 16:52:30 |
| Rick (Mindavi) | Which is not great :( | 16:52:39 |
 siraben | { nixpkgs ? <nixpkgs>
, pkgs ? (import nixpkgs {}).pkgsCross.arm-embedded
}:
pkgs.callPackage ({ mkShell, gnumake, buildPackages }: mkShell {
depsBuildBuild = [ buildPackages.gcc ];
nativeBuildInputs = [ gnumake ];
}) {}
| 17:11:48 |
| siraben | on macOS I don't seem to see the native gcc in the shell, what am I doing wrong? | 17:12:04 |
| siraben | which gcc returns /usr/bin/gcc which is impure | 17:12:13 |
 symphorien | Try $CC | 17:15:15 |
| symphorien | There is no unorefixed gcc in a cross shell | 17:15:39 |
| siraben | I get the cross-compiler | 17:15:49 |
| symphorien | * There is no unprefixed gcc in a cross shell | 17:15:56 |
| symphorien | Ah sorry I had not paid attention to buildPackages.gcc | 17:16:45 |
| siraben | In reply to @symphorien:xlumurb.eu
There is no unprefixed gcc in a cross shell how can I obtain this? the makefile I'm using implicitly assumes gcc | 17:16:59 |
| siraben | Hm, calling as uses /Users/siraben/.nix-profile/bin/as which is also impure | 17:19:59 |
| symphorien | Well everything that is not shadowed by the shell is impure. Try --pure | 17:23:03 |
| siraben | symphorien: yeah, then those commands don't work anymore | 18:10:12 |
| Rick (Mindavi) | Maybe they're in the env with some variable? | 18:12:02 |
| siraben | Rick (Mindavi): doesn't appear like it, I'm not sure | 19:06:26 |
| siraben | this fixed it | 20:12:20 |
| siraben | { nixpkgs ? <nixpkgs>
, pkgs ? (import nixpkgs {}).pkgsCross.arm-embedded
, hostPkgs ? (import nixpkgs {})
}:
pkgs.callPackage ({ mkShell, gnumake, bintools, buildPackages }: mkShell {
depsBuildBuild = [ gnumake hostPkgs.buildPackages.gcc hostPkgs.bintools ];
}) {}
| 20:12:23 |
| siraben | * { nixpkgs ? <nixpkgs>
, pkgs ? (import nixpkgs {}).pkgsCross.arm-embedded
, hostPkgs ? (import nixpkgs {})
}:
pkgs.callPackage ({ mkShell, gnumake }: mkShell {
depsBuildBuild = [ gnumake hostPkgs.gcc hostPkgs.bintools ];
}) {}
| 20:12:58 |
| siraben | * { nixpkgs ? <nixpkgs>
, pkgs ? (import nixpkgs {}).pkgsCross.arm-embedded
, hostPkgs ? (import nixpkgs {})
}:
pkgs.callPackage ({ mkShell, gnumake }: mkShell {
depsBuildBuild = [ gnumake hostPkgs.gcc ];
}) {}
| 20:13:25 |
| Rick (Mindavi) | Was already wondering about that import, should've expressed that :) | 20:15:17 |
 sterni | siraben: there's a way to do it with your first example (which is much cleaner): use pkgsBuildBuild.gcc and $CC_FOR_BUILD | 22:32:38 |
| Alyssa Ross | Ericson2314: so AIUI, the problem here is that libtool runs the equivalent of ld -v, notices that the compiler is looking in stdenv.cc's lib directory, notices that there's a libstdc++.so there, and so generates a file that hardcodes that path | 23:36:39 |
| Alyssa Ross | this isn't a problem with other libraries, because there are no .so files for it to find | 23:37:08 |
| Alyssa Ross | so it will decide to outsource finding those libraries to the linker | 23:37:27 |
