Building old systems
I am trying to build an old kernel with build.sh on a recent (9.99.108) amd64 system. However, compiling nbmake fails immediately with errors like /usr/bin/ld: buf.o:(.bss+0x0): multiple definition of `debug_file'; arch.o:(.bss+0x0): first defined here Unless I am doing something silly, it clearly is not possible for a current system to build old tools and kernels at arbitrary points in time. What is the best strategy for building old kernels to, for example, bisect the code? Cheers, Brook
Re: Building old systems
On Wed, Apr 19, 2023 at 16:34:19 -0600, Brook Milligan wrote: > I am trying to build an old kernel with build.sh on a recent > (9.99.108) amd64 system. However, compiling nbmake fails > immediately with errors like > > /usr/bin/ld: buf.o:(.bss+0x0): multiple definition of `debug_file'; > arch.o:(.bss+0x0): first defined here > > Unless I am doing something silly, it clearly is not possible for a > current system to build old tools and kernels at arbitrary points in > time. > > What is the best strategy for building old kernels to, for example, > bisect the code? It might be better to use corresponding older tools to build older kernels. Modern gcc switched to -fno-common by default, so if you want to compile an older kernel that has multiple variable definitions you will need to arrange for -fcommon option to be used. -uwe
Re: Building old systems
> On Apr 19, 2023, at 4:45 PM, Valery Ushakov wrote: > > It might be better to use corresponding older tools to build older > kernels. Modern gcc switched to -fno-common by default, so if you > want to compile an older kernel that has multiple variable definitions > you will need to arrange for -fcommon option to be used. Is there any way to do that with a current system and build.sh? Neither setting it with -V or with env works. Cheers, Brook
Re: Building old systems
>> It might be better to use corresponding older tools to build older >> kernels. Modern gcc switched to -fno-common by default, so if you >> want to compile an older kernel that has multiple variable definitions >> you will need to arrange for -fcommon option to be used. > > Is there any way to do that with a current system and build.sh? > Neither setting it with -V or with env works. Just glancing at build.sh from -current here, but since this is while building nbmake, it's early in the process, and it's the host's toolchain you will be using by necessity. You don't say which variable you tried setting via -V (I'm wondering a little what it is with folks who won't be concrete...). It could be that you should try with -V HOST_CFLAGS="-O -fcommon" or possibly with a variant with -V HOST_LDFLAGS=-fcommon possibly as an addition, possibly as the only "extra" setting, since IIUC the -fcommon flag influences the behaviour during linking. Regards, - Håvard
Re: Building old systems
> On Apr 19, 2023, at 5:12 PM, Havard Eidnes wrote: > > -V HOST_CFLAGS="-O -fcommon" Indeed, this (without -O) works. The key is the HOST_CFLAGS variable; I was thinking of just CFLAGS at first. Thanks a lot. Cheers, Brook
Re: Building old systems
On 20/04/23 10:34, Brook Milligan wrote: I am trying to build an old kernel with build.sh on a recent (9.99.108) amd64 system. However, compiling nbmake fails immediately with errors like /usr/bin/ld: buf.o:(.bss+0x0): multiple definition of `debug_file'; arch.o:(.bss+0x0): first defined here Unless I am doing something silly, it clearly is not possible for a current system to build old tools and kernels at arbitrary points in time. What is the best strategy for building old kernels to, for example, bisect the code? This problem is only going to get worse as 9.x gets older and more people use newer hosts. It occurs to me that we could fix the nbmake source code and release it as 9.4. It won't fix things for people stuck on 9.[0-3], but it's better than a poke in the eye with a sharp stick. Cheers, Lloyd
Re: Building old systems
On Thu, 20 Apr 2023 at 06:10, Lloyd Parkes wrote: > > On 20/04/23 10:34, Brook Milligan wrote: > > I am trying to build an old kernel with build.sh on a recent (9.99.108) > > amd64 system. However, compiling nbmake fails immediately with errors like > > > > /usr/bin/ld: buf.o:(.bss+0x0): multiple definition of `debug_file'; > > arch.o:(.bss+0x0): first defined here > > > > Unless I am doing something silly, it clearly is not possible for a current > > system to build old tools and kernels at arbitrary points in time. > > > > What is the best strategy for building old kernels to, for example, bisect > > the code? > > This problem is only going to get worse as 9.x gets older and more > people use newer hosts. > > It occurs to me that we could fix the nbmake source code and release it > as 9.4. It won't fix things for people stuck on 9.[0-3], but it's better > than a poke in the eye with a sharp stick. Could even pullup to netbsd-8 also :) David
Re: Building old systems
> On Apr 19, 2023, at 6:41 PM, Brook Milligan wrote: > > Indeed, this (without -O) works. The key is the HOST_CFLAGS variable; I was > thinking of just CFLAGS at first. I have had some luck with compiling old systems with -V HOST_CFLAGS=-fcommon. That only goes so far into the past, however. I thought the next step would be to try building even older systems with the compiler from oldest successful build. So, I tried setting HOST_CC and HOST_CXX to point to an oldish, but successfully built toolset that also successfully compiled its own kernel. That is, I run build.sh with -V HOST_CC=/path/to/oldish/tooldir/bin/armv7--netbsdelf-eabihf-gcc (and similarly for HOST_CXX), where those compilers are not the native systems compilers but ones used in a successful kernel build for a checkout somewhat after the target checkout. That has led to errors like the following: /path/to/oldish/tooldir/bin/ld: cannot find crt0.o: No such file or directory I’m guessing this means that some other environment variables are not set so the compiler is looking in the wrong place, but BUILDING is not helping me think of what that would be. All paths are absolute, except they do include “..” In them. What should I be configuring to make sure that a tooldir compiler is usable? Thanks a lot for pointers. Cheers, Brook
Re: Building old systems
>> Indeed, this (without -O) works. The key is the HOST_CFLAGS >> variable; I was thinking of just CFLAGS at first. > > I have had some luck with compiling old systems with -V > HOST_CFLAGS=-fcommon. > > That only goes so far into the past, however. I thought the > next step would be to try building even older systems with the > compiler from oldest successful build. So, I tried setting > HOST_CC and HOST_CXX to point to an oldish, but successfully > built toolset that also successfully compiled its own kernel. > That is, I run build.sh with -V > HOST_CC=/path/to/oldish/tooldir/bin/armv7--netbsdelf-eabihf-gcc > (and similarly for HOST_CXX), where those compilers are not the > native systems compilers but ones used in a successful kernel > build for a checkout somewhat after the target checkout. > > That has led to errors like the following: > > /path/to/oldish/tooldir/bin/ld: cannot find crt0.o: No such file or > directory > > I'm guessing this means that some other environment variables > are not set so the compiler is looking in the wrong place, but > BUILDING is not helping me think of what that would be. All > paths are absolute, except they do include ".." In them. > > What should I be configuring to make sure that a tooldir > compiler is usable? What I think I would do would be to use HOST_CFLAGS=-fcommon to do a "./build.sh ... tools" build. This should, at least in theory, result in a self-consistent and hopefully working toolchain of the same vintage as the kernel you are trying to build. Try this especially if it's somewhat uncertain where the /path/to/oldish/tooldir was built from. Best regards, - Håvard
Re: Building old systems
On Thu, Apr 20, 2023 at 11:08:43 -0600, Brook Milligan wrote: > What should I be configuring to make sure that a tooldir compiler is > usable? The tools in the tooldir expect that the netbsd src makefiles call them with -isysroot (or some such flag(s), sorry, writing from memory). I have some very old notes about making the tooldir+destdir into a self-contained cross toolchain: http://www.stderr.spb.ru/~uwe/netbsd/cross.html so that you can use CC=arch-netbsd-gcc and don't worry about -isysroot, -L, etc (I used that procedure to work e.g. on j2me cldc jvm and qt embedded). But keep in mind that that will give you a *cross* toolchain. You cannot expect it to work natively for the same $arch host as the target. You *might* be lucky, but the logistics of aligning all the things just right to get that hack to work is probably too compilcated and the result is probably too fragile. Since you try to use tooldir as HOST_*, you must be on a netbsd host - so it's probably easier to use a chroot with an old netbsd system (base + comp) in that case. -uwe
Re: Building old systems
Am Thu, Apr 20, 2023 at 10:38:56PM +0300 schrieb Valery Ushakov: > On Thu, Apr 20, 2023 at 11:08:43 -0600, Brook Milligan wrote: > > > What should I be configuring to make sure that a tooldir compiler is > > usable? > > The tools in the tooldir expect that the netbsd src makefiles call > them with -isysroot (or some such flag(s), sorry, writing from > memory). "--sysroot $DESTDIR" should be all that is necessary nowadays. Joerg
