bug#42675: Solaris 11.3 x86_64 support

bug#42675: Solaris 11.3 x86_64 support

[Jeffrey Walton]

Hi Everyone,

I'm submitting this one because etc/MACHINES says Solaris is supported.

I'm building on Solaris 11.3 using x86_64 per [1]. I use
'--build=x86_64-sun-solaris' because Autoguess chooses 32-bit instead
of 64-bit (even with CFLAGS and CXXFLAGS including -m64).

  $ ./configure ...
  checking for xcrun... no
  checking for GNU Make... gmake
  checking build system type... x86_64-sun-solaris2
  checking host system type... x86_64-sun-solaris2
  configure: error: Emacs does not support 'x86_64-sun-solaris2' systems.
  If you think it should, please send a report to bug-gnu-emacs@gnu.org.

But according to etc/MACHINES:

  $ cat etc/MACHINES
  ...

  ** Solaris

    On Solaris it is also possible to use either GCC or Solaris Studio
    to build Emacs, by pointing ./configure to the right compiler ...

[1] https://docs.oracle.com/cd/E37838_01/html/E66175/appendixb.html

bug#42675: Solaris 11.3 x86_64 support

[Andreas Schwab]

On Aug 02 2020, Jeffrey Walton wrote:

> I'm building on Solaris 11.3 using x86_64 per [1]. I use
> '--build=x86_64-sun-solaris'

You need to specify the exact solaris version you are building for.

> because Autoguess chooses 32-bit instead
> of 64-bit (even with CFLAGS and CXXFLAGS including -m64).

If you add -m64 to CC, not CFLAGS, then config.guess should do the right
thing.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

bug#42675: Solaris 11.3 x86_64 support

[Jeffrey Walton]

On Sun, Aug 2, 2020 at 10:18 AM Andreas Schwab <schwab@linux-m68k.org> wrote:
>
> On Aug 02 2020, Jeffrey Walton wrote:
>
> > I'm building on Solaris 11.3 using x86_64 per [1]. I use
> > '--build=x86_64-sun-solaris'
>
> You need to specify the exact solaris version you are building for.

Thanks Andreas.

I don't think that's the case. The Autotools docs say the triplet is
cpu-vendor-os. They don't say anything about a version number.[1]
There is no "solaris2" os. It is called 'Solaris'. Because of
Autotools name mangling a configure typically matches it to
'solaris*'.

[1] https://www.gnu.org/software/autoconf/manual/autoconf-2.65/html_node/Specifying-Target-Triplets.html

> > because Autoguess chooses 32-bit instead
> > of 64-bit (even with CFLAGS and CXXFLAGS including -m64).
>
> If you add -m64 to CC, not CFLAGS, then config.guess should do the right
> thing.

If I add -m64 to the compiler, then it breaks other packages. I don't
think that is fair to other packages that do things as expected.

But stepping back, there is no need to guess. I told the system what
to use in the --build.

Of the 100+ packages I build regularly, only Emacs has this problem.
I'm pretty sure the Emacs configure script is the problem in this
case.

The user's job is to set the environment. If I don't set the
environment properly then that's my fault and the configure script
should die. The flip side of that is, stop being clever in the script.
Just do what you are told and things will work well.

Jeff

bug#42675: Solaris 11.3 x86_64 support

[Mike Kupfer]

FWIW, I just looked at Emacs on 2 Solaris systems that I have access to.

One system is a SPARC box running S11.3.  It has Emacs 24.3, which was
built for sparc-sun-solaris2.11.

The other system is an x86 box running S11.4.  It has Emacs 26.3, which
was built for x86_64-pc-solaris2.11.

Recently I've not had much luck building Emacs using the Studio
compiler.  I don't know if it's a problem with Emacs, Studio, or
Solaris, and I haven't had the time to look into it.

regards,
mike

bug#42675: Solaris 11.3 x86_64 support

[Paul Eggert]

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

> The Autotools docs say the triplet is
> cpu-vendor-os. They don't say anything about a version number.

