Re: [boost] 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 <ebotcazou@libertysurf.fr> wrote:
[This is not appropriate for gcc@, please use gcc-help@]
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

On Sun, Oct 19, 2008 at 4:01 PM, Edward Peschko <horos11@gmail.com> wrote:
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.
These seem like GCC problems rather than Boost problems. Have you reported them to the GCC folks? --Beman
participants (2)
-
Beman Dawes
-
Edward Peschko