Subject: Re: ld(1) bug needs fixing or USE_NEW_TOOLCHAIN turned off.
To: None <tech-toolchain@netbsd.org>
From: Frank van der Linden <fvdl@wasabisystems.com>
List: tech-toolchain
Date: 10/02/2001 16:46:38
Ok.. I looked into this a bit (with Nick), and the following is the problem:

	* The script that generates the target emul.c file (eelf_i386.c)
	  is in gnu/dist/toolchain/ld/emultempl/elf32.em
	  Around line 635 of that file, it will emit some code to
	  search for DT_NEEDED libraries in rpath and some other places
	  (in addition to the rpath-link search). However, this piece
	  of code will only be generated if:

	  if [ "x${host}" = "x${target}" ] ; then

	  It turns out that ${host} is set to "none" and ${target}
	  is set to "i386-unknown-netbsdelf". The linker thinks
	  it's a crosslinker, and does not emit that code. However,
	  it's clearly needed for a native linker.

	*  The "none" is explicitly passed to
	   gnu/dist/toolchain/ld/genscripts.sh by
	   gnu/usr.bin/binutils/ld/Makefile.

	   My first idea was to specify ${MACHINE_GNU_PLATFORM} from
	   bsd.own.mk instead, but this is set to "i386--netbsdelf",
	   so that won't work either. defs.mk for the i386 contains
	   "i386-unknown-netbsdelf", perhaps it should contain
	   "i386--netbsdelf" instead, but I assume this is config.guess-
	   generated, so that might not be easy.

Anyway.. it's clear where and how it fails, but I don't know what the
right fix is.

- Frank
-- 
Frank van der Linden                           fvdl@wasabisystems.com
======================================================================
Quality NetBSD CDs, Support & Service.   http://www.wasabisystems.com/