On 22.11.2009 19:49, Florian Weimer wrote:
* Matthias Klose:
On 21.11.2009 06:20, Florian Weimer wrote:
* Steve Langasek:
It's been suggested to me that it might help Debian move forward on this
issue if I provide some background on why Canonical has chosen to not regard
this issue as
* Matthias Klose:
On 21.11.2009 06:20, Florian Weimer wrote:
* Steve Langasek:
It's been suggested to me that it might help Debian move forward on this
issue if I provide some background on why Canonical has chosen to not regard
this issue as critical for Ubuntu.
My personal impression is
Hi Florian,
On Sat, Nov 21, 2009 at 01:20:15PM +0100, Florian Weimer wrote:
It's been suggested to me that it might help Debian move forward on this
issue if I provide some background on why Canonical has chosen to not regard
this issue as critical for Ubuntu.
My personal impression is
* Steve Langasek:
It's been suggested to me that it might help Debian move forward on this
issue if I provide some background on why Canonical has chosen to not regard
this issue as critical for Ubuntu.
My personal impression is that Debian does not view this issue as
critical, either.
On 16.08.2009 10:50, Luk Claes wrote:
Matthias Klose wrote:
On 29.04.2009 04:49, Florian Weimer wrote:
* Florian Weimer:
I've asked the FSF for a clarification (the second time, the first
clarification resulted in the Java bytecode exception). Until we know
for sure how to interpret the
Matthias Klose wrote:
On 29.04.2009 04:49, Florian Weimer wrote:
* Florian Weimer:
I've asked the FSF for a clarification (the second time, the first
clarification resulted in the Java bytecode exception). Until we know
for sure how to interpret the exception, it's probably best not to
* Kalle Olavi Niemitalo:
Please consider also the effect of GCC 4.4 on GPLv2-only applications,
where the application's licence requires source code under GPLv2,
including the source code of libgcc if GCC accompanies the executable,
but the source code of libgcc in GCC 4.4 is not available
Matthias Klose d...@debian.org writes:
Apparently there's no feedback yet from the FSF. This issue should not
prevent upgrading GCC to 4.4 for squeeze.
Please consider also the effect of GCC 4.4 on GPLv2-only applications,
where the application's licence requires source code under GPLv2,
On 29.04.2009 04:49, Florian Weimer wrote:
* Florian Weimer:
I've asked the FSF for a clarification (the second time, the first
clarification resulted in the Java bytecode exception). Until we know
for sure how to interpret the exception, it's probably best not to
make GCC 4.4 the default
* Florian Weimer:
I've asked the FSF for a clarification (the second time, the first
clarification resulted in the Java bytecode exception). Until we know
for sure how to interpret the exception, it's probably best not to
make GCC 4.4 the default compiler in sid/squeeze.
For the record, due
Stéphane Glondu st...@glondu.net wrote:
So one could even
make a proprietary compiler using C as an intermediate langage, and GCC
for the final stage, I guess.
Comeau C++'s GNU/Linux builds do exactly that. (In general it uses the local
C compiler as a slightly higher level assembler. This
* Josselin Mouette:
Le vendredi 10 avril 2009 à 14:35 +0200, Florian Weimer a écrit :
At least with a strict interpretation, the run-time exception suffers
from a significant issue with compilers which are not licensed under a
GPLv3-compatible license (such as the GPLv2, or the QPL), and
Starting with version 4.4, the FSF the licenses the GCC run-time
library with a special exception:
| Under Section 7 of GPL version 3, you are granted additional
| permissions described in the GCC Runtime Library Exception, version
| 3.1, as published by the Free Software Foundation.
The
Florian Weimer a écrit :
Starting with version 4.4, the FSF the licenses the GCC run-time
library with a special exception: [...]
A few precisions:
* OCaml doesn't depend on any GCC-specific feature. It works with any
C compiler.
* There are 4 compilers for Objective Caml:
- ocamlc,
* Stéphane Glondu:
* The runtime (ocamlrun) is a pure C program, that can be compiled with
any C compiler. Customized runtimes (with functions implemented in C)
can be generated; in this case, a C file might be generated by
ocamlc{,.opt}, and this file is handled the same way as the
On 10-04-2009, Florian Weimer f...@deneb.enyo.de wrote:
* Stéphane Glondu:
* The runtime (ocamlrun) is a pure C program, that can be compiled with
any C compiler. Customized runtimes (with functions implemented in C)
can be generated; in this case, a C file might be generated by
* Sylvain Le Gall:
But in Debian, we compile with GCC. And for the Int64 module,
functionality from libgcc2.c gets compiled into the binary. (This is
just the example I've verified.)
Int64 module is under LGPL + static link exception (and everything
related to runtime library). Does it
On 10-04-2009, Florian Weimer f...@deneb.enyo.de wrote:
* Sylvain Le Gall:
But in Debian, we compile with GCC. And for the Int64 module,
functionality from libgcc2.c gets compiled into the binary. (This is
just the example I've verified.)
Int64 module is under LGPL + static link exception
* Sylvain Le Gall:
byterun/ints.c, function caml_int64_div, the I64_div macro. This is
expanded into a plain division operator, and that is compiled into a
run-time library call by GCC.
I64_div is a function defined either in byterun/int64_emul.h o
byterun/int64_native.h. Reading both
On 10-04-2009, Florian Weimer f...@deneb.enyo.de wrote:
* Sylvain Le Gall:
byterun/ints.c, function caml_int64_div, the I64_div macro. This is
expanded into a plain division operator, and that is compiled into a
run-time library call by GCC.
I64_div is a function defined either in
Le vendredi 10 avril 2009 à 14:35 +0200, Florian Weimer a écrit :
At least with a strict interpretation, the run-time exception suffers
from a significant issue with compilers which are not licensed under a
GPLv3-compatible license (such as the GPLv2, or the QPL), and which
are implemented in
21 matches
Mail list logo
