[haiku-commits] Re: haiku: hrev51908 - build/jam/repositories/HaikuPortsCross

  • From: "Alexander von Gluck IV" <kallisti5@xxxxxxxxxxx>
  • To: haiku-commits@xxxxxxxxxxxxx
  • Date: Sun, 29 Apr 2018 17:54:26 +0000

April 29, 2018 12:45 PM, "Adrien Destugues" <pulkomandy@xxxxxxxxxxxxx> wrote:

On Sun, Apr 29, 2018 at 05:38:57PM +0000, Alexander von Gluck IV wrote:

The assumed roadmap for R2 and beyond is:
* 32-bit x86_gcc2 *if* there is big demand.
* 64-bit x86_64.
* x86_gcc2 secondary if ever complete.

There is no roadmap for R2 yet. Everyone may have different assumptions.

Fair enough, we barely have R1 nailed down with general consensus :-)

For example, R2 could be:

x64_64 with R2 API
* Either one of:
- x86_64 secondary with R1 API
- x86 secondary with R1 API (for software that did not make it to 64bit yet)
* no gcc2 at all

All true potentials, but I still don't see much "won't compile under x86_64"
code.  Generally, if something doesn't build under x86_64, it is because a
bunch of really poor assumptions were made on type lengths.  I feel like
most of those issues were fixed as bugs long ago in most (active) projects.

So where would x86 under x86_64 fit in? Even on Linux which
had a long 32-bit x86 history, the only time most people run
32-bit is for old pre-compiled stuff like games. Haiku doesn't
really have much pre-compiled 32-bit x86 software that can't
be recompiled.

I'd like to see this reverted unless there is a need.

It may be easier to first get a full gcc5 32/64bit system working first,
and then see about how we can fit gcc2 in. It also makes things somewhat
easier because in principle, the _x86 packages should be the same for
x86_gcc2 and x86_64 primary arch, so basically we have all the packages
available and built to test this way already.

I don't think there's a need for revert at this point. This doesn't get
in the way of anything.

Yeah, that was one of the few reasons I could think of to go such a route.
Trying to get 32 on 64 working would be easier if you eliminate the ABI changes
as a factor.

Fair enough, lets just not encourage people to make or use x86 secondary
packages under x86_64 until we have a better idea of what direction it will
go in :-)

 -- Alex

Other related posts: