The cause of the build problems with ccache

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

The cause of the build problems with ccache

Alexander Leidinger
Hi,

I looked at the cause of the build errors when using ccache. When building
with ccache, the compiler uses /usr/include instead of the includes in
/usr/src (after the "unsigned char" -> "void" change in the md5 header this
jumps directly into your face if you look at the error message).

Does the intermediate compiler in /usr/obj get build with a different default
include path?

If yes:
 - This would also result in picking up the wrong includes when someone tries
to build the world with a different compiler (e.g. icc).
 - Wouldn't it be better to discard the default include path and add the
include path we want explicitly on the command line?

Bye,
Alexander.

--
http://www.Leidinger.net  Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org     netchild @ FreeBSD.org  : PGP ID = 72077137
Courage is your greatest present need.

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: The cause of the build problems with ccache

Ruslan Ermilov
On Thu, Jan 19, 2006 at 08:48:27AM +0100, Alexander Leidinger wrote:

> Hi,
>
> I looked at the cause of the build errors when using ccache. When building
> with ccache, the compiler uses /usr/include instead of the includes in
> /usr/src (after the "unsigned char" -> "void" change in the md5 header this
> jumps directly into your face if you look at the error message).
>
> Does the intermediate compiler in /usr/obj get build with a different default
> include path?
>
Yes.  The magic is in this line in Makefile.inc1:

XMAKE=          TOOLS_PREFIX=${WORLDTMP} ${BMAKE} -DNO_FORTRAN -DNO_GDB
                ^^^^^^^^^^^^^^^^^^^^^^^^

> If yes:
>  - This would also result in picking up the wrong includes when someone tries
> to build the world with a different compiler (e.g. icc).
>
I believe so.

>  - Wouldn't it be better to discard the default include path and add the
> include path we want explicitly on the command line?
>
This was attempted before and failed.  I don't remember all the details
now (you can also go ask Marcel and David), but I remember GCC is picky
about standard paths: it would treat them differently from other
locations, resulting in a different set of warnings etc.  And we want
it to work exactly as if these paths were standard.  The compiler set
uses stuff in ${WORLDTMP}: new headers, libraries, etc.


Cheers,
--
Ruslan Ermilov
[hidden email]
FreeBSD committer

attachment0 (194 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: The cause of the build problems with ccache

Matthew D. Fuller
On Thu, Jan 19, 2006 at 02:51:25PM +0200 I heard the voice of
Ruslan Ermilov, and lo! it spake thus:
>
> but I remember GCC is picky about standard paths: it would treat
> them differently from other locations, resulting in a different set
> of warnings etc.

Note that gcc does have a "-isystem" (as opposed to -I) that I think
mostly handles this sort of thing.


--
Matthew Fuller     (MF4839)   |  [hidden email]
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
           On the Internet, nobody can hear you scream.
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: The cause of the build problems with ccache

Marcel Moolenaar
In reply to this post by Ruslan Ermilov
On Thu, Jan 19, 2006 at 02:51:25PM +0200, Ruslan Ermilov wrote:

>
> >  - Wouldn't it be better to discard the default include path and add the
> > include path we want explicitly on the command line?
> >
> This was attempted before and failed.  I don't remember all the details
> now (you can also go ask Marcel and David), but I remember GCC is picky
> about standard paths: it would treat them differently from other
> locations, resulting in a different set of warnings etc.  And we want
> it to work exactly as if these paths were standard.  The compiler set
> uses stuff in ${WORLDTMP}: new headers, libraries, etc.

True.

Cross-building was implemented in the days when Perl was still in
the tree. A lot (if not all) of the obvious solutions simply didn't
work because the Perl buildtools weren't parameterized. The only
option was to change the behaviour of the compiler under the hood.

Now that we don't have to worry about Perl anymore, it's more likely
that we can use standard GCC options. Just keep in mind that a cross
compiler tends to behave differently from a native compiler. They
certainly did back then. There may be goblins still...

See also rev 1.16 of src/contrib/gcc/gcc.c.

--
 Marcel Moolenaar  USPA: A-39004 [hidden email]
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"