| 14 Jan 2024 |
samueldr | and I had to deal with it, but it wasn't that much of a deal, since I had their SDK to ape | 21:47:31 |
samueldr | for PROG in ''${PROGS[@]}; do
ln -sf ${binutils}/bin/i386-unknown-gnu-$PROG $PROG
done
| 21:47:40 |
samueldr | stuff like that I think you meant? | 21:47:48 |
samueldr | oh, and for the new folks reading today: there is no stakes here... I'm doing it for the fun of deepening my understanding of non-trivial cross | 21:48:19 |
trofi | Yeah, and lib paths like
+if tc_version_is_at_least 3.4.0 ; then
+ LIBPATH=${TOOLCHAIN_LIBPATH:-${PREFIX}/lib/gcc/${CTARGET}/${GCC_CONFIG_VER}}
+else
+ LIBPATH=${TOOLCHAIN_LIBPATH:-${PREFIX}/lib/gcc-lib/${CTARGET}/${GCC_CONFIG_VER}}
+fi
| 21:50:28 |
samueldr | * cd lib/gcc-lib/i386-unknown-gnu/$version
# ...
for PROG in ''${PROGS[@]}; do
ln -sf ${binutils}/bin/i386-unknown-gnu-$PROG $PROG
done
| 21:50:53 |
samueldr | * cd $out/lib/gcc-lib/i386-unknown-gnu/$version
# ...
for PROG in ''${PROGS[@]}; do
ln -sf ${binutils}/bin/i386-unknown-gnu-$PROG $PROG
done
| 21:51:04 |
samueldr | yeah, added some context | 21:51:12 |
samueldr | knowing that might have allowed me to try a newer gcc in the "non-nixpkgs" setup... still might allow | 21:51:42 |
samueldr | though I have good enough hints to know that newer gcc should also just work | 21:51:59 |
samueldr | https://github.com/samueldr/nixpkgs/commits/wip/brightv-cross | 22:31:53 |
samueldr | just finished looking/trying/packaging | 22:32:11 |
samueldr | last commit (empty) has the error in its message | 22:32:32 |
samueldr | which was where I was at, approximately, when trying stuff out yesterday | 22:32:45 |
samueldr | (though I don't remember if I hit that within Nixpkgs, or while trying to hapazardly update the non-nixpkgs-cross gcc) | 22:33:59 |
samueldr | I'm not discounting that it could be the libc exposing its headers / libraries wrong, what I needed to check next is the probably causes of the failures for this check, which initial search yesterday implied could be building a program and not just running cpp? | 22:34:42 |
samueldr | the sdk bits here is missing some bits, which are in the os-dependent part of the SDK | 22:36:12 |
trofi | I think old autoconf always used /lib/cpp. For local vanilla gcc shell I locally use the following hack:
# Add /lib/cpp symlink. Used by profiledbootstrap.
# Can be removed once gcc rebases against autoconf with
# b560f0a657 "AC_PROG_*CPP: Try ‘cpp’ before ‘/lib/cpp’" fix
# which is in 2.70 and later.
(pkgs.runCommand "mk-lib-cpp" {} ''
mkdir -p $out/lib
ln -s ${stdenv.cc}/bin/cpp $out/lib/
'')
| 22:36:12 |
samueldr | that's against gcc 12 and Nixpkgs | 22:37:21 |
samueldr | at the very least, the common parts are missing the specs file describing (AFAIUI) the proper way to link to their crt* bits | 22:38:53 |
trofi | Yeah, nixpkgs breaks quite a few rules when it builds early libgcc. It tries to pull libc's headers and attemts at linking shared library even in the absence of libc. | 22:39:09 |
raitobezarius | I'm trying to build your stuff | 22:49:32 |
raitobezarius | Alas, I will leave it to trofi for this part, because I'm not really proficient in GCC in nixpkgs | 22:51:02 |
raitobezarius | Only LLVM tbh | 22:51:04 |
trofi | I'm building it as well :) | 22:51:15 |
raitobezarius | (but I'm interested into following and trying and learning about it more :)) | 22:51:15 |
samueldr | it might be the structure of the libc package that is at fault here | 22:51:28 |
samueldr | handling some other misc. stuff at the moment, but I'll try a few things to hopefully fix that | 22:52:06 |
trofi | Yeah, looks like in-place gcc... -E -traditional-cpp fails with conftest.c:13:2: fatal error: assert.h: No such file or directory before it falls back to /lib/cpp. Try to add an assert.h into a root folder. | 23:02:23 |
trofi | * Yeah, looks like in-place gcc... -E -traditional-cpp fails with conftest.c:13:2: fatal error: assert.h: No such file or directory before it falls back to /lib/cpp. Try to add an assert.h into a root folder of your libc headers. | 23:02:41 |