don't process $(LDFLAGS) with prefix-args

don't process $(LDFLAGS) with prefix-args

[Paul Jarc]

Earlier versions of Emacs had a bug where user-supplied $(LDFLAGS)
would be processed by prefix-args when building temacs.  The bug was
fixed for 21.2 (or perhaps earlier), but it's back again in 21.3.

User-supplied $(LDFLAGS) is used with both $(CC) and, when building
temacs, $(LD).  Since it's used with $(CC), it may already contain
-Wl, or -Xlinker arguments.  So if $(LD) is $(CC) (with or without
-nostdlib), $(LDFLAGS) should not be re-escaped with -Xlinker.

If $(LD) is ld, then (currently) you're stuck; you can't pass anything
in $(LDFLAGS) except what is intelligible to both $(CC) and ld
directly.  This could be fixed by using prefix-args whenever we pass
$(LDFLAGS) to $(CC), but not when we pass $(LDFLAGS) to ld; then the
instructions would have to tell users to pass flags as they should
appear to ld, instead of as they should appear to $(CC).

The Makefile could be made to work this way on all systems: use
prefix-args whenever we pass $(LDFLAGS) to $(CC) (including when we
pass it to $(LD), on systems where $(LD) is $(CC)), but not when we
pass it to $(LD) if $(LD) is ld.  This is a tradeoff between
consistency across platforms and similarity with other packages on
systems where $(LD) is $(CC).


paul

Re: don't process $(LDFLAGS) with prefix-args

[Richard Stallman]

    Earlier versions of Emacs had a bug where user-supplied $(LDFLAGS)
    would be processed by prefix-args when building temacs.  The bug was
    fixed for 21.2 (or perhaps earlier), but it's back again in 21.3.

Can you find the difference in 21.3 which brought back the bug?  I
don't see any change in Makefile.in between 21.2 and 21.3 that would
relate to this at all.  It appears that the use of YMF_PASS_LDFLAGS
for all of LDFLAGS remains unchanged since then.

You might want to look at whether LINKER_WAS_SPECIFIED is defined in
21.2 and in 21.3.  A change in that might affect it.

    User-supplied $(LDFLAGS) is used with both $(CC) and, when building
    temacs, $(LD).

I see it is used with $(CC) when compiling prefix-args.
Anywhere else?  Why do you use -Wl or -Xlinker args in it?
Precisely which executables do you want those options for?

    This could be fixed by using prefix-args whenever we pass
    $(LDFLAGS) to $(CC), but not when we pass $(LDFLAGS) to ld; then the
    instructions would have to tell users to pass flags as they should
    appear to ld, instead of as they should appear to $(CC).

As far as I can see, src/Makefile.in already does this, except in on
case: when compiling prefix-args itself.

Re: don't process $(LDFLAGS) with prefix-args

[Paul Jarc]

Richard Stallman <rms@gnu.org> wrote:
>     Earlier versions of Emacs had a bug where user-supplied $(LDFLAGS)
>     would be processed by prefix-args when building temacs.  The bug was
>     fixed for 21.2 (or perhaps earlier), but it's back again in 21.3.
>
> Can you find the difference in 21.3 which brought back the bug?  I
> don't see any change in Makefile.in between 21.2 and 21.3 that would
> relate to this at all.

The distributed Makefile.in's are similar enough, but somewhere in the
21.2 build process, Makefile.in is modified like so:

--- Makefile.in.2       2003-03-27 14:42:33.000000000 -0500
+++ emacs-21.2/src/Makefile.in  2003-03-27 14:57:21.000000000 -0500
@@ -495,7 +495,7 @@
 #endif /* not ORDINARY_LINK */
 
 ALL_LDFLAGS = LD_SWITCH_SYSTEM LD_SWITCH_SYSTEM_TEMACS LD_SWITCH_MACHINE \
