Pretest compilation problem

Pretest compilation problem

[Chong Yidong]

I got an email from Nelson Beebe about a problem compiling a 32-bit
version on a 64-bit x64 machine:

> gcc -c -D_BSD_SOURCE -Demacs -DHAVE_CONFIG_H
> -I. -I/local/build32/gcc/emacs-23.2.94/src -D_BSD_SOURCE -m32
> -I/usr/local/include -MMD -MF deps/prefix-args.d
> prefix-args.c
> gcc -Wl,-rpath,/usr/local/lib -L/usr/local/lib -Wl,-znocombreloc
> prefix-args.o -o prefix-args
> /home/local/bin/../lib/gcc-lib/x86_64-unknown-linux-gnu/3.3.5/../../../../x86_64-unknown-linux-gnu/bin/ld:
> i386 architecture of input file `prefix-args.o' is
> incompatible with i386:x86-64 output
>
> The problem is in src/Makefile:137:
>
> 	       $(CC) $(LDFLAGS) prefix-args.o -o prefix-args
>
> In general, $(CC) should ALWAYS have a $(CFLAGS) following it;
> otherwise, architecture-specific
> flags like -m32 fail to be supplied.

Adding $(CFLAGS) sounds correct, except for a comment about this rule in
Makefile.in, which I don't understand:

/* We do not use ALL_LDFLAGS because LD_SWITCH_SYSTEM and LD_SWITCH_MACHINE
   often contain options that have to do with using Emacs''s crt0,
   which are only good with temacs.  */
prefix-args${EXEEXT}: prefix-args.o $(config_h)
	$(CC) $(LDFLAGS) prefix-args.o -o prefix-args

Does anyone know what this warning is about, and whether adding
$(CFLAGS) (or $(ALL_CFLAGS)?) could cause problems here?

Re: Pretest compilation problem

[Andreas Schwab]

Chong Yidong <cyd@stupidchicken.com> writes:

> I got an email from Nelson Beebe about a problem compiling a 32-bit
> version on a 64-bit x64 machine:
>
>> gcc -c -D_BSD_SOURCE -Demacs -DHAVE_CONFIG_H
>> -I. -I/local/build32/gcc/emacs-23.2.94/src -D_BSD_SOURCE -m32

You really should put -m32 into CC, since it is a different compiler.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Pretest compilation problem

[Glenn Morris]

Chong Yidong wrote:

> Adding $(CFLAGS) sounds correct,

ALL_CFLAGS used to be there in Emacs 23.1. It was removed in r1.461,
2009-12-16, by Andreas ("Don't compile prefix-args.c twice.")
I'm sure he will be happy to provide a detailed explanation.

http://cvs.savannah.gnu.org/viewvc/emacs/src/Makefile.in?root=emacs&r1=1.460&r2=1.461&pathrev=MAIN

>  except for a comment about this rule in Makefile.in, which I don't
> understand:
>
> /* We do not use ALL_LDFLAGS because LD_SWITCH_SYSTEM and LD_SWITCH_MACHINE
>    often contain options that have to do with using Emacs''s crt0,
>    which are only good with temacs.  */

IIRC, the Makefiles tried to make a distinction between flags that were
only needed to link temacs (see the various TEMACS variables, eg
LD_SWITCH_SYSTEM_TEMACS), and flags that were needed to compile separate
things like prefix-args. It's quite possible that the comment is
inaccurate or outdated though.

Re: Pretest compilation problem

[Andreas Schwab]

Glenn Morris <rgm@gnu.org> writes:

> Chong Yidong wrote:
>
>> Adding $(CFLAGS) sounds correct,
>
> ALL_CFLAGS used to be there in Emacs 23.1. It was removed in r1.461,
> 2009-12-16, by Andreas ("Don't compile prefix-args.c twice.")
> I'm sure he will be happy to provide a detailed explanation.

Since it's no longer compiling there is no need for CFLAGS any more.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Pretest compilation problem

[Chong Yidong]

Andreas Schwab <schwab@linux-m68k.org> writes:

> Glenn Morris <rgm@gnu.org> writes:
>
>> Chong Yidong wrote:
>>
>>> Adding $(CFLAGS) sounds correct,
>>
>> ALL_CFLAGS used to be there in Emacs 23.1. It was removed in r1.461,
>> 2009-12-16, by Andreas ("Don't compile prefix-args.c twice.")
>> I'm sure he will be happy to provide a detailed explanation.
>
> Since it's no longer compiling there is no need for CFLAGS any more.

Strictly speaking, you're correct.  But passing CFLAGS apparently does
no harm.  As for the statement that -m32 belongs in CC, I doubt that
most people make that distinction between -m32 and other arguments to
the compiler; at the very least, it is surprising requirement for us to
make.

Unless anyone can come up with a specific example where adding CFLAGS to
this rule causes compilation to do the wrong thing, I'll put it back.

CC, CFLAGS, and -m32 [was Re: Pretest compilation problem]

[Glenn Morris]

Andreas Schwab wrote:

> You really should put -m32 into CC, since it is a different compiler.

I've seen this advertized elsewhere, and it's off-topic for Emacs, but
can you explain this to me?

Eg `info make' says:

