* Re: [Linux-ia64] [PATCH] Fix for kernel DRM build
2001-01-09 22:32 [Linux-ia64] [PATCH] Fix for kernel DRM build Uros Prestor
@ 2001-01-09 22:46 ` David Mosberger
2001-01-10 1:35 ` H . J . Lu
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: David Mosberger @ 2001-01-09 22:46 UTC (permalink / raw)
To: linux-ia64
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)
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [Linux-ia64] [PATCH] Fix for kernel DRM build
2001-01-09 22:32 [Linux-ia64] [PATCH] Fix for kernel DRM build Uros Prestor
2001-01-09 22:46 ` David Mosberger
@ 2001-01-10 1:35 ` H . J . Lu
2001-01-16 0:42 ` Jim Wilson
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: H . J . Lu @ 2001-01-10 1:35 UTC (permalink / raw)
To: linux-ia64
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;
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [Linux-ia64] [PATCH] Fix for kernel DRM build
2001-01-09 22:32 [Linux-ia64] [PATCH] Fix for kernel DRM build Uros Prestor
2001-01-09 22:46 ` David Mosberger
2001-01-10 1:35 ` H . J . Lu
@ 2001-01-16 0:42 ` Jim Wilson
2001-01-16 1:13 ` H . J . Lu
2001-01-16 2:02 ` Jim Wilson
4 siblings, 0 replies; 6+ messages in thread
From: Jim Wilson @ 2001-01-16 0:42 UTC (permalink / raw)
To: linux-ia64
> 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
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [Linux-ia64] [PATCH] Fix for kernel DRM build
2001-01-09 22:32 [Linux-ia64] [PATCH] Fix for kernel DRM build Uros Prestor
` (2 preceding siblings ...)
2001-01-16 0:42 ` Jim Wilson
@ 2001-01-16 1:13 ` H . J . Lu
2001-01-16 2:02 ` Jim Wilson
4 siblings, 0 replies; 6+ messages in thread
From: H . J . Lu @ 2001-01-16 1:13 UTC (permalink / raw)
To: linux-ia64
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.
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [Linux-ia64] [PATCH] Fix for kernel DRM build
2001-01-09 22:32 [Linux-ia64] [PATCH] Fix for kernel DRM build Uros Prestor
` (3 preceding siblings ...)
2001-01-16 1:13 ` H . J . Lu
@ 2001-01-16 2:02 ` Jim Wilson
4 siblings, 0 replies; 6+ messages in thread
From: Jim Wilson @ 2001-01-16 2:02 UTC (permalink / raw)
To: linux-ia64
>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
^ permalink raw reply [flat|nested] 6+ messages in thread