>>>> "SJT" == Stephen J Turnbull
>>>> "Troy" == Troy Wu <troy(a)jgrind.org>
Troy> # bind (frame-being-created)
Troy> make-frame(nil #<x-device on ":0.0" 0x1a13>)
SJT> Ah, you have the "Hannibal Lector" release of GNU ld. It now slices
SJT> and dices your executable for you by default, confusing the Emacs
SJT> build process. That Lisp backtrace at startup is the usual symptom on
SJT> On 21.4.6 and later in 21.4 series, and 21.5.4 and later, this is
SJT> normally autodetected. For 21.1.14
SJT> LDFLAGS='-z nocombreloc'
SJT> in your environment (adjust to fit previous settings) should work.
Unfortunately, some Linux systems (SuSE 7.3) are using an ld that has
the new evil -z combreloc option, but doesn't document it in ld --help
$ ld --help
-z defs Disallows undefined symbols
-z initfirst Mark DSO to be initialized first at runtime
-z interpose Mark object to interpose all DSOs but executable
-z loadfltr Mark object requiring immediate process
-z nodefaultlib Mark object not to use default search paths
-z nodelete Mark DSO non-deletable at runtime
-z nodlopen Mark DSO not available to dlopen
-z nodump Mark DSO not available to
-z now Mark object non-lazy runtime binding
-z origin Mark object requiring immediate $ORIGIN processing
-z KEYWORD Ignored for Solaris compatibility
$ strings `which ld` | grep combreloc
$ ld --version
GNU ld 18.104.22.168.29
Now, the latest binutils snapshot _DOES_ include the help string we're
looking for in configure.in, so this problem will go away real soon.
Even though this bug affects me personally, I recommend not fixing it,
since no one should be using a pre-release binutils, and because it's
hard to come up with a portable fix.
E.g. you could try
PAGER=cat man ld | grep nocombreloc
but what if the man pages aren't installed?
You could try
strings `which ld` | grep nocombreloc
but what if there's a csh dot file config error or strings isn't
However, an addition to PROBLEMS, perhaps mentioning SuSE 7.3
specifically, might be a good idea.