[PATCH] RTEMS: Add GCC Runtime Library Exception

Jeff Law law@redhat.com
Fri Jan 12 22:57:00 GMT 2018


On 12/21/2017 11:59 PM, Sebastian Huber wrote:
> On 21/12/17 05:58, Jeff Law wrote:
>> On 08/22/2017 11:15 PM, Sebastian Huber wrote:
>>> Hello Jeff,
>>>
>>> On 03/08/17 07:11, Sebastian Huber wrote:
>>>> On 02/08/17 21:30, Jeff Law wrote:
>>>>
>>>>> On 07/24/2017 12:03 AM, Sebastian Huber wrote:
>>>>>> gcc/
>>>>>>
>>>>>>      PR libgcc/61152
>>>>>>      * aarch64/rtems.h: Add GCC Runtime Library Exception. Format
>>>>>>      changes.
>>>>>>      * arm/rtems.h: Likewise.
>>>>>>      * bfin/rtems.h: Likewise.
>>>>>>      * i386/rtemself.h: Likewise.
>>>>>>      * lm32/rtems.h: Likewise.
>>>>>>      * m32c/rtems.h: Likewise.
>>>>>>      * m68k/rtemself.h: Likewise.
>>>>>>      * microblaze/rtems.h: Likewise.
>>>>>>      * mips/rtems.h: Likewise.
>>>>>>      * moxie/rtems.h: Likewise.
>>>>>>      * nios2/rtems.h: Likewise.
>>>>>>      * powerpcspe/rtems.h: Likewise.
>>>>>>      * rs6000/rtems.h: Likewise.
>>>>>>      * rtems.h: Likewise.
>>>>>>      * sh/rtems.h: Likewise.
>>>>>>      * sh/rtemself.h: Likewise.
>>>>>>      * sparc/rtemself.h: Likewise.
>>>>> This seems horribly wrong.  Did anyone ack this change?  I'm fully
>>>>> supportive of target maintainers taking care of their areas, but
>>>>> licensing stuff probably should get explicitly ack'd.
>>>>>
>>>>> I just reviewed all the rtems config files and I don't see anything in
>>>>> any of them that deserves a runtime exception with the possible
>>>>> exception of rs6000/rtems.h.
>>>>>
>>>>> Seriously.  Redefining the CPP builtins?  LINK_SPEC?  #undefs? Those
>>>>> are not things we should be granting an exception for.
>>>>>
>>>>> The one that looks marginal to me would be rs6000/rtems.h and its
>>>>> definition of CRT_CALL_STATIC_FUNCTION.
>>>> I asked on the mailing list:
>>>>
>>>> https://gcc.gnu.org/ml/gcc/2017-07/msg00171.html
>>>>
>>>> Jakub Jelinek said that for header files included by libgcc it is
>>>> important whether they have the runtime exception or not:
>>>>
>>>> https://gcc.gnu.org/ml/gcc/2017-07/msg00176.html
>>>>
>>>> There is also this PR61152 from 2014
>>>>
>>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61152
>>>>
>>>> which adds the runtime exception to a couple of gcc/ subdirectory
>>>> files (including some RTEMS files). So, I had no explicit acknowledge,
>>>> but my impression was that I did simply fix some left over files.
>>>>
>>>> If you don't add the runtime exception to files included by libgcc,
>>>> then the user of GCC must check that these files contain no content
>>>> that deserves a copyright. Is this really user friendly?
>>>>
>>> What should I do now? It would be nice to have a general guideline on
>>> how to deal with header files used by libgcc.
>> You have to look at each header and determine how the contents are used
>> and whether or not those uses are of a nature that requires an exception.
>>
>> So, yes it's important to get the exception in there when it's needed.
>> But that doesn't mean we just drop the exception into every file that's
>> included by something in libgcc.  We are stewards of the GCC sources for
>> the FSF and we have to be very careful when it comes to changing the
>> licensing on any code.
>>
>> WRT 61152.   That doesn't mean splatting the runtime exception into
>> those files is/was the correct thing to do.  Again, one has to look at
>> it on a file by file basis.  I have not looked at those changes in
>> detail to know if they really need the license exception or not.
>>
>> The FSF has been very clear through the decades that linking against
>> libgcc should not drag the user's code under the terms of the GPL.  So
>> all users have to do is extend a degree of trust.  When files have
>> actually needed a license change we've taken care of it and always will.
>>
>>
>> I'm not going to demand you revert the change, but let's please get an
>> explicit ack before changing the licensing terms in the future.
> 
> Ok, thanks for the clarification. I will be more careful in the future.
> 
> What is the status of this PR
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61152
> 
> now? Can it be closed with a notice that this must be decided file by file?
Seems reasonable with a note that it needs to be decided file by file.

jeff



More information about the Gcc-patches mailing list