devkitPro

Posted: **Sun Dec 14, 2008 11:16 pm**

Hi,

I'm trying to port the pixman library to the gc/wii. I ran the configure script on the source using

./configure --host=ppc

and it created the makefile. I modifed the makefile to include the flags specified in the makefile for the example gc project that came with devkitPro. When I issue make, I get the following errors:

Code: Select all

powerpc-gekko-gcc -DHAVE_CONFIG_H -I. -I. -I.. -DPIXMAN_DISABLE_DEPRECATED -g -O2 -Wall -DGEKKO -mogc -mcpu=750 -meabi -mhard-float -g -O2 -Wall -fvisibility=hidden -MT libpixman_1_la-pixman-pict.lo -MD -MP -MF .deps/libpixman_1_la-pixman-pict.Tpo -c pixman-pict.c -o libpixman_1_la-pixman-pict.o
pixman-pict.c:2048: error: expected declaration specifiers or '...' before 'siginfo_t'
pixman-pict.c: In function 'pixman_have_vmx':
pixman-pict.c:2056: error: 'SA_SIGINFO' undeclared (first use in this function)
pixman-pict.c:2056: error: (Each undeclared identifier is reported only once
pixman-pict.c:2056: error: for each function it appears in.)
pixman-pict.c:2058: error: 'struct sigaction' has no member named 'sa_sigaction'

pixman-pict.c:2059: warning: implicit declaration of function 'sigaction'
make: *** [libpixman_1_la-pixman-pict.lo] Error 1

This indicates to me that siginfo_t is undefined. So I started searching for why. The file's lines are below (line numbers 2043-2050):

Code: Select all

#include <signal.h>
#include <setjmp.h>

static jmp_buf jump_env;

static void vmx_test(int sig, siginfo_t *si, void *unused) {
    longjmp (jump_env, 1);
}

So it includes <signal.h>, and that includes <sys/signal.h> that contains the definition for signal_t. But there are some preprocessor definitions that are required for signal_t to get defined (__rtems__ and _POSIX_REALTIME_SIGNALS).

Does anyone know why these might be undefined? Or does anyone have any ideas of what to try (besides defining those 2 things myself)?

Thanks.

Posted: **Mon Dec 15, 2008 7:53 pm**

There's a much easier way to get conifgure && make to work, patch config.sub with this & run autoconf in the source folder. I'm not entirely sure if that will work right with the stock msys install provided with the devkitPro toolchains but it's worth trying - let me know if you have problems with that.

Code: Select all

diff -Nbaur pixman-0.13.2/config.sub pixman-0.13.2-ppc/config.sub
--- pixman-0.13.2/config.sub	2007-04-20 03:09:10.000000000 +0100
+++ pixman-0.13.2-ppc/config.sub	2008-12-15 17:52:29.000000000 +0000
@@ -230,6 +230,10 @@
 		basic_machine=m68k-atari
 		os=-mint
 		;;
+	-gekko)
+		basic_machine=powerpc-devkitpro
+		os=-elf
+		;;
 esac
 
 # Decode aliases for certain CPU-COMPANY combinations.

I usually configure outside the source directory - it's a good habit to get into, some packages really don't like ./configure. Make sure $DEVKITPPC/bin is in the path before running this. This patch may change in the future, I'm still not sure that we're using the right triplet with this.

Code: Select all

<path/to>/pixman-0.13.2/configure --host=powerpc-gekko --prefix=$DEVKITPRO/portlibs/ppc --disable-shared --enable-static --disable-vmx
make && make install

I'm considering providing several common porting libraries with the devkitPro Installer/Updater and $DEVKITPRO/portlibs seems like a good place for libraries that aren't hardware dependent. Using the library is then just a matter of adding $(DEVKITPRO)/portlibs/ppc to the LIBDIRS variable in the makefile. For libraries which provide a bin folder too I'll need to look at adding that to the PATH, still not quite sure how best to handle that.

Posted: **Tue Dec 16, 2008 3:25 am**

Well that builds just fine then. My main development environment is Windows and Visual Studio, and my experience with Linux and GNU tools is fairly limited (only one of my projects for work was cross platform and for that I used Eclipse or a handrolled shell script). Couple of questions though about GC/Wii development.

1. Are the flags that are given in the example template in devkitPro PPC required or just suggested? The platform rules:

Code: Select all

include $(DEVKITPPC)/gamecube_rules

, the CFLAGS:

Code: Select all

 $(MACHDEP) $(INCLUDE)

and the LDFLAGS:

Code: Select all

$(MACHDEP) -Wl,-Map,$(notdir $@).map

2. Does the Gekko processor not have hte Altivec instruction set? I thought this was usually available for PPC?

3. Just in case (since you had a patch for the config.sub for pixman), does that mean that someone has already ported Cairo to the GC/Wii?

Thanks!

Posted: **Thu Dec 18, 2008 4:58 am**

cuppm wrote:
1. Are the flags that are given in the example template in devkitPro PPC required or just suggested? The platform rules:

The templates are designed to make building code as easy as possible, basically you just throw .c/.cpp files in the source folder hit make & the Makefile does the rest. We recommend sticking with those for building actual wii/gc code but obviously configure && make can work in some situations.

The main flags of interest are -mogc, required for both compilation & linking, and -mrvl which specify code for cube & wii respectively.

2. Does the Gekko processor not have hte Altivec instruction set? I thought this was usually available for PPC?

