Reply by Tim Wescott August 9, 20132013-08-09
On Fri, 09 Aug 2013 00:41:38 -0500, Robert Wessel wrote:

> On Wed, 07 Aug 2013 16:12:15 -0500, Tim Wescott > <tim@seemywebsite.really> wrote: > >>On Wed, 07 Aug 2013 21:53:54 +0200, David Brown wrote: >> >>> So don't worry - you can use C++ exceptions in your embedded code if >>> you want, with no licensing issues. You might have trouble convincing >>> yourself and others of the reliability of code using hidden and >>> unexpected jumps (which is what exceptions are), but the licences will >>> be fine :-) >> >>I use C++, but I don't use exceptions -- I have yet to work on any >>system where any conceivable result from an exception is better than >>just hitting an assert that hangs the processor. >> >>(Which means that once the code gets into production, any such bugs are >>Really Bad News anyway, so one should make damned sure that they never >>happen!) > > > There are different styles of exception use. In some exceptions are the > basic error reporting mechanism - you certainly wouldn't (usually) > want to hang the processor because: > > Socket ConnectToHostTCP("someservice.example.com", 12345)' > > threw a SocketExcepetion(HostNotFound)!
True. I generally deal with that sort of thing through milder mechanisms. But then, if it has a user input of more than two buttons and a user output of more than two blinking lights, then it's getting into "excruciatingly fancy UI" territory for me. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
Reply by Robert Wessel August 9, 20132013-08-09
On Wed, 07 Aug 2013 16:12:15 -0500, Tim Wescott
<tim@seemywebsite.really> wrote:

>On Wed, 07 Aug 2013 21:53:54 +0200, David Brown wrote: > >> So don't worry - you can use C++ exceptions in your embedded code if you >> want, with no licensing issues. You might have trouble convincing >> yourself and others of the reliability of code using hidden and >> unexpected jumps (which is what exceptions are), but the licences will >> be fine :-) > >I use C++, but I don't use exceptions -- I have yet to work on any system >where any conceivable result from an exception is better than just >hitting an assert that hangs the processor. > >(Which means that once the code gets into production, any such bugs are >Really Bad News anyway, so one should make damned sure that they never >happen!)
There are different styles of exception use. In some exceptions are the basic error reporting mechanism - you certainly wouldn't (usually) want to hang the processor because: Socket ConnectToHostTCP("someservice.example.com", 12345)' threw a SocketExcepetion(HostNotFound)!
Reply by David Brown August 8, 20132013-08-08
On 08/08/13 02:52, Rich Webb wrote:
> On Wed, 07 Aug 2013 23:55:52 +0200, David Brown > <david.brown@removethis.hesbynett.no> wrote: > >> On 07/08/13 22:48, Rich Webb wrote: >>> On Wed, 07 Aug 2013 21:53:54 +0200, David Brown >>> <david.brown@removethis.hesbynett.no> wrote: >>> >>>> There are a number of code snippets that come with gcc itself (as >>>> distinct from the libraries), and are copied verbatim from the gcc >>>> source into temporary files which end up complied and linked with your >>>> code. There are also library files that are distributed as part of gcc >>>> itself (such as support for floating point and integer arithmetic which >>>> require library routines rather than code segments). The code >>>> generators arguably also involve verbatim copying of assembly-language >>>> source code from gcc files into your own code. >>>> >>>> But while the original gcc author (Richard Stallman) is well-known for >>>> his fanaticism for free software, fortunately the other authors realised >>>> that keeping these parts under a strict GPL would make the compiler >>>> "free" but useless outside of the GNU project. So there is an explicit >>>> exception in the licence that covers all such code, letting you use it >>>> an link it with any other code that you want, under any licence. >>>> >>>> So don't worry - you can use C++ exceptions in your embedded code if you >>>> want, with no licensing issues. You might have trouble convincing >>>> yourself and others of the reliability of code using hidden and >>>> unexpected jumps (which is what exceptions are), but the licences will >>>> be fine :-) >>> >>> Thanks. I do try to Do The Right Thing on licensing issues just on GP >>> but I hadn't read up much on V3 -- more familiar with the older LGPL >>> terms and conditions. Still not tempted by exceptions, though ... >>> >> >> /All/ licences (except perhaps the "beer licence") are full of >> exceptions, small print, and legalise. > > I meant the throw..catch exceptions didn't tempt me but, yes, a hearty > "Roger that" for minding the small print. ;-)
OK, I see what you mean now. (I also disable exceptions when playing around with C++, at least on embedded systems. They are handy in Python for PC programming, but not for embedded stuff.)
> >> It's not always easy to do the right thing on licensing - whether open >> source or commercial. It's not always clear what the legal situation >> is, or what the author (or copyright holders) intend. There are plenty >> of licences (commercial and open) that are not valid in all countries, >> and there are plenty of cases where the legal situation is very >> different from the author's intentions (I've seen code with notices like >> "I'm releasing this with the GPL, so that you can use it any way you >> want along with your own code"). >> >> But the licences for gcc and the included gcc libraries are very clear - >> the tool is under the GPL (now GPLv3), with the exception and intention >> that it imposes no restrictions whatsoever on code generated with the >> tool and linked with the included libraries. >> >> Similarly, any library that comes with serious embedded tools is going >> to be fine to use with embedded code. > > Thanks. IANAL etc. and this thread has cleared up some things. >
IANAL either, and I sometimes get things wrong concerning licenses. I know more than most people, but certainly not everything. So if my free advice is helpful, that's great - it's worth every penny - but if you can envisage lawsuits down the line, then get a second opinion too :-)
Reply by Rich Webb August 7, 20132013-08-07
On Wed, 07 Aug 2013 23:55:52 +0200, David Brown
<david.brown@removethis.hesbynett.no> wrote:

