This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch] sparc-sun-solaris2.8 (cross) missing PATH_MAX


On Tue, Apr 27, 2004 at 07:42:02AM +0200, Eric Botcazou wrote:
> > I vaguely remember seeing this before, and I may have forgotten to
> > work up a patch.  If you look in <limits.h> on sparc-sun-solaris2.8,
> > the (only) definition of PATH_MAX is wrapped with the following guard,
> > which is not active when compiling gmon-sol2.c.
> >
> > #if defined(__EXTENSIONS__) || __STDC__ - 0 == 0 || \
> >         defined(_POSIX_C_SOURCE) || defined(_XOPEN_SOURCE)
> 
> Do you have access to sparc-sun-solaris2.8 native?  If so, could you try to 
> investigate why we apparently don't have any problem there?

Aha!  The native build is properly chaining gcc's <limits.h> to
<syslimits.h>, but the cross is not.

After taking a second look at the output, it looks like there was an
error, but the build didn't stop: 

  The directory that should contain system headers does not exist:
    /opt/gcc-3.4.0-cross/sparc-sun-solaris2.8/lib/gcc/sparc-sun-solaris2.8/3.4.0/../../../../sparc-sun-solaris2.8/sys-include

The problem is that
/opt/gcc-3.4.0-cross/sparc-sun-solaris2.8/lib/gcc/sparc-sun-solaris2.8/3.4.0
does not exist at the time that fixinc.sh is run.  I've examined the
configury surrounding this, but it is not entirely clear to me how to
fix this :)  

I'm confused by the logic in the make rule that runs fixinc.sh:

# Build fixed copies of system files.
stmp-fixinc: fixinc.sh gsyslimits.h
        @if test ! -d ${SYSTEM_HEADER_DIR}; then \
          echo The directory that should contain system headers does
          not exist: >&2 ; \
          echo "  ${SYSTEM_HEADER_DIR}" >&2 ; \
          if test "x${SYSTEM_HEADER_DIR}" =
          "x${gcc_tooldir}/sys-include"; \
          then sleep 1; else exit 1; fi; \
        fi

Why sleep for one second if it's $(gcc_tooldir)/sys-include (which it
seems to be)?  Doesn't this just mask exactly this problem?  Perhaps
it should make the directory in that case?  But since it's full of
relative path elements, I suppose we'd have to make $(libdir)
instead? 
 
-- 
------------------------------------------------------------------
Brad Spencer - spencer@infointeractive.com - "It's quite nice..."
Systems Architect | InfoInterActive Corp. | A Canadian AOL Company


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]