PropGCC build fails on Ubuntu 13.10
SRLM
Posts: 5,045
I tried building on Ubuntu13.10, and it didn't complete. The tail end of the messages are below, and a full log is attached. The root folder is in /home/user/propgcc/propgcc.
This is the STDERR output for the attached logfile:
It looks like colophon and cygnus are missing. I don't know if they were missing in previous versions of Ubuntu (it's always worked, so I've never checked). I've made sure to install all the prereq's mentioned in the Wiki.
make[3]: Entering directory `/home/user/propgcc/build/binutils/bfd/po' ( if test 'x../../../../propgcc/binutils/bfd/po' != 'x.'; then \ posrcprefix='../../../../propgcc/binutils/bfd/'; \ else \ posrcprefix="../"; \ fi; \ rm -f SRC-POTFILES-t SRC-POTFILES \ && (sed -e '/^#/d' \ -e '/^[ ]*$/d' \ -e "s@.*@ $posrcprefix& \\\\@" < ../../../../propgcc/binutils/bfd/po/SRC-POTFILES.in \ | sed -e '$s/\\$//') > SRC-POTFILES-t \ && chmod a-w SRC-POTFILES-t \ && mv SRC-POTFILES-t SRC-POTFILES ) ( rm -f BLD-POTFILES-t BLD-POTFILES \ && (sed -e '/^#/d' \ -e '/^[ ]*$/d' \ -e "s@.*@ ../& \\\\@" < ../../../../propgcc/binutils/bfd/po/BLD-POTFILES.in \ | sed -e '$s/\\$//') > BLD-POTFILES-t \ && chmod a-w BLD-POTFILES-t \ && mv BLD-POTFILES-t BLD-POTFILES ) cd .. \ && CONFIG_FILES=po/Makefile.in:po/Make-in \ CONFIG_HEADERS= /bin/bash ./config.status config.status: creating po/Makefile.in config.status: executing depfiles commands config.status: executing libtool commands config.status: executing default-1 commands config.status: executing bfd_stdint.h commands config.status: executing default commands make[3]: Leaving directory `/home/user/propgcc/build/binutils/bfd/po' make[3]: Entering directory `/home/user/propgcc/build/binutils/bfd/po' make[3]: Nothing to be done for `info'. make[3]: Leaving directory `/home/user/propgcc/build/binutils/bfd/po' make[3]: Entering directory `/home/user/propgcc/build/binutils/bfd' make[3]: Nothing to be done for `info-am'. make[3]: Leaving directory `/home/user/propgcc/build/binutils/bfd' make[2]: *** [info-recursive] Error 1 make[2]: Leaving directory `/home/user/propgcc/build/binutils/bfd' make[1]: *** [all-bfd] Error 2 make[1]: Leaving directory `/home/user/propgcc/build/binutils' make: *** [all] Error 2 binutils make failed. real 0m25.610s user 0m14.622s sys 0m10.610s
This is the STDERR output for the attached logfile:
../../../../propgcc/binutils/bfd/doc/bfd.texinfo:325: unknown command `colophon' ../../../../propgcc/binutils/bfd/doc/bfd.texinfo:336: unknown command `cygnus' make[3]: *** [bfd.info] Error 1 make[2]: *** [info-recursive] Error 1 make[1]: *** [all-bfd] Error 2 make: *** [all] Error 2 real 0m24.782s user 0m14.090s sys 0m10.276s
It looks like colophon and cygnus are missing. I don't know if they were missing in previous versions of Ubuntu (it's always worked, so I've never checked). I've made sure to install all the prereq's mentioned in the Wiki.
Comments
Change line 325 to @@colophon
Change line 336 to [email]doc@@cygnus.com[/email]
To get it to go further you also have to update binutils/ld/ld.texinfo with the same changes.
Then it gives the following errors:
svn checkout svn://gcc.gnu.org/svn/gcc/trunk SomeLocalDir
Ok, as it turns out the easiest solution seems to be to manually downgrade texinfo to 4.13. Make sure that you've removed the current (5.0+) version before continuing. The last command should mention the version. Make sure it's 4.13. Next install PropGCC normally.
Edit: see below for a fix to another bug that pops up.
binutils/bfd/doc/bfd.texinfo:
Change line 325 to @@colophon
Change line 336 to [email]doc@@cygnus.com[/email]
binutils/ld/ld.texinfo
Same changes (different lines, but at bottom)
binutils/gas/doc:
Place all the *.texi files from the binutils main distribution (replace if asked). Make sure that propeller.texi is there!
gcc/gcc/doc/cppopts.texi
Change "@itemx --help" to "@item --help"
The following changes still didn't make it work, but it's where I got to (7.5 minutes into the build):
gcc/gcc/doc/*
Get all the files from the main gcc distribution into a temporary storage space. Next, in the Propeller version, do a search for "propeller" in:
-extend.texi
-invoke.texi
-md.texi
And replace everything Propeller specific in the matching files in the temp space. Then copy to the Propeller version of gcc/gcc/doc/*.
Add to gcc/config/pa/som.h around line 267 (after "#define MAX_OFILE_ALIGNMENT 32768")
/* The SOM linker hardcodes paths into binaries. As a result, dotdots
must be removed from library prefixes to prevent binaries from depending
on the location of the GCC tool directory. The downside is GCC
cannot be moved after installation using a symlink. */
#undef TARGET_ALWAYS_STRIP_DOTDOT
#define TARGET_ALWAYS_STRIP_DOTDOT true
Optional (I think):
gcc/gcc/doc/gcc.texi
Replace (line 87):
@item GNU Press
@tab Website: www.gnupress.org
@item a division of the
@tab General: @tex [email]press@@gnu.org[/email] @end tex
@item Free Software Foundation
@tab Orders: @tex [email]sales@@gnu.org[/email] @end tex
@item 51 Franklin Street, Fifth Floor
@tab Tel 617-542-5942
@item Boston, MA 02110-1301 USA
@tab Fax 617-542-2652
@end multitable
with
@item GNU Press
@tab Website: @uref{http://www.gnupress.org}
@item a division of the
@tab General: @email{press@@gnu.org}
@item Free Software Foundation
@tab Orders: @email{sales@@gnu.org}
@item 51 Franklin Street, Fifth Floor
@tab Tel 617-542-5942
@item Boston, MA 02110-1301 USA
@tab Fax 617-542-2652
change line 580 to memset (statbuf, 0, sizeof (*statbuf));
Source of change: the matching file in
git clone --branch gdb_7_6-branch git://sourceware.org/git/binutils-gdb.git
Oh what? Doesn't Xcode use the Clang/llvm compiler? In that case you have Clang compiling GCC.
I was kind of wondering if that was even possible the other day as GCC has some odd extensions that it looks like the Clang guys don't want to implement.
Interesting, I recently discovered that Clang is in really good shape, supports C++11 well and can compile the Linux kernel and almost every package in Debian. (Hmm...thinks, so I probably already knew Clang can compile GCC if I thought about it
Which was a big surprise to me as it seems like only yesterday I heard of Clang and it was nowhere near complete.
I have been compiling everything I can find with Clang both on x86 and ARM, it works very well and can have much better error reporting, especially when it comes to errors in templated code.
I'm going to have a go at compiling propgcc with Clang on my Debian box.
When is the Parallax Propeller C/C++ compiler going to be Clang/llvm based
On occasion I have peeked at the "Writing an LLVM Backend" document. I can follow along as far as "Create a subclass of the TargetMachine class that describes characteristics of your target machine." soon after that I can feel my brain starting to boil.
So back then at least, GCC would have to be compilable by any generic C compiler. But maybe that has changed - I imagine they could easily rely on cross-target compiling these days to get a compiler onto a new machine. If so, they would be free to use GCCisms in the compiler itself. But originally the GCC source was plain portable C.
-Tor
Ah, yes, you are right. Last century I built Linux From Scratch. http://www.linuxfromscratch.org/
which goes through a similar multi rebuild dance. Of course I was starting from a Linux machine and GCC but the process would have to work when starting off with some other compiler
Funnily enough I have just been through a similar process but moving away from GCC to Clang. First building the Clang/LLVM compiler with GCC. Then rebuilding Clang using Clang.
This is the error messages that seem to be at the head of all the rest of the barfing the make command dies with.
I suspect this may not be what you wanted to hear, but it works for me. The computer doesn't have to change the OS (though I did eventually dump Ubuntu entirely)
Only have to rant that this sort of thing drives me nuts.
You are building binutils there, for example, like an assembler and linker or whatever. How about: "No, I don't want any documentation, and for sure as hell I don't want any texinfo package dependency to build that. Just give me the program dammit"
That texinfo thing has screwed up many a compile recently. And who uses it anyway?
I can't do much but nod in agreement here. I'm fuzzy on what texinfo is and why I need it to build the single tool I need just to load images onto a Propeller. I do know that so far I've burned way more time just trying to fix this issue/bug then I did in modifying the loader code to do what I needed. This is not a dig at the team working on PropGCC it's more of an overall frustration that I run into time and again when building from source on all the various Linux platforms.
#make all(cross-fingers..... #%#$)
an hour or two fiddling
#make all (cross-fingers..... #$%@@#$!#!!!!!!)
an hour or two fiddling
#make all (cross-fin...@$%@$#%@#$%@$%@#$%%@!!!!!!!)
an hour or two fiddling
Sometimes you are victorious after a couple cycles, sometimes it's a dead end you never figure out.
From the previous posts it appears attempts to fix the problem with the 5.2 texinfo are a rabbit-hole that leads to ever-more fixing. Trying to remove texinfo is also a bit of a rabbit-hole because of the package manager on Arch and the fact that it's at the foot of a few dependencies so I have to start ripping out a lot of packages to remove the installed 5.2 version. So right now I'm stuck between a rock and a hard place. Is there a real dependency for building these tools on using texinfo?
It's a possibility I suppose. I could bring up either a Pi running something more friendly to experimentation or setup another BBBlack with another distro to build things with.
The thing is that everything in the Linux world seems to build off of Red Hat/Fedore or Debian as the two primary forks.
Ubuntu began to get creative in odd and seemingly non-standard ways at about 12.12... mayb e covert tendencies to make a commercial version. And so, I reverted to Debian rather than have to dig and dig for why this or that won't work.
You are not alone..
http://www.pclinuxos.com/forum/index.php?topic=116345.0
http://www.linuxquestions.org/questions/linux-from-scratch-13/make-error-in-compiling-binutils-4175476855/
goto propgcc/binutils/bfd/doc/bfd.texinfo:325, replace "@colophon" into "@@colophon"
goto propgcc/binutils/bfd/doc/bfd.texinfo:336, replace "@cygnus" into "@@cygnus"
you will get same problem in "propgcc/binutils/ld/ld.texinfo"