[Solved] Missing sh-elf-g++

[Senk]

I am absolutely positive that this is an error on my part as this is my first time attempting Dreamcast development (and, really, working with any large, open-source project). Most of my experience is within academic settings, unfortunately, which means that you'll probably find me making a lot of mistakes because I simply didn't know 'x' or 'y'. Anyway, my current dilemma is just what the subject implies: I am missing sh-elf-g++ in my "/opt/toolchains/dc/sh-elf/bin/" directory (I kept the default paths when building the toolchain for KallistiOS).

I've done some brief searches for similar issues through Google and found one or two topics dicussing a missing sh-elf-g++ binary; however, they were dated back to 2004 and mentioned using other binaries found on websites that are no longer online. I haven't done a full scan of the output generated by the build of the toolchain, but I would have assumed that I would have received an error if the sh-elf-g++ binary had failed to build. My assumption is that I missed a step in the process.

I did forget to run my environ.sh before building the toolchain (I think that was a step mentioned in an old tutorial), but I don't believe that would have affected the location of that particular binary since it looks like the directory is populated by what I presume is all of the other binaries such as sh-elf-gcc, sh-elf-ar, etc.

This error arises when I run make within the kos directory and it in turn runs the makefile within the libk++ directory.

Can anyone tell me what I am doing wrong? If some sort of output is needed to help find the issue, just let me know what I need to grab and I'll post it here. Thanks in advance for taking the time to read this and consider helping me!

[BlueCrab]

Usually the problem is actually in building Newlib. When Newlib (or any part of the toolchain, IIRC) fails to build, the dc-chain Makefile doesn't actually stop the build process, which is a bit of a "known-issue" with it.

You may want to take a look at this topic, where a couple of different people had their issues worked out. If nothing in there looks like it fixes your problem, I'll probably need a bit more information to actually figure out what's going on. Error logs and other things of the like will be quite helpful.

[Senk]

Thanks for the reply, BlueCrab.