The siginfo stuff is removed by the --disable-vmx argument, I don't really understand why a graphics library is attempting to use signals either. We don't have an OS layer on these machines so anything that's particularly linux oriented does tend to have a bit of trouble.

The custom gekko processor is a 750 derivative with added support for paired singles operations. I'm not 100% certain about Altivec instructions but I do remember gekko instructions colliding with Altivec instructions when the orginal patch for binutils was being prepared.

3. Just in case (since you had a patch for the config.sub for pixman), does that mean that someone has already ported Cairo to the GC/Wii?

It's just a standard config.sub patch to recognise powerpc-gekko as a valid target.

I'm not entirely sure that porting Cairo is something worth doing really. There's no direct access to a linear RGB framebuffer on either the Wii or the Cube and both machines are very much aimed at 3D applications. Depends on what your objectives are really.

Posted: **Fri Dec 19, 2008 3:17 am**

WinterMute wrote: The main flags of interest are -mogc, required for both compilation & linking, and -mrvl which specify code for cube & wii respectively.

Ah... Is there an easy way to add those flags into a standard configuration/makefile script, like with a .cache file or something?

The siginfo stuff is removed by the --disable-vmx argument, I don't really understand why a graphics library is attempting to use signals either. We don't have an OS layer on these machines so anything that's particularly linux oriented does tend to have a bit of trouble.

Not sure why they are looking for it either, maybe something to do with synchronizing the VMX calls...? Are signals directly tied to an OS layer? I figured if pthreads were available, signals would be.

There's no direct access to a linear RGB framebuffer on either the Wii or the Cube and both machines are very much aimed at 3D applications.

I haven't looked into the GX drawing routines available and I know one answer to this question is "look at the sources", but how do other applications implement a 2D drawing then? Would one be able to just draw to an in memory array and draw that as a texture to the screen? Like double buffering?

Posted: **Tue Dec 23, 2008 4:58 am**

Ok, I've done some more checking and I can confirm that the Gekko doesn't have the Altivec instructions. These have been replaced with the paired singles operations on that chip.

cuppm wrote:
WinterMute wrote: The main flags of interest are -mogc, required for both compilation & linking, and -mrvl which specify code for cube & wii respectively.
Ah... Is there an easy way to add those flags into a standard configuration/makefile script, like with a .cache file or something?

This might get a little bit awkward, I might still have a little tweaking to do for this to work right.

Code: Select all

CFLAGS=-mogc LDFLAGS=-mogc <path/to>/configure <options>

should help a bit. You'll need to have $DEVKITPPC/bin in the path when you do this and probably some additional hacking to tell autotools where to find the gamecube headers and libs. I'll see if I can spare a bit of time to look into this more soon.

I haven't looked into the GX drawing routines available and I know one answer to this question is "look at the sources", but how do other applications implement a 2D drawing then? Would one be able to just draw to an in memory array and draw that as a texture to the screen? Like double buffering?

Unfortunately an awful lot of homebrew out there does 2D by converting from RGB to the yuv format expected by the framebuffer. It's one way to go but probably not the best for games or anything much really.

I think your best bet is to go with an RGBA buffer which you then swizzle into a texture format & draw a fullscreen quad in orthographic mode. The provided gxSprite example might help you a bit with the code for that - I should really write up an example that does this.

For the texture swizzling I posted some code for a quick & dirty PC converter tool which should hopefull give you a hint. Again, I think having swizzle functions in libogc might be a good idea. There's one there already for RGB565 format but I need to rearrange things a little & maybe change function names.

The current function in there is void MakeTexture565(const void *src,void *dst,s32 width,s32 height) which takes a pointer to a linear RGB565 buffer (src) and a pointer to a buffer where the tiled RGB565 texture will be built. width and height should be obvious. The code is in this post

I'm thinking about providing several swizzle* functions for different formats & swapping the src & dst pointers on those. It's common for dst to be specified first, like memcpy.

I'll try and put together a full screen quad example in the next day or two.

Posted: **Mon May 25, 2009 10:02 pm**

cuppm wrote:Hi,
I'm trying to port the pixman library to the gc/wii. I ran the configure script on the source using
Code: Select all
./configure --host=ppc

The thing I tried using autoconf is

./configure --host=powerpc-gekko-eabi

Apparently config does not care about the Manufacture - so powerpc-bubu-eabi should work, too.
IMO powerpc-gekko-eabi should be the most applicant standard host triple I can think of, right?
I have to admit - I haven't toyed around with it more - but in general is it necessary to explicitly define a triplet for the wii - or should reusing the already present work?

Posted: **Tue May 26, 2009 11:13 pm**

Defining a triplet for devkitPPC is worthwhile where we want to differentiate the toolchain from a standard powerpc cross compiler. This allows for gamecube/wii specific patching of a package configury where necessary - adding a search and test for libogc libraries for example.

Posted: **Wed May 27, 2009 8:52 am**

WinterMute wrote:Defining a triplet for devkitPPC is worthwhile where we want to differentiate the toolchain from a standard powerpc cross compiler.

No problem with that - but someone should then go forward and send the triplet patch to the config guys.

devkitPro

siginfo_t not defined?

siginfo_t not defined?

Re: siginfo_t not defined?

Re: siginfo_t not defined?

Re: siginfo_t not defined?

Re: siginfo_t not defined?

Re: siginfo_t not defined?

Re: siginfo_t not defined?

Re: siginfo_t not defined?

Re: siginfo_t not defined?