Bug#455501: dpkg-architecture doesn't recognize arm-none-linux-uclibcgnueabi
Package: dpkg
Version: 1.13.25
Etch's dpkg does not recognize arm-none-linux-uclibcgnueabi as a valid
architecture. Don't know if this architecture string is exactly a proper
one to begin with, but at compile time it seemed like the most
reasonable one from all the options...
Anyway, we need a separate architecture for armel+uclibc.
Meanwhile, made this horrid patch to get the architecture recognized as
armel, as with the ordinary arm+glibc equivalent.
diff -Nur old/dpkg-1.13.25/scripts/controllib.pl new/dpkg-1.13.25/scripts/controllib.pl
--- old/dpkg-1.13.25/scripts/controllib.pl 2007-08-29 16:35:03.0 +0300
+++ new/dpkg-1.13.25/scripts/controllib.pl 2007-11-20 17:47:34.0 +0200
@@ -95,7 +95,7 @@
return $cpu;
} elsif ($os =~ /^(none|gnu)-(.*)/) {
return "$2-$cpu";
-} elsif ("$os-$cpu" eq "gnueabi-linux-arm") {
+} elsif ($cpu eq "arm" && $os =~ /gnueabi/) {
return "armel";
} else {
return "$os-$cpu";
diff -Nur old/dpkg-1.13.25/ostable new/dpkg-1.13.25/ostable
--- old/dpkg-1.13.25/ostable 2007-08-29 16:35:05.0 +0300
+++ new/dpkg-1.13.25/ostable 2007-11-20 17:57:11.0 +0200
@@ -13,7 +13,7 @@
# system part of the output of the GNU config.guess script.
#
#
-gnueabi-linux linux-gnueabi linux[^-]*-gnueabi
+gnueabi-linux linux-gnueabi linux[^-]*-[^-]*gnueabi
gnu-linux linux-gnu linux[^-]*(-gnu)?
none-darwin darwin darwin[^-]*
none-freebsd freebsd freebsd[^-]*
Bug#455501: dpkg-architecture doesn't recognize arm-none-linux-uclibcgnueabi
Hi, On Mon, 2007-12-10 at 15:46:01 +0200, Jussi Hakala wrote: > Package: dpkg > Version: 1.13.25 > Etch's dpkg does not recognize arm-none-linux-uclibcgnueabi as a valid > architecture. Just to clarify, the version in etch is not going to be updated for this anyway, that's Debian release policy. > Don't know if this architecture string is exactly a proper > one to begin with, but at compile time it seemed like the most reasonable > one from all the options... It seems like a valid GNU triplet. Although for dpkg purposes the -none- is unneeded. > Anyway, we need a separate architecture for armel+uclibc. Given other conversations, I take this is for Maemo. And my same concerns apply, why do you need a new architecture? And do you realize this would imply having two different dpkg db (there's no multiarch support yet anyway)? > Meanwhile, made this horrid patch to get the architecture recognized as > armel, as with the ordinary arm+glibc equivalent. This is the completely wrong approach, I'd recommend you don't do that in Maemo either. thanks, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#455501: dpkg-architecture doesn't recognize arm-none-linux-uclibcgnueabi
Guillem Jover wrote: Just to clarify, the version in etch is not going to be updated for this anyway, that's Debian release policy. Didn't expect it would. I issued a bug because I thought it would be nice to have a record of etch dpkg-architecture breaking when the toolchain advertises itself as an uclibc toolchain. Given other conversations, I take this is for Maemo. And my same concerns apply, why do you need a new architecture? And do you realize this would imply having two different dpkg db (there's no multiarch support yet anyway)? Yes, I know. You're correct, the patch is for maemo. The bug however, is about debian. However it will be handled in maemo, is, in the end, not relevant here. Meanwhile, made this horrid patch to get the architecture recognized as armel, as with the ordinary arm+glibc equivalent. This is the completely wrong approach, I'd recommend you don't do that in Maemo either. I realize that. As I said earlier, the patch here is a quick (and ugly) fix to circumvent a problem with dpkg-architecture searching specifically for -gnueabi in architecture strings. It's not intended as a solution. It was a way to create armel packages which are built against uclibc instead of breaking down completely. Regards, Jussi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#455501: dpkg-architecture doesn't recognize arm-none-linux-uclibcgnueabi
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'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. Therefore, it would be reasonable that a uniform naming scheme would exist in the architecture names. When we have an idea what that scheme could be, we can reimplement the patch properly. Regards, Jussi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#455501: dpkg-architecture doesn't recognize arm-none-linux-uclibcgnueabi
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-, which is less confusing (people would not assume any kernel running on , but for historical reasons I don't see this changing). For the new "common" ones we use -, 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 -- for example: uclibc-linux-armeluclibceabi-linux-armarm-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. # # +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: # # +uclibceabi-linux-arm uclibc-linux-armel +uclibc-linux- uclibc-linux- gnueabi-linux-arm armel gnulp-linux-i386 lpia gnu-linux-
Bug#455501: dpkg-architecture doesn't recognize arm-none-linux-uclibcgnueabi
Hi, On Wed, 2007-12-12 at 13:13:26 +0200, Jussi Hakala wrote: > Guillem Jover wrote: >> Just to clarify, the version in etch is not going to be updated for >> this anyway, that's Debian release policy. > > Didn't expect it would. > > I issued a bug because I thought it would be nice to have a record of > etch dpkg-architecture breaking when the toolchain advertises itself as > an uclibc toolchain. 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. >>> Meanwhile, made this horrid patch to get the architecture recognized >>> as armel, as with the ordinary arm+glibc equivalent. >> >> This is the completely wrong approach, I'd recommend you don't do that >> in Maemo either. > > I realize that. > > As I said earlier, the patch here is a quick (and ugly) fix to > circumvent a problem with dpkg-architecture searching specifically for > -gnueabi in architecture strings. > > It's not intended as a solution. It was a way to create armel packages > which are built against uclibc instead of breaking down completely. The proper fix (if desired) is to create a name for this supposed uclibc based architecture. Then those warnings go away by themselves. I'm tempted to close this bug report unless there's someone starting a real Debian arm eabi uclibc port. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
