Chief Delphi - Alternate GCC Toolchain

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)

- Programming (http://www.chiefdelphi.com/forums/forumdisplay.php?f=51)

- - Alternate GCC Toolchain (http://www.chiefdelphi.com/forums/showthread.php?t=109385)

Re: Alternate GCC Toolchain

I've successfully compiled GCC and friends, and can use frcmake to compile robot code successfully. However, I can't seem to figure out how to compile another project that uses autotools (./configure), it always fails on trying to find pthreads, with the last screenfull saying "checking for pthread_***... no" and ending with 'configure: WARNING: "Don't know how to find pthread library on your system -- thread support disabled"'

I can however compile using frcmake pthread stuff, so I think its just a matter of a missing path/configuration

here is my current command:

Code:

LDFLAGS=-L/usr/powerpc-wrs-vxworks/lib/ CFLAGS='-I/usr/powerpc-wrs-vxworks/include/:/usr/powerpc-wrs-vxworks/sys-include/ -mcpu=603 -mstrict-align -mlongcall -nostdlib -ansi -Wall  -DCPU=PPC603 -DTOOL_FAMILY=gnu -DTOOL=gnu -D_WRS_KERNEL' PATH=/usr/powerpc-wrs-vxworks/bin:$PATH ./configure --host=powerpc-wrs-vxworks

I've never done anything more than basic cross compiling before, so i'm rather lost...

UPDATE: I figured it out. configure was resetting my LIBS for several things, '-lm' for math, and '-lpthread' for pthreads. Is there a way to have it ignore these libraries since they seem to be built in?

Re: Alternate GCC Toolchain

frcmake link for those (like me) who end up googling around.

Don't add the -L to LDFLAGS and that -I to CFLAGS : those are the defaults which the compiler will already use.

The other CFLAGS _may_ be needed. Specifically the -m* options are probably needed, the -D* options depend on how funky vxworks' headers are, and the others could be omitted based on preference. I don't _think_ '-nostdlib' is needed, though I might be wrong on that.

I tend to set PATH globally (in bashrc or otherwise), but setting it there is valid. Actually, instead of setting path, passing --prefix=/usr/powerpc-wrs-vxworks (in your case) probably makes more sense.

Essentially, I'd try the following and then tweak it when it doesn't work because someone screwed up their build system.

Code:

CFLAGS='-mcpu=603 -mstrict-align -mlongcall -DCPU=PPC603 -DTOOL_FAMILY=gnu -DTOOL=gnu -D_WRS_KERNEL' ./configure --host=powerpc-wrs-vxworks --prefix=/usr/powerpc-wrs-vxworks

(this all comes with the caveat that I've never built code that ran on a cRIO).

Edit: Digging a bit more, _WRS_KERNEL_, TOOL_FAMILY, and CPU are defined properly without the need for -D*.
(CPU is PPC604 unless -mcpu=603 is passed, which is strange given the --with-cpu-PPC603 configure option was used)

Potentially bringing it down to:

Code:

CFLAGS='-mcpu=603 -mstrict-align -mlongcall -DTOOL=gnu' ./configure --host=powerpc-wrs-vxworks --prefix=/usr/powerpc-wrs-vxworks

Re: Alternate GCC Toolchain

I must say, this is very cool. Has anyone gotten GDB or any debugging working yet?

Re: Alternate GCC Toolchain

Quote:

Originally Posted by byteit101 (Post 1236322)

Code:

LDFLAGS=-L/usr/powerpc-wrs-vxworks/lib/ CFLAGS='-I/usr/powerpc-wrs-vxworks/include/:/usr/powerpc-wrs-vxworks/sys-include/ -mcpu=603 -mstrict-align -mlongcall -nostdlib -ansi -Wall  -DCPU=PPC603 -DTOOL_FAMILY=gnu -DTOOL=gnu -D_WRS_KERNEL' PATH=/usr/powerpc-wrs-vxworks/bin:$PATH ./configure --host=powerpc-wrs-vxworks

I'm glad you figured it out. Just a warning though - when you try and put that on a robot it might fail, reason being that the link process that frcmake uses (and hides from you) is relatively strange.

Here's an explanation of what the cmake-based buildchain does to link your robot code module:

1) links as normal, without any libraries
2) statically links in the standard library
3) runs a script called "munch"
4) links the output of (2) with the output of (3)
5) runs a script called stripsyms

