GCCSDK crosscompiling examples?
Pages: 1 2
Tristan M. (2946) 1036 posts |
Hi. I want to use GCCSDK to write some things and really what I’m after is a few examples of skeletons or simple “Hello, world!” examples for applications and modules. I’ve been searching and can’t find the info I need for doing it from Linux. Because UnixLib is broken for ARMv8 I can’t use gcc in RISC OS, so I’d like to still mess around and write some non-UnixLib programs, and of course modules. While I’m at it, is UnixLib closed source? I can’t find the source anywhere. Only the headers. |
Chris Mahoney (1684) 2100 posts |
The source seems to be here. I can’t answer your other questions as I haven’t used it. |
Tristan M. (2946) 1036 posts |
Thanks! That was really useful. It actually helped me work out where the various parts were in the GCCSDK tree. Still no idea how to do a simple build with GCCSDK though, unless I am meant to stuff it into the autobuilder. I’m more interested in building things without UnixLib right now. |
Steve Fryatt (216) 2046 posts |
It’s not much different to using GCC natively, either on RISC OS or Linux. To start with, you need to be able to find the cross-compiler. If you’ve installed things according to the instructions, you’ll have everything in a ~/GCCSDK folder. I then have a couple of lines in my ~/.bashrc file to set up two system variables to point to the interesting bits (my home folder, ~/, is /home/steve on my system):
You can easily execute these by hand from the terminal while you’re setting things up. With these set up, you can then set up variables to point to the various tools within your makefile. The GCCSDK tools that I use regularly are GCC, Asasm + Strip and Zip (as the latter can add RISC OS filetypes to zipped files). As such, I set four variables up as follows:
You’re now good to use GCC in the normal way. For example:
I’m assuming that you’re familiar with MakeFile syntax; if the above is confusing, then I’ll try and put something simpler together. If you don’t wish to use OSLib, preferring to use the likes of _kernel_swi() and _swix(), then you don’t need to worry about compiling OSLib or including it in the LINKS declaration above. |
Jeffrey Lee (213) 6046 posts |
It’s not much different to using GCC natively, either on RISC OS or Linux. To start with, you need to be able to find the cross-compiler. If you’ve installed things according to the instructions, you’ll have everything in a ~/GCCSDK folder. I then have a couple of lines in my ~/.bashrc file to set up two system variables to point to the interesting bits (my home folder, ~/, is /home/steve on my system): It doesn’t seem to be mentioned anywhere obvious in the documentation, but there’s actually a much easier way of getting (most of) the above. $ cd path/to/gccsdk $ source env/ro-path The ro-path script exports the two GCCSDK paths, as well as a few other environment variables (e.g. $CC and $CXX). But it also adds the env folder to your path, and the env folder contains symlinks for the main compiler binaries. So after executing the above you can just enter ‘gcc’ into the terminal and it will run the cross-compiler instead of your native compiler. This is probably enough to get most simple makefiles and even autoconf/configure based projects to build correctly. There are also some other scripts in the env folder which look like they should be useful in more complex cases (I don’t think I’ve ever had to use them myself). |
Tristan M. (2946) 1036 posts |
This is great! Thank you all so much! Steve, I have to ask you about the bottom bit of your example makefile.
Why is it using RISC OS filesystem conventions? |
Chris Mahoney (1684) 2100 posts |
I presume that that’s a typo and you meant “why isn’t it?” As you’re running the cross compiler under Linux, you need to use Linux/Unix conventions since you’re running everything “natively”. You’d only use RISC OS conventions under RISC OS itself. |
David Pitt (102) 743 posts |
Thanks to Jeffrey’s “much easier way” of getting started and Tristan’s notes I have cross compiled an “Hello World” ELF on Xubuntu which runs on RISC OS, but not on the Raspberry Pi 3 which will be the UnixLib issue. A possible pthreads fix has been committed which led me to jump to the conclusion that autobuilder output might be RPi3 clean. It seems it is not that simple. Sorted It is necessary to explicitly include the |
Chris Gransden (337) 1148 posts |
Once you’ve got the autobuilder up and running you can easily build the native compiler and fixed UnixLib. Everything built statically will just work. make -j4 ronative If you mount the drive using SunFish on RISC OS it’s just a matter of copying the contents of gcc4/release-area/full-ro. If not use, ./create-gcckit -pkg and copy the zip files over from the ‘kits’ folder. |
David Pitt (102) 743 posts |
I now have a Pi3 !GCC running, as briefly tested. (I would have realised that a bit earlier if I had removed the previously loaded NOT RPi3 Shared Libraries DA from memory.) Many thanks for the build notes. |
Tristan M. (2946) 1036 posts |
I won’t save myself the embarrassment. What I said was a little muddled. I was thrown off by seeing ‘!’ and ‘/’ in the same context.
That is great news!
Did you do a build of Sunfish with the newest GCCSDK? It just dumps a stacktrace for me. Moonfish works for me but it seems to have some Pain issues. These are the most recent versions from !PackMan. Anyhow, now that I know the fix has been committed it’s time to wake up the PC and see what I can do to get some of the basic apps built and working on my Pi 3. !PDF is #1 priority for me. e: To answer my own question, building Sunfish from source seems to work fine. Even before when it worked it couldn’t connect to anything because of some bizarre permissions issue. Now it can. It crashed when I tried to dismount a share but besides that it’s nice to have it back. |
Tristan M. (2946) 1036 posts |
Okay I’m raising the white flag on this. I tried LDFLAGS= -static in the makefile among other things and nothing seemed to yield a useful result. I tried compiling without it and !GCC just doing a simple gcc -v with the task size set to 8MB still just yielded a unixlib based stack trace. Sorry! doing a lot of editing here. |
Tristan M. (2946) 1036 posts |
Whatever magic there was, it’s vanished. I can’t get !GCC working again. Even the simple “Hello, World!” elf executable no longer works. The problem points to UnixLib but I have no idea why. I’m using the one I built. |
David Pitt (102) 743 posts |
My !GCC build is still working here. @Tristan and so did yours, briefly, I believe. Just be be clear, what is meant by “UnixLib” in terms of this build. I know it is the root of the problem but what actual files does it refer to in this case. In addition to the newly built !GCC the newly built !SharedLibs must also be used, the previous, not ARMv8, !SharedLibs will fail and if that has already been loaded into memory as seen in the Tasks display then a reboot will get rid of it. The SharedULib module in !System is not the issue. Sorry if that is stating the obvious but it is an error I made here initially giving rise to an “it’s stopped working” thing. I didn’t use Sunfish to move the build from the autbuilder but copied zips the old fashioned way, HTH. OTOH I failed with !PDF. |
Tristan M. (2946) 1036 posts |
!PDF has some kind of problem with libsplash. I’m still trying to work out the finer details of the autobuilder so I haven’t tackled it yet. On the bright side, the khronos module compiles! Whoever worked that magic, Thanks! Okay, here’s where I’m at. Straight off when I copied the new !GCC over I merged the !system which added the new DRenderer and SharedULib modules. I confirmed they were there. I also put !SharedLibs on the partition and ran it after making sure I’d deleted the old one. Let’s just forget about that last bit for now. Here’s where it gets a little strange. I used GCCSDK to compile a hello world in both linked and static versions. Confirmed by file size. 14kB and 1.1 MB respectively choke I’m generating the packages to copy over btw. Don’t worry about that. It’s force of habit from working with other systems with metadata that needs to be preserved. e: Little tip to save a few seconds. Crosscompiling “make” needs the “autopoint” package installed. e again: I tweaked the mkdir patch in my copy of coreutils and it builds and works fine now. Fighting with the unwillingness to un-tar the archive in bash now. |
Ronald May (387) 407 posts |
I also put !SharedLibs on the partition and ran it after making sure I’d deleted the old one. It has to be filer run everytime you start the machine eg. putting it in Boot:Resources will take care of this, Also !GCC must be seen by the filer for gcc to be found in a taskwindow. Beware if you have a few versions of either check which one has the active paths. |
Tristan M. (2946) 1036 posts |
Thanks Ronald. That was actually very helpful. On checking I’d left a pre-Pi3 compatible !SharedLibs in Boot:Resources. It was only a week or so old but that’s still old enough. !GCC now works without issue. While we’re handling questions which nobody seems to ask, or at least answer clearly. What is “amu_machine”? I’d like to assemble Tank’s GPIO source but it wants that. Another thing. I don’t mind puttering around, tweaking patches for some of the autobuilder stuff to get it to build again. Who do I talk to / where do I look / what do I do to get the files into the wild? I saw that there are volunteers wanted no matter how small the job, so considering I’m doing it for myself anyway I might as well share. I’m a RISC OS newbie so I have to keep it simple. Have to say this thread is pure gold. It answers so many questions on getting toolchains up and running, using the autobuilder and working on non autobuilder based projects. |
David Pitt (102) 743 posts |
Returning to the PDF build. The first error is :- fatal error: ft2build.h: No such file or directory The ‘fix’ is to get The next snag was a bit more defeating. gcc -Wall -DACORN -D__APCS_32 -O3 -I . -I ../GuiLib/Task -I ../GuiLib/Wimp -I../GuiLib/Util -I../GuiLib/GuiFlex -I../DrawFile -I ../xpdf -I ../xpdf/xpdf/xpdf -I ../xpdf/xpdf/goo -I ../xpdf/xpdf/fofi -I ../xpdf/xpdf/splash -static -o !RunImage,e1f Bookmarks.o DrawOutputFont.o PageHistory.o ChoicesFilePath.o FileInfo.o Password.o Clip.o PdfDocEncoding.o ColourSpace.o PrintDialog.o Document.o Find.o Printer.o DocView.o main.o Save.o DocViewChoices.o Node.o UnicodeToAcornMap.o DocViewToolbar.o NumberField.o UnicodeToAcornMapData.o DrawOutputDevice.o outline.o UriDispatch.o -L ../DrawFile -lDrawFile -L ../GuiLib/GuiFlex -lGuiFlex -L ../GuiLib/Task -lGuiTask -L ../GuiLib/Util -lGuiUtil -L ../GuiLib/Wimp -lGuiWimp -L ../xpdf -lpdf -L ../xpdf/xpdf/goo -lGoo -L ../xpdf/xpdf/fofi -lfofi -L ../xpdf/xpdf/splash -lsplash -L/linux1/gccsdk/env/lib -lfreetype -lpng -lz -lstdc++ /media/pittdj/GCCSDK/cross/lib/gcc/arm-unknown-riscos/4.7.4/../../../../arm-unknown-riscos/bin/ld: cannot find -lpdf /media/pittdj/GCCSDK/cross/lib/gcc/arm-unknown-riscos/4.7.4/../../../../arm-unknown-riscos/bin/ld: cannot find -lGoo /media/pittdj/GCCSDK/cross/lib/gcc/arm-unknown-riscos/4.7.4/../../../../arm-unknown-riscos/bin/ld: cannot find -lfofi /media/pittdj/GCCSDK/cross/lib/gcc/arm-unknown-riscos/4.7.4/../../../../arm-unknown-riscos/bin/ld: cannot find -lsplash /media/pittdj/GCCSDK/cross/lib/gcc/arm-unknown-riscos/4.7.4/../../../../arm-unknown-riscos/bin/ld: cannot find -lfreetype /media/pittdj/GCCSDK/cross/lib/gcc/arm-unknown-riscos/4.7.4/../../../../arm-unknown-riscos/bin/ld: cannot find -lpng /media/pittdj/GCCSDK/cross/lib/gcc/arm-unknown-riscos/4.7.4/../../../../arm-unknown-riscos/bin/ld: cannot find -lz collect2: error: ld returned 1 exit status make[1]: *** [!RunImage] Error 1 make[1]: Leaving directory `/media/pittdj/GCCSDK/build/pdf/trunk/pdf' make: *** [!RunImage] Error 2 make: *** Waiting for unfinished jobs.... |
Chris Mahoney (1684) 2100 posts |
It’s an alias set up by the ROM build system. You can “fake” it with: Set alias$amu_machine amu -E %*0 |
Ronald May (387) 407 posts |
David said The next snag was a bit more defeating.But to crosscompile, shouldn’t you be using /media/pittdj/GCCSDK/env/gcc If you look in env you should see the shortcuts and the wrappers for the various gcc binaries. That would also explain why your output has been going to /usr/include instead of env |
Ronald May (387) 407 posts |
Tristan said One thing I’d like to know is whether it is possible to turn the gaze of the autobuilder toward some local files? I’d like to avoid running a local git or SVN server if I could.Lately I have usen FTPc by Chris and Tim Ballance. There is an accompaning frontend by Fred Graute, you can use without for basic use, By putting the tar in the root directory on my RISC OS machine and setting the first line in setvars to AB_URL=ftp://<ip>/<tarname> it retreives it locally with a minimum of fuss. file:// is not supported as the URL. but I think it can be done another way (that eludes me)There is a GCCSDK mailing list BTW. |
Tristan M. (2946) 1036 posts |
I’m not around very often so my replies are pretty sporadic. I’m actually plagued by:
bzip2 in this example can be replaced with x because it’s various programs that spit that exact error for various autobuilds. The constant is whenever that appears, sometimes one of the very first lines, the compile will try to complete but fall apart a little later. My problem is I can’t find where the syntax error is actually coming from. Chris, thanks for that. Still couldn’t get GPIO to make. I’ll work on it later. Ronald, I didn’t know about the GCCSDK mailing list. Thanks. I have to say this thread has been great. It’s helped turn RISC OS on my Pi 3 into something useful. I’ve invested a ridiculous number of hours into working out how to get it working properly only to encounter roadblocks almost entirely due to the extreme difficulty of finding information. It’s probably the real showstopper for a lot of people. It’s probably going to be at least a few days before I can do much more of anything but I’m going to see what I can do. |
Chris Mahoney (1684) 2100 posts |
I have to agree with you there. The DDE includes thousands of pages of documentation. GCC, on the other hand… |
David Pitt (102) 743 posts |
I undefeated apparently ‘missing’ libraries by copying Ubuntu’s versions into the autobuilder’s However I am stuck with this now! /media/pittdj/GCCSDK/env/lib/libfreetype.a: error adding symbols: File format not recognized I did manage to build
This is a second ext4 partion on I am using 64bit Ubuntu 14.04 on VirtualBox on an iMac. |
Chris Gransden (337) 1148 posts |
I’ve updated PDF in the autobuilder so it should now build successfully. If you haven’t done so already create the below folder in /media/pittdj/GCCSDK mkdir build The create a file ‘build-setvars’ in ‘build’ with the following, GCCSDK_INSTALL_CROSSBIN=/media/pittdj/GCCSDK/cross/bin GCCSDK_INSTALL_ENV=/media/pittdj/GCCSDK/env RO_SHAREDLIBS=no AB_ELFBUILD=yes Change to ‘RO_SHAREDLIBS=yes’ if you also want to build with shared libraries. Then to build a package just type e.g., ../autobuilder/build -v pdf |
Pages: 1 2