This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


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: Building cross compiler for Solaris2 and PATH_MAX


>-----Original Message-----
>From: Ronan Daly [mailto:ronan.daly@sse.ie]
>Sent: 30 January 2002 15:02

>When compiling the file gcc/config/sparc/gmon-sol2.c it chokes on an
>undeclared PATH_MAX. I've copied the solaris include files 
>from /usr/include
>to the /usr/sparc-sun-solaris2.8/include directory.

  You're building a cross compiler here, rather than a native compiler, so
the default prefix setting will be /usr/local rather than /usr (and indeed
you VERY much do NOT want to install a cross compiler directly under /usr
as you risk damaging your native compiler and thereby getting into an 
un-recoverable position.)

  So, $prefix=/usr/local; given that cross-include files should be placed
in $prefix/$target/include, you should see from the output of the make
command that all the compiler commands have '-I
/usr/local/sparc-sun-solaris2.8/include' in them, and it's because the
compiler is looking there
and not in /usr/sparc-sun-solaris2.8/include that it isn't finding your
files.

  This is one reason why I generally prefer to specify
--with-headers=/path/to/header/files at configure time: that way, the
compiler is
responsible for putting the headers in the same place as it's going to
look for them in and I don't have to remember!

>Now PATH_MAX is defined in the limits.h file in the
>/usr/sparc-sun-solaris2.8/include directory. I've looked at 
>the preprocessed
>source, and limits.h is getting included. However the the 
>define statement
>is inside a conditional block, repeated here
>
>#if defined(__EXTENSIONS__) || __STDC__ - 0 == 0 || \
> defined(_POSIX_C_SOURCE) || defined(_XOPEN_SOURCE)
>
>None of these are defined when the file is being compiled
>My question would be, should one of these be defined? Or is 
>there something
>else funny happening?

  I imagine what you're seeing is Gcc's build procedure failing to find the
solaris include files and falling back on the default system includes that
it keeps in the 'ginclude' subdirectory of the source.  These files were
only meant to provide absolute minimum fallbacks to get gcc up and running
on new targets or on embedded systems that have no native toolchain, and
it's no surprise that they don't provide the relevant #defines that the
solaris headers need to work properly.  Take a look at the output from the
build commands, and look at the -I options and the order they occur in:
from that, you should be able to verify *which* limits.h is being included.
However, this is a fairly speculative explanation and I haven't checked my
facts: assuming the problem is indeed that you put the header files in the
wrong place, the precise details don't matter except for curiosity's sake,
just so long as the build works right after you *do* install the headers
where they're needed!


     hth,
      DaveK
-- 
Burn your ID card!  http://www.optional-identity.org.uk/
Help support the campaign, copy this into your .sig!


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com


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