Note: The default build toolchain does (1) and (3) and then links them together

An explanation for munch: this finds all of the constructors and destructors of global or static objects in the binary and creates a special vxworks data structure that will allow vxworks to run these.

Also, with the new toolchain, we link the necessary standard libraries statically. In the default implementation, the standard libraries is linked dynamically, and vxworks already loads a copy of the standard library into memory, so your code sees these symbols and works. However, because of any incompatibilities between the old and new versions at a binary level, we include our own copy. This is where stripsyms comes in

Stripsyms is necessary in order to localize (think hide) our copy of the vxworks standard library from the rest of the system. This way, when vxworks loads our code, it doesn't load the symbols from our copy of the standard library into memory, so the rest of the OS can pretend that our copy doesn't exist.

This manual linking and processing is the reason why '-nostdlib' is necessary - don't want to prematurely link in something twice. It's not the most elegant way to do things, but it's the way that worked for me. At the end of the 2012 season I spent quite a bit of time fiddling with this, and it took a *long* time before I could finally get everything to cooperate and run successfully.

Thus, any third-party code might require some special coaxing before it'll work on a real robot :(

Also, I am relying on the community to test this project. It still hasn't been vigorously tested in a production environment using all the features and possible corner cases. Right now I am not a good maintainer as my time is severely limited and I do not have access to a cRIO to run code on :(

I'm hoping that with a bit of testing, once GCC 4.8 is released this can be sufficiently mature to offer to teams as a stable alternative to the official toolchains and the UCPP project (a great project, but with different aims) for real robot code (not just to play with). Though, if anyone *is* using this on their robot, I'm eager to hear how it turns out!

Also, as a bit of good news, my final patch for GCC got accepted (though for 4.8.1, not 4.8.0 :/). There's still no real support for any other languages (fortran is the closest I think, but when I tried to make it gcc's build system acts strangely). Don't worry though, that patch relates to a corner case in thread specific data, so for 99% of people 4.8.0 should be safe.

Quote:

I must say, this is very cool. Has anyone gotten GDB or any debugging working yet?

I'm glad you think it's cool too :)

No, I haven't gotten GDB working. There's a couple of different ways to attack the issue, and I'm not sure what's best.

Re: Alternate GCC Toolchain

Can you link to the patch that is going into 4.8.1?

Re: Alternate GCC Toolchain

It's uber trivial (has to do with neglecting to pass an argument to a function, that's it), but here you go: http://article.gmane.org/gmane.comp.gcc.patches/281127/

Re: Alternate GCC Toolchain

Alright, I got it to compile, but I think I might have issues. The cmake scripts depend on "/usr/powerpc-wrs-vxworks/lib/libstdc++.a" and "/usr/powerpc-wrs-vxworks/lib/libsupc++.a" existing, but post-install, they are nowhere to be found. Did I miss a step? Or are they added by the debian package that I cannot use?

Re: Alternate GCC Toolchain

So, it turns out I (or we) haven't actually been building with libstdc++-v3 enabled, because the flag is "--enable-libstdcxx" not "--enable-libstdc++-v3". As I'm pretty sure it was being built with 4.7.x, my guess is that the flag got changed in 4.8.

