Re: A different way to bootstrap and build GCC

[Rutherther]

Hi Stefan,

> Well, finally my actual goal is to build GCC differently: There is no need to 
> patch in CROSS_C_INCLUDE_PATH etc.  The include paths to standard header 
> files must not be provided through
> environment variables at all.  This is the cause of all the troubles people 
> have with GCC in Guix for both native and cross building.  In the end only 
> the one
> gcc-12-strmov-store-file-names.patch is necessary, and this not even for 
> static builds during bootstrapping.  Keeping (package (inherit …) …) will 
> tear in all the mistakes, which I try
> hard to avoid.

I think it's good idea to move away from C_INCLUDE_PATH,
LIBRARY_PATH for the toolchain libraries (glibc, stdlibc++, ...), but
what about other libraries? Those, as far as I can tell,
have to be provided by a search path, as they cannot be compiled inside
the toolchain. Or am I mistaken in this?

And if this is true, I think it would be good to still keep
this CROSS_* convention that allows at least gcc for base system,
libraries for the base system, along with cross gcc and libraries
for cross target. Of course there will still be problems with multiple
target toolchains, and I am not sure what could be done to resolve that.

Regards,
Rutherther

Blog post: Guix/Hurd on Real Iron

[janneke]

Hello Guix!

Now that the last (!) core-updates branch has been merged, Guix/Hurd on
real iron has become a reality.  It's still experimental and certainly
not for daily use, but exciting for sure!  Read all about it in this new
post:

https://guix.gnu.org/en/blog/2024/hurd-on-thinkpad/

Greetings,
Janneke

-- 
Janneke Nieuwenhuizen   | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com

Re: A different way to bootstrap and build GCC

[Stefan]

Hi Rutherther!


I think it's good idea to move away from C_INCLUDE_PATH,
LIBRARY_PATH for the toolchain libraries (glibc, stdlibc++, ...), but
what about other libraries? Those, as far as I can tell,
have to be provided by a search path, as they cannot be compiled inside
the toolchain. Or am I mistaken in this?


These search paths stay.


And if this is true, I think it would be good to still keep
this CROSS_* convention


For other libraries than the standard ones there will be no real problems, as 
in Guix the build environments only provide the needed packages, so there 
shouldn’t be any problems.

For cross-compilers used by guix build --target=… these CROSS… variables anyway collect the 
same paths, namely /include and /lib.  So whatever the name 
of these variables is, it makes no difference.

I also think that there won’t be many clashes between include files from 
packages for the host and include files from packages used with an embedded 
cross-compiler.  I currently don’t see the real need.  Even if you install 
several compilers into your profile, you certainly won’t install embedded 
source code packages into your profile.  Or do you?  Even on “usual“ 
Filesystem-Hierarchy-Standard systems no cross-compiler uses different 
environment variables for include paths.

But to be honest, I'm not really sure about this for embedded cross-compilers 
yet.  Whatever I did myself so far was all fine without these CROSS… variables. 
 So I’d like to first try without as far as possible.


Bye

Stefan

Re: A different way to bootstrap and build GCC

[Stefan]

Hi Ekaitz!


Very interesting work. I'll read it with more detail tomorrow but at the moment 
it feels very similar to what we did for RISC-V
Is there any obvious difference in the beginning of the chain that I'm missing?


I use tcc-boot0 only to build the latest TCC with the latest musl, with much 
less handcrafting (using make and normal installation). There are less packages 
involved (no need for muls 1.1.24, patch, gzip, xz, flex, bison).

An important difference from my point of view is that I avoid (package (inherit 
…) …).  I believe that the bootstrap packages need to be the independent base.  
For example in commencement.scm gcc-core-mesboot0 (version 2.95.3) inherits 
from gcc (version 11).  So changes to a newer gcc will change the way how to 
build an older version.  This is fragile.  This tears in stuff, which is 
useless or even problematic for the bootstrap.

Well, finally my actual goal is to build GCC differently: There is no need to 
patch in CROSS_C_INCLUDE_PATH etc.  The include paths to standard header files 
must not be provided through environment variables at all.  This is the cause 
of all the troubles people have with GCC in Guix for both native and cross 
building.  In the end only the one gcc-12-strmov-store-file-names.patch is 
necessary, and this not even for static builds during bootstrapping.  Keeping 
(package (inherit …) …) will tear in all the mistakes, which I try hard to 
avoid.


Bye

Stefan

Re: TTY auto-login broken

[Tomas Volf]

Hi,

Christian Miller  writes:

