> On Fri, Sep 02, 2011 at 10:06:55PM +0100, Paul Brook wrote: > > Right. That's almost certainly a bug. My guess would be cargo-cult > > copying or an old hack to workaround borkenness elsewhere. > > OK, so simply removing the explicit CFLAGS settings in the Makefile, > should make the package work correctly on both armel and armhf. > That would be nice and simple.
Yes. Obviously if your code assumes [say] a Cortex-A8 and uses NEON assembly without checking first than all bets are off. There are two ways of resolving this: - Don't do that. - Hack the makefile to always build with NEON enabled, and hope noone ever runs in on a different CPU, or tries to build for a system that is incompatible wth NEON. > > In the unlikely event that you did decide to build multilibs with/without > > interworking (which for any vaguely recent core would be completely > > pointless and have no effect as interworking is enabled whether you want > > it or not) it might cause some subtle breakage. Until then the only > > effect is to confuse people who don't understand what they're reading > > (i.e. you). GCC spec files, and multilib selection in partiular, is a > > horribly crufty mess which tends to acquire historic warts like this. > > It's also in the process of being rewritten, so noone cares. > > So is there a way to ask gcc "What the hell are your defaults right now?". I don't consider that a well formed question[1]. You should be asking what the compiler is *doing* right now. The answer is in a preprocessor macro. Interesting options should result in some form of preprocessor macro being defined, so code that cares can test and act accordingly. It's possible some of these are missing, though in some cases the options aren't something you have any business wanting to know - on EABI toolchains this includes interworking[2]. For old-abi toolchains interworking is a valid question, but noone cares about those any more. There is a __THUMB_INTERWORK__ macro, however it almost certainly doesn't mean what you want it to (specifically it means you're on armv4t, so have to jump through additional hoops to make interworking happen). I'm not aware of any comprehensive list of these macros, and they vary between architectures (e.g. arm and mips both support big/little endian, but define different macros for it). If you mean "what options do I give to a random compiler to get the same output", then no you can't. There's a whole raft of twisty settings which effect how gcc behaves. Some are intended for the user[3], some almost certainly break if the user does change them, some are determined when you configure the compiler, some require hacking the compiler sources, and some combine all the above. Part of the reson for this is that GCC has way to many commandline options. This isn't unique to gcc, but GCC makes the mistake of putting them in the documentation. Some other compilers don't admit they exist until you buy an expensive technical support contract and ask very nicely. The other reason is that the compiler is not really a standalone utility. In practice you need the whole toolchain (compiler, linker and runtime libraries) to come as a set, correctly configured for your target. In theorysome level of separation is possible - the EABI isolates the compiler from the runtime library implementation. However everything else is explicitly expected to work as an intertwined set. This includes the gcc exectable when acting as a proxy for the linker. The uClinux folks originally tried to use other (linux or bare metal toolchains). However this ended up horribly fragile, and causes endless grief, especialy when you start caring about things like shared libraries. The linux kernel itself also does this (uses a linux toolchain to compile something which isn't a linux application). However they also jump through a good number of hoops to make it work, and have precicely one application/toolchain combination they care about. Paul [1] I can't mentally reconcile "default" and "right now". In practice default usually means "What happens when I do X". In which case just do X and stop making me guess! [2] The EABI says interworking must always be supported. Attempting to turn it off means you're doing something naughty, and we get to point and laugh when it breaks. [3] user == person/script building the application. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201109030026.05618.p...@codesourcery.com