-        LD_SWITCH_MACHINE_TEMACS LD_SWITCH_SITE $(LDFLAGS)
+        LD_SWITCH_MACHINE_TEMACS LD_SWITCH_SITE
 
 /* A macro which other sections of Makefile can redefine to munge the
    flags before they're passed to LD.  This is helpful if you have
@@ -868,7 +868,7 @@
 #endif
 
 temacs: MAKE_PARALLEL $(LOCALCPP) $(STARTFILES) stamp-oldxmenu ${obj} ${otherobj} OBJECTS_MACHINE prefix-args
-       $(LD) YMF_PASS_LDFLAGS (${STARTFLAGS} ${ALL_LDFLAGS}) \
+       $(LD) YMF_PASS_LDFLAGS (${STARTFLAGS} ${ALL_LDFLAGS}) $(LDFLAGS) \
     -o temacs ${STARTFILES} ${obj} ${otherobj}  \
     OBJECTS_MACHINE ${LIBES}
 

21.3 does not modify its Makefile.in during the build process.

> You might want to look at whether LINKER_WAS_SPECIFIED is defined in
> 21.2 and in 21.3.  A change in that might affect it.

Where should I look for that?

>     User-supplied $(LDFLAGS) is used with both $(CC) and, when building
>     temacs, $(LD).
>
> I see it is used with $(CC) when compiling prefix-args.
> Anywhere else?

I tried building with raw linker flags in LDFLAGS, and I got
diagnostics about unrecognized options when building test-distrib,
make-docfile, profile, digest-doc, sorted-doc, movemail, cvtmail,
fakemail, yow, emacsserver, hexl, etags, ctags, emacsclient, b2m,
ebrowse, and prefix-args.

> Why do you use -Wl or -Xlinker args in it?

I need to supply rpath options so shared libraries will be found.

> Precisely which executables do you want those options for?

*I* need it for any executables that link to the jpeg, libpng,
libungif, ncurses, tiff, xfree86, or zlib libraries.  But I imagine
other users might want to pass other flags that should take effect for
all executables, regardless of what they link to.

>     This could be fixed by using prefix-args whenever we pass
>     $(LDFLAGS) to $(CC), but not when we pass $(LDFLAGS) to ld; then the
>     instructions would have to tell users to pass flags as they should
>     appear to ld, instead of as they should appear to $(CC).
>
> As far as I can see, src/Makefile.in already does this, except in on
> case: when compiling prefix-args itself.

Yes, but the same user-supplied LDFLAGS is used for all
subdirectories, so the problem is not limited to src/Makefile.in.


paul

Re: don't process $(LDFLAGS) with prefix-args

[Richard Stallman]

    The distributed Makefile.in's are similar enough, but somewhere in the
    21.2 build process, Makefile.in is modified like so:

That is really bizarre.  Can you find out where the code is
that makes this change?  If it is in configure, can you show us
the code which does so?

Re: don't process $(LDFLAGS) with prefix-args

[Paul Jarc]

I wrote:
> The distributed Makefile.in's are similar enough, but somewhere in the
> 21.2 build process, Makefile.in is modified like so:

Sorry, my mistake.  That isn't happening; I had simply patched my 21.2
this way to make it compile.  So the bug hasn't reappeared - it was
never fixed. :/  ISTR what happened was that I posted this patch for
21.1 or 21.2, and it was agreed that it should be applied, but
apparently it never was.  It still works for me with 21.3.

The patch makes it so the user-supplied LDFLAGS is not processed by
YMF_PASS_LDFLAGS.  So on systems where $(LD) is $(CC), this patch
changes the interpretation of LDFLAGS in src/ to match its
interpretation in other subdirectories.  On systems where $(LD) is ld,
YMF_PASS_LDFLAGS is a no-op, so there is no real change: the
interpretation is still inconsistent among subdirectories.

--- Makefile.in.2       2003-03-27 14:42:33.000000000 -0500
+++ emacs-21.2/src/Makefile.in  2003-03-27 14:57:21.000000000 -0500
@@ -495,7 +495,7 @@
 #endif /* not ORDINARY_LINK */
 
 ALL_LDFLAGS = LD_SWITCH_SYSTEM LD_SWITCH_SYSTEM_TEMACS LD_SWITCH_MACHINE \
-        LD_SWITCH_MACHINE_TEMACS LD_SWITCH_SITE $(LDFLAGS)
+        LD_SWITCH_MACHINE_TEMACS LD_SWITCH_SITE
 
 /* A macro which other sections of Makefile can redefine to munge the
    flags before they're passed to LD.  This is helpful if you have
@@ -868,7 +868,7 @@
 #endif
 
 temacs: MAKE_PARALLEL $(LOCALCPP) $(STARTFILES) stamp-oldxmenu ${obj} ${otherobj} OBJECTS_MACHINE prefix-args
-       $(LD) YMF_PASS_LDFLAGS (${STARTFLAGS} ${ALL_LDFLAGS}) \
+       $(LD) YMF_PASS_LDFLAGS (${STARTFLAGS} ${ALL_LDFLAGS}) $(LDFLAGS) \
     -o temacs ${STARTFILES} ${obj} ${otherobj}  \
     OBJECTS_MACHINE ${LIBES}
 


paul