| Message ID | 20230428174524.1006324-1-mikpelinux@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | add glibc-stdint.h to vax and lm32 linux target (PR target/105525) | expand |
On 4/28/23 11:45, Mikael Pettersson via Gcc-patches wrote: > PR target/105525 is a build regression for the vax and lm32 linux > targets present in gcc-12/13/head, where the builds fail due to > unsatisfied references to __INTPTR_TYPE__ and __UINTPTR_TYPE__, > caused by these two targets failing to provide glibc-stdint.h. > > Fixed thusly, tested by building crosses, which now succeeds. > > Ok for trunk? (Note I don't have commit rights.) > > 2023-04-28 Mikael Pettersson<mikpelinux@gmail.com> > > PR target/105525 > * config.gcc (vax-*-linux*): Add glibc-stdint.h. > (lm32-*-uclinux*): Likewise. Thanks. I've pushed this to the trunk. jeff
On Sat, 29 Apr 2023, Jeff Law via Gcc-patches wrote: > > PR target/105525 is a build regression for the vax and lm32 linux > > targets present in gcc-12/13/head, where the builds fail due to > > unsatisfied references to __INTPTR_TYPE__ and __UINTPTR_TYPE__, > > caused by these two targets failing to provide glibc-stdint.h. > > > > Fixed thusly, tested by building crosses, which now succeeds. > > > > Ok for trunk? (Note I don't have commit rights.) > > > > 2023-04-28 Mikael Pettersson<mikpelinux@gmail.com> > > > > PR target/105525 > > * config.gcc (vax-*-linux*): Add glibc-stdint.h. > > (lm32-*-uclinux*): Likewise. > Thanks. I've pushed this to the trunk. Hmm, I find it quite insteresting and indeed encouraging that someone actually verifies our VAX/Linux target. Mikael, how do you actually verify it however? I'm asking because while I did a glibc port for VAX/Linux (including VAX floating-point format support), it was many years ago and for LinuxThreads configuration only (hence glibc 2.4 only), which I suspect may not be supported by GCC anymore. And it has never made its way upstream, because we'd have to land Linux kernel bits there first and that effort has stalled. I can still boot that old stuff on my VAX machine, but the userland is minimal and somewhat unstable as things sometimes crash or otherwise behave in a weird way. I do have working `bash' and more importantly `gdbserver' binaries though. Maciej
On Fri, May 19, 2023 at 2:06 PM Maciej W. Rozycki <macro@orcam.me.uk> wrote: > > On Sat, 29 Apr 2023, Jeff Law via Gcc-patches wrote: > > > > PR target/105525 is a build regression for the vax and lm32 linux > > > targets present in gcc-12/13/head, where the builds fail due to > > > unsatisfied references to __INTPTR_TYPE__ and __UINTPTR_TYPE__, > > > caused by these two targets failing to provide glibc-stdint.h. > > > > > > Fixed thusly, tested by building crosses, which now succeeds. > > > > > > Ok for trunk? (Note I don't have commit rights.) > > > > > > 2023-04-28 Mikael Pettersson<mikpelinux@gmail.com> > > > > > > PR target/105525 > > > * config.gcc (vax-*-linux*): Add glibc-stdint.h. > > > (lm32-*-uclinux*): Likewise. > > Thanks. I've pushed this to the trunk. > > Hmm, I find it quite insteresting and indeed encouraging that someone > actually verifies our VAX/Linux target. > > Mikael, how do you actually verify it however? My vax builds are only cross-compilers without kernel headers or libc. The background is that I maintain a script to build GCC-based crosses to as many targets as I can, currently it supports 78 distinct processors and 82 triplets (four processors have multiple triplets). I only check that I can build the toolchains (full linux-gnu ones where possible). /Mikael > I'm asking because while I did a glibc port for VAX/Linux (including VAX > floating-point format support), it was many years ago and for LinuxThreads > configuration only (hence glibc 2.4 only), which I suspect may not be > supported by GCC anymore. And it has never made its way upstream, because > we'd have to land Linux kernel bits there first and that effort has > stalled. > > I can still boot that old stuff on my VAX machine, but the userland is > minimal and somewhat unstable as things sometimes crash or otherwise > behave in a weird way. I do have working `bash' and more importantly > `gdbserver' binaries though. > > Maciej
On Fri, 19 May 2023, Mikael Pettersson wrote: > > Hmm, I find it quite insteresting and indeed encouraging that someone > > actually verifies our VAX/Linux target. > > > > Mikael, how do you actually verify it however? > > My vax builds are only cross-compilers without kernel headers or libc. Hmm, interesting, I wasn't aware you could actually build stage 1 GCC without target headers nowadays. When I tried it previously, it failed, and I had to come up with a hack to make glibc's `make install-headers' work, as ordinarily it requires a target compiler, making it a chicken-and-egg problem. > The background is that I maintain a script to build GCC-based crosses to > as many targets as I can, currently it supports 78 distinct processors and > 82 triplets (four processors have multiple triplets). I only check that I can > build the toolchains (full linux-gnu ones where possible). Great work, thanks! Maciej
Hi! On Mon, 2023-05-22 14:10:48 +0100, Maciej W. Rozycki <macro@orcam.me.uk> wrote: > On Fri, 19 May 2023, Mikael Pettersson wrote: > > The background is that I maintain a script to build GCC-based crosses to > > as many targets as I can, currently it supports 78 distinct processors and > > 82 triplets (four processors have multiple triplets). I only check that I can > > build the toolchains (full linux-gnu ones where possible). > > Great work, thanks! I'd be very much interested in running your script as one build variant for my http://toolchain.lug-owl.de/ efforts. Is it available somewhere? That would be nice! MfG, JBG --
On Mon, May 22, 2023 at 3:57 PM Jan-Benedict Glaw <jbglaw@lug-owl.de> wrote: > > Hi! > > On Mon, 2023-05-22 14:10:48 +0100, Maciej W. Rozycki <macro@orcam.me.uk> wrote: > > On Fri, 19 May 2023, Mikael Pettersson wrote: > > > The background is that I maintain a script to build GCC-based crosses to > > > as many targets as I can, currently it supports 78 distinct processors and > > > 82 triplets (four processors have multiple triplets). I only check that I can > > > build the toolchains (full linux-gnu ones where possible). > > > > Great work, thanks! > > I'd be very much interested in running your script as one build > variant for my http://toolchain.lug-owl.de/ efforts. Is it available > somewhere? That would be nice! The script is publicly available as https://github.com/mikpe/buildcross.git. Usage for actively maintained toolchains is pretty easy. For example, to build a cross to sparc64-unknown-linux-gnu you just run buildcross -jN sparc64 and it will leave the toolchain in cross-sparc64. (Other bits will land in downloads/, sources/, and host-tools/.) Many older targets require older gcc versions to even build, and may not work well as 64-bit builds, so for those the operator needs to provide overrides via the environment, see e.g. the comments for the "a29k" target. None of that is automated, sorry. If you're only interested in linux-gnu toolchains for actively maintained targets there's a build-many-glibcs.py script in glibc that should be a better fit. /Mikael
Hi Mikael! On Mon, 2023-05-22 17:25:39 +0200, Mikael Pettersson <mikpelinux@gmail.com> wrote: > On Mon, May 22, 2023 at 3:57 PM Jan-Benedict Glaw <jbglaw@lug-owl.de> wrote: > > On Mon, 2023-05-22 14:10:48 +0100, Maciej W. Rozycki <macro@orcam.me.uk> wrote: > > > On Fri, 19 May 2023, Mikael Pettersson wrote: > > > > The background is that I maintain a script to build GCC-based crosses to > > > > as many targets as I can, currently it supports 78 distinct processors and > > > > 82 triplets (four processors have multiple triplets). I only check that I can > > > > build the toolchains (full linux-gnu ones where possible). > > > > > > Great work, thanks! > > > > I'd be very much interested in running your script as one build > > variant for my http://toolchain.lug-owl.de/ efforts. Is it available > > somewhere? That would be nice! > > The script is publicly available as https://github.com/mikpe/buildcross.git. > Usage for actively maintained toolchains is pretty easy. For example, to build > a cross to sparc64-unknown-linux-gnu you just run > > buildcross -jN sparc64 > > and it will leave the toolchain in cross-sparc64. (Other bits will > land in downloads/, > sources/, and host-tools/.) Thanks, I'll have a look! > If you're only interested in linux-gnu toolchains for actively > maintained targets there's > a build-many-glibcs.py script in glibc that should be a better fit. My intention is to gain access to as many targets and different configurations and build strategies as possible. glibc's script is already included. (As I build with all languages, most of the target configurations fail right now.) Thanks! Jan-Benedict --
diff --git a/gcc/config.gcc b/gcc/config.gcc index 6fd1594480a..671c7e3b018 100644 --- a/gcc/config.gcc +++ b/gcc/config.gcc @@ -2287,7 +2287,7 @@ lm32-*-rtems*) tmake_file="${tmake_file} lm32/t-rtems" ;; lm32-*-uclinux*) - tm_file="elfos.h ${tm_file} gnu-user.h linux.h lm32/uclinux-elf.h" + tm_file="elfos.h ${tm_file} gnu-user.h linux.h glibc-stdint.h lm32/uclinux-elf.h" tmake_file="${tmake_file} lm32/t-lm32" ;; m32r-*-elf*) @@ -3488,7 +3488,7 @@ v850*-*-*) use_gcc_stdint=wrap ;; vax-*-linux*) - tm_file="${tm_file} elfos.h gnu-user.h linux.h vax/elf.h vax/linux.h" + tm_file="${tm_file} elfos.h gnu-user.h linux.h glibc-stdint.h vax/elf.h vax/linux.h" extra_options="${extra_options} vax/elf.opt" ;; vax-*-netbsdelf*)