GCC dropping SCO support in next release.
FyRE
page for the GCC compiler, they're dropping support for SCO UnixWare
in the next release:
http://gcc.gnu.org/gcc-3.4/changes.html#obsolete_systems
Hopefully OpenServer will have support dumped next. Lets hope some
other opensource projects pick up on the idea ;-)
--
FyRE < "War: The way Americans learn geography" >
Mike Brown
It may be a small point, but it looks like the UnixWare with UDK support
is being obsoleted, which in some way makes sense. The Universal
Development Kit allowed a single compiler and binary to work on both
OpenServer and UnixWare. The next release of OpenServer will have
a UnixWare kernel, so likely the reported better native UnixWare
compiler will serve for both. Makes the UDK version, well, obsolete.
I hope all the opensource teams continue to support SCO customers,
punishing all of these people is just a bad idea in the long run. It
will make the M$ solution look less risky.
Mike
--
Michael Brown
The Kingsway Group
J. L. Schilling
> Some more good news (what a great day!), according to the GNU project
> page for the GCC compiler, they're dropping support for SCO UnixWare
> in the next release:
>
> http://gcc.gnu.org/gcc-3.4/changes.html#obsolete_systems
Sorry to throw water on you FyRE, but you're the victim of a labelling
mistake in the GCC release notes.
The GCC "triple" that is being labelled obsolete (with SCO's blessing)
is i?86-*-udk*, which is the configuration for the UnixWare/UDK ABI
on OpenServer. This is a "cross" environment that parallels how
the UnixWare UDK development tools work on OpenServer. For various
reasons, this cross environment hasn't been used much at all in
the GCC world, and thus there was no longer any useful reason to
keep it going.
OpenServer and UnixWare both have "native" triples, i?86-pc-sco3.2v5.0
and i?86-unknown-sysv respectively, and those are still fully
maintained within the GCC world, and SCO engineers have write access
to the GCC repository to keep them maintained. These are the GCC's
that everyone uses on SCO platforms.
Jonathan Schilling
Klaus Heinz
> OpenServer and UnixWare both have "native" triples, i?86-pc-sco3.2v5.0
> and i?86-unknown-sysv respectively, and those are still fully
> maintained within the GCC world, and SCO engineers have write access
> to the GCC repository to keep them maintained. These are the GCC's
> that everyone uses on SCO platforms.
Recently, I tried to find information about the 'official' GNU triplet
for Unixware. On UW 7.1.1, the latest config.guess ('2004-03-12')
chooses
i586-unknown-sysv5UnixWare7.1.1
Config.sub which is supposed to "canonicalize a configuration type" does
not change this. On the other hand, the latest libtool recognizes
"sysv4 | sysv4.2uw2* | sysv4.3* | sysv5*)"
end even
"sysv5OpenUNIX8* | sysv5UnixWare7* | sysv5uw[78]* | unixware7* | sysv4*uw2*)"
in its configure script. To me, all this suggests there is no generally
accepted triplet for Unixware7.
Wouldn't it make sense to have config.sub convert the above to
"i?86-pc-sysv5uw" or "i?86-pc-sysv5uw7"?
ciao
Klaus
J. L. Schilling
>
> Recently, I tried to find information about the 'official' GNU triplet
> for Unixware. On UW 7.1.1, the latest config.guess ('2004-03-12')
> chooses
>
> i586-unknown-sysv5UnixWare7.1.1
I am told that SCO was able to get the GNU/GCC staff to take this triplet:
i[3456]86 - processor
unknown - SCO is not a hardwar company - not tied to specific system
sysv5* - "sysv" + uname -r + uname -s + uname -v
So the generic UW7 based check should be sysv5*.
Note that UnixWare 7 is the ONLY System 5, version 5 UNIX out there....
> Config.sub which is supposed to "canonicalize a configuration type" does
> not change this. On the other hand, the latest libtool recognizes
>
> "sysv4 | sysv4.2uw2* | sysv4.3* | sysv5*)"
>
> end even
>
> "sysv5OpenUNIX8* | sysv5UnixWare7* | sysv5uw[78]* | unixware7* | sysv4*uw2*)"
>
> in its configure script. To me, all this suggests there is no generally
> accepted triplet for Unixware7.
Again, I am told that
libtool has always been a little ahead of the curve with many individuals
submitting changes. Even after the config.guess was part of the
GNU source tree, tools such as libtool did not immediately sync up.
The sysv4 and sysv4.2 were UnixWare 2 and earlier releases of AT&T UNIX.
The sysv4.3 was an early (ahead of time guess) as to what "Gemini"
was going to be named (became UnixWare 7).
The sysv5Open*, sysv5Unix*, etc. were hacks made by multiple users as
each UW release came out.
A future work item is to synch the libtool checks to "sysv5*".
Jonathan Schilling