* Re: -znocombreloc? @ 2016-12-05 3:23 Ali Bahrami 2016-12-05 15:50 ` -znocombreloc? Eli Zaretskii 0 siblings, 1 reply; 11+ messages in thread From: Ali Bahrami @ 2016-12-05 3:23 UTC (permalink / raw) To: emacs-devel > From: Eli Zaretskii <eliz@gnu.org> > Date: Sun, 04 Dec 2016 17:34:08 +0200 > > What about other systems: Solaris, *BSD (when they use GNU ld)? Do > they also not need this? Speaking for Solaris, I don't think you need to worry about it. It sounds like whatever bug might have been in the GNU ld that led to turning combreloc off has been fixed long ago, and I would bet that fix isn't really platform specific. Aide from that, emacs is usually built using the native ld on Solaris, so the bug was probably never seen. We'd prefer to have combreloc enabled, all things being equal. It's a good, if minor, optimization for the runtime linker at startup. If emacs has a problem with it, we'll deal with it, and come back here to ask for help if needed. With regard to the wider discussion of pdumper vs handling it entirely in lisp, I'll just say that I'm thrilled to see this being moved up the stack and out of the object file format level. Either solution is massively simpler and more robust than what it will replace. Thank you both for caring about the issue enough to have this debate and see it through. I'm confident that either outcome will be a big improvement over the status quo. - Ali ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: -znocombreloc? 2016-12-05 3:23 -znocombreloc? Ali Bahrami @ 2016-12-05 15:50 ` Eli Zaretskii 0 siblings, 0 replies; 11+ messages in thread From: Eli Zaretskii @ 2016-12-05 15:50 UTC (permalink / raw) To: Ali Bahrami; +Cc: emacs-devel > From: Ali Bahrami <ali_gnu2@emvision.com> > Date: Sun, 4 Dec 2016 20:23:30 -0700 > > Aside from that, emacs is usually built using the native ld on > Solaris, so the bug was probably never seen. This switch was only used with GNU ld. > With regard to the wider discussion of pdumper vs handling > it entirely in lisp, I'll just say that I'm thrilled to see > this being moved up the stack and out of the object file > format level. Either solution is massively simpler and > more robust than what it will replace. Thank you both for > caring about the issue enough to have this debate and see > it through. I'm confident that either outcome will be a > big improvement over the status quo. Thanks, I;m sure you are right. ^ permalink raw reply [flat|nested] 11+ messages in thread
* -znocombreloc? @ 2016-12-04 0:12 Daniel Colascione 2016-12-04 5:36 ` -znocombreloc? Paul Eggert 0 siblings, 1 reply; 11+ messages in thread From: Daniel Colascione @ 2016-12-04 0:12 UTC (permalink / raw) To: Emacs developers Does anyone remember _why_ temacs segfaults on startup unless we give ld this option? ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: -znocombreloc? 2016-12-04 0:12 -znocombreloc? Daniel Colascione @ 2016-12-04 5:36 ` Paul Eggert 2016-12-04 10:36 ` -znocombreloc? Richard Copley 2016-12-04 15:34 ` -znocombreloc? Eli Zaretskii 0 siblings, 2 replies; 11+ messages in thread From: Paul Eggert @ 2016-12-04 5:36 UTC (permalink / raw) To: Daniel Colascione, Emacs developers [-- Attachment #1: Type: text/plain, Size: 661 bytes --] Daniel Colascione wrote: > Does anyone remember _why_ temacs segfaults on startup unless we give ld this > option? It doesn't segfault for me, even when I build with -zcombreloc. I think -znocombreloc worked around bugs in now-obsolete versions of the GNU linker. See, for example: https://lists.gnu.org/archive/html/bug-gnu-emacs/2004-02/msg00278.html https://lists.gnu.org/archive/html/help-gnu-emacs/2003-05/msg00627.html Looking at recent GCC documentation it appears that this old hack should not matter now, so I'm inclined to remove it, as in the proposed patch (attached), which I tested on Fedora 24 x86-64 but have not installed. [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: 0001-Remove-old-znocombreloc-hack.patch --] [-- Type: text/x-diff; name="0001-Remove-old-znocombreloc-hack.patch", Size: 3179 bytes --] From fe4a24b33bb72610cf6703143cf910d7eef547b6 Mon Sep 17 00:00:00 2001 From: Paul Eggert <eggert@cs.ucla.edu> Date: Sat, 3 Dec 2016 21:29:06 -0800 Subject: [PATCH] Remove old -znocombreloc hack It no longer seems relevant. See the thread starting at: http://lists.gnu.org/archive/html/emacs-devel/2016-12/msg00142.html * configure.ac (LDFLAGS_NOCOMBRELOC): Remove. (LD_SWITCH_SYSTEM_TEMACS): Do not test for -znocombreloc. * etc/PROBLEMS: Update problem description. --- configure.ac | 32 -------------------------------- etc/PROBLEMS | 7 +++---- 2 files changed, 3 insertions(+), 36 deletions(-) diff --git a/configure.ac b/configure.ac index 2d116de..65b963c 100644 --- a/configure.ac +++ b/configure.ac @@ -1272,36 +1272,6 @@ AC_DEFUN ac_link="$ac_link $NON_GCC_LINK_TEST_OPTIONS" fi -dnl We need -znocombreloc if we're using a relatively recent GNU ld. -dnl If we can link with the flag, it shouldn't do any harm anyhow. -dnl Treat GCC specially since it just gives a non-fatal 'unrecognized option' -dnl if not built to support GNU ld. - -dnl For a long time, -znocombreloc was added to LDFLAGS rather than -dnl LD_SWITCH_SYSTEM_TEMACS. That is: -dnl * inappropriate, as LDFLAGS is a user option but this is essential. -dnl Eg "make LDFLAGS=... all" could run into problems, -dnl http://bugs.debian.org/684788 -dnl * unnecessary, since temacs is the only thing that actually needs it. -dnl Indeed this is where it was originally, prior to: -dnl http://lists.gnu.org/archive/html/emacs-pretest-bug/2004-03/msg00170.html -late_LDFLAGS="$LDFLAGS" -if test x$GCC = xyes; then - LDFLAGS_NOCOMBRELOC="-Wl,-znocombreloc" -else - LDFLAGS_NOCOMBRELOC="-znocombreloc" -fi - -LDFLAGS="$LDFLAGS $LDFLAGS_NOCOMBRELOC" - -AC_MSG_CHECKING([for -znocombreloc]) -AC_LINK_IFELSE([AC_LANG_PROGRAM([], [])], - [AC_MSG_RESULT(yes)], - LDFLAGS_NOCOMBRELOC= - [AC_MSG_RESULT(no)]) - -LDFLAGS="$late_LDFLAGS" - AC_CACHE_CHECK([whether addresses are sanitized], [emacs_cv_sanitize_address], [AC_COMPILE_IFELSE( @@ -5176,8 +5146,6 @@ AC_DEFUN esac fi -LD_SWITCH_SYSTEM_TEMACS="$LDFLAGS_NOCOMBRELOC $LD_SWITCH_SYSTEM_TEMACS" - AC_SUBST(LD_SWITCH_SYSTEM_TEMACS) ## Common for all window systems diff --git a/etc/PROBLEMS b/etc/PROBLEMS index c9b11fbc5..82c727f 100644 --- a/etc/PROBLEMS +++ b/etc/PROBLEMS @@ -196,10 +196,9 @@ as Xming or Cygwin/X. It crashes on X, but runs fine when called with option "-nw". -This has been observed when Emacs is linked with GNU ld but without passing -the -z nocombreloc flag. Emacs normally knows to pass the -z nocombreloc -flag when needed, so if you come across a situation where the flag is -necessary but missing, please report it via M-x report-emacs-bug. +This was observed when Emacs was linked with old versions of GNU ld. +If this happens, please file a bug report and mention the ld version. +Configuring with LDFLAGS="-Wl,-znocombreloc" may fix the problem. On platforms such as Solaris, you can also work around this problem by configuring your compiler to use the native linker instead of GNU ld. -- 2.7.4 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: -znocombreloc? 2016-12-04 5:36 ` -znocombreloc? Paul Eggert @ 2016-12-04 10:36 ` Richard Copley 2016-12-04 11:24 ` -znocombreloc? Richard Copley 2016-12-04 15:34 ` -znocombreloc? Eli Zaretskii 1 sibling, 1 reply; 11+ messages in thread From: Richard Copley @ 2016-12-04 10:36 UTC (permalink / raw) To: Paul Eggert; +Cc: Daniel Colascione, Emacs developers On 4 December 2016 at 05:36, Paul Eggert <eggert@cs.ucla.edu> wrote: > Daniel Colascione wrote: >> >> Does anyone remember _why_ temacs segfaults on startup unless we give ld >> this >> option? > > > It doesn't segfault for me, even when I build with -zcombreloc. I think > -znocombreloc worked around bugs in now-obsolete versions of the GNU linker. > See, for example: > > https://lists.gnu.org/archive/html/bug-gnu-emacs/2004-02/msg00278.html > https://lists.gnu.org/archive/html/help-gnu-emacs/2003-05/msg00627.html > > Looking at recent GCC documentation it appears that this old hack should not > matter now, so I'm inclined to remove it, as in the proposed patch > (attached), which I tested on Fedora 24 x86-64 but have not installed. Not sure where GCC and x86-64 come into it if this was for the Solaris native linker. (Is Solaris still a thing?) ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: -znocombreloc? 2016-12-04 10:36 ` -znocombreloc? Richard Copley @ 2016-12-04 11:24 ` Richard Copley 0 siblings, 0 replies; 11+ messages in thread From: Richard Copley @ 2016-12-04 11:24 UTC (permalink / raw) To: Paul Eggert; +Cc: Daniel Colascione, Emacs developers On 4 December 2016 at 10:36, Richard Copley <rcopley@gmail.com> wrote: > On 4 December 2016 at 05:36, Paul Eggert <eggert@cs.ucla.edu> wrote: >> Daniel Colascione wrote: >>> >>> Does anyone remember _why_ temacs segfaults on startup unless we give ld >>> this >>> option? >> >> >> It doesn't segfault for me, even when I build with -zcombreloc. I think >> -znocombreloc worked around bugs in now-obsolete versions of the GNU linker. >> See, for example: >> >> https://lists.gnu.org/archive/html/bug-gnu-emacs/2004-02/msg00278.html >> https://lists.gnu.org/archive/html/help-gnu-emacs/2003-05/msg00627.html >> >> Looking at recent GCC documentation it appears that this old hack should not >> matter now, so I'm inclined to remove it, as in the proposed patch >> (attached), which I tested on Fedora 24 x86-64 but have not installed. > > Not sure where GCC and x86-64 come into it if this was for the Solaris native > linker. (Is Solaris still a thing?) Sorry! I misread the old posts you referenced. Please ignore my reply, it's not useful. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: -znocombreloc? 2016-12-04 5:36 ` -znocombreloc? Paul Eggert 2016-12-04 10:36 ` -znocombreloc? Richard Copley @ 2016-12-04 15:34 ` Eli Zaretskii 2016-12-04 17:14 ` -znocombreloc? Daniel Colascione ` (2 more replies) 1 sibling, 3 replies; 11+ messages in thread From: Eli Zaretskii @ 2016-12-04 15:34 UTC (permalink / raw) To: Paul Eggert, Andreas Schwab; +Cc: dancol, emacs-devel > From: Paul Eggert <eggert@cs.ucla.edu> > Date: Sat, 3 Dec 2016 21:36:49 -0800 > > https://lists.gnu.org/archive/html/bug-gnu-emacs/2004-02/msg00278.html > https://lists.gnu.org/archive/html/help-gnu-emacs/2003-05/msg00627.html > > Looking at recent GCC documentation it appears that this old hack should not > matter now, so I'm inclined to remove it, as in the proposed patch (attached), > which I tested on Fedora 24 x86-64 but have not installed. What about other systems: Solaris, *BSD (when they use GNU ld)? Do they also not need this? Andreas, you introduced the use of this switch back in Sep 2001; do you perhaps remember the details of the original problem? Thanks. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: -znocombreloc? 2016-12-04 15:34 ` -znocombreloc? Eli Zaretskii @ 2016-12-04 17:14 ` Daniel Colascione 2016-12-05 2:47 ` -znocombreloc? Paul Eggert 2016-12-07 23:58 ` -znocombreloc? Jeremie Courreges-Anglas 2 siblings, 0 replies; 11+ messages in thread From: Daniel Colascione @ 2016-12-04 17:14 UTC (permalink / raw) To: Eli Zaretskii, Paul Eggert, Andreas Schwab; +Cc: emacs-devel On 12/04/2016 07:34 AM, Eli Zaretskii wrote: >> From: Paul Eggert <eggert@cs.ucla.edu> >> Date: Sat, 3 Dec 2016 21:36:49 -0800 >> >> https://lists.gnu.org/archive/html/bug-gnu-emacs/2004-02/msg00278.html >> https://lists.gnu.org/archive/html/help-gnu-emacs/2003-05/msg00627.html >> >> Looking at recent GCC documentation it appears that this old hack should not >> matter now, so I'm inclined to remove it, as in the proposed patch (attached), >> which I tested on Fedora 24 x86-64 but have not installed. > > What about other systems: Solaris, *BSD (when they use GNU ld)? Do > they also not need this? In any case, my guess would be that other systems won't need this switch with pdumper (because with pdumper, we won't be doing anything magical), so locally, I'll just make this stuff conditional on !CANNOT_DUMP. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: -znocombreloc? 2016-12-04 15:34 ` -znocombreloc? Eli Zaretskii 2016-12-04 17:14 ` -znocombreloc? Daniel Colascione @ 2016-12-05 2:47 ` Paul Eggert 2016-12-07 23:58 ` -znocombreloc? Jeremie Courreges-Anglas 2 siblings, 0 replies; 11+ messages in thread From: Paul Eggert @ 2016-12-05 2:47 UTC (permalink / raw) To: Eli Zaretskii, Andreas Schwab; +Cc: dancol, emacs-devel On 12/04/2016 07:34 AM, Eli Zaretskii wrote: > What about other systems: Solaris, *BSD (when they use GNU ld)? Do > they also not need this? They did long ago, with binutils 2.14 (2003) reportedly, but I doubt whether they need it now. I attempted to reproduce the problem on Solaris 10 sparc (it ships with binutils 2.15 dated 2004) and failed to reproduce it. I could well have gotten the recipe wrong, though. I doubt whether the dwindling band of Solaris users will care about this one way or another, as they invariably use the Solaris linker, which does not need this flag. Following up to other emails: Yes, Solaris is still a thing and we run it on a few servers here. Solaris 11.3 was released last month. Oracle plans to support Solaris 10 through 2021 and Solaris 11 through at least 2024. Daniel's right that -znocombreloc isn't needed if CANNOT_DUMP. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: -znocombreloc? 2016-12-04 15:34 ` -znocombreloc? Eli Zaretskii 2016-12-04 17:14 ` -znocombreloc? Daniel Colascione 2016-12-05 2:47 ` -znocombreloc? Paul Eggert @ 2016-12-07 23:58 ` Jeremie Courreges-Anglas 2016-12-08 1:19 ` -znocombreloc? Paul Eggert 2 siblings, 1 reply; 11+ messages in thread From: Jeremie Courreges-Anglas @ 2016-12-07 23:58 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel, Paul Eggert, Andreas Schwab, dancol Eli Zaretskii <eliz@gnu.org> writes: >> From: Paul Eggert <eggert@cs.ucla.edu> >> Date: Sat, 3 Dec 2016 21:36:49 -0800 >> >> https://lists.gnu.org/archive/html/bug-gnu-emacs/2004-02/msg00278.html >> https://lists.gnu.org/archive/html/help-gnu-emacs/2003-05/msg00627.html >> >> Looking at recent GCC documentation it appears that this old hack should not >> matter now, Paul, can you please point at the relevant information in the gcc documentation? >> so I'm inclined to remove it, as in the proposed patch (attached), >> which I tested on Fedora 24 x86-64 but have not installed. > > What about other systems: Solaris, *BSD (when they use GNU ld)? Do > they also not need this? nocombreloc doesn't seem to be needed on OpenBSD/amd64, using gcc and ld from the base system (4.2.1 and 2.17, respectively). I've asked for reports on other archs (emacs-25.1.90 + a patch to disable the ld flag). > Andreas, you introduced the use of this switch back in Sep 2001; do > you perhaps remember the details of the original problem? > > Thanks. > -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: -znocombreloc? 2016-12-07 23:58 ` -znocombreloc? Jeremie Courreges-Anglas @ 2016-12-08 1:19 ` Paul Eggert 0 siblings, 0 replies; 11+ messages in thread From: Paul Eggert @ 2016-12-08 1:19 UTC (permalink / raw) To: Eli Zaretskii, Andreas Schwab, dancol, emacs-devel On 12/07/2016 03:58 PM, Jeremie Courreges-Anglas wrote: >>> Looking at recent GCC documentation it appears that this old hack should not >>> matter now, > Paul, can you please point at the relevant information in the gcc > documentation? > Sorry, I can't find it now. Weird. I recall reading what looked like a manual and inferring that -znocombreloc wasn't needed now (this was not plainly stated), but I can't seem to find that information now. I thought it was the GCC manual, but perhaps it was another GNU manual, or perhaps I was reading the GCC Wiki. Sorry. ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2016-12-08 1:19 UTC | newest] Thread overview: 11+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-12-05 3:23 -znocombreloc? Ali Bahrami 2016-12-05 15:50 ` -znocombreloc? Eli Zaretskii -- strict thread matches above, loose matches on Subject: below -- 2016-12-04 0:12 -znocombreloc? Daniel Colascione 2016-12-04 5:36 ` -znocombreloc? Paul Eggert 2016-12-04 10:36 ` -znocombreloc? Richard Copley 2016-12-04 11:24 ` -znocombreloc? Richard Copley 2016-12-04 15:34 ` -znocombreloc? Eli Zaretskii 2016-12-04 17:14 ` -znocombreloc? Daniel Colascione 2016-12-05 2:47 ` -znocombreloc? Paul Eggert 2016-12-07 23:58 ` -znocombreloc? Jeremie Courreges-Anglas 2016-12-08 1:19 ` -znocombreloc? Paul Eggert
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.