Nevertheless Andreas is right, as the 'os' string is 'solaris2.11' in Autoconf 
triplets. I disagreed with this kind of 'os' string when it was introduced in 
the 1990s and I still think it's confusing, but it's been that way for decades 
and it's not likely to be worth changing now.

Also, Andreas is right that the best way to build 64-bit Emacs executables on 
Solaris is to configure with CC='gcc -m64' or CC='cc -m64' or whatever. This has 
long been documented in Emacs's etc/MACHINES file, and this method works for 
many other GNU packages as well. (If method doesn't work on some other packages, 
I suggest the problem lies with those other packages. :-)

That being said, it would be helpful for Emacs to cater to nonstandard 'os' 
strings like plain 'solaris', so I installed the attached patch into Emacs 
master to do that. This should appear in Emacs 28 whenever that comes out, but 
it's too risky to slide into Emacs 27 so when building that I suggest using 
'solaris2.11'.

[-- Attachment #2: 0001-Simplify-Solaris-port.patch --]
[-- Type: text/x-patch, Size: 18641 bytes --]

From 155b2c8a8d51a492a8c350b92bd3e83187d72b78 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Wed, 5 Aug 2020 17:36:50 -0700
Subject: [PATCH] Simplify Solaris port
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This should avoid some configuration confusion as exemplified
by Jeffrey Walton’s recent bug report (Bug#42675).
* configure.ac (opsys): Simplify Solaris configuration by
not worrying about Solaris 9 and earlier, as they are no
longer supported by the Solaris developers.  This should
support Walton’s ‘./configure --build=x86_64-sun-solaris’.
Instead of bothering with ‘opsys=sol2-6’ and ‘opsys=sol2-10’,
just use ‘opsys=solaris’.  All uses changed.
(emacs_check_sunpro_c): Remove unused var.
* doc/misc/tramp.texi (Remote programs):
* etc/MACHINES, etc/PROBLEMS:
Modernize PATH for Oracle Developer Studio.
* etc/PROBLEMS: Move Solaris-related problems to legacy area,
except those that are still relevant.
---
 configure.ac        |  76 ++++++++-----------------
 doc/misc/tramp.texi |   2 +-
 etc/MACHINES        |  25 ++++----
 etc/PROBLEMS        | 135 ++++++++++++++++++++++----------------------
 lisp/dired-aux.el   |   4 +-
 5 files changed, 110 insertions(+), 132 deletions(-)

diff --git a/configure.ac b/configure.ac
index 4ee4517e11..c9aa076eb3 100644
--- a/configure.ac
+++ b/configure.ac
@@ -748,44 +748,21 @@ AC_DEFUN
     opsys=aix4-2
   ;;
 
-  ## Suns
-  *-sun-solaris* \
-    | i[3456]86-*-solaris2* | i[3456]86-*-sunos5* \
-    | x86_64-*-solaris2*    | x86_64-*-sunos5*)
+  ## Solaris
+  *-*-solaris* | *-*-sunos*)
     case "${canonical}" in
       i[3456]86-*-* )   ;;
       amd64-*-*|x86_64-*-*) ;;
       sparc* )		;;
       * )		unported=yes ;;
     esac
-    case "${canonical}" in
-      *-sunos5.[1-9][0-9]* | *-solaris2.[1-9][0-9]* )
-		opsys=sol2-10
-		emacs_check_sunpro_c=yes
-		;;
-      *-sunos5.[1-5]* | *-solaris2.[1-5]* ) unported=yes ;;
-      ## Note that Emacs 23.1's NEWS said the following would be dropped.
-      *-sunos5.6* | *-solaris2.6* )
-		opsys=sol2-6
-		RANLIB="ar -ts"
-		;;
-      ## 5.7 EOL Aug 2008, 5.8 EOL Mar 2012.
-      *-sunos5.[7-9]* | *-solaris2.[7-9]* )
-		opsys=sol2-6
-		emacs_check_sunpro_c=yes
-		;;
-    esac
+    opsys=solaris
     ## Watch out for a compiler that we know will not work.