For future notice, I am running ArchLinux, which works with a rolling release system; however, I manually installed gcc-4.5.2 thinking it was necessary at the time. I've switched between gcc-4.5.2 and gcc-4.6.2 (the current version I have for my system) for builds and haven't had issues with either one except for the fact that I am missing this binary (at least, this is the first issue I've encountered).

I reran the make within the dc-toolchain directory and sent the output to a file. I grepped through it looking for errors and only noticed:

Code: Select all

configure: error: building out of tree but ../gcc-4.5.2 contains host-x86_64-unknown-linux-gnu.

The only mentions of sh-elf-g++ I could find were instances where a check for it existing were called. I think this was done twice and in both cases the result was no. Checks for sh-elf-gcc and other existing binaries resulted in a positive 'yes'; so, I'm not sure if it was just checking for existing binaries or if it was looking somewhere else.

If I did a build of each of the downloaded directories within the dc-toolchain directory, would that help me pinpoint the issue?

[EDIT]
I threw onto my site the log outputs along with a dump of the main output from the dc-chain makefile. I'll scan them again, but would you mind taking a look at some point if I can't find anything?

Log Files:
http://senkbeil.no-ip.org/tmp/build-bin ... f-2.22.log
http://senkbeil.no-ip.org/tmp/build-bin ... f-2.22.log
http://senkbeil.no-ip.org/tmp/build-gcc ... -pass1.log
http://senkbeil.no-ip.org/tmp/build-gcc ... -pass1.log
http://senkbeil.no-ip.org/tmp/build-gcc ... -pass2.log
http://senkbeil.no-ip.org/tmp/build-new ... 1.19.0.log

Main Output File:
http://senkbeil.no-ip.org/tmp/output-dc-toolchain.log

[EDIT2]
Found another error in the main output from the dc-chain makefile:

Code: Select all

make[3]: *** No rule to make target `../../build-x86_64-unknown-linux-gnu/fixincludes/fixincl', needed by `stmp-fixinc'.  Stop.

From a quick search of the word 'error' in the main output file, the above missing rule and the issue with building out of tree seem to be the only two issues. I'll check through the other files later.

[EDIT3]
From what I can tell of all of the output, those two issues in the code blocks above are the only things mentioned. After all, it looks like pretty much everything else was built.

[BlueCrab]

Yeah... That's definitely one I've never seen before. Lets see... Try doing a "sh-elf-gcc --version" (you might need to put the whole path to sh-elf-gcc, if its not in your $PATH) and see what happens. Not quite sure how you'd have a sh-elf-gcc binary, since it doesn't look like it ever got to the install phase on the stage1 gcc build for sh-elf.

I never had any issues building a toolchain on Arch in the past, granted its been quite a while since I've tried to build a toolchain on it.

[Senk]

I ran through each of the files located in my /opt/toolchains/dc/sh-elf/bin/ directory and got the version. For most of them, it's 2.22; however, for gcc, gcc-4.5.2, cpp, and gcov, the version is 4.5.2. I've uploaded an output file here:

Versions:
http://senkbeil.no-ip.org/tmp/version-output.log

[EDIT]
I ran through my head the steps I had taken to get this far and wanted to mention that I did the following:
1. Created the directory /opt/toolchains/
2. Created the directory /opt/toolchains/dc/
3. Renamed /opt/toolchains/dc/sh-elf/sh-elf/include to /opt/toolchains/dc/sh-elf/sh-elf/include-backup
4. Created the directory /opt/toolchains/dc/sh-elf/sh-elf/include/

I was getting complaints about missing directories even after I ran the process as root. This fixed those issues. Inside the include file (not directory) was a local copy of pthread.h that was apparently supposed to be included as the default copy was buggy. However, when I checked inside the include directory, there is a pthread.h with the exact same code; so, I'm not sure why a copy of pthread.h was created as include during the build process.

[BlueCrab]

Bah... I'm sorry, I meant "sh-elf-gcc -v" not --version...

[Senk]

Here's what I got from running sh-elf-gcc with the 'v' switch:

Code: Select all

./sh-elf-gcc -v
Using built-in specs.
COLLECT_GCC=./sh-elf-gcc
COLLECT_LTO_WRAPPER=/opt/toolchains/dc/sh-elf/libexec/gcc/sh-elf/4.5.2/lto-wrapper
Target: sh-elf
Configured with: ../gcc-4.5.2/configure --target=sh-elf --prefix=/opt/toolchains/dc/sh-elf --without-headers --with-newlib --enable-languages=c --disable-libssp --disable-tls --with-multilib-list=m4-single-only,m4-nofpu,m4 --with-endian=little --with-cpu=m4-single-only
Thread model: single
gcc version 4.5.2 (GCC) 

[BlueCrab]

When you built gcc-4.5.2 for your native machine, did you do it out of the source that dc-chain is using? If so, clean out that source directory completely, and try it again from scratch (I'd recommend emptying out the /opt/toolchains/dc directory before trying again as well).

Also, you might want to try having it use the normal system gcc to build the toolchain, not your manually-built gcc-4.5.2. I doubt that would have anything to do with it, but it can't hurt to try it that way.

[Senk]

I built gcc 4.5.2 from a different source than the downloaded gcc 4.5.2 in the dc-chain directory. For ArchLinux, I used this package: http://aur.archlinux.org/packages.php?ID=57582

So, I should try building it with my normal GCC, which is version 4.6.2? I'll give that a go and see what happens.

[BlueCrab]

It appears that some of the messages in the log imply that a in-tree build of GCC 4.5.2 was done for your native machine. Clean up the source code and see what happens.

[Senk]

So, I removed my multilib installation of GCC 4.5.2 and also cleaned out my /opt/toolchains/dc/ directory and the dc-chain directory within kos/utils/. Building it went well and it now has a binary of sh-elf-g++ in the bin directory. Furthermore, I successfully built kos, I think, as I didn't receive any errors from running make. I am receiving an error with kos-ports because I'm missing endian.h when attempting to build libtremor:

Code: Select all

misc.h:33:20: fatal error: endian.h: No such file or directory

Furthermore, when attempting to build all of the examples for the Dreamcast, I'm getting errors:

Code: Select all

kos-cc  -c pvrmap.c -o pvrmap.o
pvrmap.c: In function 'main':
pvrmap.c:31:31: error: 'MMU_NOT_SHARED' undeclared (first use in this function)
pvrmap.c:31:31: note: each undeclared identifier is reported only once for each function it appears in
pvrmap.c:31:47: error: 'MMU_DIRTY' undeclared (first use in this function)

Building the hello example worked, although I am not in a position to attempt to try it out by running it through my Dreamcast. Did I forget to do something again? Also, this has been bothering me:

Code: Select all

export PATH="${PATH}:${KOS_CC_BASE}/bin:/opt/toolchains/dc/bin"

I was editing the environ.sh script and wasn't sure what directory to point the path to. For most of the changes, I could just rewrite the first part to point to /opt/toolchains/dc/...; however, I'm not sure what to do with that one. Is it supposed to be the individual bin directories of sh-elf and arm-elf? Or is it something else? If there is good documentation to learn about some of the environment information, I'd love to see it! I'm very inexperienced with this kind of stuff and wanted to "break in" myself to get more familiar with this type of environment. I've also got a few classmates interested whom are also rooming with me in the summer during our co-ops; so, I'm hoping we can crank something interesting out over the summer.

[BlueCrab]

So, I removed my multilib installation of GCC 4.5.2 and also cleaned out my /opt/toolchains/dc/ directory and the dc-chain directory within kos/utils/. Building it went well and it now has a binary of sh-elf-g++ in the bin directory. Furthermore, I successfully built kos, I think, as I didn't receive any errors from running make. I am receiving an error with kos-ports because I'm missing endian.h when attempting to build libtremor:

Code: Select all

misc.h:33:20: fatal error: endian.h: No such file or directory

I'll take a look at that. That should be fairly easy to fix. Didn't realize there was anything using that broken header (which I removed a little while back).

Furthermore, when attempting to build all of the examples for the Dreamcast, I'm getting errors:

Code: Select all

kos-cc  -c pvrmap.c -o pvrmap.o
pvrmap.c: In function 'main':
pvrmap.c:31:31: error: 'MMU_NOT_SHARED' undeclared (first use in this function)
pvrmap.c:31:31: note: each undeclared identifier is reported only once for each function it appears in
pvrmap.c:31:47: error: 'MMU_DIRTY' undeclared (first use in this function)

Fixed in r755. svn update, and you'll grab it. Not that you'd probably ever run that example anyway.

Building the hello example worked, although I am not in a position to attempt to try it out by running it through my Dreamcast. Did I forget to do something again?

Nope... Just stuff that I broke without realizing it.

Also, this has been bothering me:

Code: Select all

export PATH="${PATH}:${KOS_CC_BASE}/bin:/opt/toolchains/dc/bin"

I was editing the environ.sh script and wasn't sure what directory to point the path to. For most of the changes, I could just rewrite the first part to point to /opt/toolchains/dc/...; however, I'm not sure what to do with that one. Is it supposed to be the individual bin directories of sh-elf and arm-elf? Or is it something else? If there is good documentation to learn about some of the environment information, I'd love to see it! I'm very inexperienced with this kind of stuff and wanted to "break in" myself to get more familiar with this type of environment. I've also got a few classmates interested whom are also rooming with me in the summer during our co-ops; so, I'm hoping we can crank something interesting out over the summer.

That is for a convenient place to install things like dc-tool or other Dreamcast-related tools, so no, its not meant for the individual sh-elf and arm-elf toolchains. Actually, the one right before the /opt/toolchains/dc/bin entry will add the sh-elf toolchain's bin directory to the PATH already.

Unfortunately, a good portion of KOS has gone severely undocumented for some time. I only recently finished making Doxygen-style documentation for all the functionality in KOS, and I haven't gotten around to documenting other things (like the environ script).

[Senk]

Furthermore, when attempting to build all of the examples for the Dreamcast, I'm getting errors:

Code: Select all

kos-cc  -c pvrmap.c -o pvrmap.o
pvrmap.c: In function 'main':
pvrmap.c:31:31: error: 'MMU_NOT_SHARED' undeclared (first use in this function)
pvrmap.c:31:31: note: each undeclared identifier is reported only once for each function it appears in
pvrmap.c:31:47: error: 'MMU_DIRTY' undeclared (first use in this function)

Fixed in r755. svn update, and you'll grab it. Not that you'd probably ever run that example anyway.

Alrighty! Making progress. So, I tried a build again and ran into another issue (this is using the makefile within the Dreamcast directory of the examples directory).

Code: Select all

kos-cc  -c vq-example.c -o vq-example.o
vq-example.c: In function 'loadtxr':
vq-example.c:39:2: warning: implicit declaration of function 'memcpy2'
/home/rcsvt/cadcdev/kos/utils/vqenc/vqenc -t -v fruit.jpg
make[3]: /home/rcsvt/cadcdev/kos/utils/vqenc/vqenc: Command not found
make[3]: *** [fruit.vq] Error 127

That is for a convenient place to install things like dc-tool or other Dreamcast-related tools, so no, its not meant for the individual sh-elf and arm-elf toolchains. Actually, the one right before the /opt/toolchains/dc/bin entry will add the sh-elf toolchain's bin directory to the PATH already.

Unfortunately, a good portion of KOS has gone severely undocumented for some time. I only recently finished making Doxygen-style documentation for all the functionality in KOS, and I haven't gotten around to documenting other things (like the environ script).

I'd love to help you document this stuff because it's something I find enjoyable... oddly enough. At least, I get a sense of pleasure when I see completed documentation. Unfortunately, I have no experience with these things; so, the best I can do for you right now is simply test and break things. And ask questions, I suppose! It feeds the list of topics you can direct people to!

On another note, I have questions regarding the dcload-ip Makefile.cfg, but I'll probably ask those questions in another topic after I roam around to see if there are existing topics on the subject. I don't want to derail this thread in case others come to it looking for answers.

[BlueCrab]

Alrighty! Making progress. So, I tried a build again and ran into another issue (this is using the makefile within the Dreamcast directory of the examples directory).

Code: Select all

kos-cc  -c vq-example.c -o vq-example.o
vq-example.c: In function 'loadtxr':
vq-example.c:39:2: warning: implicit declaration of function 'memcpy2'
/home/rcsvt/cadcdev/kos/utils/vqenc/vqenc -t -v fruit.jpg
make[3]: /home/rcsvt/cadcdev/kos/utils/vqenc/vqenc: Command not found
make[3]: *** [fruit.vq] Error 127

That means that the vqenc util didn't build. Go to that directory and try to build it. You may want to svn update first, as I just noticed that it didn't build on my machine either (and I fixed the issue that prevented it from building here).

That is for a convenient place to install things like dc-tool or other Dreamcast-related tools, so no, its not meant for the individual sh-elf and arm-elf toolchains. Actually, the one right before the /opt/toolchains/dc/bin entry will add the sh-elf toolchain's bin directory to the PATH already.

Unfortunately, a good portion of KOS has gone severely undocumented for some time. I only recently finished making Doxygen-style documentation for all the functionality in KOS, and I haven't gotten around to documenting other things (like the environ script).

I'd love to help you document this stuff because it's something I find enjoyable... oddly enough. At least, I get a sense of pleasure when I see completed documentation. Unfortunately, I have no experience with these things; so, the best I can do for you right now is simply test and break things. And ask questions, I suppose! It feeds the list of topics you can direct people to!

Pointing out things that are broken/odd is always a good start. As I get time, I can try to fix them. I dunno how much time I'm going to have in the coming weeks, but we'll see what happens.

On another note, I have questions regarding the dcload-ip Makefile.cfg, but I'll probably ask those questions in another topic after I roam around to see if there are existing topics on the subject. I don't want to derail this thread in case others come to it looking for answers.

Probably a good idea.

[Senk]

So, when trying to build vqenc in the utils directory, I was receiving this error:

Code: Select all

make
cc -o vqenc vqenc.o get_image.o get_image_jpg.o get_image_png.o readpng.o -lpng -ljpeg -lz 
/usr/bin/ld: vqenc.o: undefined reference to symbol 'sqrt@@GLIBC_2.2.5'
/usr/bin/ld: note: 'sqrt@@GLIBC_2.2.5' is defined in DSO /lib/libm.so.6 so try adding it to the linker command line
/lib/libm.so.6: could not read symbols: Invalid operation
collect2: ld returned 1 exit status

I checked the make file and it didn't reference the libm library, so I appended -lm to the LDFLAGS:

Code: Select all

LDFLAGS = -lpng -ljpeg -lz -lm #-s -g

It built after adding that library to the list. I went back to try building the examples and got to this point:

Code: Select all

kos-cc -o vorbistest.elf romdisk.o vorbistest.o   -ltremor -lm
/opt/toolchains/dc/sh-elf/lib/gcc/sh-elf/4.5.2/../../../../sh-elf/bin/ld: cannot find -ltremor
collect2: ld returned 1 exit status
make[2]: *** [vorbistest.elf] Error 1[/quote]

I wasn't able to build libtremor within the kos-ports directory because I was missing endian.h; so, I'm not sure what I can do at this point.

[BlueCrab]

Well, its not like building all of the examples is necessary or even important.
At this point, you pretty much have a working toolchain, so I wouldn't be too concerned with it.

EDIT: If you svn update, libtremor should be fixed now.

[Senk]

Yeah, I agree. I'd still like to not let this get ignored, though. It'd be nice to compile the examples right out of the box. The newest issue I have is this one regarding networking's simhost:

Code: Select all

kos-cc  -c simhost.c -o simhost.o
In file included from /home/rcsvt/cadcdev/kos/../kos-ports/lwip/lwip/src/include/lwip/api_msg.h:39:0,
                 from /home/rcsvt/cadcdev/kos/../kos-ports/lwip/lwip/src/include/lwip/tcpip.h:35,
                 from /home/rcsvt/cadcdev/kos/../kos-ports/lwip/lwip/src/../../kos/include/lwip/lwip.h:25,
                 from simhost.c:2:
/home/rcsvt/cadcdev/kos/../kos-ports/lwip/lwip/src/include/ipv4/lwip/ip.h:92:3: warning: 'packed' attribute ignored for field of type 'struct ip_addr'
/home/rcsvt/cadcdev/kos/../kos-ports/lwip/lwip/src/include/ipv4/lwip/ip.h:93:3: warning: 'packed' attribute ignored for field of type 'struct ip_addr'
In file included from /home/rcsvt/cadcdev/kos/../kos-ports/lwip/lwip/src/include/lwip/netif.h:43:0,
                 from /home/rcsvt/cadcdev/kos/../kos-ports/lwip/lwip/src/include/ipv4/lwip/icmp.h:40,
                 from /home/rcsvt/cadcdev/kos/../kos-ports/lwip/lwip/src/include/lwip/tcp.h:41,
                 from /home/rcsvt/cadcdev/kos/../kos-ports/lwip/lwip/src/include/lwip/api_msg.h:42,
                 from /home/rcsvt/cadcdev/kos/../kos-ports/lwip/lwip/src/include/lwip/tcpip.h:35,
                 from /home/rcsvt/cadcdev/kos/../kos-ports/lwip/lwip/src/../../kos/include/lwip/lwip.h:25,
                 from simhost.c:2:
/home/rcsvt/cadcdev/kos/../kos-ports/lwip/lwip/src/include/lwip/dhcp.h:66:3: warning: 'packed' attribute ignored for field of type 'u8_t'
/home/rcsvt/cadcdev/kos/../kos-ports/lwip/lwip/src/include/lwip/dhcp.h:67:3: warning: 'packed' attribute ignored for field of type 'u8_t'
/home/rcsvt/cadcdev/kos/../kos-ports/lwip/lwip/src/include/lwip/dhcp.h:68:3: warning: 'packed' attribute ignored for field of type 'u8_t'
/home/rcsvt/cadcdev/kos/../kos-ports/lwip/lwip/src/include/lwip/dhcp.h:69:3: warning: 'packed' attribute ignored for field of type 'u8_t'
/home/rcsvt/cadcdev/kos/../kos-ports/lwip/lwip/src/include/lwip/dhcp.h:78:3: warning: 'packed' attribute ignored for field of type 'u8_t[16]'
/home/rcsvt/cadcdev/kos/../kos-ports/lwip/lwip/src/include/lwip/dhcp.h:80:3: warning: 'packed' attribute ignored for field of type 'u8_t[64]'
/home/rcsvt/cadcdev/kos/../kos-ports/lwip/lwip/src/include/lwip/dhcp.h:82:3: warning: 'packed' attribute ignored for field of type 'u8_t[128]'
/home/rcsvt/cadcdev/kos/../kos-ports/lwip/lwip/src/include/lwip/dhcp.h:90:3: warning: 'packed' attribute ignored for field of type 'u8_t[68]'
In file included from /home/rcsvt/cadcdev/kos/../kos-ports/lwip/lwip/src/../../kos/include/netif/kosnetif.h:12:0,
                 from /home/rcsvt/cadcdev/kos/../kos-ports/lwip/lwip/src/../../kos/include/lwip/lwip.h:26,
                 from simhost.c:2:
/home/rcsvt/cadcdev/kos/../kos-ports/lwip/lwip/src/include/netif/etharp.h:46:3: warning: 'packed' attribute ignored for field of type 'u8_t[6]'
/home/rcsvt/cadcdev/kos/../kos-ports/lwip/lwip/src/include/netif/etharp.h:52:3: warning: 'packed' attribute ignored for field of type 'struct eth_addr'
/home/rcsvt/cadcdev/kos/../kos-ports/lwip/lwip/src/include/netif/etharp.h:53:3: warning: 'packed' attribute ignored for field of type 'struct eth_addr'
/home/rcsvt/cadcdev/kos/../kos-ports/lwip/lwip/src/include/netif/etharp.h:61:3: warning: 'packed' attribute ignored for field of type 'struct eth_hdr'
/home/rcsvt/cadcdev/kos/../kos-ports/lwip/lwip/src/include/netif/etharp.h:66:3: warning: 'packed' attribute ignored for field of type 'struct eth_addr'
/home/rcsvt/cadcdev/kos/../kos-ports/lwip/lwip/src/include/netif/etharp.h:67:3: warning: 'packed' attribute ignored for field of type 'struct ip_addr'
/home/rcsvt/cadcdev/kos/../kos-ports/lwip/lwip/src/include/netif/etharp.h:68:3: warning: 'packed' attribute ignored for field of type 'struct eth_addr'
/home/rcsvt/cadcdev/kos/../kos-ports/lwip/lwip/src/include/netif/etharp.h:69:3: warning: 'packed' attribute ignored for field of type 'struct ip_addr'
/home/rcsvt/cadcdev/kos/../kos-ports/lwip/lwip/src/include/netif/etharp.h:75:3: warning: 'packed' attribute ignored for field of type 'struct eth_hdr'
/home/rcsvt/cadcdev/kos/../kos-ports/lwip/lwip/src/include/netif/etharp.h:76:3: warning: 'packed' attribute ignored for field of type 'struct ip_hdr'
In file included from /home/rcsvt/cadcdev/kos/../kos-ports/lwip/lwip/src/../../kos/include/lwip/lwip.h:61:0,
                 from simhost.c:2:
/home/rcsvt/cadcdev/kos/../kos-ports/lwip/lwip/src/include/lwip/sockets.h:38:8: error: redefinition of 'struct sockaddr_in'
/home/rcsvt/cadcdev/kos/include/netinet/in.h:76:8: note: originally defined here
/home/rcsvt/cadcdev/kos/../kos-ports/lwip/lwip/src/include/lwip/sockets.h:46:8: error: redefinition of 'struct sockaddr'
/home/rcsvt/cadcdev/kos/include/sys/socket.h:38:8: note: originally defined here
/home/rcsvt/cadcdev/kos/../kos-ports/lwip/lwip/src/include/lwip/sockets.h:58:0: warning: "SOCK_DGRAM" redefined
/home/rcsvt/cadcdev/kos/include/sys/socket.h:87:0: note: this is the location of the previous definition
/home/rcsvt/cadcdev/kos/../kos-ports/lwip/lwip/src/include/lwip/sockets.h:105:0: warning: "AF_INET" redefined
/home/rcsvt/cadcdev/kos/include/sys/socket.h:90:0: note: this is the location of the previous definition
/home/rcsvt/cadcdev/kos/../kos-ports/lwip/lwip/src/include/lwip/sockets.h:113:0: warning: "INADDR_ANY" redefined
/home/rcsvt/cadcdev/kos/include/netinet/in.h:120:0: note: this is the location of the previous definition
/home/rcsvt/cadcdev/kos/../kos-ports/lwip/lwip/src/include/lwip/sockets.h:114:0: warning: "INADDR_BROADCAST" redefined
/home/rcsvt/cadcdev/kos/include/netinet/in.h:126:0: note: this is the location of the previous definition
make[2]: *** [simhost.o] Error 1

You've said you'll be fairly busy the next few weeks as will I; so, no real pressure to look at this.

My other issue is that I can't seem to compile dcload-ip, but that seems to be from missing libintl, which I'm having difficulties installing on ArchLinux through packages like gettext and llibintltools. I think this is more of an issue with ArchLinux; so, I won't bother you with that.

[BlueCrab]

Fixed in r760, along with the only other example that didn't compile when I tried.

[Senk]

Hurray! All examples build, just like you promised! You definitely fix issues quickly! I'm going to mark this topic as solved considering the main issue of missing sh-elf-g++ was fixed.

[BlueCrab]

Usually, I'm not this quick at solving issues (as much as I may try to be). I just happened to have the free time, and they were (for the most part) fairly simple.

Glad to hear you've got everything at least seemingly working at this point.