gcc 64 bit

[asfoster]

Rodney - excellent news regarding the 64 bit compiler. We will get on to this as soon as the g option is up and running. But....what plans are there for tools library support -eg png, jpeg, zlib, Xlibs, OpenGL, Motif?

[rodney]

Sort of cascades. OpenGL needs Motif needs X11.
X11 consists of a large number of separate items these days (as opposed to the one
large thunk historically). This (X11) takes a fair amount of time. I did (with MSVC) do this
a while back (X11R7) but it wasn't released. I can't remember why off-hand but something
must have not been working right.

That stated, I did build Motif with gcc64 as a test. Can't do anything with it, but it did build.

Others like png are more "can be built alone".
However, the libraries png, jpeg & zlib have been available as 64bit
for about 2 years now. There are many others in 64-bit too.

[rodney]

I'm making a new libncurses package with the gcc 64bit.
I was trying to make a 64-bit version of rogue and the code kept SEGV'ing
in the ncurses library. After trying different things I thought I'd try building
with the beta gcc64 (previous was with cc/MSVC).
Lo-and-behold that fixed the SEGV!
More proof that gcc is better for us

No C module right now *blah* but cc didn't give it either.
Curiously, FYI, the ccMSVC build and gcc 64bit build both done as
level 2 optimization and the gcc built libncurses is 27% smaller.

[jerker_back]

Rodney, I don't know what to say or start.
Your patches to the SUA include files makes them incompatible with any other compiler than gcc in 64-bit. Furthermore, the headers does not follow POSIX standard.

To view an example: inttypes.h

[rodney]

> Rodney, I don't know what to say or start.

It is a Beta release.
The changes where given to me by Doug and
I just quickly put them together in a small package for gcc to work.
But Microsoft had already put size_t and ssize_t in .

I can make adjustments to this.
Originally we had hopes that MS would get back to us with the share library loading info in a
shorter timeframe. It's dragged out now with our MS contact changing divisions.

[oeffner]

Rodney, what's the status of this work now with the ominous news about SUA being deprecated with Windows 8?
Has the work been stalled or will it eventually be committed to the FSF?

[rodney]

I wouldn't call it stalled. I'd say it's in "hold, waiting information".
A couple of weeks ago some paperwork started (legal) to get the information
to Interop Systems (for Doug who's doing the work). Agonizingly slow, but progress.

In the "Department of Positive Thinking" I came across some positive information. The first item of positiveness is that web
traffic to SUA Community had increased a large amount from 2010 (which had slightly increased from 2009). The second
is that ftp downloads are up significantly as well (raw bytes, # of bundles, # of individual packages). I just started to look
at this data yesterday and there's a lot to go through to determine certain data is a not a "monthly blip". But, for the
curious people, the downloads for Interix 3.5 increased (2010 saw a slight drop) in absolute numbers while reducing as a
portion of the whole. Interix 6.0/6.1 increased it's percentage of the whole while increasing it's absolute numbers.
So Interix 3.5 (XP, 2003, 2003/R2) still has a significant number of active installs that I had assumed would have migrated
to Vista, Win7 and 2008. *rock on*
It also looks like folks have taken the 64-bit plunge. In previous years the bias with Interix 6.0/6.1 was to X86 and it is
now significantly to 64-bit.
To me that's positive data that is confirmed and measured.

In the unconfirmed information zone (read "rumours") I heard the number of downloads of the
MS SUA Utilities & Libraries was up too.
A number of analogies swirl through my head. But it seems to be a case of "someone" asserting the patient
is dead or almost dead to make everyone think it is a fact so it will come true, when really the patient is doing quite well.

[oeffner]

Rodney

A number of analogies swirl through my head. But it seems to be a case of "someone" asserting the patient
is dead or almost dead to make everyone think it is a fact so it will come true, when really the patient is doing quite well.

Sounds good. But it's a crying shame that MS isn't advertising and promoting it more loudly. I have only tried Oracles VirtualBox as an alternative to SUA. Aside from poor scaling on multi-core CPU it also has an arbitrarily large memory usage. Not sure how windows hypervisor scales but I can't imagine virtualisation OS platforms to ever become as lean and efficient as native code. So I'd love to have SUA as providing to real thing.
Once gcc 64 eventually is released I'd definitely install it on my Windows7 machines, stick to it and simply ignore future Windows releases that deprecates SUA.

[Marsu42]

I just tried SUA 64bit and I generally like it as a quick alternative to a full-fledged vm. Here's my 2 cents:

* To me, a working 64bit c is even more important than shared lib support - w/o it, many important tools won't compile. I didn't read much about that in the last posts except *blah* - does this mean that there hope for it, too?

* with two scripts switching a lot of env vars, I got the 64bit and default 32bit gcc working alongside, so no problem there.

* even if Microsoft is phasing out SUA on Windows 8, if it's still there in the rtm it is going to be around for the lifecycle of win8 = at least until 2017

* to be fair: VirtualBox is at least 2 times as fast as SUA on my box...

[oeffner]

Marsu42

* to be fair: VirtualBox is at least 2 times as fast as SUA on my box...

Can you substantiate this claim with some timings of test runs?

Compilers were compared on SUA 32bit a while ago.

http://www.suacommunity.com/forum/tm.asp...3&high=gcc

From that it's clear that the gcc 3.3 that comes along with the Tools and Utilities produces slow code. But an experimental gcc4.4 compiler produces code running as fast as any commercial compiler. I'd be surprised if any code compiled on VirtualBox would beat that.