>>In any case, I think it's a bug in liboil, given that the -maltivec flag 
>>is
>>added during the altivec test, but not during the build phase, or am I 
>>wrong?
>>I have somehow resolved the relocation issues that I described earlier
>>(Unsupported relocation type 10 in non-PLT relocations). There are only a
>>couple of functions that use that type of relocation, and they are both
>>assembler-optimized-altivec-version of memcpy and memset, so I axed them 
>>out,
>>and got rid of those messages.
>>While the fix is pretty small (a line changed in a Makefile.am) it 
>>involves
>>rerunning automake. How should this be handled, making a big patch for all 
>>the
>>files changed after the rerun of automake ?
>>(I know this is not exactly 'fixing' the problem, but it's what I can do 
>>for
>>now, at least until I can get some advice from someone more expert, maybe 
>>on
>>the liboil ml ).

>This problem was reported to the liboil mailing list:
>
>http://lists.freedesktop.org/archives/liboil/2006-June/000096.html
>http://lists.freedesktop.org/archives/liboil/2006-June/000097.html
>
>I later opened a bug report for it:
>
>https://bugs.freedesktop.org/show_bug.cgi?id=7900
>
>A related problem is that liboil seems to assume if it's compiling for
>PowerPC it's safe to employ Altivec instructions  In my case, I'm
>running an old iBook SE with a G3 processor that doesn't support
>Alivec instructions, yet liboil still tries to compile them in.

To follow up on this, I was able to fix my compile on my G3 iBook by
enabling -maltivec and -mabi=altivec.  The way liboil works, it doesn't
matter if the CPU on the machine doing the compile actually supports
Altivec, it looks at what machine architecture the compiler supports
and if it's PowerPC, it just compiles Altivec in.  That doesn't mean
those instructions are necessarily used.  At run-time, liboil determines
the capabilities of the particular CPU it is running on and invokes the
appropriate code path.  (Or so I understand from the liboil site.)

So the fix to this is that any compiles on GCC targeting PowerPC need
to have the Altivec flags passed, no matter what the compiler is
running on.  Theoretically it would extend beyond macppc to other
NetBSD ports to PowerPC, like ofppc, so if a script were to check for
something, /usr/bin/machine wouldn't be the best choice, MACHINE_ARCH
would be.  In any case, I have reported this upstream to the liboil
developers in my bug report, so hopefully they will address this in
their configure script.  (The bug report is here:
https://bugs.freedesktop.org/show_bug.cgi?id=7900)

By the way, I don't know if this has any impact on the problems with
gstreamer on a G4, but the GCC documentation suggests -mabi=altivec may
be needed.  I found a Debian bug report for liboil's PowerPC support,
and it suggests they are using this flag.
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=334944)

With the changes I made, I also see an instance of the "Unsupported
relocation type 10 in non-PLT relocations" error when testing a
gstreamer-dependent application on my G3.  I haven't looked into this,
as I don't normally use multimedia or audio on my iBook at all, I just
wanted a basic Gnome desktop.  (Prior to Gnome 2.16, it was possible to
build some of the packages with the gstreamer dependcency disabled, but
apparently Gnome removed that option in at least one package with 2.16,
hence my focus on liboil.)

If other Gnome enthusiasts running NetBSD/macppc are reading this, yes,
if you fix the liboil problem, both 2.14 and 2.16 should compile
successfully.  (They did for me.  Big thanks to jmmv@ and others here
who maintain Gnome.)  But like I said, multimedia and audio might not
always work.

Dave