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.
> I think this is an internal header file, so this looks like it could
> possibly be a bug in the gcc dependency logic (not RISC OS specific),
> although this would be a bit surprising.
>
> Fortunately you don't need standard header files in dependency files
> anyway. Seeing as they don't change, all they do is slow 'make' down.
Yes, that seems sensible. I've since found the header file in question -
it is in the ditribution, but not where I was expecting.
> I use: -MMD -MP
>
> -MMD stops system header files, and writes the dependency files to *.d.
> I think it might be -MM to just stop the system header files.
> (I just put 'd' in the sfix list, and then all my dependency files get
> conveniently hidden away in a directory 'd').
>
> -MP is worth having, as it avoids some problems with dependency files.
>
> This is all explained in the gcc manual., and is worth looking at.
> That's in !GCC.docs.gcc. But I normally just google for 'gcc manual'.
Thanks, I'll go away and read!
>> 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.
What's confusing me more, though, is that I thought the GCCSDK autobuilder
basically took Unix-style source trees, applied patches (all the .p files
in the SVN repo) and then built a RISC OS binary. I don't think the AB
moves the source files into 'c' 'h' etc. dirs, does it? Ah! But it doesn't
need to, because the AB doesn't run on RISC OS, does it? So it presumably
uses a Linux version of GCC, which will have the inbuilt headers stored in
a flat dir structure. I think I just answered my own question.
Anyway, on RISC OS, I think the source files have to be in 'c' 'h' etc.
dirs for !GCC to function - does that sound likely?
>> I've figured out that I have to do:
>>
>> Set UnixEnv$cc1plus$sfix ""
>>
>> What tripped me up, was that the command to invoke the C++ compiler in
>> my
>> makefile is "g++". So I initially tried:
>>
>> Set UnixEnv$g++$sfix ""
>>
>> But that didn't work. Can anyone explain to me the difference between
>> the
>> g++ and cc1plus commands?
>
> I think g++ calls cc1plus. I think you'll be better off setting all the
> gcc commands to have the same suffix list, otherwise inconsistencies
> might arise. They are set in !GCC.!Run.
Thanks for the pointer, and thanks to Lee for elaborating further-
brilliant!
>> Finally, if there's somewhere the whole UnixEnv$* environment variable
>> thing is documented, I'd love to know about it. I could find much info
>> in
>> the !GCC help file. Everything I know about it now (not much!) is from
>> Duncan's 'make' help file.
>
> There's some documentation in !GCC.docs.libunixlib.README.
> It might be worthwhile 'grep'ing through the whole of the docs directory.
> You might possibly find something in pages linked from
> http://www.riscos.info/index.php/GCCSDK. Even if it's not there, there's
> lots of other useful information.
Again, I'll go away and read - thanks for the pointers.
> Duncan
WPB
_______________________________________________
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
No comments:
Post a Comment