>On 07/08/13 22:48, Rich Webb wrote: >> On Wed, 07 Aug 2013 21:53:54 +0200, David Brown >> <david.brown@removethis.hesbynett.no> wrote: >> >>> There are a number of code snippets that come with gcc itself (as >>> distinct from the libraries), and are copied verbatim from the gcc >>> source into temporary files which end up complied and linked with your >>> code. There are also library files that are distributed as part of gcc >>> itself (such as support for floating point and integer arithmetic which >>> require library routines rather than code segments). The code >>> generators arguably also involve verbatim copying of assembly-language >>> source code from gcc files into your own code. >>> >>> But while the original gcc author (Richard Stallman) is well-known for >>> his fanaticism for free software, fortunately the other authors realised >>> that keeping these parts under a strict GPL would make the compiler >>> "free" but useless outside of the GNU project. So there is an explicit >>> exception in the licence that covers all such code, letting you use it >>> an link it with any other code that you want, under any licence. >>> >>> So don't worry - you can use C++ exceptions in your embedded code if you >>> want, with no licensing issues. You might have trouble convincing >>> yourself and others of the reliability of code using hidden and >>> unexpected jumps (which is what exceptions are), but the licences will >>> be fine :-) >> >> Thanks. I do try to Do The Right Thing on licensing issues just on GP >> but I hadn't read up much on V3 -- more familiar with the older LGPL >> terms and conditions. Still not tempted by exceptions, though ... >> > >/All/ licences (except perhaps the "beer licence") are full of >exceptions, small print, and legalise.
I meant the throw..catch exceptions didn't tempt me but, yes, a hearty "Roger that" for minding the small print. ;-)
>It's not always easy to do the right thing on licensing - whether open >source or commercial. It's not always clear what the legal situation >is, or what the author (or copyright holders) intend. There are plenty >of licences (commercial and open) that are not valid in all countries, >and there are plenty of cases where the legal situation is very >different from the author's intentions (I've seen code with notices like >"I'm releasing this with the GPL, so that you can use it any way you >want along with your own code"). > >But the licences for gcc and the included gcc libraries are very clear - >the tool is under the GPL (now GPLv3), with the exception and intention >that it imposes no restrictions whatsoever on code generated with the >tool and linked with the included libraries. > >Similarly, any library that comes with serious embedded tools is going >to be fine to use with embedded code.
Thanks. IANAL etc. and this thread has cleared up some things.
Reply by David Brown August 7, 20132013-08-07
On 07/08/13 22:39, Tim Wescott wrote:
> On Wed, 07 Aug 2013 21:53:54 +0200, David Brown wrote: > >> On 07/08/13 17:27, Rich Webb wrote: >>> On Wed, 07 Aug 2013 16:34:28 +0200, David Brown >>> <david@westcontrol.removethisbit.com> wrote: >>> >>>> On 04/08/13 19:51, Rich Webb wrote: >>>>> On Sun, 04 Aug 2013 11:53:58 -0500, Tim Wescott >>>>> <tim@seemywebsite.really> wrote: >>>>> >>>>>> This is related to my "D'oh post" regarding the Cortex M4 floating >>>>>> point size. >>>>>> >>>>>> According to ARM, the Cortex R4 supports double-precision floating >>>>>> point, >>>>>> and it looks like it's maybe more amenable to embedding than the >>>>>> Cortex Ax cores. I really want to find a chip that I can just lick >>>>>> the back of and stick onto a board, rather than something that'll >>>>>> become the CPU in a built-up computer with external memory and all >>>>>> that razz-matazz. >>>>>> >>>>>> TI has a Cortex R4 part, but I've used the predecessor part and the >>>>>> only tools available for it were from Keil -- I dislike >>>>>> single-sourcing, and I'd much prefer using Gnu tools if there are >>>>>> such for the R4. >>>>>> >>>>>> So, has anyone used the R4? Do you happen to know if the Gnu tools >>>>>> support it well? Can you recommend any off the shelf embedded >>>>>> processors that use it? (TI included -- just because the SM470R1B1M >>>>>> was hard to work with doesn't mean that TI hasn't solved those >>>>>> problems with their Cortex version). >>>>> >>>>> Both Rowley http://www.rowley.co.uk/arm/Support_Packages.htm and >>>>> Imagecraft https://www.imagecraft.com/ seem to support TI TMS570 >>>>> series processors. I've used both compilers but not that series (or >>>>> other R4) processors so I'm not absolutely sure that's what you're >>>>> looking for. >>>>> >>>>> Rowley is GNU-based, Imagecraft is independent. I've used both for >>>>> commercial embedded products. There's probably a pure GNU solution >>>>> out there, but I'm in a situation where (L)GPL issues arise. >>>>> >>>>> >>>> The GPL nature of gcc does not affect you unless you are trying to run >>>> the compiler on the microcontroller. Any sane toolchain will have >>>> libraries that can be linked with your code without any license >>>> restrictions - but if you use additional third-party libraries or >>>> code, >>>> you obviously need to check the licence (whether commercial or open >>>> source). >>> >>> Correct. Rowley, for example, does use a gcc compiler and, of course, >>> the generated code itself isn't GPL-burdened. They also (being a sane >>> toolchain ;-) provide their own non-LGPL libraries. >>> >>> >> Rowley provide their own libraries - that's one of the reasons people >> might pay for an otherwise free compiler (along with things like >> support, the IDE, the debugger, etc.). But they like Rowley's libraries >> because they are small and fast, not because there is any practical >> difference in the licences compared to newlib or (for examle) Code >> Sourcery's libraries' licences. My point is merely that there are no >> GPL or LGPL issues to worry about with gcc or commonly used free >> libraries targeted at static linking. >> >>> In the "check the license" vein, however, using C++ RTTI or exceptions >>> does link in GPL-licensed code (not just LGPL). I've been puzzled about >>> why that's the case but since I stay away from C++ in embedded work I >>> haven't worried about (or investigated) that too much. >>> >>> >> There are a number of code snippets that come with gcc itself (as >> distinct from the libraries), and are copied verbatim from the gcc >> source into temporary files which end up complied and linked with your >> code. There are also library files that are distributed as part of gcc >> itself (such as support for floating point and integer arithmetic which >> require library routines rather than code segments). The code >> generators arguably also involve verbatim copying of assembly-language >> source code from gcc files into your own code. >> >> But while the original gcc author (Richard Stallman) is well-known for >> his fanaticism for free software, fortunately the other authors realised >> that keeping these parts under a strict GPL would make the compiler >> "free" but useless outside of the GNU project. So there is an explicit >> exception in the licence that covers all such code, letting you use it >> an link it with any other code that you want, under any licence. >> >> So don't worry - you can use C++ exceptions in your embedded code if you >> want, with no licensing issues. You might have trouble convincing >> yourself and others of the reliability of code using hidden and >> unexpected jumps (which is what exceptions are), but the licences will >> be fine :-) > > I think you may be a bit inaccurate in your "no LGPL worries" statement, > at least with the open-source code. > > The libraries that come with the gnu compiler are LGPL which frees you > from having to release your code, but it doesn't free you from having the > license notices and code availability for the libraries themselves. >
No, there are no standard gcc libraries that are LGPL. There are standard C libraries (like glibc) that are LGPL - and you /do/ need to release your source or linkable object files if you want to statically link to LGPL libraries. LGPL libraries are almost exclusively used with dynamic linking. The libraries included with gcc itself are GPL with an exception, because they are targeted at static linking but have an exception to avoid enforcing the GPL on the rest of the code. It is quite possible to distribute a gcc for embedded targets along with a pure LGPL library, but I have never heard of such a beast (it would be of very limited value). A common free library used with embedded gcc is newlib, which has no "LGPL worries" - it is mostly BSD (with some public domain licensing, and a few GPL bits for linking to specific bits of the Linux kernel - if you use these parts, you code would be GPL anyway by linkage to the kernel). It does, I suppose, have a "BSD worry" - you need to include the library copyright notice in documentation. This is frequently omitted, or relegated to the least read technical manuals - the newlib copyright owners have never been known to complain about missing copyright notices.
> If Rowley (or Mentor/CodeSourcery) ships their "real" product with > libraries that have been written to get around that -- cool. >
Rowley and CodeSourcery (and probably also Code Red, though I don't know them as well) wrote libraries designed to be more efficient in embedded systems, to have features more suited to embedded systems, and to be more tightly targeted to the processors in question (newlib is so portable that it's code is illegible). That has always been the main reason for having these libraries. The lack of a copyright clause on the binary is a minor issue.
Reply by David Brown August 7, 20132013-08-07
On 07/08/13 22:48, Rich Webb wrote:
> On Wed, 07 Aug 2013 21:53:54 +0200, David Brown > <david.brown@removethis.hesbynett.no> wrote: > >> There are a number of code snippets that come with gcc itself (as >> distinct from the libraries), and are copied verbatim from the gcc >> source into temporary files which end up complied and linked with your >> code. There are also library files that are distributed as part of gcc >> itself (such as support for floating point and integer arithmetic which >> require library routines rather than code segments). The code >> generators arguably also involve verbatim copying of assembly-language >> source code from gcc files into your own code. >> >> But while the original gcc author (Richard Stallman) is well-known for >> his fanaticism for free software, fortunately the other authors realised >> that keeping these parts under a strict GPL would make the compiler >> "free" but useless outside of the GNU project. So there is an explicit >> exception in the licence that covers all such code, letting you use it >> an link it with any other code that you want, under any licence. >> >> So don't worry - you can use C++ exceptions in your embedded code if you >> want, with no licensing issues. You might have trouble convincing >> yourself and others of the reliability of code using hidden and >> unexpected jumps (which is what exceptions are), but the licences will >> be fine :-) > > Thanks. I do try to Do The Right Thing on licensing issues just on GP > but I hadn't read up much on V3 -- more familiar with the older LGPL > terms and conditions. Still not tempted by exceptions, though ... >
/All/ licences (except perhaps the "beer licence") are full of exceptions, small print, and legalise. It's not always easy to do the right thing on licensing - whether open source or commercial. It's not always clear what the legal situation is, or what the author (or copyright holders) intend. There are plenty of licences (commercial and open) that are not valid in all countries, and there are plenty of cases where the legal situation is very different from the author's intentions (I've seen code with notices like "I'm releasing this with the GPL, so that you can use it any way you want along with your own code"). But the licences for gcc and the included gcc libraries are very clear - the tool is under the GPL (now GPLv3), with the exception and intention that it imposes no restrictions whatsoever on code generated with the tool and linked with the included libraries. Similarly, any library that comes with serious embedded tools is going to be fine to use with embedded code.
Reply by Tim Wescott August 7, 20132013-08-07
On Wed, 07 Aug 2013 21:53:54 +0200, David Brown wrote:

