FS#75179 - [devtools] makechrootpkg Doesn't Respect Non-Default CARCH Values
Attached to Project:
Arch Linux
Opened by Neko-san (Neko-san) - Tuesday, 28 June 2022, 16:23 GMT
Last edited by Levente Polyak (anthraxx) - Tuesday, 28 June 2022, 20:33 GMT
Opened by Neko-san (Neko-san) - Tuesday, 28 June 2022, 16:23 GMT
Last edited by Levente Polyak (anthraxx) - Tuesday, 28 June 2022, 20:33 GMT
|
Details
Description:
Changing the default CARCH value in makepkg.conf for makechrootpkg usage is not respected and displays a message about unsupported architectures despite being told in the relevant configuration files that any/the specified architecture *is* supported. This shouldn't be the case; as long as the CPU supports it, makechrootpkg shouldn't bar the user from building their packages the way they specify. Additional info: * package version(s): 20220207-2 * config and/or log files etc.: https://gist.github.com/ThisNekoGuy/eb50f80cd6d99bcc349f35e5fe168dfc * link to upstream bug report, if any: https://bbs.archlinux.org/viewtopic.php?pid=2043230#p2043230 Steps to reproduce: 1) Create a local repo for building packages 2) Initialize the repo and build any package via makechrootpkg 3) Change the chroot's makepkg.conf CARCH value with any compiler-accepted architecture value (optionally, do so on the host as well; it shouldn't make a difference[?], but I did do this) 4) Append this architecture value to pacman.conf's "Architecture" variable and additionally replace its "auto" value with x86_64, in case "auto" interferes 5) Run makechrootpkg to build any package again; this should fail, complaining that the system doesn't support the specified architecture despite being explicitly told that it does |
This task depends upon
Is this because `setarch` is failing? Did you create the proper config files in `/usr/share/devtools/`?
Reading this bugreport it mostly seems like you are using devtools wrong, but it's hard to tell.
setarch: znver2: Unrecognized architecture
I've not read anything about needing config files in /usr/share/devtools for the wiki page about makepkg, so I hadn't known/don't know its significance to the problem, to be clear
Honestly though... would be great if this was automated via arch detection like: /lib/ld-linux-x86-64.so.2 --help | grep -w "^ x86-64" | cut -d "," -f 1
or something akin to it if a non-default value is detected...
I don't mean to sound like a bother but it would make this cleaner from a usage standpoint, at least from my perspective :/
I'm quite surprised something like it didn't already already exist to determine the requested architecture association to x64
I did say explicitly "something like it," I'm not trying to suggest something flimsy, I'm just referencing the concept. Obviously, if one would attempt such, it should be done right and in a predictable and verifiable manner.
@Morten
Regardless, we're still talking about x64 architectures here, so that's honestly kind of off-base... We're still using the same instruction sets...
Unless you mean to say anything that isn't explicitly x64, from which point I'd refer you to the mailing lists discussing implementing x86-64-v3 repos officially, making that train of thought kind of a moot point...
Variations of x64 are the future, sorry to say
One could say that this topic is relevant to building packages locally via makepkg with v3 because it's just as susceptible to the problem, since it's not "x86-64," but I know the response I'll get is "then we'll just add v3" -- I'm not jumping to conclusions, I'm just saying it's stupid to inhibit the tools to do what people already do just for the sake of what Arch supports on paper.
The reality is, a user's system will support what it does: it's their computer.
But yes, makechrootpkg doesn't have a problem with it.
As it stands, there isn't really an alternative for achieving this automically besides a solution akin to what devtools has, until that changes otherwise.