On 4/9/12 10:56 AM, Koen Kooi wrote:
Op 9 apr. 2012, om 17:17 heeft Mark Hatle het volgende geschreven:
On 4/8/12 4:34 PM, Andreas Oberritter wrote:
On 07.04.2012 02:10, Mark Hatle wrote:
Just ran a local build with the qemumips machine, this is a standard
mips32 target.
From the configure line for eglibc:
/msp-lpggp1/mhatle/git/oe-core/build-mips32/tmp-eglibc/work/mips32-oe-linux/eglibc-2.13-r23+svnr15508/eglibc-2_13/libc/configure
--build=x86_64-linux --host=mips-oe-linux --target=mips-oe-linux
--prefix=/usr --exec_prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin
--libexecdir=/usr/libexec --datadir=/usr/share --sysconfdir=/etc
--sharedstatedir=/com --localstatedir=/var --libdir=/usr/lib
--includedir=/usr/include --oldincludedir=/usr/include
--infodir=/usr/share/info --mandir=/usr/share/man --disable-silent-rules
--disable-dependency-tracking
--with-libtool-sysroot=/msp-lpggp1/mhatle/git/oe-core/build-mips32/tmp-eglibc/sysroots/qemumips
--enable-kernel=2.6.16 --without-cvs --disable-profile --disable-debug
--without-gd --enable-clocale=gnu
--enable-add-ons=ports,nptl,libidn,ports
--with-headers=/msp-lpggp1/mhatle/git/oe-core/build-mips32/tmp-eglibc/sysroots/qemumips/usr/include
--without-selinux
The system is correctly setting the target to "mips-oe-linux".
I checked and bash is the same way.
So the canonical arch is correct, the mips32 is only the packaging
arch. It was always intended that the packaging arch be used in full on
MIPS. (This will allow us to specify mips32r2, mipsiii, mipsiv, etc as
necessary if we expand the mips tunings.)
I don't think such a change should be done only few days before a
release. Until this patch was applied, the packaging arch has always
been mipsel, not mips32el. Please, revert or fix this!
This is easy to change to the previous behavior... however it was a bug in the
original implementation.
But again, I stress nothing changed except for the packaging arch... the way
the packages are configured, compiled, installed remain the same, only the
package arch has changed.
"only"
Yes, only. The package arch is used by the feed system and the build of the
images. I verified the images were still being generated corrected. I did not
verify anything within external package feeds, as I have no way to easily do this.
If anything else in the system is using the package arch as a key, then it's
broken. The configure arch, the tuning, and similar are all reasonable things
to use, but the package arch is arbitrary. We may have a fairly defined,
defacto set, but they really are arbitrary and should not affect any software --
other then those directly working with the package feeds.
--Mark
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
