Re: What GNU triplet should be for mipsn64 (Re: mips64eb seems to be mostly 32-bit)
Warner Losh <[email protected]>
| Newsgroups | gmane.os.netbsd.devel.toolchain,gmane.os.netbsd.ports.mips.devel |
|---|---|
| Message-ID | <CANCZdfr0iX6fPP9XOo0f3RJxFkOyFxSkGoQ9S6=F_E4AX_jCEg@mail.gmail.com> |
On Mon, Jul 5, 2021 at 4:21 AM Rin Okuyama <[email protected]> wrote: > Hi, > > On 2021/07/04 11:26, Denis Ovsienko wrote: > > * pkgsrc-2021Q2 fails to build Autoconf-driven packages because the > > latter is not aware of the new build name. > > > > checking build system type... Invalid configuration > > `mipsn64eb-unknown-netbsd9.99': machine `mipsn64eb-unknown' not > > recognized > > With the attached patch, some packages including python38 and perl5 > build successfully for me on my erlite. > > However, I'm not sure what GNU triplets should be for mipsn64e[bl]. > > In the attached patch, I used mips64- and mips64el-unknown-netbsd for > mipsn64eb and el, respectively. However, these are indistinguishable > with conventional mips64e[bl] ones. > > IMO, mips64e[bl] should not really advertise themselves as mips64, > since their userlands are n32. But it is too late to correct... > > Ideas? > Years ago we went through this in FreeBSD. We settled on the unappealing, but mostly compatible, mips64 (for big endian) and mips64el (for little endian). Almost no upstreams at the time supported mips64eb, since SGI had used mips64 to mean big-endian 64-bit mips. We changed our build system to insert a few ugly special cases for mips64 where before we had nice regular expressions because that was way less painful than fixing the different upstreams at the time. Granted, this was around 2010, so your mileage may vary. We also didn't have the added complication of n32. So take this more as a fellow traveller's tail of dragons along the way when the journey was made in the time of yore :) Warner