-    case "${canonical}" in
-     *-solaris* | *-sunos5* )
-		if [ "x$CC" = x/usr/ucb/cc ]; then
-		  ## /usr/ucb/cc doesn't work;
-		  ## we should find some other compiler that does work.
-		  unset CC
-		fi
-		;;
-      *) ;;
-    esac
+    if [ "$CC" = /usr/ucb/cc ]; then
+      ## /usr/ucb/cc doesn't work;
+      ## we should find some other compiler that does work.
+      unset CC
+    fi
   ;;
 
   ## QNX Neutrino
@@ -1476,14 +1453,11 @@ AC_DEFUN
   mingw32)
    UNEXEC_OBJ=unexw32.o
    ;;
-  sol2-10)
+  solaris)
    # Use the Solaris dldump() function, called from unexsol.c, to dump
    # emacs, instead of the generic ELF dump code found in unexelf.c.
    # The resulting binary has a complete symbol table, and is better
    # for debugging and other observability tools (debuggers, pstack, etc).
-   #
-   # It is likely that dldump() works with older Solaris too, but this has
-   # not been tested, so for now this change is for Solaris 10 or newer.
    UNEXEC_OBJ=unexsol.o
    ;;
   *)
@@ -1586,7 +1560,7 @@ AC_DEFUN
 
   qnxnto) LIBS_SYSTEM="-lsocket" ;;
 
-  sol2*) LIBS_SYSTEM="-lsocket -lnsl" ;;
+  solaris) LIBS_SYSTEM="-lsocket -lnsl" ;;
 
   ## Motif needs -lgen.
   unixware) LIBS_SYSTEM="-lsocket -lnsl -lelf -lgen" ;;
@@ -1647,7 +1621,7 @@ AC_DEFUN
     SYSTEM_TYPE=berkeley-unix
     ;;
 
-  sol2* | unixware )
+  solaris | unixware )
     SYSTEM_TYPE=usg-unix-v
     ;;
 
@@ -2291,7 +2265,7 @@ AC_DEFUN
 test $with_unexec = yes &&
 case "$opsys" in
   ## darwin ld insists on the use of malloc routines in the System framework.
-  darwin | mingw32 | nacl | sol2-10) ;;
+  darwin | mingw32 | nacl | solaris) ;;
   cygwin | qnxnto | freebsd)
 	  hybrid_malloc=yes
           system_malloc= ;;
@@ -2427,7 +2401,7 @@ AC_DEFUN
     # need special flags to disable these optimizations. For example, the
     # definition of 'errno' in <errno.h>.
     case $opsys in
-      hpux* | sol*)
+      hpux* | solaris)
 	AC_DEFINE([_REENTRANT], 1,
 	  [Define to 1 if your system requires this in multithreaded code.]);;
       aix4-2)
@@ -2557,7 +2531,7 @@ AC_DEFUN
     ## inoue@ainet.or.jp says Solaris has a bug related to X11R6-style
     ## XIM support.
     case "$opsys" in
-      sol2-*) : ;;
+      solaris) : ;;
       *) AC_DEFINE(HAVE_X11R6_XIM, 1,
            [Define if you have usable X11R6-style XIM support.])
          ;;
@@ -4692,7 +4666,7 @@ AC_DEFUN
 fi
 
 case $opsys in
-  sol2* | unixware )
+  solaris | unixware )
     dnl Some SVr4s don't define NSIG in sys/signal.h for ANSI environments;
     dnl instead, there's a system variable _sys_nsig.  Unfortunately, we
     dnl need the constant to dimension an array.  So wire in the appropriate
@@ -4705,7 +4679,7 @@ AC_DEFUN
 
 case $opsys in
   dnl SIGIO exists, but the feature doesn't work in the way Emacs needs.
-  hpux* | nacl | openbsd | sol2* | unixware )
+  hpux* | nacl | openbsd | solaris | unixware )
     emacs_broken_SIGIO=yes
     ;;
 
@@ -4754,7 +4728,7 @@ AC_DEFUN
 esac
 
 case $opsys in
-  gnu-* | sol2-10 )
+  gnu-* | solaris )
     dnl FIXME Can't we test if this exists (eg /proc/$$)?
     AC_DEFINE(HAVE_PROCFS, 1, [Define if you have the /proc filesystem.])
   ;;
