Should we remove remnants of UWIN support in gcc/config.* files?

Should we remove remnants of UWIN support in gcc/config.* files?

[FX]

[-- Attachment #1: Type: text/plain, Size: 673 bytes --]

UWIN support was apparently removed from GCC in 2008. Yet some traces can still be found in gcc/config.* files.
Attached patch would remove them. OK to commit?

FX


PS: gcc/config.host and gcc/config.build include some other such targets… without checking them all, I think the following could be removed:

powerpc-*-beos
i370-*-opened* | i370-*-mvs*
i386-*-vsta
i[34567]86-*-udk*
i[34567]86-*-sysv4*
i[34567]86-sequent-ptx4* | i[34567]86-sequent-sysv4*
i[34567]86-*-sco3.2v5*

Is there a good reason for not removing those targets? If not, I’ll try to track them down, check that they are indeed unsupported, and propose a patch removing them.




[-- Attachment #2: uwin.ChangeLog --]
[-- Type: application/octet-stream, Size: 196 bytes --]

2015-08-20  Francois-Xavier Coudert  <fxcoudert@gcc.gnu.org>

	* config.build: Remove i[34567]86-*-uwin* case.
	* config.host: Remove i[34567]86-*-uwin* case.
	* configure.ac: Remove uwin* case.


[-- Attachment #3: uwin.diff --]
[-- Type: application/octet-stream, Size: 1939 bytes --]

Index: gcc/config.build
===================================================================
--- gcc/config.build	(revision 226823)
+++ gcc/config.build	(working copy)
@@ -92,9 +92,6 @@ case $build in
     # Intel x86 on SCO UW/OSR5 Dev Kit
     build_install_headers_dir=install-headers-cpio
     ;;
-  i[34567]86-*-uwin*)
-    build_exeext=.exe
-    ;;
   i386-*-vsta) 
     # Intel 80386's running VSTa kernel
     ;;
Index: gcc/config.host
===================================================================
--- gcc/config.host	(revision 226823)
+++ gcc/config.host	(working copy)
@@ -252,11 +252,6 @@ case ${host} in
     out_host_hook_obj=host-mingw32.o
     host_lto_plugin_soname=liblto_plugin-0.dll
     ;;
-  i[34567]86-*-uwin*)
-    echo "*** UWIN may not be used as a host platform because"
-    echo "*** linking with posix.dll is not allowed by the GNU GPL."
-    exit 1
-    ;;
   i[34567]86-*-darwin* | x86_64-*-darwin*)
     out_host_hook_obj="${out_host_hook_obj} host-i386-darwin.o"
     host_xmake_file="${host_xmake_file} i386/x-darwin"
Index: gcc/configure.ac
===================================================================
--- gcc/configure.ac	(revision 226823)
+++ gcc/configure.ac	(working copy)
@@ -1795,7 +1795,7 @@ AS_HELP_STRING([--enable-win32-registry=
                 of the registry key])],,)
 
 case $host_os in
-  win32 | pe | cygwin* | mingw32* | uwin*)
+  win32 | pe | cygwin* | mingw32*)
     if test "x$enable_win32_registry" != xno; then
       AC_SEARCH_LIBS(RegOpenKeyExA, advapi32,, [enable_win32_registry=no])
     fi
@@ -2752,7 +2752,7 @@ gcc_GAS_CHECK_FEATURE([cfi sections dire
 	.cfi_startproc
 	.cfi_endproc],
 [case $target_os in
-  win32 | pe | cygwin* | mingw32* | uwin*)
+  win32 | pe | cygwin* | mingw32*)
     # Need to check that we generated the correct relocation for the
     # .debug_frame section.  This was fixed for binutils 2.21.
     gcc_cv_as_cfi_sections_directive=no

Re: Should we remove remnants of UWIN support in gcc/config.* files?

[Joseph Myers]

[-- Attachment #1: Type: text/plain, Size: 1012 bytes --]

On Thu, 20 Aug 2015, FX wrote:

> PS: gcc/config.host and gcc/config.build include some other such 
> targets… without checking them all, I think the following could be 
> removed:
> 
> powerpc-*-beos
> i370-*-opened* | i370-*-mvs*
> i386-*-vsta
> i[34567]86-*-udk*
> i[34567]86-*-sysv4*
> i[34567]86-sequent-ptx4* | i[34567]86-sequent-sysv4*
> i[34567]86-*-sco3.2v5*
> 
> Is there a good reason for not removing those targets? If not, I’ll try 
> to track them down, check that they are indeed unsupported, and propose 
> a patch removing them.

Well, they aren't *targets*, but *host* and *build* systems.  However, I 
don't think any of them are actually significantly relevant to GCC now as 
host or build systems (and nor do I think we need case statements for 
unsupported host or build systems - just let people try to build and 
possibly have the build fail, a fix for such a failure would better use 
autoconf than special-casing a triplet anyway).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Should we remove remnants of UWIN support in gcc/config.* files?

[FX]

> Well, they aren't *targets*, but *host* and *build* systems.

Yes, but do we maintain a list of support host or build systems, that would be different from our list of supported targets?
(That’s a question out of curiosity. I do agree with the rest of your message: in practice, they are not supported.)

FX

Re: Should we remove remnants of UWIN support in gcc/config.* files?

[Joseph Myers]

On Thu, 20 Aug 2015, FX wrote:

> > Well, they aren't *targets*, but *host* and *build* systems.
> 
> Yes, but do we maintain a list of support host or build systems, that 
> would be different from our list of supported targets?

I don't think there's such a list.  For any such system that's not a 
supported target to work in practice, it would need a reasonably modern 
C++ compiler, which probably rules out a lot of systems that have been 
obsoleted as targets.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Should we remove remnants of UWIN support in gcc/config.* files?

[Joel Sherrill]

On August 20, 2015 5:22:47 PM EDT, Joseph Myers <joseph@codesourcery.com> wrote:
>On Thu, 20 Aug 2015, FX wrote:
>
>> > Well, they aren't *targets*, but *host* and *build* systems.
>> 
>> Yes, but do we maintain a list of support host or build systems, that
>
>> would be different from our list of supported targets?
>
>I don't think there's such a list.  For any such system that's not a 
>supported target to work in practice, it would need a reasonably modern
>
>C++ compiler, which probably rules out a lot of systems that have been 
>obsoleted as targets.

Wouldn't a list be able to be compiled from major branch release announcements? There should be a deprecated and removed note in two release branch descriptions. Even if we screwed up and forgot to list it on both, if it likely to be in one of them.

--joel