out of date docs? (alpha/64bit vs. 32bit vs. cross)
http://gcc.gnu.org/install/specific.html#alpha-dec-osf "Note that since the Alpha is a 64-bit architecture, cross-compilers from 32-bit machines will not generate code as efficient as that generated when the compiler is running on a 64-bit machine because many optimizations that depend on being able to represent a word on the target in an integral value on the host cannot be performed. Building cross-compilers on the Alpha for 32-bit machines has only been tested in a few cases and may not work properly. " This is false lately, eh? Can it be amended to note what versions it was possibly true for and what versions it is definitely false for? In particular, I /assume/ it is false for any version that uses gmp. Thanks, - Jay
Re: thread build on solaris
2008/10/19 Edward Peschko: > > That worked (thanks) but exactly why did it work? Shouldn't gcc be > smart enough to realize that it is working either with a c++ file or > linking to a c++ library? http://gcc.gnu.org/onlinedocs/gcc-4.3.2/gcc/Invoking-G_002b_002b.html "g++ ... automatically specifies linking against the C++ library" Jonathan
Re: [PATCH]: GMP/MPFR in-tree build instructions [Was: Re: [PATCH]: bump minimum MPFR version, (includes some fortranbits)]
On Tue, 14 Oct 2008, Tobias Schlüter wrote: > I'll take care of this, provided Gerald approves the change. Gerald, if > you think that copyright is a problem, I'll gladly rephrase it. Thanks for the change, it looks like a good one. You may want to make one or the other adjustment for extra safety, but this should be on the harmless side. Gerald
Re: [PATCH]: GMP/MPFR in-tree build instructions [Was: Re: [PATCH]: bump minimum MPFR version, (includes some fortranbits)]
Gerald Pfeifer wrote:
On Tue, 14 Oct 2008, Tobias Schlüter wrote:
I'll take care of this, provided Gerald approves the change. Gerald, if
you think that copyright is a problem, I'll gladly rephrase it.
Thanks for the change, it looks like a good one. You may want to make
one or the other adjustment for extra safety, but this should be on the
harmless side.
I expanded the patch somewhat, so that the information appears in a
somewhat more user-friendly place. See below.
Committed after make info, make dvi and make html succeeded.
Cheers,
- Tobi
2008-10-19 Tobias Schlüter <[EMAIL PROTECTED]>
* doc/install.texi: Document in-tree building of gcc and mpfr.
Index: install.texi
===
--- install.texi(revision 141230)
+++ install.texi(working copy)
@@ -307,7 +307,9 @@ systems' @command{tar} programs will als
Necessary to build [EMAIL PROTECTED] If you do not have it installed in your
library search path, you will have to configure with the
@option{--with-gmp} configure option. See also
[EMAIL PROTECTED] and @option{--with-gmp-include}.
[EMAIL PROTECTED] and @option{--with-gmp-include}. Alternatively,
+if a GMP source ditribution is found in a subdirectory of you GCC
+sources named @file{gmp}, it will be built together with [EMAIL PROTECTED]
@item MPFR Library version 2.3.2 (or later)
@@ -319,8 +321,12 @@ fixed when using this version. It is st
to the recommended version of MPFR.
The @option{--with-mpfr} configure option should be used if your MPFR
-Library is not installed in your default library search path. See
-also @option{--with-mpfr-lib} and @option{--with-mpfr-include}.
+Library is not installed in your default library search path. See also
[EMAIL PROTECTED] and @option{--with-mpfr-include}.
+Alternatively, if a MPFR source ditribution is found in a subdirectory
+of you GCC sources named @file{mpfr}, it will be built together with
[EMAIL PROTECTED]
+
@item @command{jar}, or InfoZIP (@command{zip} and @command{unzip})
@@ -496,6 +502,12 @@ components of the binutils you intend to
(@file{bfd}, @file{binutils}, @file{gas}, @file{gprof}, @file{ld},
@file{opcodes}, @dots{}) to the directory containing the GCC sources.
+Likewise, the GMP and MPFR libraries can be automatically built together
+with GCC. Unpack the GMP and/or MPFR source distributions in the
+directory containing the GCC sources and rename their directories to
[EMAIL PROTECTED] and @file{mpfr}, respectively (or use symbolic links with the
+same name).
+
@html
Re: thread build on solaris
Eric, I don't want to be a hair-splitter, but I do think this message does belong in gcc - it's a question of functionality, and how easy to use gcc is. I am trying to move to gcc-4 for its technical improvements, but I'm finding that it seems to be far less forgiving than gcc-3. This is having the unfortunate side effect that a lot of packages that used to compile perfectly fine with gcc-3 are no longer doing so with gcc-4. IMO it should be flexible enough to 'do the right thing' when it can. >From the point of the user, it makes it far more user friendly than otherwise. Is there a flag, environmental variable, or some switch that I can use to make gcc-4 have the older, looser behaviour? (ie: to be backwards compatible with the large volume of code I compile and maintain). Here's another example I'm finding: Constructs of the form extern enum vtype iftovt_tab[]; are now failing with forgiving error: array type has incomplete element type This would be fine if it was code that I controlled - but the matter of fact is that this code is in /usr/include/sys/mode.h, which comes bundled with solaris 10, and the upshot is that I'm going to have to somehow hack solaris headers in order to make gcc-4.3.2 be able to compile perl-5.10.0. Which is just plain wrong. Ed On Sun, Oct 19, 2008 at 2:06 AM, Eric Botcazou <[EMAIL PROTECTED]> wrote: > [This is not appropriate for gcc@, please use [EMAIL PROTECTED] > >> That worked (thanks) but exactly why did it work? Shouldn't gcc be >> smart enough to realize that it is working either with a c++ file or >> linking to a c++ library? > > gcc is the C compiler, use g++ when you're compiling C++, gfortran when you're > compiling Fortran and so on. > > -- > Eric Botcazou >
Re: thread build on solaris
> This is having the unfortunate side effect that a lot of packages that > used to compile perfectly fine with gcc-3 are no longer doing so with > gcc-4. The major Linux distributions use GCC 4.x so this should be doable. > Here's another example I'm finding: > > Constructs of the form > > extern enum vtype iftovt_tab[]; > > are now failing with forgiving > > error: array type has incomplete element type > > This would be fine if it was code that I controlled - but the matter > of fact is that this code is in /usr/include/sys/mode.h, which comes > bundled with solaris 10, and the upshot is that I'm going to have to > somehow hack solaris headers in order to make gcc-4.3.2 be able to > compile perl-5.10.0. This should be fix-included if it's really a bug in the Solaris headers. -- Eric Botcazou
Re: [lto][RFC] Do not emit hybrid object files
David Edelsohn wrote: >>> I actually think that the hybrid files should be the default. If you >>> are willing to make invasive changes to your build environment to >>> support two files, then you should be willing to add extra options to >>> support that. > IBM XLC whole program IPA mode defaults to hybrid files. One explicitly > specified -qipa=noobject to avoid emitting standard object files. Hybrid by > default follows the rule of least surprise. I third this suggestion. I think having the option is very useful, but I still think hybrid should be the default. There are lots of reasons LTO isn't going to work for many users for a while (like, for example, a bug in LTO), and having hybrid object files gives them an easy way to succeed. As with any argument about defaults, it depends on what you think is the "typical" use case. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