@@ -4883,7 +4857,7 @@ AC_DEFUN
     AC_DEFINE(PTY_TTY_NAME_SPRINTF, [sprintf (pty_name, "/dev/pty/tty%c%x", c, i);])
     ;;
 
-  sol2* )
+  solaris )
     dnl On SysVr4, grantpt(3) forks a subprocess, so do not use
     dnl O_CLOEXEC when opening the pty, and keep the SIGCHLD handler
     dnl from intercepting that death.  If any child but grantpt's should die
@@ -4893,7 +4867,7 @@ AC_DEFUN
     ;;
 
   unixware )
-    dnl Comments are as per sol2*.
+    dnl Comments are as per solaris.
     AC_DEFINE(PTY_OPEN, [fd = open (pty_name, O_RDWR | O_NONBLOCK)])
     AC_DEFINE(PTY_TTY_NAME_SPRINTF, [{ char *ptsname (int), *ptyname; int grantpt_result; sigset_t blocked; sigemptyset (&blocked); sigaddset (&blocked, SIGCHLD); pthread_sigmask (SIG_BLOCK, &blocked, 0); grantpt_result = grantpt (fd); pthread_sigmask (SIG_UNBLOCK, &blocked, 0); if (grantpt_result == -1) fatal("could not grant slave pty"); if (unlockpt(fd) == -1) fatal("could not unlock slave pty"); if (!(ptyname = ptsname(fd))) fatal ("could not enable slave pty"); snprintf (pty_name, PTY_NAME_SIZE, "%s", ptyname); }])
     ;;
@@ -4901,7 +4875,7 @@ AC_DEFUN
 
 
 case $opsys in
-  sol2* | unixware )
+  solaris | unixware )
     dnl This change means that we don't loop through allocate_pty too
     dnl many times in the (rare) event of a failure.
     AC_DEFINE(FIRST_PTY_LETTER, ['z'])
@@ -4996,7 +4970,7 @@ AC_DEFUN
    AC_DEFINE(GC_SETJMP_WORKS, 1)
 else
   case $opsys in
-    aix* | dragonfly | freebsd | netbsd | openbsd | sol2* )
+    aix* | dragonfly | freebsd | netbsd | openbsd | solaris )
       AC_DEFINE(GC_SETJMP_WORKS, 1)
       ;;
   esac
@@ -5043,7 +5017,7 @@ AC_DEFUN
 esac
 
 case $opsys in
-  sol2* | unixware )
+  solaris | unixware )
     dnl TIOCGPGRP is broken in SysVr4, so we can't send signals to PTY
     dnl subprocesses the usual way.  But TIOCSIGNAL does work for PTYs,
     dnl and this is all we need.
@@ -5053,7 +5027,7 @@ AC_DEFUN
 
 
 case $opsys in
-  hpux* | sol2* )
+  hpux* | solaris )
     dnl Used in xfaces.c.
     AC_DEFINE(XOS_NEEDS_TIME_H, 1, [Compensate for a bug in Xos.h on
       some systems, where it requires time.h.])
@@ -5108,7 +5082,7 @@ AC_DEFUN
     fi
     ;;
 
-  sol2*)
+  solaris)
     AC_DEFINE(USG, [])
     AC_DEFINE(USG5_4, [])
     AC_DEFINE(SOLARIS2, [], [Define if the system is Solaris.])
@@ -5173,7 +5147,7 @@ AC_DEFUN
       reopen it in the child.])
     ;;
 
-  sol2-10)
+  solaris)
     AC_DEFINE(_STRUCTURED_PROC, 1, [Needed for system_process_attributes
       on Solaris.])
     ;;
diff --git a/doc/misc/tramp.texi b/doc/misc/tramp.texi
index 91b1e996f4..56cd220e20 100644
--- a/doc/misc/tramp.texi
+++ b/doc/misc/tramp.texi
@@ -2105,7 +2105,7 @@ Remote programs
 @file{/usr/bin}, which are reasonable for most hosts.  To accommodate
 differences in hosts and paths, for example, @file{/bin:/usr/bin} on
 Debian GNU/Linux or
