Actually, I'm building a cross compiler to target Solaris-2.8. As this drags in the Solaris include files, I figure this error might also happen when compiling on Solaris-2.8. Anyway, the fix is simply to add line #include <limits.h> /* for PATH_MAX */ to gcc-3.4.0/gcc/config/sparc/gmon-sol2.c /pub/unpacked/gcc-3.4.0/gcc/config/sparc/gmon-sol2.c:182: error: `PATH_MAX' unde clared (first use in this function)
> Actually, I'm building a cross compiler to target Solaris-2.8. You didn't provide enough information. Please specify the host, the exact target, the configure line, the 'make' command line and so on. Also specify how much of a cross-compilation environment is intalled on the host. > As this drags in the Solaris include files, I figure this error > might also happen when compiling on Solaris-2.8. No, we wouldn't have shipped a compiler that doesn't build on Solaris 8.
Investigation at http://gcc.gnu.org/ml/gcc-patches/2004-04/msg01738.html .
Patch here: <http://gcc.gnu.org/ml/gcc-patches/2004-05/msg00173.html>, this looks like a regression also.
Yes, it's a regression.
Eric, if this patch looks correct to you, would you please apply it?
> Eric, if this patch looks correct to you, would you please apply it? Yes, it looks correct to me but I'm not familiar with the Makefile machinery. I'm going to ping Alexandre, who seems to be versed in the cross-compilation business.
Hi Alexandre, Would you mind reviewing the patch linked to from comment #3 in the audit trail of this PR? You will also find a discussion linked to from comment #2. Thanks in advance.
Alexandre explained why the patch is not correct and suggested a solution: http://gcc.gnu.org/ml/gcc-patches/2004-06/msg01646.html The workaround is probably to create the missing directory before building the cross-compiler.
Postponed until GCC 3.4.2.
The problem lies in the Makefile machinery.
Postponed until GCC 3.4.3.
Postponed until GCC 3.4.4.
Moving to 4.0.2 pre Mark.
We now have --build-sysroot, which ameliorates this situation. (I don't fully understand Alexandre's suggestion, in the message linked from Comment #13.) In any case, I've downgraded this to P5, as, although clearly desirable, building such a cross-compiler will not be release-critical.
Subject: Re: [3.4/4.0/4.1 regression] Minor compilation problem for cross to Solaris 8 What's this "4.1blocker-" stuff about? This certainly isn't a 4.1 blocker, and that information is already computable from the other fields, as I've described.
(In reply to comment #15) > Subject: Re: [3.4/4.0/4.1 regression] Minor compilation > problem for cross to Solaris 8 > What's this "4.1blocker-" stuff about? This certainly isn't a 4.1 > blocker, and that information is already computable from the other > fields, as I've described. Flags are better as we can have a requestor and only one group of people able to set the flag (you in this case). So if I requested this should be a blocker, you can deny it without even being CC'd to the bug. It is a little more automated than what fields do. This is why I asked about flags. Fields to me should not be used in this way.
Subject: Re: [3.4/4.0/4.1 regression] Minor compilation problem for cross to Solaris 8 pinskia at gcc dot gnu dot org wrote: > ------- Comment #16 from pinskia at gcc dot gnu dot org 2005-10-30 22:36 ------- > (In reply to comment #15) > >>Subject: Re: [3.4/4.0/4.1 regression] Minor compilation >> problem for cross to Solaris 8 >>What's this "4.1blocker-" stuff about? This certainly isn't a 4.1 >>blocker, and that information is already computable from the other >>fields, as I've described. > > > Flags are better as we can have a requestor and only one group of people able > to set the flag (you in this case). So if I requested this should be a > blocker, you can deny it without even being CC'd to the bug. It is a little > more automated than what fields do. This is why I asked about flags. Fields > to me should not be used in this way. I don't think I agree. Maybe I can be made to, but please drive this on the GCC list, and get buy-in, rather than doing it unilaterally. These fields are tools for the RM, and all you're doing at the moment is confusing me.
*** Bug 28097 has been marked as a duplicate of this bug. ***
*** Bug 28098 has been marked as a duplicate of this bug. ***
Won't fix for GCC-4.0.x
After three years of deafening silence, I'm sure closing this as WONTFIX will perhaps ignite protests from anyone on the CC: list who still cares about this one. Should that happen, I encourage the respected victim to get some motion in the process to resolve this bug :-)