[Linux-ia64] [PATCH] Fix for kernel DRM build

[Linux-ia64] [PATCH] Fix for kernel DRM build

[Uros Prestor]

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

When building the latest 2.4.0-010109 kernel with DRI support enabled,
I got the following link-time error:

     ld: drivers/char/drm/drm.o: linking 64-bit files with 32-bit
     files
     ld: drivers/char/drm/drm.o: linking constant-gp files with
     non-constant-gp files

It turns out that drm.o was built as follows:

     rm -f drmlib.a
     ar  rcs drmlib.a init.o memory.o proc.o auth.o context.o
     drawable.o bufs.o lists.o lock.o ioctl.o fops.o vm.o dma.o
     ctxbitmap.o
     rm -f drm.o
     ld  -r -o drm.o drmlib.a

Looks like the ar output confuses the linker.  I don't even know if this
is supposed to work with the current toolchain.  In any case, if you
remove the ar step and use ld -r directly the problem disappears.  The
enclosed patch fixes the DRI Makefile to remove the ar step.

Uros.

--
Uros Prestor
uros@turbolinux.com



[-- Attachment #2: linux-2.4.0-ia64-drm-build.patch --]
[-- Type: text/plain, Size: 931 bytes --]

diff -ruN linux-2.4.0-010109/drivers/char/drm/Makefile linux-2.4.0-010109.drm/drivers/char/drm/Makefile
--- linux-2.4.0-010109/drivers/char/drm/Makefile	Thu Jan  4 13:07:01 2001
+++ linux-2.4.0-010109.drm/drivers/char/drm/Makefile	Tue Jan  9 13:43:21 2001
@@ -63,9 +63,9 @@
 lib-objs-mod := $(patsubst %.o,%-mod.o,$(lib-objs))
 
 ifdef MAKING_MODULES
-  lib = drmlib-mod.a
+  lib = drmlib-mod.o
 else
-  obj-y += drmlib.a
+  obj-y += drmlib.o
 endif
 
 include $(TOPDIR)/Rules.make
@@ -73,13 +73,11 @@
 $(patsubst %.o,%.c,$(lib-objs-mod)): 
 	@ln -sf $(subst -mod,,$@) $@
 
-drmlib-mod.a: $(lib-objs-mod)
-	rm -f $@
-	$(AR) $(EXTRA_ARFLAGS) rcs $@ $(lib-objs-mod)
+drmlib-mod.o: $(lib-objs-mod)
+	$(LD) -r -o $@ $(lib-objs-mod)
 
-drmlib.a: $(lib-objs)
-	rm -f $@
-	$(AR) $(EXTRA_ARFLAGS) rcs $@ $(lib-objs)
+drmlib.o: $(lib-objs)
+	$(LD) -r -o $@ $(lib-objs)
 
 gamma.o: $(gamma-objs) $(lib)
 	$(LD) -r -o $@ $(gamma-objs) $(lib)

Re: [Linux-ia64] [PATCH] Fix for kernel DRM build

[David Mosberger]

This should be labeled a toolchain issue.  The problem occurs whenever
someone is building and linking against an "empty" archive.  The same
problem occurred in the "media/" subdirectory but I did a quick hack to
work around the problem.

	--david

>>>>> On Tue, 09 Jan 2001 14:32:23 -0800, Uros Prestor <uros@turbolinux.com> said:

  Uros> When building the latest 2.4.0-010109 kernel with DRI support
  Uros> enabled, I got the following link-time error:

  Uros>      ld: drivers/char/drm/drm.o: linking 64-bit files with
  Uros> 32-bit files ld: drivers/char/drm/drm.o: linking constant-gp
  Uros> files with non-constant-gp files

  Uros> It turns out that drm.o was built as follows:

  Uros>      rm -f drmlib.a ar rcs drmlib.a init.o memory.o proc.o
  Uros> auth.o context.o drawable.o bufs.o lists.o lock.o ioctl.o
  Uros> fops.o vm.o dma.o ctxbitmap.o rm -f drm.o ld -r -o drm.o
  Uros> drmlib.a

  Uros> Looks like the ar output confuses the linker.  I don't even
  Uros> know if this is supposed to work with the current toolchain.
  Uros> In any case, if you remove the ar step and use ld -r directly
  Uros> the problem disappears.  The enclosed patch fixes the DRI
  Uros> Makefile to remove the ar step.

  Uros> Uros.

  Uros> -- Uros Prestor uros@turbolinux.com


  Uros> diff -ruN linux-2.4.0-010109/drivers/char/drm/Makefile
  Uros> linux-2.4.0-010109.drm/drivers/char/drm/Makefile ---
  Uros> linux-2.4.0-010109/drivers/char/drm/Makefile Thu Jan 4
  Uros> 13:07:01 2001 +++
  Uros> linux-2.4.0-010109.drm/drivers/char/drm/Makefile Tue Jan 9
  Uros> 13:43:21 2001 @@ -63,9 +63,9 @@ lib-objs-mod := $(patsubst
  Uros> %.o,%-mod.o,$(lib-objs))
 
  Uros>  ifdef MAKING_MODULES - lib = drmlib-mod.a + lib   Uros> drmlib-mod.o else - obj-y += drmlib.a + obj-y += drmlib.o
  Uros> endif
 
  Uros>  include $(TOPDIR)/Rules.make @@ -73,13 +73,11 @@ $(patsubst
  Uros> %.o,%.c,$(lib-objs-mod)): @ln -sf $(subst -mod,,$@) $@
 
  Uros> -drmlib-mod.a: $(lib-objs-mod) - rm -f $@ - $(AR)
  Uros> $(EXTRA_ARFLAGS) rcs $@ $(lib-objs-mod) +drmlib-mod.o:
  Uros> $(lib-objs-mod) + $(LD) -r -o $@ $(lib-objs-mod)
 
  Uros> -drmlib.a: $(lib-objs) - rm -f $@ - $(AR) $(EXTRA_ARFLAGS) rcs
  Uros> $@ $(lib-objs) +drmlib.o: $(lib-objs) + $(LD) -r -o $@
  Uros> $(lib-objs)
 
  Uros>  gamma.o: $(gamma-objs) $(lib) $(LD) -r -o $@ $(gamma-objs)
  Uros> $(lib)

Re: [Linux-ia64] [PATCH] Fix for kernel DRM build

[H . J . Lu]

On Tue, Jan 09, 2001 at 02:46:27PM -0800, David Mosberger wrote:
> This should be labeled a toolchain issue.  The problem occurs whenever
> someone is building and linking against an "empty" archive.  The same
> problem occurred in the "media/" subdirectory but I did a quick hack to
> work around the problem.
> 

This patch seems to work for me.


H.J.
---
2001-01-09  H.J. Lu <hjl@valinux.com>

	* elf64-ia64.c (elf64_ia64_merge_private_bfd_data): Don't
	merge with the empty input file.

--- bfd/elf64-ia64.c.empty	Tue Jan  9 17:06:55 2001
+++ bfd/elf64-ia64.c	Tue Jan  9 17:28:42 2001
@@ -3973,6 +3973,10 @@ elf64_ia64_merge_private_bfd_data (ibfd,
       || bfd_get_flavour (obfd) != bfd_target_elf_flavour)
     return false;
 
+  /* If the input file has no data, we have nothing to merge.  */
+  if (ibfd->sections = NULL)
+    return true;
+
   in_flags  = elf_elfheader (ibfd)->e_flags;
   out_flags = elf_elfheader (obfd)->e_flags;
 

Re: [Linux-ia64] [PATCH] Fix for kernel DRM build

[Jim Wilson]

>     ld: drivers/char/drm/drm.o: linking 64-bit files with 32-bit
>     files
>     ld: drivers/char/drm/drm.o: linking constant-gp files with
>     non-constant-gp files

I've sent a proposed patch to binutils@sources.redhat.com for comment.

I don't like HJ's proposed solution, which is to ignore the ELF header flags
if an object file is empty.  That can mask real errors, as this ar/ld -r
trick is not the only way to create empty object files.

My proposed patch fixes the linker to notice when the output file is empty,
and then we set the ELF header flags from the first member of the first
archive even though we aren't linking it in.  This fixes the kernel build
failure.  Alternatively, it might be better to check the ELF header flags
of every member of every archive to avoid ambiguity, but that seemed like
unnecessary extra work so I won't do that unless the binutils maintainers
request it.

Here is my proposed patch.


2001-01-15  Jim Wilson  <wilson@redhat.com>

	* ldlang.c (lang_check): If file_chain.head is NULL, then find first
	member of first archive, and call bfd_merge_private_bfd_data on it.

Index: ldlang.c
=================================RCS file: /cvs/cvsfiles/devo/ld/ldlang.c,v
retrieving revision 1.289
diff -p -r1.289 ldlang.c
*** ldlang.c	2000/07/10 11:46:54	1.289
--- ldlang.c	2001/01/16 00:03:58
*************** lang_check ()
*** 3477,3482 ****
--- 3477,3507 ----
  	    bfd_set_error_handler (pfn);
  	}
      }
+ 
+   /* There can be no used input files if the only inputs are archives.
+      In that case, arbitrarily pick the first element of the first archive
+      and use that one to initialize private bfd data.  This construct occurs
+      in the linux kernel, and if we don't have the bfd_merge_private_bfd_data
+      call, we can get errors in the final link.  */
+   if (file_chain.head = NULL)
+     {
+       lang_input_statement_type *f;
+ 
+       for (f = (lang_input_statement_type *) input_file_chain.head;
+ 	   f != NULL;
+ 	   f = (lang_input_statement_type *) f->next_real_file)
+ 	{
+ 	  if (f->the_bfd
+ 	      && bfd_check_format (f->the_bfd, bfd_archive))
+ 	    {
+ 	      bfd *member;
+ 
+ 	      member = bfd_openr_next_archived_file (f->the_bfd, (bfd *) NULL);
+ 	      bfd_merge_private_bfd_data (member, output_bfd);
+ 	      break;
+ 	    }
+ 	}
+     }
  }
  
  /* Look through all the global common symbols and attach them to the

Re: [Linux-ia64] [PATCH] Fix for kernel DRM build

[H . J . Lu]

On Mon, Jan 15, 2001 at 04:42:26PM -0800, Jim Wilson wrote:
> >     ld: drivers/char/drm/drm.o: linking 64-bit files with 32-bit
> >     files
> >     ld: drivers/char/drm/drm.o: linking constant-gp files with
> >     non-constant-gp files
> 
> I've sent a proposed patch to binutils@sources.redhat.com for comment.
> 
> I don't like HJ's proposed solution, which is to ignore the ELF header flags
> if an object file is empty.  That can mask real errors, as this ar/ld -r
> trick is not the only way to create empty object files.
> 
> My proposed patch fixes the linker to notice when the output file is empty,
> and then we set the ELF header flags from the first member of the first
> archive even though we aren't linking it in.  This fixes the kernel build

Does that work with an empty archive or an archive with files of
mixed types? I thought about your approach. But I decided against
it since it didn't work with the cases above.


H.J.

Re: [Linux-ia64] [PATCH] Fix for kernel DRM build

[Jim Wilson]

>Does that work with an empty archive or an archive with files of
>mixed types? I thought about your approach. But I decided against
>it since it didn't work with the cases above.

No, but I don't see how we can make those cases work in a reasonable fashion,
except to give an error, and hence the user should not expect them to work.
If there are linux kernel Makefiles that do this, then I would consider them
broken.

If you want to argue for your solution, then you should make this argument
on the binutils@sources.redhat.com list, as that is where the issue will be
decided.

Jim