-@file{/usr/xpg4/bin:/usr/ccs/bin:/usr/bin:/opt/SUNWspro/bin} on
+@file{/usr/xpg4/bin:/usr/ccs/bin:/usr/bin:/opt/developerstudio12.6/bin} on
 Solaris, @value{tramp} queries the remote host with @command{getconf
 PATH} and updates the symbol @code{tramp-default-remote-path}.
 
diff --git a/etc/MACHINES b/etc/MACHINES
index 1bb244b49b..78e9cef0fd 100644
--- a/etc/MACHINES
+++ b/etc/MACHINES
@@ -81,25 +81,26 @@ the list at the end of this file.
 
 ** Solaris
 
-  On Solaris it is also possible to use either GCC or Solaris Studio
-  to build Emacs, by pointing ./configure to the right compiler:
+  On Solaris it is also possible to use either GCC or Oracle Developer
+  Studio to build Emacs, by pointing ./configure to the right compiler:
 
-    ./configure CC='/usr/sfw/bin/gcc'  # GCC
-    ./configure CC='cc'                # Solaris Studio
+    ./configure                # Defaults to 'gcc' if available.
+    ./configure CC='cc'        # Oracle Developer Studio
 
-  On Solaris, do not use /usr/ucb/cc.  Use /opt/SUNWspro/bin/cc.  Make
-  sure that /usr/ccs/bin and /opt/SUNWspro/bin are in your PATH before
-  /usr/ucb.  (Most free software packages have the same requirement on
-  Solaris.)  With this compiler, use '/opt/SUNWspro/bin/cc -E' as the
+  On Solaris, do not use /usr/ucb/cc.  Use Oracle Developer Studio.
+  Make sure that /usr/ccs/bin and the Oracle Developer Studio bin
+  directory (e.g., /opt/developerstudio12.6/bin) are in your PATH
+  before /usr/ucb.  (Most free software packages have the same
+  requirement on Solaris.)  With this compiler, use 'cc -E' as the
   preprocessor.  If this inserts extra whitespace into its output (see
-  the PROBLEMS file) then add the option '-Xs'.
+  the PROBLEMS file), add the option '-Xs'.
 
   To build a 64-bit Emacs (with larger maximum buffer size) on a
-  Solaris system which supports 64-bit executables, specify the -m64
+  Solaris system that defaults to 32-bit executables, specify the -m64
   compiler option.  For example:
 
-    ./configure CC='/usr/sfw/bin/gcc -m64'  # GCC
-    ./configure CC='cc -m64'                # Solaris Studio
+    ./configure CC='gcc -m64'  # GCC
+    ./configure CC='cc -m64'   # Oracle Developer Studio
 
 \f
 * Obsolete platforms
diff --git a/etc/PROBLEMS b/etc/PROBLEMS
index 4ce738d9a5..598a79f978 100644
--- a/etc/PROBLEMS
+++ b/etc/PROBLEMS
@@ -2222,6 +2222,7 @@ We list bugs in current versions here.  See also the section on legacy
 systems.
 
 *** On Solaris 10, Emacs crashes during the build process.
+(This applies only with './configure --with-unexec=yes', which is rare.)
 This was reported for Emacs 25.2 on i386-pc-solaris2.10 with Sun
 Studio 12 (Sun C 5.9) and with Oracle Developer Studio 12.6 (Sun C
 5.15), and intermittently for sparc-sun-solaris2.10 with Oracle
@@ -2239,66 +2240,6 @@ Solaris.  See Bug#26638.
 This is a Solaris feature (at least on Intel x86 cpus).  Type C-r
 C-r C-t, to toggle whether C-x gets through to Emacs.
 