`CC'
     Program for compiling C programs; default `cc'.  

"gcc -m32" is not a program. It is a program plus some switches.
I believe you if you say that switch causes an entirely different compiler
to be invoked behind the scenes, but I don't buy that as a justification
for why -m32 should go there and not in CFLAGS.

It just seems like an excuse to get round the fact that some Makefiles
don't pass CFLAGS during the linking stage...

`info make' also says:

`CFLAGS'
     Extra flags to give to the C compiler.

Not "flags passed to the compiler if it is being invoked as a compiler,
not a linker". Just "flags passed to the C compiler", full-stop.

Re: CC, CFLAGS, and -m32 [was Re: Pretest compilation problem]

[Paul Eggert]

On 02/16/2011 07:16 PM, Glenn Morris wrote:
> I've seen this advertized elsewhere, and it's off-topic for Emacs, but
> can you explain this to me?

It's to cater to a common usage, where one does
"configure CC='cc -m32'; [edit]; make CFLAGS=-g".

"configure" may decide to use "-g -O2", but you may find it easier
to compile with plain -g than with -g -O2, because it's easier to debug
code that isn't optimized.

If instead you use "configure CC=cc CFLAGS=-m32", it's more of
a pain: "configure" won't set all the CFLAGS for you, and when
you run "make" yourself you need to say "make CFLAGS='-m32 -g'".

Re: CC, CFLAGS, and -m32 [was Re: Pretest compilation problem]

[Miles Bader]

Glenn Morris <rgm@gnu.org> writes:
>> You really should put -m32 into CC, since it is a different compiler.
>
> I've seen this advertized elsewhere, and it's off-topic for Emacs, but
> can you explain this to me?
>
> Eg `info make' says:
>
> `CC'
>      Program for compiling C programs; default `cc'.  
>
> "gcc -m32" is not a program. It is a program plus some switches.

CC is just the first part of the command line invoked to compile things.
The term "program" is used because it's easy for humans to understand,
but the documentation is not a strict rule.

Standard practice is to use that form (CC="compiler + options") for
options that be should used consistently for all invocations of the
compiler... CFLAGS, by comparison is a bit unreliable.

-Miles

-- 
Learning, n. The kind of ignorance distinguishing the studious.

Re: CC, CFLAGS, and -m32 [was Re: Pretest compilation problem]

[Chong Yidong]

Paul Eggert <eggert@cs.ucla.edu> writes:

> On 02/16/2011 07:16 PM, Glenn Morris wrote:
>> I've seen this advertized elsewhere, and it's off-topic for Emacs, but
>> can you explain this to me?
>
> It's to cater to a common usage, where one does
> "configure CC='cc -m32'; [edit]; make CFLAGS=-g".
>
> "configure" may decide to use "-g -O2", but you may find it easier
> to compile with plain -g than with -g -O2, because it's easier to debug
> code that isn't optimized.
>
> If instead you use "configure CC=cc CFLAGS=-m32", it's more of
> a pain: "configure" won't set all the CFLAGS for you, and when
> you run "make" yourself you need to say "make CFLAGS='-m32 -g'".

Nonetheless, there should be no downside for us to add CFLAGS to this
Makefile rule, correct?  If you know of any risk, let me know.

Re: CC, CFLAGS, and -m32 [was Re: Pretest compilation problem]

[Paul Eggert]

On 02/19/2011 09:39 AM, Chong Yidong wrote:
> Nonetheless, there should be no downside for us to add CFLAGS to this
> Makefile rule, correct?

I don't see any downside.  It's normal to use both $(CC) and $(CFLAGS)
when linking.  If there's some weird setup that this breaks, we should
fix the setup, not contort the makefile.