Revision 176335 (removal of #include <unistd.h> in thr-posix.h) cause numerous compile failures

Revision 176335 (removal of #include <unistd.h> in thr-posix.h) cause numerous compile failures

[Markus Trippelsdorf]

Revisions 176335 removed the traditional "#include <unistd.h>" from
gthr-posix.h. This breaks the build of many programs (Firefox, Chromium,
etc.) that implicitly rely on it. 
I'm not sure that the gain is worth the pain in this case.

-- 
Markus

Re: Revision 176335 (removal of #include <unistd.h> in thr-posix.h) cause numerous compile failures

[Jakub Jelinek]

On Tue, Aug 02, 2011 at 03:08:03PM +0200, Markus Trippelsdorf wrote:
> Revisions 176335 removed the traditional "#include <unistd.h>" from
> gthr-posix.h. This breaks the build of many programs (Firefox, Chromium,
> etc.) that implicitly rely on it. 

This isn't the first time the libstdc++ headers were cleaned up, and
each time there are dozens of programs that need to be fixed up.
Each time they just were fixed.

> I'm not sure that the gain is worth the pain in this case.

It certainly is.

	Jakub

Re: Revision 176335 (removal of #include <unistd.h> in thr-posix.h) cause numerous compile failures

[Jonathan Wakely]

On 2 August 2011 14:08, Markus Trippelsdorf wrote:
> Revisions 176335 removed the traditional "#include <unistd.h>" from
> gthr-posix.h. This breaks the build of many programs (Firefox, Chromium,
> etc.) that implicitly rely on it.
> I'm not sure that the gain is worth the pain in this case.

The "pain" fixes a real bug in libstdc++ which caused g++ to reject
valid programs.

Not rejecting valid programs is more important than accepting invalid
ones, especially ones that can be easily fixed by adding a missing
header.

Lack of libstdc++ compatibility (was: Revision 176335)

[Gerald Pfeifer]

On Tue, 2 Aug 2011, Jakub Jelinek wrote:
>> Revisions 176335 removed the traditional "#include <unistd.h>" from
>> gthr-posix.h. This breaks the build of many programs (Firefox, Chromium,
>> etc.) that implicitly rely on it. 
> This isn't the first time the libstdc++ headers were cleaned up, and 
> each time there are dozens of programs that need to be fixed up. Each 
> time they just were fixed.

I think that is a bit too much of a cavalier approach.

For example, right now I am in the process of changing the compiler
FreeBSD uses for Fortran packages from GCC 4.5 to 4.6 and 100% of
the issues we run into are not related to Fortran but...C++.

Breaking source code compatbility with a step like GCC 3 to GCC 4
is one thing, but constantly doing so with every release is just
painful and makes as look bad.  And it hinders the adoption of 
newer releases.

Gerald

Re: Lack of libstdc++ compatibility (was: Revision 176335)

[Richard Guenther]

On Thu, Aug 18, 2011 at 11:34 AM, Gerald Pfeifer <gerald@pfeifer.com> wrote:
> On Tue, 2 Aug 2011, Jakub Jelinek wrote:
>>> Revisions 176335 removed the traditional "#include <unistd.h>" from
>>> gthr-posix.h. This breaks the build of many programs (Firefox, Chromium,
>>> etc.) that implicitly rely on it.
>> This isn't the first time the libstdc++ headers were cleaned up, and
>> each time there are dozens of programs that need to be fixed up. Each
>> time they just were fixed.
>
> I think that is a bit too much of a cavalier approach.

Because you ignore the fact that this change fixed a bug.

> For example, right now I am in the process of changing the compiler
> FreeBSD uses for Fortran packages from GCC 4.5 to 4.6 and 100% of
> the issues we run into are not related to Fortran but...C++.
>
> Breaking source code compatbility with a step like GCC 3 to GCC 4
> is one thing, but constantly doing so with every release is just
> painful and makes as look bad.  And it hinders the adoption of
> newer releases.

Such visible changes are less of an issue when adopting a new release
compared to hidden issues that only show up during testing.

Richard.

> Gerald
>

Re: Lack of libstdc++ compatibility

[Paolo Carlini]

On 08/18/2011 11:42 AM, Richard Guenther wrote:
> On Thu, Aug 18, 2011 at 11:34 AM, Gerald Pfeifer<gerald@pfeifer.com>  wrote:
>> On Tue, 2 Aug 2011, Jakub Jelinek wrote:
>>>> Revisions 176335 removed the traditional "#include<unistd.h>" from
>>>> gthr-posix.h. This breaks the build of many programs (Firefox, Chromium,
>>>> etc.) that implicitly rely on it.
>>> This isn't the first time the libstdc++ headers were cleaned up, and
>>> each time there are dozens of programs that need to be fixed up. Each
>>> time they just were fixed.
>> I think that is a bit too much of a cavalier approach.
> Because you ignore the fact that this change fixed a bug.
Indeed and actually a rather serious one, already reported multiple 
times. When thanks to Jon's idea and Jukub refinements we have been able 
to fix it I was very happy!

Paolo.

Re: Lack of libstdc++ compatibility

[Jonathan Wakely]

On 18 August 2011 11:19, Paolo Carlini <paolo.carlini@oracle.com> wrote:
> On 08/18/2011 11:42 AM, Richard Guenther wrote:
>>
>> On Thu, Aug 18, 2011 at 11:34 AM, Gerald Pfeifer<gerald@pfeifer.com>
>>  wrote:
>>>
>>> On Tue, 2 Aug 2011, Jakub Jelinek wrote:
>>>>>
>>>>> Revisions 176335 removed the traditional "#include<unistd.h>" from
>>>>> gthr-posix.h. This breaks the build of many programs (Firefox,
>>>>> Chromium,
>>>>> etc.) that implicitly rely on it.
>>>>
>>>> This isn't the first time the libstdc++ headers were cleaned up, and
>>>> each time there are dozens of programs that need to be fixed up. Each
>>>> time they just were fixed.
>>>
>>> I think that is a bit too much of a cavalier approach.
>>
>> Because you ignore the fact that this change fixed a bug.
>
> Indeed and actually a rather serious one, already reported multiple times.
> When thanks to Jon's idea and Jukub refinements we have been able to fix it
> I was very happy!


As I've already explained, we rejected certain valid programs, and
accepted certain other invalid ones.
Now we accept those valid ones and reject the invalid ones.
Which do you prefer?

Working around the GCC bug required renaming functions or variables to
avoid collisions, not even possible for third-party code.
Working around the new compiler failures involves adding a missing
header, even if it's third-party code that's wrong you can include the
missing header before including the third-party ones.
Which is easier?

In many cases those invalid programs would have been rejected by other
compilers, which don't have the same namespace pollution problem that
GCC did. If the change makes us look so bad that users switch to a
different compiler then they'll probably still have to fix those
invalid programs anyway.

Re: Lack of libstdc++ compatibility (was: Revision 176335)

[Jonathan Wakely]

On 18 August 2011 10:34, Gerald Pfeifer wrote:
> On Tue, 2 Aug 2011, Jakub Jelinek wrote:
>>> Revisions 176335 removed the traditional "#include <unistd.h>" from
>>> gthr-posix.h. This breaks the build of many programs (Firefox, Chromium,
>>> etc.) that implicitly rely on it.
>> This isn't the first time the libstdc++ headers were cleaned up, and
>> each time there are dozens of programs that need to be fixed up. Each
>> time they just were fixed.
>
> I think that is a bit too much of a cavalier approach.
>
> For example, right now I am in the process of changing the compiler
> FreeBSD uses for Fortran packages from GCC 4.5 to 4.6 and 100% of
> the issues we run into are not related to Fortran but...C++.
>
> Breaking source code compatbility with a step like GCC 3 to GCC 4
> is one thing, but constantly doing so with every release is just
> painful and makes as look bad.  And it hinders the adoption of
> newer releases.

Personally I *like* it when a new release identifies portability
problems such as missing includes.  I consider it an advantage, and an
improvement in the compiler.

Re: Lack of libstdc++ compatibility

[Gerald Pfeifer]

On Thu, 18 Aug 2011, Jonathan Wakely wrote:
> Personally I *like* it when a new release identifies portability 
> problems such as missing includes.  I consider it an advantage,
> and an improvement in the compiler.

That's a valid approach from a technology perspective.  From a 
customer/user perspective it's just painful.

These incompatibilities have been costing me days, if not weeks, when 
upgrading the versions of GCC in the FreeBSD Ports Collection, for example 
-- for no benefit to anyone since it all was about older version of
ports or old pieces of software, abandoned upstream.

(And it's mostly on the C++ front; C and Fortran appear a lot more
stable.)

Gerald