This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: [PATCH] Add Blackfin support in newlib
Basically I would have to agree with the RTEMS folks regarding the
licencing (thanks Joel, for explaining the implications of section 6).
Being the author of another kernel (TinKer), I'm having the same
issues.
For other comments, see below:
On 10/20/06, Alain Schaefer <alani@easc.ch> wrote:
Hi,
I spent the better part of yesterday trying to build newlib-cvs
with this patch. I have to admit the cvs version is not very easy to
build. In the end I succeded.
Congrats buddy, well done! :)
The RTEMS port to blackfin, which is almost ready for publishing,
compiles and works fine with it. So from the technical point of view
it is ok and we can forget about the port/patch I and Michael Ambrus
have been working on. Altough Michael has some
technical objections which don't seem to affect RTEMS. Michael ?
- Both setjmp and longjmp are lacking (or according to the current gcc
release, it's rather _setjmp and _longjmp). If your application or
Newlib (or other libraries) don't need them, the build will pass
however.
- The implementation of ___sigsetjmp is not needed. If I'm not
mistaken, sigsetjmp and siglongjmp are wrapped around setjmp and
longjmp macros in machine/setjmp.h.
- The usage of the predefined BFIN macro in machine/ieeefp.h will lead
to the same compiling issues as mentioned in:
http://sourceware.org/ml/newlib/2006/msg00787.html
http://sourceware.org/ml/newlib/2006/msg00791.html
But me too, I am not happy with the port using the LGPL license.
Jeff, would I be allowed to replace the ADI port by my own port ?
And such have a newlib for bfin which does not impose the
restrictions of the LGPL ? Ralf and Joel is this a path
we could go for the bfin-rtems toolchain ?
I suppose you could, but I believe you would have to manage your port
(i.e. the files in conflict with the AD license) outside of the Newlib
source tree.
/Michael
Alain
On 10/20/06, Ralf Corsepius <ralf.corsepius@rtems.org> wrote:
> On Thu, 2006-10-19 at 18:23 -0400, Robin Getz wrote:
> > >Did Analog Devices really intend to apply this requirement on people
> > >fielding Blackfin applications using newlib (from LGPL section 6)
> >
> > Yes - kind of.
> Then we (rtems) should stay with the policy we had always applied:
>
> The LGPL is not acceptable to us, because it imposes restrictions to
> RTEMS and other embedded systems (static linkage), at least we don't
> want to impose on users (LGPL/GPL our and their code).
>
> I am bit surprised Jeff seems to be willing to accept the LGPL in case,
> despite he had reject other similar submissions in the past. If I were
> to decide, I would not accept it.
>
> > This is a small way, we can get people who are aware of things to contact
> > us, and we can put it under a BSD license for them. That was the intent -
> > so see how many people are actually using things.
> Hmm? People facing technical issues with your code will contact this
> list, not you.
>
> > A BSD license, where the adverting clause is removed, and a email me for
> > permission, is added - is even worse in my opinion - there are too many
> > licenses out there already...
> >
> > >I can't help but believe that the inconsistency is going to lead to users
> > >unwittingly violating the license.
> >
> > I understand the concern - and the copyright maintainer (ADI) is not going
> > to go after anyone who is using this on products that they make (kind of
> > selfish, but we all have to pay rent/eat). If someone bases a different MSA
> > port on this work (Intel has a MSA Core), I don't want them keeping it
> > internal (which is what a BSD license would allow).
> >
> > Thoughts?
> Well, IMO, you can choose: Having bfin user-base on embedded systems or not.
>
> Ralf
>
>
>