Bugzilla Bug 77430

Hi,
I noticed that "emerge emacs" fails when LDFLAGS is set to something like LDFLAGS="-Wl,-O1,--enable-new-dtags,--sort-common"

I got the following error:
 
gcc -nostdlib `./prefix-args -Xlinker  -z nocombreloc -Wl,-O1,--enable-new-dtags,--sort-common -L/usr/X11R6/lib/lesstif -R/usr/X11R6/lib/lesstif ` -o temacs pre-crt0.o /usr/lib/crt1.o /usr/lib/crti.o dispnew.o frame.o scroll.o xdisp.o xmenu.o window.o charset.o coding.o category.o ccl.o cm.o term.o xfaces.o xterm.o xfns.o xselect.o xrdb.o fontset.o emacs.o keyboard.o macros.o keymap.o sysdep.o buffer.o filelock.o insdel.o marker.o minibuf.o fileio.o dired.o filemode.o cmds.o casetab.o casefiddle.o indent.o search.o regex.o undo.o alloc.o data.o doc.o editfns.o callint.o eval.o floatfns.o fns.o print.o lread.o abbrev.o syntax.o unexelf.o mocklisp.o bytecode.o process.o callproc.o region-cache.o sound.o atimer.o doprnt.o strftime.o intervals.o textprop.o composite.o md5.o  terminfo.o lastfile.o vm-limit.o  widget.o    ../lwlib/liblw.a  -lXm -lXpm -lXp -lXmu -lXt -lSM -lICE -lXext -ltiff -ljpeg -lpng -lz -lm -lungif -lXpm -lX11  -lncurses   -lm -lgcc -lc -lgcc /usr/lib/crtn.o 
/usr/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../i686-pc-linux-gnu/bin/ld: unrecognized option '-Wl,-O1,--enable-new-dtags,--sort-common'
/usr/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../i686-pc-linux-gnu/bin/ld: use the --help option for usage information
collect2: ld returned 1 exit status

Seems to be a problem with ./prefix-args but I can be wrong...
Maybe this would be better if this compilation issue was fixed.
(LDFLAGS could be used for something else than optimization)

Confirmed and agreed: it is a bit cumbersome to edit make.conf just for emacs..

well, 

well, « LDFLAGS="" emerge emacs » also works fine. But you're stuck to
compile emacs alone.

Unfortunately portage doesn't know about /etc/portage/package.ldflags :(
Neither about /etc/portage/package.{cflags,features} btw :(

Also just happened to me with 21.3-r3 (which is odd, since it's marked stable
on 
most arches...)

I changed the ebuild to use the filter_ldflags thing, and now it barfs on the 
lisp files installe by octave (to emacs/site-lisp).  I think octave needs an 
emacs use flag...

Btw, the filter-ldflags thing works if you treat it as one flag, ie:

 filter-ldflags '-Wl,-O1'

Sorry, the filter-ldflags thing only works with "ebuild foo merge" but not with
a 
regular emerge foo.  I'm not sure why, but the -Wl,-O1 construct for passing 
flags just doesn't sit right with flag-o-matic's handling of LDFLAGS...

More info in bug #65002 on the whole LDFLAGS thing.

*** Bug 81574 has been marked as a duplicate of this bug. ***

*** Bug 81591 has been marked as a duplicate of this bug. ***

Steve: filter-ldflags '-Wl,-O1' works fine here

at least with emacs-21.4

Filter-ldflags doesn't work here (with
LDFLAGS="-Wl,-O1,--enable-new-dtags,--sort-common").
Looking at flag-o-matic.eclass filter-ldflags must match exactly the same flag
of LDFLAGS in
order to remove it from LDFLAGS. "filter-ldflags '-Wl,-O1'" works only if you
do not have anything
separated with commas after -O1. Should we unset LDFLAGS completely then?

i think unsetting LDFLAGS completly is the best way

k, I unset LDFLAGS in emacs-21.4{,-r1}.ebuild.
Thanks for your input.

LDFLAGS are passed directly through the linker. This is why -Wl, is not
recognized.

The proper way to fix this is to set LDFLAGS=$(raw-ldflags) (the function is
defined in flag-o-matic.

(In reply to comment #13)
> The proper way to fix this is to set LDFLAGS=$(raw-ldflags) (the function is
> defined in flag-o-matic.

For emacs-22.1-r3, this will fail in configure already:
configure: error: C compiler cannot create executables

I think we can remove the "unset LDFLAGS" line for Emacs 22 and later. I've
done so for emacs-cvs. However, I suggest that we don't touch stable 22.1.

Reopening for proper closing. emacs-22.3-r1.ebuild doesn't touch LDFLAGS and is
stable since quite some time.