In short, this is my current gcc configure (I've also fiddled with static & shared, you could leave those as they were previously set if there are issues in practice):

Code:

        FLAGS_FOR_TARGET="-isystem $PREFIX/powerpc-wrs-vxworks/sys-include/wrn/coreip"



        CFLAGS_FOR_TARGET="$FLAGS_FOR_TARGET"\

        CXXFLAGS_FOR_TARGET="$FLAGS_FOR_TARGET" \

        "$SRC/gcc-$GCC_VERSION/configure" \

            --prefix="$PREFIX" \

            --target=powerpc-wrs-vxworks \

            --with-gnu-as \

            --with-gnu-ld \

            --with-headers="$WIND_BASE/target/h" \

            --disable-libssp \

            --disable-multilib \

            --with-float=hard \

            --enable-languages=c,c++ \

            --enable-threads=vxworks \

            --enable-libstdcxx \

            --without-gconv \

            --disable-libgomp \

            --disable-nls \

            --disable-libmudflap \

            --with-cpu-PPC603 \

            --enable-static \

            --enable-shared

Re: Alternate GCC Toolchain

I finally figured out what was wrong with the symlinking! In the second step, we make the directory "/usr/powerpc-wrs-vxworks/include". So, when we try to make a symlink with the same name later:

Code:

ln -s sys-include/wrn/coreip /usr/powerpc-wrs-vxworks/include

It instead is placed inside that directory as a symlink called "coreip" which is now referencing an invalid location. If that directory is never created, then everything builds as expected.

Re: Alternate GCC Toolchain

Does anyone have an example of a CMakeLists.txt file for a robot project? I'm a little lost on what to do, and being able to see one would help greatly.

Re: Alternate GCC Toolchain

With my setup, I have:

Code:

cmake_minimum_required(VERSION 2.8)



include(FRCDeploy)



project(GUILLOTINE)



file(GLOB_RECURSE SOURCE_CODE *.cpp)



find_package(WPILib)



include_directories(${WPILIB_INCLUDE_DIRS})



add_executable(612-code ${SOURCE_CODE})



target_link_libraries(612-code ${WPILIB_LIBRARY})



add_make_deploy(612-code 10.6.12.2)

Let me know if a similar setup causes any issues for you, and if it will run on real hardware. If it doesn't, please supply a build log using make VERBOSE=1 (remember to make clean first), your CMakeLists.txt file, and a log of netconsole output (if applicable).

Re: Alternate GCC Toolchain

Thanks for the help!

Re: Alternate GCC Toolchain

Alright, one final thing. I seem to be missing "/usr/powerpc-wrs-vxworks/share/ldscripts/dkm.ld". Where is this supposed to come from? I didn't see it in any of the git repos and it didn't look like it was generated by any of the CMakeLists files. I'm probably missing something obvious.

Re: Alternate GCC Toolchain

It's generated by my wrs-headers-installer install script. You can see it near the bottom of that script. Link: https://github.com/rbmj/wrs-headers-...ebian/postinst

Re: Alternate GCC Toolchain

Has anyone been able to build this with Ubuntu 12.04? (x86_64)
I was able to build it fine on both of my Arch Linux machines, but no luck on Ubuntu.
Here is one of the errors while compiling gcc-build (with "make -j4 inhibit_libc=true"):

Quote:

g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -W c
ast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE
-I. -Ibuild -I../../gcc-master/gcc -I../../gcc-master/gcc/build -I../../gcc-master/gcc/../include -I../../gcc-master/gcc/../libcpp/include -I../../gcc -
master/gcc/../libdecnumber -I../../gcc-master/gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc-master/gcc/../libbacktrace \
-DBASEVER="\"4.8.0\"" -DDATESTAMP="\" 20130227\"" \
-DREVISION="\"\"" \
-DDEVPHASE="\" (experimental)\"" -DPKGVERSION="\"(GCC) \"" \
-DBUGURL="\"<http://gcc.gnu.org/bugs.html>\"" -o build/version.o ../../gcc-master/gcc/version.c
/usr/powerpc-wrs-vxworks/bin/as: unrecognized option '--64'
make[2]: *** [build/version.o] Error 1
make[2]: *** Waiting for unfinished jobs....
/bin/bash ../../gcc-master/gcc/../move-if-change tmp-optionlist optionlist
echo timestamp > s-options
make[2]: *** wait: No child processes. Stop.
make[1]: *** [all-gcc] Error 2
make[1]: Leaving directory `/home/wmeng/vxworks-gcc/gcc-build'
make: *** [all] Error 2