Hi, Agreed with guillem that we'll decide this at the Extremadura meeting next week, else we'll end up like the amd64 port with flaming for the name choice in tech-ctte..
> >should be clear why current dpkg-architecture limits our choices. (emphasize on current) > <rant> > Pardon me, but to me it looks outright stupid to let development be > constrained by some perl script. Well it's free software, so we can change it to whatever we want =) The big but is that it is also a very important interface, and changes should be done with care. > I would want to install a Debian distribution compiled with > -march=armv5te -mtune=xscale -Wa,-mcpu=xscale on a newer iPAQ > and another one compiled with -march=armv4 -mtune=strongarm1100 > on my older iPAQ. Thats unreleated to architecture strings. It's worth remembering that compliler flags rea turn O(n^2) solutions into O(1) solutions. The linear max 5% increase will not solve the real big performance problems. > Attaching patches for -softfloat and -uclibc... With these patches, > this is what my local dpkg-architecture says (DEB_BUILD lines removed): These are nice, but did you test if they work with the autodetection from compiler? with -a flag things seem work more easily.. > I would expect arm-eabi to look like this: > $ dpkg-architecture -aarm-eabi > DEB_HOST_ARCH=arm-eabi > DEB_HOST_ARCH_OS=linux-eabi > DEB_HOST_ARCH_CPU=arm > DEB_HOST_GNU_CPU=arm > DEB_HOST_GNU_SYSTEM=linux-gnu-eabi > DEB_HOST_GNU_TYPE=arm-linux-gnu-eabi Actually EABI compiler reports arm-none-linux-gnueabi, so the last ones should be: > DEB_HOST_GNU_SYSTEM=linux-gnueabi > DEB_HOST_GNU_TYPE=arm-linux-gnueabi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
