IRC channel logs

<fossy>gah, that was a nasty one

<fossy>a couple of files in gcc 10.4 have to be compiled with a particular long double length using mlong-double-XX but gcc 4.7 doesn't support a long double length of 80

<fossy>(which is what is required, the code doesn't compile properly without it)

<fossy>luckily the backport wasn't too painful

<muurkha>huh, I thought long double on i386 had been 80 since... the 8087

<muurkha>80 its

<muurkha>*bits

<fossy>i thought the same, apparently that's the most common, but not standardized

<fossy>On x86, the "long double" type is platforma specific, which may be the

<fossy>same as double or __float128.

<fossy>according to the commit message introducing the use of mlong-double-80

<muurkha>I mean, the floating-point registers on the 8087, the 80387, and the integrated FPU in the 80486DX, the 80487SX, the Pentium, and the PPro were all 80 bits long. Only.

<fossy>i'm not sure this makes any sense now that i think about it again

<muurkha>I think the Pentium II was the first hardware in the line to support a non-80-bit floating-point format?

<muurkha>And nowadays the vector instructions from the PII or PIII are the normal way to do floating point.

<nektro>.longdouble entries here https://github.com/ziglang/zig/blob/master/src/type.zig#L6710

<fossy>actually, this offending invocation of mlong-double is platform independent, which explains the explicit 80

<fossy>(architecture-independent also)

<fossy>doesn't explain the build failure though, probably some strange gcc internals

<nektro>linux switch here https://github.com/ziglang/zig/blob/master/src/type.zig#L6787

<muurkha>I feel like you *could* add floating-point support for the i386 without having an in-memory data type for the processor's floating point register size, but it seems like it would be a bad thing to do

<stikonas>fossy: so the trick to run python from random directory was to fix symlink

<stikonas>there is an absolute symlink in /usr/lib/python3.11/lib-dynload -> /usr/lib/musl/python3.11/lib-dynload

<stikonas>that can actually be done even in src_install()

<stikonas>fossy: if you have build failure with GCC 10, maybe we should go with earlier versions, e.g. GCC 4 -> GCC 9 -> GCC 12

<fossy>stikonas[m]: yes, i will if i reach something too painful to be fixed

<fossy>ah, interesting

<fossy>fixing up all these little GCC things is actually rather fun now that i'm out of build system land

<fossy>i wish gcc 10.x was still accepting patches... all of these are upstreamable

<fossy>(since most of them are backports from 12.x)

<fossy>(and a few are compatibility fixes)

<stikonas>well, they only accept regressions for GCC 10

<fossy>do they even that now that 10.4 is released? i thought .4 was end of cycle

<fossy>stikonas: hrm, i just realised since musl 1.2.3 we require explicit LDFLAGS="-static", which isn't too problematic, so far...

<fossy>but need to keep it in mind

<stikonas>yes, I know that

<stikonas>that's why I later moved musl after autogen

<stikonas>for some time it was the last package buitt

<stikonas>fossy: are you building static gcc then?

<fossy>stikonas: yes, that is the plan

<stikonas>I think some stuff have problems with LDFLAGS="-static", possibly autogen but hopefully newer software that we build now would be fine

<fossy>i should hope so, static linking is not all that incredibly uncommon, especially in the embedded world

<oriansj>mihi: well there are sanity checks in M1 from when bugs have occurred in the past; sometimes when the code changes and fixes the problem in other ways, the old checks remain. So there are certainly clean up and optimizations that can be done

<stikonas>fossy: one thing that I missed in python review

<stikonas>(that I only thought of now)

<stikonas>when doing ln -s in src_install, it's worth adding --relative

<stikonas>(also as a general note, we should probably be using more long options in scripting)

<rickmasters>I have a follow up from my update yesterday on the kernel bootstrapping.

<rickmasters>I've resolved a couple problems, one with creating the ext2 ram drive and the other with booting Fiwix.

<rickmasters>Unfortunately, I had to add this qemu option to boot Fiwix: -machine kernel-irqchip=split

<rickmasters>Apparently there is some problem with the irq chip emulation when kvm is enabled.

<rickmasters>I don't like adding workarounds that I don't understand and shouldn't need, but for now I'm able to move on with that option.

<rickmasters>Fiwix can now boot with kvm enabled and it can run programs off the ext2 ram drive.

<rickmasters>Next I need to populate the ext2 for a Linux build and after that implement kexec of Linux from Fiwix.

<rickmasters>And I'll probably get started on live-bootstrap integration soon as that may require some exploration.

<doras>Regarding the Python leftovers, we have the following cleanup code in fd-sdk: https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/blob/master/elements/components/python3.bst#L38-58

<doras>It removes the installed tests and a bunch of other files that should have never been installed

<doras>It seems that Python is not implementing a sane "make install" and one has to clean up after it.

<stikonas>doras: do you want to upstream it?

<stikonas>(to live-bootstrap, not to python)

<doras>stikonas @stikonas:libera.chat: this is actually from our runtime, so not specifically related to live-bootstrap and our seed repo. Though I assume something similar could work for live-bootstrap.

<doras>I can test to see if it's enough, though I expect we may need different logic for different Python versions.

<stikonas>well, we can start with the last one

<stikonas>cleanup of the earlier ones might be better done by implementing package upgrade that removes the old package

IRC channel logs

2023-01-25.log