-*** Problem with remote X server on Suns.
-
-On a Sun, running Emacs on one machine with the X server on another
-may not work if you have used the unshared system libraries.  This
-is because the unshared libraries fail to use YP for host name lookup.
-As a result, the host name you specify may not be recognized.
-
-*** Solaris 2.6: Emacs crashes with SIGBUS or SIGSEGV on Solaris after you delete a frame.
-
-We suspect that this is a bug in the X libraries provided by
-Sun.  There is a report that one of these patches fixes the bug and
-makes the problem stop:
-
-105216-01 105393-01 105518-01 105621-01 105665-01 105615-02 105216-02
-105667-01 105401-08 105615-03 105621-02 105686-02 105736-01 105755-03
-106033-01 105379-01 105786-01 105181-04 105379-03 105786-04 105845-01
-105284-05 105669-02 105837-01 105837-02 105558-01 106125-02 105407-01
-
-Another person using a newer system (kernel patch level Generic_105181-06)
-suspects that the bug was fixed by one of these more recent patches:
-
-106040-07  SunOS 5.6: X Input & Output Method patch
-106222-01  OpenWindows 3.6: filemgr (ff.core) fixes
-105284-12  Motif 1.2.7: sparc Runtime library patch
-
-*** Solaris 7 or 8: Emacs reports a BadAtom error (from X)
-
-This happens when Emacs was built on some other version of Solaris.
-Rebuild it on Solaris 8.
-
-*** When using M-x dbx with the SparcWorks debugger, the 'up' and 'down'
-commands do not move the arrow in Emacs.
-
-You can fix this by adding the following line to '~/.dbxinit':
-
- dbxenv output_short_file_name off
-
-*** On Solaris, CTRL-t is ignored by Emacs when you use
-the fr.ISO-8859-15 locale (and maybe other related locales).
-
-You can fix this by editing the file:
-
-        /usr/openwin/lib/locale/iso8859-15/Compose
-
-Near the bottom there is a line that reads:
-
-        Ctrl<t> <quotedbl> <Y>                  : "\276"        threequarters
-
-while it should read:
-
-        Ctrl<T> <quotedbl> <Y>                  : "\276"        threequarters
-
-Note the lower case <t>.  Changing this line should make C-t work.
-
-*** On Solaris, Emacs fails to set menu-bar-update-hook on startup, with error
-"Error in menu-bar-update-hook: (error Point before start of properties)".
-This seems to be a GCC optimization bug that occurs for GCC 4.1.2 (-g
-and -g -O2) and GCC 4.2.3 (-g -O and -g -O2).  You can fix this by
-compiling with GCC 4.2.3 or CC 5.7, with no optimizations.
-
 * Runtime problems specific to MS-Windows
 
 ** Emacs on Windows 9X requires UNICOWS.DLL
@@ -2733,13 +2674,13 @@ Libxpm is available for macOS as part of the XQuartz project.
 
 This indicates a mismatch between the C compiler and preprocessor that
 configure is using.  For example, on Solaris 10 trying to use
-CC=/opt/SUNWspro/bin/cc (the Sun Studio compiler) together with
-CPP=/usr/ccs/lib/cpp can result in errors of this form (you may also
-see the error '"/usr/include/sys/isa_defs.h", line 500: undefined control').
+CC=/opt/developerstudio12.6/bin/cc (the Oracle Developer Studio
+compiler) together with CPP=/usr/lib/cpp can result in errors of
+this form.
 
 The solution is to tell configure to use the correct C preprocessor
-for your C compiler (CPP="/opt/SUNWspro/bin/cc -E" in the above
-example).
+for your C compiler (CPP="/opt/developerstudio12.6/bin/cc -E" in the
+above example).
 
 ** Compilation
 
@@ -3110,7 +3051,69 @@ This section covers bugs reported on very old hardware or software.
 If you are using hardware and an operating system shipped after 2000,
 it is unlikely you will see any of these.
 
