On Tue, Apr 15, 2014 at 4:45 AM, Douglas B Rupp <r...@adacore.com> wrote: > On 04/14/2014 02:01 PM, Ian Lance Taylor wrote: >> >> You may have failed to consider that unwind.h is installed and can be >> #include'd by any program that is built with GCC. Renaming the >> installed file will break an unknown number of existing programs. >> > > No I considered that but I think that number will be very small. Will you > concede, in hindsight, that it would be better had the name been chosen to > be more unique?
No, I won't concede that. The unwind.h file provides the interface for the C++ exception handling interface (http://mentorembedded.github.io/cxx-abi/abi-eh.html). That interface is implemented by several different compilers, not just GCC. > If it's the avowed policy of the FSF to never require a source code change > in a user program, then obviously this is unacceptable. Could you advise me > on that policy please? There is no such policy. However, when making backward incompatible changes, we must be thoughtful about the needs of our users, and we must not break them unnecessarily. > The problem for us is there's no good solution for bypassing the VxWorks7 > header file when compiling libgcc. The only way I see to do this is to > introduce a new variable for header files to be included after the internal > gcc header files, when compiling libgcc. If you have some other > suggestions, they would be welcome. If the only problem is in building libgcc, then I do not think we should break GCC users. GCC provides a number of ways to control the header file search path. I'm confident we can manage to build libgcc even if the system has an <unwind.h> file. In fact, it's clearly a bug if libgcc manages to #include anything other than its own unwind.h file. Can you explain the problem in more detail? What, specifically, breaks? Ian
