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] |
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] |