-*** Solaris 2.x
+** Solaris
+
+*** Problem with remote X server on Suns.
+
+On a Sun, running Emacs on one machine with the X server on another
+may not work if you have used the unshared system libraries.  This
+is because the unshared libraries fail to use YP for host name lookup.
+As a result, the host name you specify may not be recognized.
+
+*** Solaris 2.6: Emacs crashes with SIGBUS or SIGSEGV on Solaris after you delete a frame.
+
+We suspect that this is a bug in the X libraries provided by
+Sun.  There is a report that one of these patches fixes the bug and
+makes the problem stop:
+
+105216-01 105393-01 105518-01 105621-01 105665-01 105615-02 105216-02
+105667-01 105401-08 105615-03 105621-02 105686-02 105736-01 105755-03
+106033-01 105379-01 105786-01 105181-04 105379-03 105786-04 105845-01
+105284-05 105669-02 105837-01 105837-02 105558-01 106125-02 105407-01
+
+Another person using a newer system (kernel patch level Generic_105181-06)
+suspects that the bug was fixed by one of these more recent patches:
+
+106040-07  SunOS 5.6: X Input & Output Method patch
+106222-01  OpenWindows 3.6: filemgr (ff.core) fixes
+105284-12  Motif 1.2.7: sparc Runtime library patch
+
+*** Solaris 7 or 8: Emacs reports a BadAtom error (from X)
+
+This happens when Emacs was built on some other version of Solaris.
+Rebuild it on Solaris 8.
+
+*** When using M-x dbx with the SparcWorks debugger, the 'up' and 'down'
+commands do not move the arrow in Emacs.
+
+You can fix this by adding the following line to '~/.dbxinit':
+
+ dbxenv output_short_file_name off
+
+*** On Solaris, CTRL-t is ignored by Emacs when you use
+the fr.ISO-8859-15 locale (and maybe other related locales).
+
+You can fix this by editing the file:
+
+        /usr/openwin/lib/locale/iso8859-15/Compose
+
+Near the bottom there is a line that reads:
+
+        Ctrl<t> <quotedbl> <Y>                  : "\276"        threequarters
+
+while it should read:
+
+        Ctrl<T> <quotedbl> <Y>                  : "\276"        threequarters
+
+Note the lower case <t>.  Changing this line should make C-t work.
+
+*** On Solaris, Emacs fails to set menu-bar-update-hook on startup, with error
+"Error in menu-bar-update-hook: (error Point before start of properties)".
+This seems to be a GCC optimization bug that occurs for GCC 4.1.2 (-g
+and -g -O2) and GCC 4.2.3 (-g -O and -g -O2).  You can fix this by
+compiling with GCC 4.2.3 or CC 5.7, with no optimizations.
+
+*** Other legacy Solaris problems
 
 **** Strange results from format %d in a few cases, on a Sun.
 
diff --git a/lisp/dired-aux.el b/lisp/dired-aux.el
index 806a3955e4..777df79a6e 100644
--- a/lisp/dired-aux.el
+++ b/lisp/dired-aux.el
@@ -1014,8 +1014,8 @@ dired-compress
 (defvar dired-compress-file-suffixes
   '(
     ;; "tar -zxf" isn't used because it's not available on the
-    ;; Solaris10 version of tar. Solaris10 becomes obsolete in 2021.
-    ;; Same thing on AIX 7.1.
+    ;; Solaris 10 version of tar (obsolete in 2024?).
+    ;; Same thing on AIX 7.1 (obsolete 2023?) and 7.2 (obsolete 2022?).
     ("\\.tar\\.gz\\'" "" "gzip -dc %i | tar -xf -")
     ("\\.tgz\\'" "" "gzip -dc %i | tar -xf -")
     ("\\.gz\\'" "" "gunzip")
-- 
2.17.1

bug#42675: Solaris 11.3 x86_64 support

[Paul Eggert]

> Recently I've not had much luck building Emacs using the Studio
> compiler.  I don't know if it's a problem with Emacs, Studio, or
> Solaris, and I haven't had the time to look into it.

For what it's worth, I built and ran Emacs master with Oracle Developer Studio 
12.6 on Solaris 10 sparc with these commands:

../emacs-28.0.50/configure CC=cc --with-jpeg=ifavailable --with-png=ifavailable 
--with-gif=ifavailable --with-tiff=ifavailable --with-gnutls=ifavailable
gmake

I needed the "ifavailable" options because those libraries aren't available on 
Solaris 10.

If you're still having problems with Studio please file a bug report when you 
have the time. I did just now fix a problem on OpenIndiana (which needs 
"#include <gmp/gmp.h>" not "#include <gmp.h>") so if that's what you ran into it 
should be fixed now.

The original bug that prompted this bug report seems to have been fixed so I'm 
taking the liberty of marking this bug as done.