pkgsrc-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Build problems for liboil on netbsd-macppc (a.k.a. how to build Gnome)



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





Home | Main Index | Thread Index | Old Index