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]

more about the external target headers/libraries issue


Gang,

(In a diplomatic tone):
Recent comments suggested that there may be some stupidity involved, by
those that
try to build a cross-compiler without getting all the target headers
and/or libraries in
place before running the build. I cannot agree with this sentiment.(end
tone)

The reality is that this topic is not adequately and consistently
documented by the
formal documentation from gcc.gnu.org. Thus, many, if not most,
cross-builders will
not fully understand the issues involved.

For example, from today's gcc.gnu.org web site, under the links to
online documentation,
we see document groups for the four most recent releases. If you read
the manuals for
2.95.3 and 3.0.4, you will see they are titled "Using and Porting the
GNU Compiler Collection (GCC)".
Within, you will find verbage that attempts to cover the topics of
target headers and
libraries. That verbage is not crystal clear, nor very comprehensive. If
you read the
manuals for 3.1.1 and 3.2.1, you will see that "and Porting" has been
dropped from the
title, and indeed, all the sections related to
installing/porting/configuring are gone!
Where did they go?

Well, if you have downloaded and installed 3.1.1 or 3.2.1, you will find
that the missing
information is there, in the "info" files. I stumbled on this by
accident, since I built a successful
native 3.2.1 on a SPARC/Solaris machine, and started reading the info
files which
were installed into the /usr/local/info directory by the "make install"
step. I do not believe
that this "info" file content is currently online-browsable at
gcc.gnu.org website.

I suggest reading the "info" files in 3.2.1, for gcc, for the
cross-compiling topics. To date,
that is the best coverage of the subject I have been able to find. There
is actually
a decent level of elaboration on the whys and wherefores, and more
useful suggestions
as how to go about providing the mystery target header files and/or
libraries. The general
focus of the verbage is generic, however. Thus, for a specific target,
you still will not
know if libgcc.a is going to build or not, let alone other steps in the
build.

I think that it is quite possible, that by reading the older official
documentation, and
some of the personal FAQS on cross-compiling, you can still come away
with the
impression that all you need to do is give that old "--target=foo" flag
to the configure
script, type "make", and soon be on your way to application-building
heaven! You
really won't know until you try it!

Which brings me to Dan Kegel's point about goals. I would agree, that if
you download
the GCC package, and it tells you it can be configured as a
cross-compiler, then you
are being led to the belief that the thing should build, from the
contents of the package.
If, however, there really is a prerequisite to using the package for
cross-builds, then
the proper place to document this is on the download site, with
statements such as
"this packages requires foobar".  This type of information does not
belong deep in
the middle of the package itself, to be found (or not) after spending
time downloading,
unpacking, configuring, and running a long build which fails.

Within the formal documentation, there is a statement which declares:
"The GNU C compiler does not come with these files, because (1) they
are system-specific, and (2) they belong in a C library, not in a
compiler". Dan's point would seem to argue that the files do belong
in the GCC package, which would, of course, make our lives easier.
I would lean toward agreement with this goal.

However, if the GCC folks wish to stick with the way it is, then I would
claim
that a formal package needs to be created by the community, which would
be considered the prerequisite to utilizing the GCC package in a cross
mode.
This hypothetical package would have directories for each supported
target,
with submitted header files and/or library source files needed to
satisfy a
cross build of the GCC target. This could be a huge time saver!

Where would such a package live? Hey Red Hat!  Got some more disk space?



Have fun,
Rick



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