> So don't worry - you can use C++ exceptions in your embedded code if you > want, with no licensing issues. You might have trouble convincing > yourself and others of the reliability of code using hidden and > unexpected jumps (which is what exceptions are), but the licences will > be fine :-)
I use C++, but I don't use exceptions -- I have yet to work on any system where any conceivable result from an exception is better than just hitting an assert that hangs the processor. (Which means that once the code gets into production, any such bugs are Really Bad News anyway, so one should make damned sure that they never happen!) -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
Reply by Rich Webb August 7, 20132013-08-07
On Wed, 07 Aug 2013 21:53:54 +0200, David Brown
<david.brown@removethis.hesbynett.no> wrote:

>There are a number of code snippets that come with gcc itself (as >distinct from the libraries), and are copied verbatim from the gcc >source into temporary files which end up complied and linked with your >code. There are also library files that are distributed as part of gcc >itself (such as support for floating point and integer arithmetic which >require library routines rather than code segments). The code >generators arguably also involve verbatim copying of assembly-language >source code from gcc files into your own code. > >But while the original gcc author (Richard Stallman) is well-known for >his fanaticism for free software, fortunately the other authors realised >that keeping these parts under a strict GPL would make the compiler >"free" but useless outside of the GNU project. So there is an explicit >exception in the licence that covers all such code, letting you use it >an link it with any other code that you want, under any licence. > >So don't worry - you can use C++ exceptions in your embedded code if you >want, with no licensing issues. You might have trouble convincing >yourself and others of the reliability of code using hidden and >unexpected jumps (which is what exceptions are), but the licences will >be fine :-)
Thanks. I do try to Do The Right Thing on licensing issues just on GP but I hadn't read up much on V3 -- more familiar with the older LGPL terms and conditions. Still not tempted by exceptions, though ...
Reply by Tim Wescott August 7, 20132013-08-07
On Wed, 07 Aug 2013 21:53:54 +0200, David Brown wrote:

