*** mx08 <mx08!~mx08@user/mx08> has quit IRC | 01:07 | |
*** mx08 <mx08!~mx08@user/mx08> has joined #libre-soc | 01:08 | |
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 01:25 | |
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 01:29 | |
*** Ritish <Ritish!~Ritish@202.131.158.114> has joined #libre-soc | 03:29 | |
Ritish | Happy New Year everyone <3 | 04:16 |
---|---|---|
*** Ritish <Ritish!~Ritish@202.131.158.114> has quit IRC | 04:48 | |
*** Ritish <Ritish!~Ritish@202.131.158.114> has joined #libre-soc | 05:41 | |
*** Ritish <Ritish!~Ritish@202.131.158.114> has quit IRC | 05:47 | |
*** Ritish <Ritish!~Ritish@202.131.158.114> has joined #libre-soc | 05:52 | |
*** Ritish <Ritish!~Ritish@202.131.158.114> has quit IRC | 06:07 | |
*** Ritish <Ritish!~Ritish@202.131.158.114> has joined #libre-soc | 06:50 | |
*** Ritish <Ritish!~Ritish@202.131.158.114> has quit IRC | 06:51 | |
sadoon[m] | Happy new year | 14:09 |
lkcl | happy new year Ritish, sadoon[m] | 14:53 |
lkcl | sadoon[m], when you did the compile of debian for ppc64lesffs what options did you use? i have "-mno-vsx -mno-altivec" and am thinking that's probably all that's needed? | 15:12 |
sadoon[m] | I haven't done that yet | 15:24 |
lkcl | ah ok :) | 15:24 |
sadoon[m] | I've only done ppc and ppc64 so far and only a set of packages | 15:24 |
sadoon[m] | I'm a little worried about adding flags to debian build systems | 15:25 |
sadoon[m] | As in, I'm worried how it can be universally done | 15:25 |
lkcl | my understanding is it's best to define a new triplet | 15:25 |
lkcl | then define a new machine | 15:25 |
sadoon[m] | Ah good thinking | 15:25 |
lkcl | then compile a version of gcc specifically containing that name | 15:26 |
lkcl | in this case | 15:26 |
lkcl | powerpc64lesffs-linux-gnu-gcc | 15:26 |
sadoon[m] | Much more tedious than something like arch or better yet gentoo, but I'll do it when I reach that point | 15:26 |
lkcl | gentoo is specifically optimised to allow users to change options easily and perform a full rebuild | 15:27 |
sadoon[m] | Unfortunately I somehow lost the disk image containing the debian sid packages but I still have the repo clone so I can remake it | 15:27 |
lkcl | debian is specifically designed to allow *debian developers* to reproduce builds in a stable way | 15:28 |
sadoon[m] | lkcl: Huge plus for a project like us but unfortunately they don't have a stable set of packages with security updates like debian :( | 15:28 |
lkcl | they don't have the resources/people | 15:28 |
* lkcl currently trying to get xchacha20 to run under ISACaller | 15:30 | |
sadoon[m] | My custom script does a full rebuild of a chosen deb-src repo which is useful, but that's it | 15:30 |
lkcl | (which only supports sffs) | 15:30 |
lkcl | the other thing that's a strict hard rule in debian is that builds must be done entirely on native hardware | 15:31 |
lkcl | because the problems that result on cross-compiling are subtle and an absolute sod to track down | 15:32 |
lkcl | gentoo/arch's attitude: "if you cross-compile, it's your problem" | 15:32 |
lkcl | (again, not enough resources) | 15:32 |
lkcl | whereas debian devs, having run into serious problems with cross-compiling, just put their foot down and said "no" | 15:33 |
lkcl | which helps explain why there's zero cross-compile support for debian: *nobody* does it. or, correction: wookey used to maintain a minimal cross-compiled debian set of repos | 15:34 |
lkcl | similar to openwrt, some systems are so small they're literally incapable of native compiles. | 15:35 |
lkcl | emdebian. that was it. | 15:35 |
lkcl | https://en.wikipedia.org/wiki/Emdebian_Grip | 15:35 |
lkcl | "The main reasons stated as the cause for ending the project were a lack of embedded devices that do not provide support for expandable storage, and too much work involved with preparing the updates and releasing new versions." | 15:36 |
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 16:48 | |
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 17:03 | |
sadoon[m] | Is it really cross compilation when you disable a feature on the ISA? | 17:08 |
sadoon[m] | This is literally what they do for x86, they build for v1 or v2 and that leaves out many ISA additions since then | 17:08 |
sadoon[m] | Talos systems are fully capable of running and natively compiling that code too | 17:09 |
sadoon[m] | In the least there should be a universal on/off switch for compiler options | 17:10 |
sadoon[m] | Gentoo does that well, Arch too to a lesser extent | 17:10 |
sadoon[m] | It would make their lives easier yoo | 17:10 |
sadoon[m] | Too* | 17:11 |
sadoon[m] | I also could never find a way to point the sbuild to a local repo unless I manually inject it to the chroot | 17:12 |
sadoon[m] | Meaning without some hackery you have to download every single dependency while building each package again and again | 17:12 |
sadoon[m] | That is why I mirrored the repo and did some really hacky stuff to help out | 17:13 |
sadoon[m] | I copy all the chroots to a tmpfs and I mount the repo inside them too just to avoid this | 17:13 |
sadoon[m] | If gentoo had a stable release as well as the widespread compatibility with many projects I would leave debian without turning back | 17:14 |
programmerjake | lkcl: you might want to use Mem.log_fancy rather than Mem.dump(asciidump=True) since it tries to match hexdump -C (or whatever the hd alias is on debian), it can do 16-byte lines (adjustable with log2_line_size=...) | 17:18 |
programmerjake | <sadoon[m]> "Is it really cross compilation..." <- imho if it's a feature that's enabled by default, disabling it by default does require a different triple, different triple means cross compilation | 17:20 |
sadoon[m] | Technically a different triple is not needed | 17:21 |
sadoon[m] | Just a compiler option | 17:21 |
sadoon[m] | Then again | 17:22 |
sadoon[m] | Even if the triple is needed | 17:22 |
sadoon[m] | The hardware is capable of running such software | 17:22 |
sadoon[m] | And we can natively compile | 17:22 |
programmerjake | but it's not ABI compatible with existing libraries or ld.so, so imho it just works by accident. | 17:23 |
programmerjake | though running in a chroot would be fine | 17:23 |
programmerjake | since you can have then have a different ld.so and stuff | 17:24 |
sadoon[m] | The same can be said of any of the Debian ports | 17:24 |
sadoon[m] | They start by cross compilation | 17:24 |
sadoon[m] | And then they continue to build natively | 17:24 |
programmerjake | what i meant is it has to be treated as cross-compiling to work correctly, since disabling default features that affect ABI makes it incompatible with libraries with those features enabled... | 17:26 |
sadoon[m] | Those libraries have to be rebuilt too ;) | 17:27 |
programmerjake | well, gtg, leaving for belated christmas party...ttyl | 17:28 |
sadoon[m] | Enjoy! | 17:28 |
programmerjake | thx! | 17:28 |
lkcl | sadoon[m], except that you're not allowed (in debian) to give any options, everything has to "appear to be native". | 18:24 |
lkcl | therefore, when running "/usr/bin/gcc" its options *must* "do-the-right-thing(tm)" | 18:24 |
lkcl | i mean | 18:25 |
lkcl | once everything is cross-compiled (including /usr/bin/gcc) and once everything is running [under qemu-with-vsx-disabled] | 18:25 |
lkcl | if you run "/usr/bin/gcc -dumpmachine" it should say "powerpc64elsffs-linux-gnu" | 18:26 |
lkcl | and if you run "/usr/bin/gcc -dumpspecs" it should say a whole stack of stuff | 18:27 |
lkcl | which includes | 18:27 |
lkcl | *asm_cpu: | 18:27 |
lkcl | mcpu=ppcsffs: -mppcsffs | 18:29 |
lkcl | -mcpu=ppcsffs: -mno-vsx -mno-altivec | 18:29 |
lkcl | *asm_default: | 18:29 |
lkcl | -mppcsffs%{!m32:64} | 18:29 |
lkcl | something like that. almost the same as -mpower4 | 18:31 |
lkcl | also the default ld.so will have to be compiled with -mno-vsx -mno-altivec | 18:32 |
lkcl | and the machine/spec "detected" and "-DHAS_VSX" disabled during detection | 18:33 |
lkcl | which is where it gets hairy because IBM programmers continue to submit "#ifdef POWER9" in direct violation of programming practices | 18:34 |
lkcl | > "disabling default features that affect ABI makes it incompatible with libraries with those features enabled..." | 18:36 |
lkcl | yyep, that's the whole point of the exercise. | 18:36 |
lkcl | to do precisely and exactly that. | 18:36 |
lkcl | once the dust settles from "downgrading" [basically to EABI 1.5] then the dynamic feature detection which was present for years [and foolishly removed] can be added back in | 18:38 |
*** choozy <choozy!~choozy@75-63-174-82.ftth.glasoperator.nl> has joined #libre-soc | 19:46 | |
*** choozy <choozy!~choozy@75-63-174-82.ftth.glasoperator.nl> has quit IRC | 20:27 | |
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 21:39 | |
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 22:06 | |
lkcl | gaah fiinally got xchacha20.c to work (no svp64 - just ppc64lesffs) | 23:35 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!