Build failures w/RSB

[Doug Hawkins]

Hi,

I put my questions at the bottom.  Intervening is "reference" material.

I recently read about RTEMS and it seems like a great addition to my
project (on a TI LaunchPad), but I'm having trouble building it.  I'm
running Linux Mint Debian Edition 64bit.

I cloned the git repository for RTEMS and tried to configure it (but
automake was a newer version, so there were many warnings). Then I noticed
the comments about RTEMS Source Builder and thought that might be a useful
way to proceed, since it integrates many of the other packages I'm using
(newlib, gdb, etc.).

My first question that I could not find in the documentation (
https://ftp.rtems.org/pub/rtems/people/chrisj/source-builder/source-builder.html):
How can I take advantage of the hundreds of MB's I've already downloaded?
Too late for me, but an answer might help someone else.

I ran sb-check and everything was fine.  Then gritted my teeth and ran
sb-set-builder and re-downloaded everything. But it failed at an "#include
<zlib.h>" while compiling gcc-4.9.2: lto_compress.c... I found the header
in the gcc tree (should have been <zlib/zlib.h> and re-ran "sb-set-builder".

Since everything seems to be reset, my <zlib.h> code change was cast out,
so the failure occurred again. I finally decided to try installing
"zlib1g-dev" package on my system -- that got me through this pickle,
though I thought it should look for the local file.

I also tried the --no-clean and --no-download options, to see if that would
speed up this re-cycling.  But then I learned that not everything was
already downloaded, so the next failure occurred when the gdb source
package wasn't found.  Each "build" cycle costs me 25 minutes on my
four-core i7 machine.

Re-starting without the --no-download & --no-clean options (I've given up
on "optimizing" this process) -- next failure is telling me that python2.7
doesn't exist (it is installed on my system).  I've spent the last couple
hours searching through configure code & run logs to try to understand what
part of python2.7 it needs.

I did find the gdb configure call just before the failure, but when I
re-ran it, it completed successfully, duplicating the log messages up to,
but except the last 40 lines or so.  The start of that sequence (which
seemed too generic to locate) was:

checking whether NLS is requested... no
checking whether makeinfo --split-size=5000000 supports @click... yes
checking for default auto-load directory... $debugdir:$datadir/auto-load
checking for default auto-load safe-path... $debugdir:$datadir/auto-load

I've finally given up!  Here are the remaining questions running through my
mind.

1) Is there any way I can optimize the compile process (not rebuild
everything when a failure occurs)?  Specifically: how do I "resume"
sb-set-builder?  It appears that I have to check all repositories & rebuild
everything each time I run it.

2) When a failure occurs, how can I locate the "real" problem and find
information on how to resolve it?  It seems that the source-builder is too
complex & doesn't have enough documentation for me to dig deep enough into
the sorts of problems I'm encountering.  On other "meta-builders" I've
worked with, there is usually a large header pushed into the log file for
each execution segment, with all the necessary options to re-run that
segment manually, but I couldn't find anything like that in the log file.

I had a look through some of set-builder's python code, but I'd need more
documentation there to understand some of the structures (I was hoping to
redirect the sources to my already existing repositories).

My log file is over 90MB now, the error log files are each about 280kB.  I
could compress them and send, if needed, but won't do that until requested.

Any help that can be offered would be greatly appreciated.

Thanks!
Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20150322/6ca01095/attachment.html>