> Hello,
>
> this is how I configured my system:
>
> (modify-services %desktop-services
>   (delete gdm-service-type)
>   (mingetty-service-type config =>
> (mingetty-configuration
>   (inherit config)
>   (auto-login "cm")
>   ;; TODO: Work around to fix "Error in service module"
>   (login-pause? #t
>
> Without the (login-pause? #t) I would get "Error in service module" as
> an error message in my TTY and can't use the system.
>
> There is also someone else with that issue[0]
>
> I asked on the IRC[1] some time ago (somenickname was me in that case)
> and nckx had an assumption why this is happening.
>
> [0]: https://issues.guix.gnu.org/68384
> [1]: https://logs.guix.gnu.org/guix/2023-09-28.log#211350

I just send a two-patch series[0] that allows this to be solved.  If it
is merged, it will allow to do the following:

--8<---cut here---start->8---
(modify-services (operating-system-user-services %basic-os)
  (mingetty-service-type config =>
 (mingetty-configuration
  (inherit config)
  (auto-login "user")
  (shepherd-requirement
   (cons 'dbus-system
 (mingetty-configuration-shepherd-requirement
  config))
--8<---cut here---end--->8---

At least in QEMU it seems to solve the issue.

Have a nice day,
Tomas

0: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=74508

-- 
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.


signature.asc
Description: PGP signature

Re: A different way to bootstrap and build GCC

[Efraim Flashner]

On Sun, Nov 24, 2024 at 12:46:21AM +0100, Ekaitz Zarraga wrote:
> Hi!
> 
> On 2024-11-24 00:20, Stefan wrote:
> > Hi!
> > 
> > I got a step further with the different way to build GCC.  The problem
> > not using the proper multilib variant for embedded systems is solved now
> > and I updated to GCC 14.2.
> > 
> > To cite myself, my gut feeling is that the whole GCC version chain
> > starting in (gnu packages commencement) should be build this way.  So I
> > started to play around with the bootstrapping of GCC.
> > 
> > Starting with only few packages from (gnu packages commencement) I so
> > far managed to build a static GCC 10.4.0 using a static musl 1.2.5.
> > 
> > The initial packages I reuse are:
> > 
> > %bootstrap-guile
> > gash-boot
> > bootar
> > gash-utils-boot
> > tcc-boot0
> > gnu-make-mesboot0
> > gmp-boot
> > mpfr-boot
> > mpc-boot
> > 
> > 
> > Using only these I build a recent TCC from 2024-08-20 with Mes from
> > tcc-boot0 as C library, and then MUSL 1.2.5. Then (only) three
> > iterations of TCC with musl are needed to get a stable TCC with working
> > floating point support.
> > 
> > The chain continues with GNU Make 4.4.1, Binutils 2.42, Findutils
> > 4.10.0, GCC 4.6.4 with gmp-boot, mpfr-boot, mpc-boot (the version with
> > the RISC-V patches may just work), M4 1.4.19, GMP 6.3.0, MPFR 4.2.1, MPC
> > 1.3.1, GCC 10.4.0.
> > 
> > These are all static builds so far.  I'm using latest versions of all
> > packages, except Binutils, whose version 2.43 does not link the object
> > files from TCC.  I avoid to use --build=i686-unknown-linux-gnu to make
> > it possible to build for other architectures as well.
> > 
> > I think the next step should be GCC 14, then glibc with shared library
> > support and GCC 14 again.
> > 
> > I need several small patches to work around shortcomings in Mes, gash,
> > gash-utils, missing functionality of version 3.8.0 of gnu-make-mesboot0
> > (version 3.81 would have it), bugs in TCC.  They are all described in
> > the comments.  Maybe gash and gash-utils could be improved in future.
> > The most annoying thing is that only one core can be used for the
> > builds, otherwise they hang.  I guess it is related to gash in
> > combination with %bootstrap-guile, at least using Make 4.4.1 makes no
> > difference.
> > 
> > I published a git repository at
> > .  Unfortunately it's not
> > a proper channel yet.  If someone likes to give that bootstrap path a
> > try, use this command:
> > 
> > guix build --cores=1 -L  GCC-10-bootstrap
> > 
> > The working GCCs can be build with
> > 
> > guix build -L  GCC GCC-cross-picolibc-arm-none-eabi,
> > GCC-cross-newlib-arm-none-eabi
> > 
> > There are GCC…-toolchain package as well, which propagate ld and all the
> > other tools from Binutils.  But if these tools are only used indirectly
> > through the gcc or g++ drivers, these GCC…-toolchain packages are not
> > needed at all, as the GCC packages are standalone.  There are also
> > GCC…-c-toolchain variables for use with package-with-c-toolchain.  There
> > is no separate libstdc++ package yet, the library is just part of GCC.
> > A separate package will only be needed for Clang or other compilers
> > (maybe Zig), but I'm not sure yet, if clang actually needs a dependency
> > to GCC.
> > 
> > I hope this will be useful, maybe it can help the RISC-V bootstrap
> > effort.  I'm open for suggestions how to proceed from here.
> > 
> > 
> > Bye
> > 
> > Stefan
> 
> 
> Very interesting work. I'll read it with more detail tomorrow but at the
> moment it feels very similar to what we did for RISC-V (which is more or
> less what live-bootstrap does):
> 
> https://github.com/ekaitz-zarraga/commencement.scm
> 
> Is there any obvious difference in the beginning of the chain that I'm
> missing?
> 
> We also agreed in the RISC-V port that using musl makes everything easier,
> mostly because of the RISC-V support is a complicated in glibc+gcc couples,
> but also because Musl is very easy to compile (and also read and patch, when
> needed).
> 
> We also went straight for a modern GCC and left many other packages in the
> way.
> 
> Efraim is working adapt that into Guix so he probably would have more to say
> about it.
> 
> Interesting work, thanks for sharing!

Indeed, thank you very much!

In terms of integrating the riscv64 bootstrap work I had gotten stuck
building gcc-7 using Ekaitz's gcc-4.6.4 with riscv64 support patched in.

In terms of what I've seen so far from your repo and reading your email
I would suggest just trying to bump make from 3.80 to 3.82, it Just
Worked™ for me, even on riscv64.

Also I had been using musl-1.1.24 as an intermediate step, but with some
of your code I currently have 1.2.5 built and am testing that out.

I'd also recommend checking out the wip-riscv-bootstrap branch on
savannah https://git.savannah.gnu.org/cgit/guix.git/log/?h=wip-riscv-bootstrap
or one of my mirrors https://git.sr.ht/~efraim/guix/tree/wip-riscv-boot

Re: A different way to bootstrap and build GCC

[Stefan]

Hi Efraim!


In terms of what I've seen so far from your repo and reading your email
I would suggest just trying to bump make from 3.80 to 3.82, it Just
Worked™ for me, even on riscv64.


Yes, you are right, I should drop the use of gnu-make-mesboot0.  This would 
allow me to drop four substitutions in the TCC package.  In the original 
commencement.scm it is anyway bound to i686-unknown-linux-gnu, which I want to 
avoid.  I think I should try version 4.4.1, which I build with the latest TCC 
anyway.


Also I had been using musl-1.1.24 as an intermediate step, but with some
of your code I currently have 1.2.5 built and am testing that out.


Nice!


For example I ended up rewriting the musl install phase.


Ah, I know about the trouble.  I patch the install script a bit.  Look for “;; 
Gash does not support getopts, replace its use.”  With that patch the default 
install phase of musl is working just fine.  Maybe I should try to send that 
patch upstream.


Bye

Stefan

Re: A different way to bootstrap and build GCC

[Ekaitz Zarraga]

On 2024-11-24 13:02, Stefan wrote:

Hi Ekaitz!

Very interesting work. I'll read it with more detail tomorrow but at 
the moment it feels very similar to what we did for RISC-V
Is there any obvious difference in the beginning of the chain that I'm 
missing?


I use tcc-boot0 only to build the latest TCC with the latest musl, with 
much less handcrafting (using make and normal installation). There are 
less packages involved (no need for muls 1.1.24, patch, gzip, xz, flex, 
bison).


I'll check in detail why we need those, but some are for the later GCC 
build.


An important difference from my point of view is that I avoid (package 
(inherit …) …).  I believe that the bootstrap packages need to be the 
independent base.  For example in commencement.scm gcc-core-mesboot0 
(version 2.95.3) inherits from gcc (version 11).  So changes to a newer 
gcc will change the way how to build an older version.  This is 
fragile.  This tears in stuff, which is useless or even problematic for 
the bootstrap.


Oh yes! I strongly agree with this. Our GCC's are too complex and that 
gave us a lot of trouble. It's really hard to know where things are 
coming from.


It's very fragile, indeed.

Well, finally my actual goal is to build GCC differently: There is no 
need to patch in CROSS_C_INCLUDE_PATH etc.  The include paths to 
standard header files must not be provided through environment variables 
at all.  This is the cause of all the troubles people have with GCC in 
Guix for both native and cross building.  In the end only the one 
gcc-12-strmov-store-file-names.patch is necessary, and this not even for 
static builds during bootstrapping.  Keeping (package (inherit …) …) 
will tear in all the mistakes, which I try hard to avoid.


Yes. Very interesting. We can try to make something on this line.



Bye

Stefan



Thanks for the explanation.

Ekaitz