|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
|
|
Thread Tools | Rate Thread | Display Modes |
|
|
|
#1
|
|||
|
|||
|
Re: Custom C++ Toolchain
WIND_BASE doesn't matter anymore. It just needs to be defined to something. I just say export WIND_BASE='asdf'. If you want to be 'proper' about it, you can set WIND_BASE to /usr/local/powerpc-wrs-vxworks/wind_base
|
|
#2
|
|||
|
|||
|
Re: Custom C++ Toolchain
Okay, then, I guess I got confused because when I tried setting it myself, I got a different error, which I interpreted to be because I had an incorrect setting for that variable
![]() I have it working now (I think... I have yet to try it on the robot). However, I did have to make some symbolic links to make it work. In particular, I had to make the following links: Code:
lrwxrwxrwx 1 root root 15 May 26 12:49 /usr/local/powerpc-wrs-vxworks/host -> wind_base/host/ lrwxrwxrwx 1 root root 11 May 26 12:48 /usr/local/powerpc-wrs-vxworks/lib/libWPILib.a -> libwpilib.a lrwxrwxrwx 1 root root 18 May 26 12:43 /usr/local/powerpc-wrs-vxworks/munch.sh -> wind_base/munch.sh lrwxrwxrwx 1 root root 23 May 26 12:46 /usr/local/powerpc-wrs-vxworks/strip_syms.sh -> wind_base/strip_syms.sh |
|
#3
|
||||
|
||||
|
Re: Custom C++ Toolchain
This is awesome, and I hope I'll be programming on Linux come next season.
I'm trying to set up this toolchain on a 64-bit install of Archlinux, and I'm getting some errors after
Maybe this is something of note: while running Code:
cmake /home/azrathud/vxworks-c++-toolchain/project -DCMAKE_TOOLCHAIN_FILE=/home/ azrathud/vxworks-c++-toolchain/cmake_vxworks/vxworks_toolchain.cmake I'm trying to compile last season's code which is in the src directory specified in the CMakeLists.txt From the errors, I think gcc cannot find the header files in /usr/local/powerpc-wrs-vxworks/sys-include Code:
In file included from /home/azrathud/vxworks-c++-toolchain/project/wpilib/ErrorBase.h:12:0,
from /home/azrathud/vxworks-c++-toolchain/project/wpilib/Commands/Command.h:10,
from /home/azrathud/vxworks-c++-toolchain/project/src/CommandBase.h:4,
from /home/azrathud/vxworks-c++-toolchain/project/src/CommandBase.cpp:1:
/home/azrathud/vxworks-c++-toolchain/project/wpilib/Error.h:13:21: fatal error: vxWorks.h: No such file or directory
compilation terminated.
make[2]: *** [CMakeFiles/FRC_UserProgram.dir/src/CommandBase.cpp.o] Error 1
make[1]: *** [CMakeFiles/FRC_UserProgram.dir/all] Error 2
make: *** [all] Error 2
Code:
cmake_minimum_required(VERSION 2.8)
project(FRC)
aux_source_directory(./src FRC_SOURCES) # I'll just run cmake all the time to
# make sure new files are added
set(FRC_INCLUDES ${WPILIB_INCLUDE_DIR} wpilib ${TOOLCHAIN_PREFIX}/sys-include ) #defined by toolchain
set(FRC_LIBS ${WPILIB_LIBRARY}) # defined by toolchain
add_executable(FRC_UserProgram ${FRC_SOURCES})
set_target_properties(FRC_UserProgram PROPERTIES SUFFIX .out)
target_link_libraries(FRC_UserProgram ${FRC_LIBS})
include_directories(${FRC_INCLUDES})
|
|
#4
|
|||
|
|||
|
Re: Custom C++ Toolchain
Quote:
Quote:
The final option is that that code worked on windows because windows is a non-case-sensitive filesystem. Check your capitalization (vxWorks.h maybe?) Quote:
|
|
#5
|
|||
|
|||
|
Re: Custom C++ Toolchain
OK, so a few slight changes to the build process.
headers-build.patch is no longer necessary. Instead, best solution (read: least kludgey) is to manually copy gccdist/WindRiver/vxworks-6.3/target/h to /usr/powerpc-wrs-vxworks/sys-include, and then symlink /usr/powerpc-wrs-vxworks/include to sys-include/wrn/coreip. Yes, this is less kludgey. Actually all of the patches that are there have been deprecated. The latest GCC incorporates some, and there are others that fix things "better". These haven't been incorporated into mainline yet, but the main issue is that I'm going off to school and won't have internet until late august (no working around this either). So I'm hoping that somebody can make sure that the work is not lost and that these make it in. [1] is approved, but not yet committed, and handles all of the patches to the WRS headers inside of GCC through the fixincludes process. It is a patch series, of which every patch depends on the first in the series. [2] is also approved, but not yet committed, and allows one to force a build of libstdc++-v3 with --enable-libstdc++-v3 passed to configure. A fix for the first gcov issue (obvious) is at [3]. A fix for the second gcov issue (approved, not committed) is at [4]. With those things done correctly, a complete build works. The other issue is that some of the targets appear to be mis-configuring themselves, as they are allowing implicit declaration of functions in the configure process, which results in bad detection of the target platform's available functions. Hopefully somebody can fix this :-D. I'm looking for someone to take this over, at least until the regular school year starts, at which point I should be able to maintain everything again (at least for a little while). [1]: http://gcc.gnu.org/ml/gcc-patches/2012-06/msg00382.html [2]: http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01525.html [3]: http://gcc.gnu.org/ml/gcc-patches/2012-06/msg01508.html [4]: http://gcc.gnu.org/ml/gcc-patches/2012-06/msg01548.html I'm going to try and get one of the GCC maintainers to adopt this, but if the conversation doesn't say committed, then it means I wasn't annoying enough. NOTE: if you look at a patch message and it says a certain file needs to be regenerated, then you'll need to do that otherwise things won't work. The configure files can be regened with autoconf2.64, and the fixincl.x file can be regened by going into the fixincludes directory of gcc and running ./genfixes. |
|
#6
|
||||
|
||||
|
Re: Custom C++ Toolchain
It would be nice if you put the realpath dependency more prominently in the first post. It doesn't come by default with Ubuntu (the most popular linux distribution, and common among newbies), and the error message when you don't have it is pretty opaque (It'll complain about it a few times, but start downloading anyway, only to fatal later.)
Last edited by nightpool : 17-08-2012 at 17:50. |
|
#7
|
|||
|
|||
|
Re: Custom C++ Toolchain
I get the following error when running the make command.
Code:
couldn't read file "/usr/local/powerpc-wrs-vxworks/host/resource/hutils/tcl/munch.tcl": no such file or directory The frc_userprogram still appears to build. Is it alright to just ignore this error? Edit: So I decided to try and deploy the frc_userprogram.out to the robot. I used the wput, reset the robot, and then on the driver station it said no robot code. I checked to make sure the program got on via the web-ftp interface. In addition to that, I also flashed the v43 image... Included is the output from the cmake and make commands. Last edited by agartner01 : 27-09-2012 at 02:20. |
|
#8
|
|||
|
|||
|
Re: Custom C++ Toolchain
@agartner01: That's due to a bug in the installation, which will be fixed when I come out with a new release (I'm waiting on some patches upstream right now). Read flameout's post and see if that helps.
|
|
#9
|
|||
|
|||
|
Re: Custom C++ Toolchain
Also, If you still have difficulty, please post NetConsole output. That usually helps. But because of some bugs in the cmake files you have to make those symlinks.
|
|
#10
|
|||
|
|||
|
Re: Custom C++ Toolchain
Quote:
EDIT: Somehow I managed to miss your message. I'll get the netconsole output and post it... Last edited by agartner01 : 27-09-2012 at 15:00. Reason: Noticed other message |
|
#11
|
|||
|
|||
|
Re: Custom C++ Toolchain
Here's my netcosole output. There are two files. One without any program. One with the Simple Template deployed (built on linux).
Edit: I added the log from a normal WindRiver program too... Last edited by agartner01 : 27-09-2012 at 19:19. Reason: Added File |
|
#12
|
||||
|
||||
|
Re: Custom C++ Toolchain
I noticed that the last commits to the the repositories on github were quite a while ago despite the last posts in the thread being relatively recent. Are they still up to date?
|
|
#13
|
|||
|
|||
|
Re: Custom C++ Toolchain
@rbmj any thoughts?
|
|
#14
|
||||
|
||||
|
Re: Custom C++ Toolchain
To anybody that's still dealing with this, I've posted some reworking and numerous bugfixes to rbmj's cmake toolchain. Off of the top of my head:
I'd also like to give a little shoutout to Ross Light's frctool, which I'm using to push the FRC_UserProgram.out file up to the cRIO. I'm putting in a pull request to rbmj as we speak, but if anybody wants to see my changes now, and any future changes, my fork of cmake_vxworks can be found at https://github.com/mcoffin/cmake_vxworks. |
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|