|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
| Thread Tools |
Rating:
|
Display Modes |
|
#16
|
|||
|
|||
|
Re: GCC 4.8 Toolchain
I don't suppose you can detail your exact build configuration (distro, version, file location, partition)? I'm doing this all in a virtual machine, so it's no problem to build a new one to test things out, and if it works under that maybe I can narrow down where this bug is.
|
|
#17
|
|||
|
|||
|
Re: GCC 4.8 Toolchain
Update: I tried the build again, this time on Ubuntu 13.04 and cloning onto an NTFS formatted flash drive. It again failed because it was unable to find <stdio.h>. For reference, here's the last command it attempted to execute:
Code:
/media/frc-build/windows-toolchain-environment/win32/linux-build-gcc-4.8.0/./gcc/xgcc -B/media/frc-build/windows-toolchain-environment/win32/linux-build-gcc-4.8.0/./gcc/ -B/mingw/powerpc-wrs-vxworks/bin/ -B/mingw/powerpc-wrs-vxworks/lib/ -isystem /mingw/powerpc-wrs-vxworks/include -isystem /mingw/powerpc-wrs-vxworks/sys-include -g -O2 -O2 -nostdinc -I `case "/$(MULTIDIR)" in */mrtp*) echo /h ;; *) echo /media/frc-build/windows-toolchain-environment/win32/install-prefix/mingw/powerpc-wrs-vxworks/wind_base/target/h ;; esac` -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -I. -I. -I../.././gcc -I/media/frc-build/windows-toolchain-environment/win32/gcc-4.8.0/libgcc -I/media/frc-build/windows-toolchain-environment/win32/gcc-4.8.0/libgcc/. -I/media/frc-build/windows-toolchain-environment/win32/gcc-4.8.0/libgcc/../gcc -I/media/frc-build/windows-toolchain-environment/win32/gcc-4.8.0/libgcc/../include -DHAVE_CC_TLS -o _ashldi3.o -MT _ashldi3.o -MD -MP -MF _ashldi3.dep -DL_ashldi3 -c /media/frc-build/windows-toolchain-environment/win32/gcc-4.8.0/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS Code:
/bin/bash: MULTIDIR: command not found
/bin/bash: MULTIDIR: command not found
In file included from /media/frc-build/windows-toolchain-environment/win32/gcc-4.8.0/libgcc/libgcc2.c:27:0:
/media/frc-build/windows-toolchain-environment/win32/gcc-4.8.0/libgcc/../gcc/tsystem.h:87:19: fatal error: stdio.h: No such file or directory
#include <stdio.h>
^
compilation terminated.
make[3]: *** [_muldi3.o] Error 1
make[3]: *** Waiting for unfinished jobs....
/bin/bash: MULTIDIR: command not found
In file included from /media/frc-build/windows-toolchain-environment/win32/gcc-4.8.0/libgcc/libgcc2.c:27:0:
/media/frc-build/windows-toolchain-environment/win32/gcc-4.8.0/libgcc/../gcc/tsystem.h:87:19: fatal error: stdio.h: No such file or directory
#include <stdio.h>
^
compilation terminated.
In file included from /media/frc-build/windows-toolchain-environment/win32/gcc-4.8.0/libgcc/libgcc2.c:27:0:
/media/frc-build/windows-toolchain-environment/win32/gcc-4.8.0/libgcc/../gcc/tsystem.h:87:19: fatal error: stdio.h: No such file or directory
#include <stdio.h>
^
compilation terminated.
make[3]: *** [_lshrdi3.o] Error 1
make[3]: *** [_negdi2.o] Error 1
In file included from /media/frc-build/windows-toolchain-environment/win32/gcc-4.8.0/libgcc/libgcc2.c:27:0:
/media/frc-build/windows-toolchain-environment/win32/gcc-4.8.0/libgcc/../gcc/tsystem.h:87:19: fatal error: stdio.h: No such file or directory
#include <stdio.h>
^
compilation terminated.
make[3]: *** [_ashldi3.o] Error 1
make[3]: Leaving directory `/media/frc-build/windows-toolchain-environment/win32/linux-build-gcc-4.8.0/powerpc-wrs-vxworks/libgcc'
make[2]: *** [all-target-libgcc] Error 2
make[2]: Leaving directory `/media/frc-build/windows-toolchain-environment/win32/linux-build-gcc-4.8.0'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/media/frc-build/windows-toolchain-environment/win32/linux-build-gcc-4.8.0'
make: *** [stmp-build-gcc-target] Error 2
|
|
#18
|
||||
|
||||
|
Re: GCC 4.8 Toolchain
I haven't been able to get the linux compiler in linux-build-gcc-4.8.x to build either under most circumstances. I've found that with both the commands in linux.mk and the PKGBUILD files on Arch Linux, it builds when --prefix=/usr is specified in configure, but not when any other prefix is specified. I've tried messing around with --with-sysroot=, --with-headers=, and --disable-bootstrap, but they all cause various errors at different points in the build process.
With the default configure options, it determines that /lib/cpp is how the C preprocessor should be run when building libiberty.a and fails. I applied a patch for vxworks mkdir in libgcov that comes with the Arch Linux PKGBUILD, which got it past that but caused compiler errors while building libstdc++: Code:
/tmp/gcc-test-build/build/powerpc-wrs-vxworks/libstdc++-v3/include/bits/atomic_base.h:228:62: error: invalid type in declaration before ';' token typedef __atomic_base<uintmax_t> atomic_uintmax_t; Last edited by calcmogul : 30-09-2013 at 18:07. |
|
#19
|
||||
|
||||
|
Re: GCC 4.8 Toolchain
In regards to the stdio.h no such file error, try moving the target stmp-gccdist-all to the top of the make targets in linux.mk under "all:". gcc's configure is looking for stdio.h in $(PREFIX)/$(TARGET)/sys-include, which expands to the directory /mingw/powerpc-wrs-vxworks/sys-include, but that folder isn't there until the target stmp-gccdist-all copies sys-include and wind_base there from the zip archive it downloads.
|
|
#20
|
|||
|
|||
|
Re: GCC 4.8 Toolchain
Sadly, rearranging the order of the make targets like that had no effect on the build; it still failed because it was unable to find stdio.h. However, mingw/powerpc-wrs-vxwors/sys-include exists. The build fails during stmp-build-gcc-target. Looking at the configuration, it seems like it should be searching for my actual system headers at this step, because it's building a cross-compiler from the host to powerpc-wrs-vxworks, and so should be using the native gcc and the native system headers. It should just copy the headers from mingw/powerpc-wrs-vxworks/sys-include to $(PREFIX)/include, if I'm reading the GCC docs correctly.
|
|
#21
|
||||
|
||||
|
Re: GCC 4.8 Toolchain
stmp-build-gcc-target is, from what I can tell, bootstrapping a cross compiler to build the target libraries such as libstdc++, libgcc, etc. In the last few days, I was able to get the target libraries to compile and have made some working installers with Wix. I had to patch the gcc source and the headers coming from gccdist. The toolchain works with the exception of the "Relocation value does not fit in 24 bits" error on 8 slot cRIOs, which is due to libraries linked in which are not being built with -mlongcall; on Arch Linux, it was libstdc++ and libgcc, but I'm still trying to find the library responsible for this particular failure. The final installation doesn't have anything in /mingw/include and has no gccdist headers in /mingw/powerpc-wrs-vxworks/include (only c++ standard includes and the WPILib folder). I've submitted a pull request to the windows-toolchain-environment repo which has the patch files and other fixes. These are my modified gccdist recipes:
Code:
stmp-gccdist-scripts: stmp-gccdist-directories
- cp -R $(GCCDIST_ARCHIVE_BASE)/host $(WIND_BASE)
+ cp -dpr --no-preserve=ownership $(GCCDIST_ARCHIVE_BASE)/host $(WIND_BASE)
touch stmp-gccdist-scripts
stmp-gccdist-headers: stmp-gccdist-directories
- cp -R $(GCCDIST_ARCHIVE_BASE)/target/h/. $(TOOL_DIR)/sys-include
- cp -R $(GCCDIST_ARCHIVE_BASE)/target/h/wrn/coreip/. $(WIND_BASE)/target/h
+ cp -dpr --no-preserve=ownership $(GCCDIST_ARCHIVE_BASE)/target/h/. $(WIND_BASE)/target/h
+ cp -r $(WIND_BASE)/target/h/. $(TOOL_DIR)/sys-include
+ cp -r $(WIND_BASE)/target/h/wrn/coreip/. $(WIND_BASE)/target/h
touch stmp-gccdist-headers
Last edited by calcmogul : 06-10-2013 at 02:31. |
|
#22
|
|||
|
|||
|
Re: GCC 4.8 Toolchain
I lost my repo key for the debian repository, so I started over from scratch - I'm sorry if this affects anyone. The URL should be the same but you need to import the new key (again at the same URL).
Much improved amd64 debian builds (now based on jessie), including one last patch into GCC with the upgrade to GCC 4.8.2, better handling of the include files, and fixes for the environment variable system, is now up. If there are any issues let me know. x86 debian to come soon. Sorry for all you RPM/TGZ/Arch folks, but debian testing is still the only officially supported distribution. Other debian based distributions should be binary compatible as most of GCC is statically linked. Finally, new windows builds are here. Many thanks to mathmogul for his major improvements to the build system! The build process is completely automated on my system. frcmake && mingw32-make works to build my teams' old code on my windows box. However, I can't test anything. I need to double-check the build logs w/r/t mlongcall. Windows toolchain (linux component) build specs:
I realized that I had made some symlinks in special places on my filesystem to make the build work previously. However, these are no longer necessary, and I have successfully build without them. As a second announcement, if any of you maintain libraries for FRC, I'll host your packages on the repo! A few points:
I know that FIRST likes having IDE integration, but when a real world CMakeLists.txt is only 8 lines long, which can be easily copied/pasted off the wiki, and it makes it VERY easy to use other teams' libraries, and installation doesn't require sitting around on your computer all day dealing with the WindRiver installation process and license keys... I think this is a superior workflow. I know that Patrick made some significant headway on integrating GDB, so if people want to try and get that to work (check the bitbucket and the wiki), you might be able to get somewhere. |
|
#23
|
|||
|
|||
|
Re: GCC 4.8 Toolchain
Do you know the status of libstdc++ is on this architecture/compiler? I just tried to use std::copysign and got back
Quote:
|
|
#24
|
|||
|
|||
|
Re: GCC 4.8 Toolchain
We're currently working on figuring out what features for c++11 on the library side are available.
A lot of things that seem like they should work don't, and I have to dive into the libstdc++ code to see what's going on... Sorry for the long wait on reply! |
|
#25
|
||||
|
||||
|
Re: GCC 4.8 Toolchain
For anyone who is interested, I've created a Vagrant-based VM configuration that you can run and get a easy to use virtual machine to do your building on. The current configuration sets up the apt configuration and installs the binary packages as recommended on the wiki, and FRCMake seems to work correctly.
It's an Ubuntu 12.04 image, but the binaries seem to work just fine there. I've built the core of RobotPy with it, and the build succeeded without any problems -- though, I haven't ran it on the cRio yet. Get it from the github repo. |
|
#26
|
||||
|
||||
|
Re: GCC 4.8 Toolchain
Quote:
|
|
#27
|
||||
|
||||
|
Re: GCC 4.8 Toolchain
True, I'll change the docs. Vagrant 1.2+ should work. There are various bugs in vagrant that I've ran into over time, so I'd recommend 1.3.5 if you're not going to use 1.4.
|
|
#28
|
||||
|
||||
|
Re: GCC 4.8 Toolchain
Quote:
Code:
Bringing machine 'default' up with 'virtualbox' provider... [default] Clearing any previously set forwarded ports... [Berkshelf] This version of the Berkshelf plugin has not been fully tested on this version of Vagrant. [Berkshelf] You should check for a newer version of vagrant-berkshelf. [Berkshelf] If you encounter any errors with this version, please report them at https://github.com/RiotGames/vagrant-berkshelf/issues [Berkshelf] You can also join the discussion in #berkshelf on Freenode. [Berkshelf] Updating Vagrant's berkshelf: '/home/eric/.berkshelf/default/vagrant/berkshelf-20131223-3824-141h9iv-default' [Berkshelf] Using frc-gcc-vm (0.1.0) [Berkshelf] Using apt (1.7.0) [default] Clearing any previously set network interfaces... [default] Preparing network interfaces based on configuration... [default] Forwarding ports... [default] -- 22 => 2222 (adapter 1) [default] Booting VM... [default] Waiting for machine to boot. This may take a few minutes... The guest machine entered an invalid state while waiting for it to boot. Valid states are 'starting, running'. The machine is in the 'poweroff' state. Please verify everything is configured properly and try again. If the provider you're using has a GUI that comes with it, it is often helpful to open that and watch the machine, since the GUI often has more helpful error messages than Vagrant can retrieve. For example, if you're using VirtualBox, run `vagrant up` while the VirtualBox GUI is open. Also, it might be helpful to note that the "vagrant up" should be done in the directory of the checkout. This is probably obvious to someone who has used vagrant before but I suspect most people haven't. |
|
#29
|
||||
|
||||
|
Re: GCC 4.8 Toolchain
Quote:
![]() You're right, it's a 64-bit guest. If you switch the box name (and the name in the URL) to 'precise32', then you'll get a 32-bit guest. However, it appears that there is not a build of gcc available for 32-bit in the repository. You might try older versions of virtualbox to see if they have the same problems, or google about the mixed host problem. |
|
#30
|
||||
|
||||
|
Re: GCC 4.8 Toolchain
So I got RobotPy to build successfully using the frcmake in the VM I made, but I've noticed that some of the output files are significantly larger than the binaries I built with Wind River. In particular, all of the SIP-based binaries seem to be much larger than they were previously, double or triple the size. Looking at the objdump output, there seems to be a lot more symbols in the new binaries compared to the old binaries, but it seems to be mostly C++ gibberish and duplicate symbols.
My suspicion is that something isn't getting stripped/munched from the object file properly, but I can't tell. For comparison purposes, I've attached the nivision.pyd binary output files if someone wants to compare them. Additionally, I've checked in the CMake build files for RobotPy into the gcc48 branch of https://github.com/robotpy/robotpy.git . |
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|