On Wed, 2008-06-04 at 12:51:40 +0300, Jussi Hakala wrote: > Guillem Jover wrote: >> Sure, no problem with that, it's always good to have bugs on file, but >> the only problem here is trying to overload the meaning of armel for a >> different architecture. > > I understand. But surely we can choose a different name (uarmel?) and > after we've agreed with the arch naming scheme, this can be implemented > properly. > >> The proper fix (if desired) is to create a name for this supposed >> uclibc based architecture. Then those warnings go away by themselves. > > Agreed. The patch was only intended as a temporary solution. I'd rather > see a working package with somewhat conflicting architecture, than no > package at all and an error message when trying to build the package.
I think producing this kind of packages with overloaded architectures is really bad, might give really confusing errors, and you'll have to migrate at some point to use the new architecture name as they are going to be incompatible anyway. It was a pain to move the arm with eabi binaries to proper armel at Nokia... >> I'm tempted to close this bug report unless there's someone starting a >> real Debian arm eabi uclibc port. > > Sure. > > However, the core problem is not entirely armel related. When we want to > use something else than glibc (uClibc, Newlib, dietlibc, Klibc, ...) in > any architecture, we want (generally) those packages to be of different > arch than the ones built against "vanilla" glibc. Right (except for s/generally/always/. :) > Therefore, it would be reasonable that a uniform naming scheme would > exist in the architecture names. There's already one, it is probably not well documented though. The Debian architectures are now internally handled as triplets (which are more or less the reversed GNU triplets), so for armel we have: Debian arch Debian triplet GNU triplet armel gnueabi-linux-arm arm-linux-gnueabi The most common arches right now are GNU/Linux based so those do not include the abi nor the os, they are implicit, and the cpu might get mapped to make it distinguishible, in the previous case we have to merge the eabi and arm info into a single arch name. Ideally those would be called linux-<arch>, which is less confusing (people would not assume any kernel running on <arch>, but for historical reasons I don't see this changing). For the new "common" ones we use <kernel>-<cpu>, like in: kfreebsd-i386 gnu-kfreebsd-i386 i386-kfreebsd-gnu And in this case the abi is implicit, if we wanted a different libc, then we'd have to include it explicitly. And for really uncommon ones we'd use something like <abi>-<kernel>-<cpu> for example: uclibc-linux-armel uclibceabi-linux-arm arm-linux-uclibceabi I'm attaching a patch which should make uclibc based architectures work. regards, guillem
diff --git a/ostable b/ostable index f79ad0b..0cc9b8d 100644 --- a/ostable +++ b/ostable @@ -14,6 +14,8 @@ # system part of the output of the GNU config.guess script. # # <Debian name> <GNU name> <config.guess regex> +uclibceabi-linux linux-uclibceabi linux[^-]*-uclibceabi +uclibc-linux linux-uclibc linux[^-]*-uclibc gnueabi-linux linux-gnueabi linux[^-]*-gnueabi gnulp-linux linux-gnulp linux[^-]*-gnulp gnu-linux linux-gnu linux[^-]*(-gnu.*)? diff --git a/triplettable b/triplettable index 79ca1d0..c0439f2 100644 --- a/triplettable +++ b/triplettable @@ -3,6 +3,8 @@ # Supported variables: <cpu> # # <Debian triplet> <Debian arch> +uclibceabi-linux-arm uclibc-linux-armel +uclibc-linux-<cpu> uclibc-linux-<cpu> gnueabi-linux-arm armel gnulp-linux-i386 lpia gnu-linux-<cpu> <cpu>