> On 07/08/13 17:27, Rich Webb wrote: >> On Wed, 07 Aug 2013 16:34:28 +0200, David Brown >> <david@westcontrol.removethisbit.com> wrote: >> >>> On 04/08/13 19:51, Rich Webb wrote: >>>> On Sun, 04 Aug 2013 11:53:58 -0500, Tim Wescott >>>> <tim@seemywebsite.really> wrote: >>>> >>>>> This is related to my "D'oh post" regarding the Cortex M4 floating >>>>> point size. >>>>> >>>>> According to ARM, the Cortex R4 supports double-precision floating >>>>> point, >>>>> and it looks like it's maybe more amenable to embedding than the >>>>> Cortex Ax cores. I really want to find a chip that I can just lick >>>>> the back of and stick onto a board, rather than something that'll >>>>> become the CPU in a built-up computer with external memory and all >>>>> that razz-matazz. >>>>> >>>>> TI has a Cortex R4 part, but I've used the predecessor part and the >>>>> only tools available for it were from Keil -- I dislike >>>>> single-sourcing, and I'd much prefer using Gnu tools if there are >>>>> such for the R4. >>>>> >>>>> So, has anyone used the R4? Do you happen to know if the Gnu tools >>>>> support it well? Can you recommend any off the shelf embedded >>>>> processors that use it? (TI included -- just because the SM470R1B1M >>>>> was hard to work with doesn't mean that TI hasn't solved those >>>>> problems with their Cortex version). >>>> >>>> Both Rowley http://www.rowley.co.uk/arm/Support_Packages.htm and >>>> Imagecraft https://www.imagecraft.com/ seem to support TI TMS570 >>>> series processors. I've used both compilers but not that series (or >>>> other R4) processors so I'm not absolutely sure that's what you're >>>> looking for. >>>> >>>> Rowley is GNU-based, Imagecraft is independent. I've used both for >>>> commercial embedded products. There's probably a pure GNU solution >>>> out there, but I'm in a situation where (L)GPL issues arise. >>>> >>>> >>> The GPL nature of gcc does not affect you unless you are trying to run >>> the compiler on the microcontroller. Any sane toolchain will have >>> libraries that can be linked with your code without any license >>> restrictions - but if you use additional third-party libraries or >>> code, >>> you obviously need to check the licence (whether commercial or open >>> source). >> >> Correct. Rowley, for example, does use a gcc compiler and, of course, >> the generated code itself isn't GPL-burdened. They also (being a sane >> toolchain ;-) provide their own non-LGPL libraries. >> >> > Rowley provide their own libraries - that's one of the reasons people > might pay for an otherwise free compiler (along with things like > support, the IDE, the debugger, etc.). But they like Rowley's libraries > because they are small and fast, not because there is any practical > difference in the licences compared to newlib or (for examle) Code > Sourcery's libraries' licences. My point is merely that there are no > GPL or LGPL issues to worry about with gcc or commonly used free > libraries targeted at static linking. > >> In the "check the license" vein, however, using C++ RTTI or exceptions >> does link in GPL-licensed code (not just LGPL). I've been puzzled about >> why that's the case but since I stay away from C++ in embedded work I >> haven't worried about (or investigated) that too much. >> >> > There are a number of code snippets that come with gcc itself (as > distinct from the libraries), and are copied verbatim from the gcc > source into temporary files which end up complied and linked with your > code. There are also library files that are distributed as part of gcc > itself (such as support for floating point and integer arithmetic which > require library routines rather than code segments). The code > generators arguably also involve verbatim copying of assembly-language > source code from gcc files into your own code. > > But while the original gcc author (Richard Stallman) is well-known for > his fanaticism for free software, fortunately the other authors realised > that keeping these parts under a strict GPL would make the compiler > "free" but useless outside of the GNU project. So there is an explicit > exception in the licence that covers all such code, letting you use it > an link it with any other code that you want, under any licence. > > So don't worry - you can use C++ exceptions in your embedded code if you > want, with no licensing issues. You might have trouble convincing > yourself and others of the reliability of code using hidden and > unexpected jumps (which is what exceptions are), but the licences will > be fine :-)
I think you may be a bit inaccurate in your "no LGPL worries" statement, at least with the open-source code. The libraries that come with the gnu compiler are LGPL which frees you from having to release your code, but it doesn't free you from having the license notices and code availability for the libraries themselves. If Rowley (or Mentor/CodeSourcery) ships their "real" product with libraries that have been written to get around that -- cool. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
Reply by David Brown August 7, 20132013-08-07
On 07/08/13 17:27, Rich Webb wrote:
> On Wed, 07 Aug 2013 16:34:28 +0200, David Brown > <david@westcontrol.removethisbit.com> wrote: > >> On 04/08/13 19:51, Rich Webb wrote: >>> On Sun, 04 Aug 2013 11:53:58 -0500, Tim Wescott >>> <tim@seemywebsite.really> wrote: >>> >>>> This is related to my "D'oh post" regarding the Cortex M4 floating point >>>> size. >>>> >>>> According to ARM, the Cortex R4 supports double-precision floating point, >>>> and it looks like it's maybe more amenable to embedding than the Cortex >>>> Ax cores. I really want to find a chip that I can just lick the back of >>>> and stick onto a board, rather than something that'll become the CPU in a >>>> built-up computer with external memory and all that razz-matazz. >>>> >>>> TI has a Cortex R4 part, but I've used the predecessor part and the only >>>> tools available for it were from Keil -- I dislike single-sourcing, and >>>> I'd much prefer using Gnu tools if there are such for the R4. >>>> >>>> So, has anyone used the R4? Do you happen to know if the Gnu tools >>>> support it well? Can you recommend any off the shelf embedded processors >>>> that use it? (TI included -- just because the SM470R1B1M was hard to >>>> work with doesn't mean that TI hasn't solved those problems with their >>>> Cortex version). >>> >>> Both Rowley http://www.rowley.co.uk/arm/Support_Packages.htm and >>> Imagecraft https://www.imagecraft.com/ seem to support TI TMS570 >>> series processors. I've used both compilers but not that series (or >>> other R4) processors so I'm not absolutely sure that's what you're >>> looking for. >>> >>> Rowley is GNU-based, Imagecraft is independent. I've used both for >>> commercial embedded products. There's probably a pure GNU solution out >>> there, but I'm in a situation where (L)GPL issues arise. >>> >> >> The GPL nature of gcc does not affect you unless you are trying to run >> the compiler on the microcontroller. Any sane toolchain will have >> libraries that can be linked with your code without any license >> restrictions - but if you use additional third-party libraries or code, >> you obviously need to check the licence (whether commercial or open source). > > Correct. Rowley, for example, does use a gcc compiler and, of course, > the generated code itself isn't GPL-burdened. They also (being a sane > toolchain ;-) provide their own non-LGPL libraries. >
Rowley provide their own libraries - that's one of the reasons people might pay for an otherwise free compiler (along with things like support, the IDE, the debugger, etc.). But they like Rowley's libraries because they are small and fast, not because there is any practical difference in the licences compared to newlib or (for examle) Code Sourcery's libraries' licences. My point is merely that there are no GPL or LGPL issues to worry about with gcc or commonly used free libraries targeted at static linking.
> In the "check the license" vein, however, using C++ RTTI or exceptions > does link in GPL-licensed code (not just LGPL). I've been puzzled > about why that's the case but since I stay away from C++ in embedded > work I haven't worried about (or investigated) that too much. >
There are a number of code snippets that come with gcc itself (as distinct from the libraries), and are copied verbatim from the gcc source into temporary files which end up complied and linked with your code. There are also library files that are distributed as part of gcc itself (such as support for floating point and integer arithmetic which require library routines rather than code segments). The code generators arguably also involve verbatim copying of assembly-language source code from gcc files into your own code. But while the original gcc author (Richard Stallman) is well-known for his fanaticism for free software, fortunately the other authors realised that keeping these parts under a strict GPL would make the compiler "free" but useless outside of the GNU project. So there is an explicit exception in the licence that covers all such code, letting you use it an link it with any other code that you want, under any licence. So don't worry - you can use C++ exceptions in your embedded code if you want, with no licensing issues. You might have trouble convincing yourself and others of the reliability of code using hidden and unexpected jumps (which is what exceptions are), but the licences will be fine :-)