Re: [gccsdk] GCC: bits/c++config.h

On 06/02/2015 22:15, WPB wrote:
> On Fri, 06 Feb 2015 17:14:53 -0000, Duncan Moore <duncan.moore@gmx.com>
> wrote:
>
>> On 06/02/2015 07:34, WPB wrote:
>>> I'm currently hitting an error when creating the dependencies file:
>>>
>>> Fatal error: bits/c++config.h: No such file or directory
>>>
>>> And it's true, when I look inside !GCC in include.c++.4/7/4.bits.h, I
>>> can
>>> see no such file. There's "c++0x_warning", but that's the closest. Is
>>> this
>>> an omission from the 4.7.4 distribution?
>> You say the error is when creating dependency files. I assume it's OK if
>> you're not using dependency files?
> Actually, it's generating a single dependency file for the whole project
> at once.
>

A single dependency file? From a different thread, you're using:

g++ -M $(CPPFLAGS) $(SRC) > $(DEPSFILE)

So I'm guessing that for each 'make' invocation you're running gcc once
to create all the dependency files, and then again for each source that
has changed, to compile it. Is that correct? (If it's not, then ignore
this next bit). That's inefficient because you have to pre-process the
whole project each time any source file changes (or maybe even if no
source files have changed). It's much more efficient to just generate
the dependency files as a side effect of the compilation, ready for the
next invocation of 'make'. This works because:

If a dependency file needs to be updated then so does the
corresponding object file.
A side-effect of updating an object file is to update the
corresponding dependency file.
Therefore, if the object files are updated when necessary then so
are the dependency files.

This is how my Makefile in the 'make' zip file works.

>>> Also, as the source I'm trying to compile is in "Unix" directory layout
>>> (no "c", "h" subdirectories, etc., just everything in one flat "src"
>>> directory),
>> I've never tried that myself. I think it works, but I'm not 100% certain.
> I've now convinced myself that this can't work. I'd appreciate others'
> input on my reasoning. To get 'gcc' to find my source files in a flat,
> single-dir layout, I have to see UnixEnv$gcc$sfix to "", and, as you say,
> it's probably sensible to set all the associated gcc tools' sfix variables
> the same way. But if I do that, of course 'gcc' can't find the in-built
> library headers, which (if you look inside !GCC) are stored in 'c' and 'h'
> (etc.) dirs. So I don't see how that could ever work.

I was wondering about the library headers myself! As I say I've never
used a 'flat' layout myself, but seemed to recall that others may have done.

I've just had a look through the gccsdk mail list, and there's a thread
"sfix doesn't work in all situations" beginning 23 Feb 2012 about this.
John Tytgat advises against trying sfix="". Ron suggests that he did get
it to work (for a simple test case at least) in the last mail in that
thread.

Duncan

_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK