[ppc patch] link with -m32

[ppc patch] link with -m32

[Hollis Blanchard]

[-- Attachment #1: Type: text/plain, Size: 313 bytes --]

Some 64-bit PowerPC compilers default to 64-bit output. Right now we're 
building all the object files with -m32, but then the linker complains 
when it tries to link a 64-bit grubof. We need to add -m32 to LDFLAGS 
as well as CFLAGS.

Could somebody please confirm that this patch doesn't break x86-64?

-Hollis

[-- Attachment #2: grub-biarch-link.txt --]
[-- Type: text/plain, Size: 2211 bytes --]

Index: Makefile.in
===================================================================
RCS file: /sources/grub/grub2/Makefile.in,v
retrieving revision 1.17
diff -u -p -r1.17 Makefile.in
--- Makefile.in	3 Jan 2006 17:58:02 -0000	1.17
+++ Makefile.in	15 Apr 2006 03:59:21 -0000
@@ -56,6 +56,7 @@ mkinstalldirs = $(srcdir)/mkinstalldirs
 
 CC = @CC@
 CFLAGS = @CFLAGS@
+LDFLAGS = @LDFLAGS@
 CPPFLAGS = -I. -Iinclude -I$(srcdir)/include -Wall -W
 BUILD_CC = @BUILD_CC@
 BUILD_CFLAGS = -g -O2
Index: configure
===================================================================
RCS file: /sources/grub/grub2/configure,v
retrieving revision 1.31
diff -u -p -r1.31 configure
--- configure	2 Apr 2006 08:53:31 -0000	1.31
+++ configure	15 Apr 2006 03:59:22 -0000
@@ -2907,6 +2907,8 @@ echo "${ECHO_T}$falign_loop_flag" >&6
 
   if test "x$biarch32" = x1; then
     tmp_CFLAGS="$tmp_CFLAGS -m32"
+    LDFLAGS="$tmp_LDFLAGS -m32"
+
   fi
 
   CFLAGS="$tmp_CFLAGS"
Index: configure.ac
===================================================================
RCS file: /sources/grub/grub2/configure.ac,v
retrieving revision 1.22
diff -u -p -r1.22 configure.ac
--- configure.ac	2 Apr 2006 08:53:31 -0000	1.22
+++ configure.ac	15 Apr 2006 03:59:22 -0000
@@ -89,6 +89,8 @@ if test "x$default_CFLAGS" = xyes; then
 
   if test "x$biarch32" = x1; then
     tmp_CFLAGS="$tmp_CFLAGS -m32"
+    LDFLAGS="$tmp_LDFLAGS -m32"
+    AC_SUBST(LDFLAGS)
   fi
 
   CFLAGS="$tmp_CFLAGS"
Index: conf/powerpc-ieee1275.rmk
===================================================================
RCS file: /sources/grub/grub2/conf/powerpc-ieee1275.rmk,v
retrieving revision 1.52
diff -u -p -r1.52 powerpc-ieee1275.rmk
--- conf/powerpc-ieee1275.rmk	25 Dec 2005 15:59:50 -0000	1.52
+++ conf/powerpc-ieee1275.rmk	15 Apr 2006 03:59:23 -0000
@@ -69,7 +69,7 @@ grubof_SOURCES = kern/powerpc/ieee1275/c
 grubof_HEADERS = grub/powerpc/ieee1275/ieee1275.h
 grubof_CFLAGS = $(COMMON_CFLAGS)
 grubof_ASFLAGS = $(COMMON_ASFLAGS)
-grubof_LDFLAGS = -nostdlib -static-libgcc -lgcc -Wl,-N,-S,-Ttext,0x200000,-Bstatic
+grubof_LDFLAGS = -nostdlib -static-libgcc -lgcc -Wl,-N,-S,-Ttext,0x200000,-Bstatic $(LDFLAGS)
 
 # For genmoddep.
 genmoddep_SOURCES = util/genmoddep.c

Re: [ppc patch] link with -m32

[Hollis Blanchard]

On Apr 14, 2006, at 11:06 PM, Hollis Blanchard wrote:

> Some 64-bit PowerPC compilers default to 64-bit output. Right now 
> we're building all the object files with -m32, but then the linker 
> complains when it tries to link a 64-bit grubof. We need to add -m32 
> to LDFLAGS as well as CFLAGS.

Hmm, I didn't notice the error messages this caused. -m32 is a gcc 
flag, not an ld flag. However, there's some confusion about LDFLAGS and 
CFLAGS in genmk.rb (and conf/*.rmk). In particular, you cannot do $(CC) 
$(LDFLAGS), and you cannot do $(LD) $(CFLAGS).

There is also confusion about which *FLAGS are used to build which 
targets. I've been investigating, but in the meantime this patch won't 
work.

Having dug through this for the past couple hours, I'm considering 
rewriting the Makefiles using plain make (i.e. no generating scripts). 
Thoughts?

-Hollis

Re: [ppc patch] link with -m32

[Marco Gerards]

Hollis Blanchard <hollis@penguinppc.org> writes:

> On Apr 14, 2006, at 11:06 PM, Hollis Blanchard wrote:
>
>> Some 64-bit PowerPC compilers default to 64-bit output. Right now
>> we're building all the object files with -m32, but then the linker
>> complains when it tries to link a 64-bit grubof. We need to add -m32
>> to LDFLAGS as well as CFLAGS.
>
> Hmm, I didn't notice the error messages this caused. -m32 is a gcc
> flag, not an ld flag. However, there's some confusion about LDFLAGS
> and CFLAGS in genmk.rb (and conf/*.rmk). In particular, you cannot do
> $(CC) $(LDFLAGS), and you cannot do $(LD) $(CFLAGS).
>
> There is also confusion about which *FLAGS are used to build which
> targets. I've been investigating, but in the meantime this patch won't
> work.

I think LDFLAGS are really processed by cc, no?  So we do not use ld,
but cc if I am not mistaken.

Can you show what you currently have?  Or should I just look at your
previous patch?

--
Marco

Re: [ppc patch] link with -m32

[Vincent Pelletier]

[-- Attachment #1: Type: text/plain, Size: 720 bytes --]

Le Samedi 15 Avril 2006 12:36, Marco Gerards a écrit :
> Hollis Blanchard <hollis@penguinppc.org> writes:
> > Hmm, I didn't notice the error messages this caused. -m32 is a gcc
> > flag, not an ld flag. However, there's some confusion about LDFLAGS
> > and CFLAGS in genmk.rb (and conf/*.rmk). In particular, you cannot do
> > $(CC) $(LDFLAGS), and you cannot do $(LD) $(CFLAGS).
> I think LDFLAGS are really processed by cc, no?  So we do not use ld,
> but cc if I am not mistaken.

I've had such problems with the sparc64 port, so the solution might be in 
my .rmk . IIRC, there was a specific way to pass arguments to ld through gcc, 
like -gccoption ldoption1,ldopt2,ldopt3,...

-- 
Vincent Pelletier

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [ppc patch] link with -m32

[Hollis Blanchard]

On Apr 15, 2006, at 5:36 AM, Marco Gerards wrote:

> I think LDFLAGS are really processed by cc, no?  So we do not use ld,
> but cc if I am not mistaken.

No; compare the man pages for ld and gcc.

For example, -m32 is a gcc flag, and -melf32ppc is an ld flag. GCC 
complains if you pass it -melf32ppc, and ld complains if you pass it 
-m32. Look at all the -Wl options we use in grubof_LDFLAGS: -Wl means 
"pass these options to the linker".

We can use either gcc or ld to link, but we need to pick one. If we use 
ld, we will also need to use 'gcc -m32 -print-file-name=libc.a', since 
ld cannot find libgcc on its own.

-Hollis

Re: [ppc patch] link with -m32

[Hollis Blanchard]

On Apr 15, 2006, at 5:36 AM, Marco Gerards wrote:

> I think LDFLAGS are really processed by cc, no?  So we do not use ld,
> but cc if I am not mistaken.

If I misunderstood your mail, and you mean LDFLAGS in general is  
supposed to be processed by $(CC), then I disagree: see for example  
http://www.gnu.org/software/make/manual/html_node/Implicit- 
Variables.html#Implicit-Variables .

-Hollis

Re: LDFLAGS

[Hollis Blanchard]

On Apr 15, 2006, at 8:54 AM, Hollis Blanchard wrote:

> On Apr 15, 2006, at 5:36 AM, Marco Gerards wrote:
>
>> I think LDFLAGS are really processed by cc, no?  So we do not use ld,
>> but cc if I am not mistaken.
>
> If I misunderstood your mail, and you mean LDFLAGS in general is  
> supposed to be processed by $(CC), then I disagree: see for example  
> http://www.gnu.org/software/make/manual/html_node/Implicit- 
> Variables.html#Implicit-Variables .

To reply to myself just one more time... I think I interpreted that  
page incorrectly before.

The page says this:
LDFLAGS
	Extra flags to give to compilers when they are supposed to invoke the  
linker, `ld'.

If we take "compiler" to mean "gcc", then LDFLAGS contains gcc options,  
and should never be used directly by ld. It is worth noting that there  
is no standard LD variable, suggesting (as I have heard others suggest)  
that we should not be invoking ld directly. I will try out that patch.

-Hollis

Re: LDFLAGS

[Yoshinori K. Okuji]

On Saturday 15 April 2006 16:06, Hollis Blanchard wrote:
> If we take "compiler" to mean "gcc", then LDFLAGS contains gcc options,
> and should never be used directly by ld. It is worth noting that there
> is no standard LD variable, suggesting (as I have heard others suggest)
> that we should not be invoking ld directly. I will try out that patch.

I agree. We should not invoke ld directly, if possible...

But please don't remove genmk.rb. I don't want to maintain huge Makefiles.

Okuji