I figure out a set of
--build=amd64 --host=amd64 --target=i686
toolchain. [1]
It seems work, with some problems left:
1. gcc64 depends on mpfr4/gmp/mpclib3, which has no multilib support yet.
2. I use dpkg-divert to replace the executable with this one. Is it suitable?
It is in a very early
> "Luke" == Luke Kenneth Casson Leighton writes:
>On Friday, August 23, 2019, Karsten Merker wrote:
> and decide for themselves who is displaying "violent
> hatred" on mailing lists and come to their own judgement about
> your allegations:
Luke>You've now violated the
Aurélien,
Thanks for caring about 32bits arches !
On Thu, Aug 8, 2019 at 10:39 PM Aurelien Jarno wrote:
[...]
> mips and mipsel are more affected by the issue as the virtual address
> space is limited to 2GB. Therefore on those architectures, this issue
> recently started to also affect core
"Theodore Y. Ts'o" writes:
> On Wed, Aug 21, 2019 at 10:03:01AM +0100, Luke Kenneth Casson Leighton wrote:
>> so i hope that list gives a bit more context as to how serious the
>> consequences of dropping 32 bit support really is.
>
> I very much doubt we are any where near "dropping 32-bit
On Friday, August 23, 2019, Karsten Merker wrote:
>
> and decide for themselves who is displaying "violent hatred" on
> mailing lists and come to their own judgement about your
> allegations:
You've now violated the Debian Conduct twice in under an hour.
https://www.debian.org/code_of_conduct
On Thu, Aug 22, 2019 at 7:58 PM Karsten Merker wrote:
> On Fri, Aug 23, 2019 at 01:49:57AM +0800, Luke Kenneth Casson Leighton wrote:
>
> > The last time that we spoke, Theo, some time around 2003 you informed me
> > that you were doing so very deliberately "to show everyone how stupid I
> >
On Thursday, August 22, 2019, Theodore Y. Ts'o wrote:
> On Wed, Aug 21, 2019 at 10:03:01AM +0100, Luke Kenneth Casson Leighton
> wrote:
> >
> > so i hope that list gives a bit more context as to how serious the
> > consequences of dropping 32 bit support really is.
>
> I very much doubt we are
On Wed, Aug 21, 2019 at 10:03:01AM +0100, Luke Kenneth Casson Leighton wrote:
>
> so i hope that list gives a bit more context as to how serious the
> consequences of dropping 32 bit support really is.
I very much doubt we are any where near "dropping 32-bit support".
There's a lot of "all or
i remembered a couple more:
* the freescale iMX6 has a 19-year supply / long-term support (with
about another 10 years to go). it's used in the bunnie huang "Novena
Laptop" and can take up to 4GB of RAM. processor core: *32-bit* ARM
Cortex A9, in 1, 2 and 4-core SMP arrangements.
* the Zync
On Tue, Aug 20, 2019 at 04:21:43PM +0100, Luke Kenneth Casson Leighton wrote:
that 32-bit hardware is consigned to landfill. debian has a far
higher impact (as a leader, due to the number of ports) than i think
anyone realises. if debian says "we're dropping 32 bit hardware",
that's it, it's
On Tue, Aug 20, 2019 at 3:31 PM Sam Hartman wrote:
>
> > "\Luke" == Luke Kenneth Casson Leighton writes:
> Hi.
> First, thanks for working with you.
> I'm seeing a lot more depth into where you're coming from, and it is
> greatly appreciated.
likewise.
> I'd like to better understand the
> "\Luke" == Luke Kenneth Casson Leighton writes:
Hi.
First, thanks for working with you.
I'm seeing a lot more depth into where you're coming from, and it is
greatly appreciated.
\Luke> indeed.
\Luke> i do get it - i did say. i'm aware that software libre
\Luke> developers
On Tue, Aug 20, 2019 at 2:52 PM Sam Hartman wrote:
> I think my concern about your approach is that you're trying to change
> how the entire world thinks.
that would be... how can i put it... an "incorrect" interpretation. i
think globally - i always have. i didn't start the NT Domains
> "Luke" == Luke Kenneth Casson Leighton writes:
>> I even agree with you that we cannot address these challenges and
>> get to a point where we have confidence a large fraction of our
>> software will cross-build successfully.
Luke> sigh.
I don't really see the need for a
On Tue, Aug 20, 2019 at 1:17 PM Sam Hartman wrote:
> I'd ask you to reconsider your argument style.
that's very reasonable, and appreciated the way that you put it.
> I'm particularly frustrated that you spent your entire reply moralizing
> and ignored the technical points I made.
ah: i
[trimming the cc]
> "Luke" == Luke Kenneth Casson Leighton writes:
Luke> On Mon, Aug 19, 2019 at 7:29 PM Sam Hartman
wrote:
>> Your entire argument is built on the premise that it is actually
>> desirable for these applications (compilers, linkers, etc) to
>> work in
On Mon, Aug 19, 2019 at 7:29 PM Sam Hartman wrote:
> Your entire argument is built on the premise that it is actually
> desirable for these applications (compilers, linkers, etc) to work in
> 32-bit address spaces.
that's right [and in another message in the thread it was mentioned
that builds
> "Luke" == Luke Kenneth Casson Leighton writes:
Luke> On Wed, Aug 14, 2019 at 5:13 PM Aurelien Jarno
wrote:
>> > a proper fix would also have the advantage of keeping linkers
>> for > *other* platforms (even 64 bit ones) out of swap-thrashing,
>> saving > power consumption
On Wed, Aug 14, 2019 at 5:13 PM Aurelien Jarno wrote:
> > a proper fix would also have the advantage of keeping linkers for
> > *other* platforms (even 64 bit ones) out of swap-thrashing, saving
> > power consumption for build hardware and costing a lot less on SSD and
> > HDD regular
On 2019-08-09 16:26, Luke Kenneth Casson Leighton wrote:
> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
>
> On Fri, Aug 9, 2019 at 1:49 PM Ivo De Decker wrote:
> >
> > Hi Aurelien,
> >
> > On 8/8/19 10:38 PM, Aurelien Jarno wrote:
> >
> > > 32-bit processes are
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Thu, Aug 8, 2019 at 9:39 PM Aurelien Jarno wrote:
> We are at a point were we should probably look for a real solution
> instead of relying on tricks.
*sigh* i _have_ been pointing out for several years now that
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Fri, Aug 9, 2019 at 1:49 PM Ivo De Decker wrote:
>
> Hi Aurelien,
>
> On 8/8/19 10:38 PM, Aurelien Jarno wrote:
>
> > 32-bit processes are able to address at maximum 4GB of memory (2^32),
> > and often less (2 or 3GB)
Hi,
On 8/9/19 4:41 PM, Karsten Merker wrote:
On Fri, Aug 09, 2019 at 02:31:47PM +0200, Ivo De Decker wrote:
Some random notes (these are just my preliminary thoughts, not a new release
team policy):
[...]
- We are talking about having both native 32-bit and 64-bit packages in
the same
On Fri, 09 Aug 2019 at 14:31:47 +0200, Ivo De Decker wrote:
> On 8/8/19 10:38 PM, Aurelien Jarno wrote:
> > This is still a kind of cross-compiler
>
> As you noted, our current policy doesn't allow that.
...
> The resulting (32-bit) binaries still need to run natively in the build
> environment.
Hi Aurelien,
On 8/8/19 10:38 PM, Aurelien Jarno wrote:
32-bit processes are able to address at maximum 4GB of memory (2^32),
and often less (2 or 3GB) due to architectural or kernel limitations.
[...]
Thanks for bringing this up.
1) Build a 64-bit compiler targeting the 32-bit
On Fri, 2019-08-09 at 00:28 +0200, Aurelien Jarno wrote:
> On 2019-08-08 22:23, Ben Hutchings wrote:
[...]
> > 1a. Require 32-bit build environments to be multiarch with the
> > related 64-bit architecture also enabled.
>
> Indeed, but that looks like the first step. From there do you think
>
On 2019-08-08 23:57, John Paul Adrian Glaubitz wrote:
> Hi!
>
> On 8/8/19 10:38 PM, Aurelien Jarno wrote:
> > Any comments, ideas, or help here?
> I'm by no means a GHC nor Haskell expert, but I think it should be generally
> feasible to add native code generation support in GHC for all
On 2019-08-08 22:23, Ben Hutchings wrote:
> On Thu, 2019-08-08 at 22:38 +0200, Aurelien Jarno wrote:
> [...]
> > 1) Build a 64-bit compiler targeting the 32-bit corresponding
> >architecture and install it in the 32-bit chroot with the other
> >64-bit dependencies. This is still a kind of
Hi!
On 8/8/19 10:38 PM, Aurelien Jarno wrote:
> Any comments, ideas, or help here?
I'm by no means a GHC nor Haskell expert, but I think it should be generally
feasible to add native code generation support in GHC for all architectures
which are supported by LLVM.
According to a bug report I saw
On Thu, 2019-08-08 at 22:38 +0200, Aurelien Jarno wrote:
[...]
> 1) Build a 64-bit compiler targeting the 32-bit corresponding
>architecture and install it in the 32-bit chroot with the other
>64-bit dependencies. This is still a kind of cross-compiler, but the
>rest of the build is
[ debian-arm is Cced: as armel and armhf might be impacted in the
future]
[ debian-devel is Cced: as i386 might be impacted in the future]
[ debian-release is Cced: as the release has to agree with the
solution]
Hi all,
32-bit processes are able to address at maximum 4GB of memory (2^32),
31 matches
Mail list logo
