[Pixman] [PATCH] build: Support building Loongson code for 2e, 2f, 3a
sandmann at cs.au.dk
Wed Sep 19 05:28:44 PDT 2012
Matt Turner <mattst88 at gmail.com> writes:
> pixman/Makefile.am contains a hack that allows pixman-mmx.c to
> be compiled with different overriding CFLAGS, since automake
> seriously doesn't have a way to do this. Seriously stupid.
> It works by defining a new rule and recursively calling make
> with modified CFLAGS set.
> Note the difference between the USE_LOONGSON* and HAVE_LOONGSON*
> preprocessor macros.
> Cc: Cyril Brulebois <kibi at debian.org>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=51451
> This patch applies on top of the previous.
The DEP patch looks good to me. Apparently the "DEP" stuff was present
in the first check-in but never used.
> Although the build system works, linking unfortunately doesn't. gcc
> refuses to link object files that have been compiled with different
> -march=loongson* options together. This sucks.
> I'm not sure what to do. I guess I could make them separate shared
> objects or even dlopen them, but that really sucks, especially when
> I don't see a reason why gcc shouldn't be able to link this code
> Anyone have any other ideas?
If the shared library thing works, I'm fine with it.
Another idea is to use some objcopy or elfedit hack where the binary
files are edited to have the same architecture. That's not exactly
beautiful either, though.
> It's really obnoxious that there's not just a simple -mloongson-mmi
> flag irrespective of -march=...
This probably just have to be fixed in GCC or the linker.
We have a similar obnoxiousness in x86 where the -mmmx/-msse flags mean
two separate things at the same time: "the compiler may generate mmx/sse
instructions" and "the files may use mmx/sse intrinsics". But at least
the linker doesn't refuse to link files compiled with different such
More information about the Pixman