# # CDDL HEADER START # # The contents of this file are subject to the terms of the # Common Development and Distribution License (the "License"). # You may not use this file except in compliance with the License. # # You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE # or http://www.opensolaris.org/os/licensing. # See the License for the specific language governing permissions # and limitations under the License. # # When distributing Covered Code, include this CDDL HEADER in each # file and include the License file at usr/src/OPENSOLARIS.LICENSE. # If applicable, add the following below this CDDL HEADER, with the # fields enclosed by brackets "[]" replaced with your own identifying # information: Portions Copyright [yyyy] [name of copyright owner] # # CDDL HEADER END # # Copyright (c) 2008, 2023, Oracle and/or its affiliates. # NAME: emacs VERSION: 28.2 DESCRIPTION: GNU Emacs editor LICENSE: GPLv3 BUGTRAQ: solaris/utility/emacs COMMENTS: This file contains information about the emacs package within the Userland consolidation. Along with the comments in the Makefile, it documents any deviations from standard Userland or emacs practice, as well as miscellaneous information needed to understand how this component is put together. - We patch the following changes into the emacs sources. Additional details are found in the comment at the top of each patch. emacsclient1.patch emacsclient2.patch emacsclient3.patch Versions of Emacs through 28.2 are vulnerable to CVE-2023-27985, and CVE-2023-27986. These three patches cumulatively apply the fixes from the Emacs 29.1 repository to emacsclient-mail.desktop emacsclient.desktop. These patches come from the upstream git repository, and can be removed when we move to Emacs 29 or newer. etags.patch Versions of Emacs through 28.2 are vulnerable to CVE-2022-45939. This patch comes from the upstream git repository, and can be removed when we move to Emacs 29 or newer. etags2.patch Versions of Emacs through 28.2 are vulnerable to CVE-2022-48337. This patch comes from the upstream git repository, and can be removed when we move to Emacs 29 or newer. find.patch The rgrep function uses the GNU-specific -path option to the find command. Change the default value for the find-program variable in grep.el to use GNU find. In recent releases, we find that the find-program variable is repeated in other autogenerated files (ldefs.boot.el, loaddefs.el), and that these copies must also be adjusted. The safest policy is to do a brute force search of the entire source tree for defvar of find-program, and to fix them all. htmlfontify.patch Versions of Emacs through 28.2 are vulnerable to CVE-2022-48339. This patch comes from the upstream git repository, and can be removed when we move to Emacs 29 or newer. mediator.patch Modify the way emacs searches for its dump files in the PATH_EXEC directory so that it works correctly when emacs is run via the /usr/bin/emacs mediator symlink. See the following for the background behind this change. https://lists.gnu.org/archive/html/emacs-devel/2021-04/msg00875.html ruby-mode.patch Versions of Emacs through 28.2 are vulnerable to CVE-2022-48338. This patch comes from the upstream git repository, and can be removed when we move to Emacs 29 or newer. - If you patch configure.ac, as we did with emacs 24.5 for jpeg6b_config.patch, then you need a COMPONENT_PREP_ACTION definition in the Makefile in order to get the configure script generated during the 'prep' phase. This must issue the same commands that would otherwise be generated by the emacs Makefile. To get those commands, comment out COMPONENT_PREP_ACTION, and do a 'gmake clobber; gmake build', capturing the output, and then look for 'autoconf' in the output. The COMPONENT_PREP_ACTION for jpeg6b looked like: # We patch the configure.ac file. Get the new configure generated during prep. COMPONENT_PREP_ACTION = (cd $(@D) ; aclocal -I m4; autoconf ) It went just after the include lines, above VARIANTS - The emacs distribution used to have a subdirectory, src/s, which contained per-platform header files. We would apply the following patches. Please note that the contact information given in the comment in the first patch is no longer valid. Current information is found in the README file in the top level directory of this workspace. sol2-6.h: Enable the use of the native Solaris dldump() --- sol2-6.h.~1~ 2011-10-17 19:20:46.000000000 -0600 +++ sol2-6.h 2013-09-23 13:34:26.683033182 -0600 @@ -2,10 +2,17 @@ #include "sol2-5.h" -#if 0 /* dldump does not handle all the extensions used by GNU ld. */ +/* + * Use the Solaris dldump() function to dump emacs, instead of + * the generic unexelf code. + * + * If you encounter a problem using dldump(), please consider sending + * a message to the OpenSolaris tools-linking mailing list: + * http://mail.opensolaris.org/mailman/listinfo/tools-linking + */ + #undef UNEXEC #define UNEXEC unexsol.o -#endif /* arch-tag: 71ea3857-89dc-4395-9623-77964e6ed3ca (do not change this comment) */ sol2-5.h: Use the system malloc instead of the GNU malloc: --- sol2-5.h.~1~ 2011-10-17 19:20:46.000000000 -0600 +++ sol2-5.h 2013-09-23 13:34:26.732656398 -0600 @@ -17,6 +17,7 @@ /* This is not always necessary. Turned off at present for testers to identify any problems with gmalloc more accurately. */ /* #define SYSTEM_MALLOC */ +#define SYSTEM_MALLOC /* There have problems reported with mmap at least on Solaris 2.6 and 2.7. For simplicity, let's not use mmap for anything >= 2.5. These are now both handled by default by the configure process, and in fact, comments from the header files appear to have been carried over. With every update, we must verify that these settings stick and remain enabled. System Malloc: The information output at the end of the configure step verifies this: Configured for `x86_64-pc-solaris2.12'. ... Should Emacs use the GNU version of malloc? no (The GNU allocators don't work with this system configuration.) dldump: As of Emacs 27, emacs uses the "portable dumper" pdump, and no longer uses the traditional ELF style of dumped object. Unless you build it with specific options to enable the old dump model, you can dispense with caring about dldump(). If you do build it that way, one could examine the configure script looking for the setting "UNEXEC_OBJ=unexsol.o", but it seems easier/better to simply examine the final executable: % pvs -nos emacs | grep dldump emacs - libc.so.1 (SUNW_1.22): dldump; - Emacs can be built as either 32-bit or 64-bit, depending on the target machine. The benefit of a 64-bit emacs is that the size of the files it can handle is not limited to 128MB, as it is with the 32-bit version. For Solaris, we used to build both versions, using /usr/lib/isaexec to run the 64-bit version if possible, and the 32-bit version otherwise. Note that this was only done for the emacs binary itself, as there is no technical need for 64-bit versions of the ancillary programs that come with emacs (etags, emacsclient, etc). Fortunately, the vast majority of the files in an emacs tree are identical, regardless of the platform and/or word size, which makes this particularly easy to do. With Solaris 11, all kernels are 64-bit, and we therefore do not need the 32-bit executables. As such, we only supply 64-bit emacs binaries now, and the use of usr/lib/isaexec has been removed: This cuts the number of builds necessary in half, and also the binary package size. It also simplifies packaging, and the user's view of /usr/bin/emacs*. - With Emacs 28, there is a JIT facility for native compilation of Lisp (.eln) files. In the interest of simplicity, and to avoid a requirement on libgccjit, we are currently not enabling the feature. - There are three different toolkit options: None, Athena widgets (aka Xaw, or lucid), and gtk. It would be nice to only support gtk, but for purposes of minimization and user preference, we supply binaries for all three. We follow the Linux model in this regard. The Xaw and no-X versions are quite stable from release to release, so this isn't a large burden. - By default, emacs will find and use the Image Magick image manipulation library. The problem with this for Solaris is that the IM library APIs are not committed, and change from release to release, as opposed to the command line interfaces which are stable. Any update to IM causes breakage in emacs that takes 2 builds to resolve. At the same time, IM is not central to emacs use, and so, we choose to explicitly disable it with the --without-imagemagick config option. This can be revisited if we find that common emacs use suffers without it, or if IM stabilizes their library APIs. - With multiple emacs binaries, there is a need for a generic /usr/bin/emacs to exist, which will by default run the "best" version of emacs installed on the system. Older versions of Emacs for Solaris, dating back to the original integration into OpenSolaris, used a shell script that contained this logic: for EXE in emacs-gtk emacs-x emacs-nox; do if [ -f /usr/bin/$EXE ]; then exec /usr/bin/$EXE "$@" fi done With the update to Emacs 24.5 (July 2015), we have dropped that script, and /usr/bin/emacs is now an IPS mediated link: % pkg mediator emacs MEDIATOR VER. SRC. VERSION IMPL. SRC. IMPLEMENTATION emacs vendor vendor emacs-gtk The mediator names are the same as those of the emacs binaries (emacs-gtk, emacs-x, emacs-nox). By default, the mediated link will give the same order as before (gtk, x, nox). The admin can use 'pkg set-mediator' to override this vendor default. For example, to set emacs-x as the mediated default emacs: # pkg set-mediator -I emacs-x emacs The means by which the ordering (emacs-gtk, emacs-x emacs-nox) is achieved needs some explanation. The mediated options are by default sorted in the order: priority, version, implementation-order, implementation Where "implementation" is sorted lexically. Lexical sorting puts emacs-gtk first, which is what we want, but it puts emacs-nox ahead of emacs-x. I played with setting the version or implementation-order values to achieve the desired sorting. This works, but as these are not real Emacs versions, the output from 'pkg mediator' is confusing. Instead, we set the priority of emacs-gtk and emacs-x to "vendor", and leave the priority of emacs-nox unspecified. Hence, emacs-gtk trumps emacs-x based on lexical sorting, and both of them trump emacs-nox based on priority. - In the past, we built emacs with gcc. The Makefile contained: # This code is built with gcc. The primary reason for this is that the # configure script has problems using a non-GNU cpp. I am not aware of # any reason Sun Studio could not be made to work, but simply made a # cost/benefit decision not to pursue it at this time COMPILER = gcc With emacs 24.3, I removed this, and found that studio now builds emacs without issue. With emacs 25.2, the studio compilers on sparc produce broken behavior at the -xO4 optimization level. 26552153 emacs on sparc does not wrap long line 26558067 emacs loses mouse cursor on sparc This can be mitigated by changing to -xO2. However, we don't know what the real issue is, and therefore, do not fully know if that's sufficient. Therefore, we went back to using gcc. - As mentioned above, starting with Emacs 27, we no longer rely on the traditional "unexec", used by emacs since the 1980's. on the Solaris dldump() function. Portable dumps (pdump) bring many benefits for us: * Inherent simplicity. * Elimination of the dependency on the Solaris dldump() function. dldump() was originally created specifically to handle emacs, back when dynamic linking started complicating the task of unexec. * Emacs can be delivered as a position independent executable (PIE). * ASLR, and the non-executable heap and stack security options are enabled. To enable ASLR, and the stack/heap options, the following lines were removed from the makefile. I record them here for their historical value, and in case we ever need to revisit these things: # LD_OPTIONS is defined to apply desirable link-editor options to # Userland components. Non-executable stack and data break sparc emacs. # LD_MAP_NOEXDATA.sparc= # ASLR should remain disabled for emacs. ASLR undermines emacs's dumping # code, which requires every execution to have the same mappings. Since # emacs is not network facing, or run with elevated privileges, this is # not a security concern. # # Similarly, emacs cannot cope with a non-executable stack and with # a protected and non-executable heap. ASLR_MODE = $(ASLR_DISABLE) NXHEAP_MODE = $(NXHEAP_DISABLE) NXSTACK_MODE = $(NXSTACK_DISABLE) - When updating to a new version, remember to ensure that the REQUIRED_PACKAGES lines in the Makefile are updated to match. Instructions can be found in the doc directory at the top of the userland workspace. Basically: % gmake REQUIRED_PACKAGES and then edit the Makefile to incorporate the added lines into what's there, and remove any no longer needed things. - Emacs is configured to use GnuTLS 3 rather than version 2. Version 3 used to require gnutls-3, but has been moved to the default gnutls. The gnutls-3 line remains during the transition period, and can be removed soon. REQUIRED_PACKAGES += library/gnutls-3 - We deliver the following packages: gnu-emacs - Everything you need to run emacs, except the emacs binaries. gnu-emacs-gtk - Binary for the X11 version using the GTK toolkit. gnu-emacs-no-x11 - Pure tty emacs binary, built without any X11 linkage or other extra support (i.e. D-bus). This is the most basic emacs possible, ideal for headless server systems. gnu-emacs-x11 - Binary for the X11 version using the Athena widget (Xaw) toolkit. gnu-emacs-lisp - The compressed LISP files for which compiled versions are delivered by gnu-emacs. These are only needed for emacs developers and those who like to read source code. The core gnu-emacs package is required by all of the other packages. In turn, gnu-emacs requires at least one of the packages supplying an emacs binary to be installed. - Emacs things we don't deliver: x) We do not ship any suid/sgid binaries for obvious security reasons. x) We do not install the files under /var/games/emacs. The reason for this is that we do not install update-game-score as setuid, and therefore the game files are not usable. This the same decision made by Debian, among others. x) usr/lib/systemd/user/emacs.service, which is only applicable to Linux.