[arm-gnu] Different Specs Generated for 2009q3

[James Snyder <jbsnyder@xxxxxxxxxxxxxx>]

Hi -

I'm wondering if anyone might have some insight into why when I build
the 2009q3 lite sources, I get slightly different multilib specs.  On
Mac OS X 10.6.1, I get a working toolchain that builds and links
thumb2 code for Cortex-M3.  On Linux 64-bit (Ubuntu 9.10), individual
object files contain thumb2 code, but the final linking runs against
the arm libraries rather than thumb2.  It is a multilib build, and I
do have thumb, thumb2, etc.. directories for versions of these
libraries, and if I copy the spec file from the OS X machine to the
Linux machine, the Linux toolchain does things correctly on linking
and I get working binaries.

Here's the difference in the dumped specs:
--- /home/jsnyder/localspecs    2009-12-16 11:02:39.985261306 -0600
+++ /home/jsnyder/jungledisk/specfile2  2009-12-16 10:39:33.000000000 -0600
@@ -78,7 +78,7 @@
 4.4.1

 *multilib:
-. !mthumb !march=armv7 !march=armv6-m !mfix-cortex-m3-ldrd;thumb
mthumb !march=armv7 !march=armv6-m !mfix-cortex-m3-ldrd;armv6-m mthumb
!march=armv7 march=armv6-m !mfix-cortex-m3-ldrd;thumb2 mthumb
march=armv7 !march=armv6-m mfix-cortex-m3-ldrd;
+. !mthumb !march=armv7 !march=armv6-m !mfix-cortex-m3-ldrd;thumb
mthumb !march=armv7 !march=armv6-m !mfix-cortex-m3-ldrd;armv6-m mthumb
!march=armv7 march=armv6-m !mfix-cortex-m3-ldrd;thumb2 mthumb
march=armv7 !march=armv6-m mfix-cortex-m3-ldrd;thumb2 mthumb
march=armv7 !march=armv6-m !mfix-cortex-m3-ldrd;

 *multilib_defaults:
 marm mlittle-endian msoft-float mno-thumb-interwork fno-leading-underscore

(where the latter is from OS X)

Any idea why on one platform it includes this extra clause for
multilib and on the other it doesn't? Both are configured from the
same options:
configure --prefix=$(PREFIX) --target=arm-eabi --enable-languages="c"
--with-gnu-ld --with-gnu-as --with-newlib --disable-nls
--disable-libssp --with-newlib --without-headers --disable-shared
--disable-threads --disable-libmudflap --disable-libgomp
--disable-libstdcxx-pch --disable-libunwind-exceptions
--disable-libffi --enable-extra-sgxxlite-multilibs

I suppose I don't mind just copying a working specfile over for use
with this release, but it seems like this might be a bug of some sort?
 I'm not sure I understand why the host platform would influence
multilib configuration.

Any thoughts?

-- 
James Snyder
Biomedical Engineering
Northwestern University
jbsnyder@xxxxxxxxx
PGP: http://fanplastic.org/key.txt
Phone: (847) 448-0386