Re: My progress on armhf: xf86-video-msm for armhf attempt. Please test.
> 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.
Reply to: