Change default location of DJGPP's ld scripts

Change default location of DJGPP's ld scripts

[Mark E.]

Hello again,

This patch attempts to deal with another problem brought on by the 8.3 restriction 
of filenames under plain DOS. The path generated for the default location of 
generated scripts is unusuable in a dual SFN/LFN setup like under Win 95:
c:/djgpp/i386-pc-msdosdjgpp/lib/ldscripts/

i386-pc-msdosdjgpp would turn into something like i386-pc-~.1 in plain DOS. This 
will force ld to fall back to its internal linker script.

Also, the path assumes that everyone builds their own binutils. But DJGPP users 
typically use the official port rather than rolling their own. So including the 
target alias in the path is somewhat redundant. Please consider this patch which 
deletes the target alias from the default linker script  path for DJGPP only.

*** configure.in.orig	Sun Aug  8 13:06:06 1999
--- configure.in	Thu Sep  9 20:04:46 1999
*************** else
*** 186,190 ****
--- 186,199 ----
  fi
  AC_SUBST(TESTBFDLIB)
  
+ dnl Including $(target_alias) in the DJGPP definition of 'tooldir'
+ dnl makes the path hostile to DOS.
+ case ${target_os} in
+   *msdosdjgpp*) tooldir="\$(exec_prefix)" ;;
+   *) tooldir="\$(exec_prefix)/\$(target_alias)" ;;
+ esac
+ 
+ AC_SUBST(tooldir)
+ 
  AC_OUTPUT(Makefile po/Makefile.in:po/Make-in,
  [sed -e '/POTFILES =/r po/POTFILES' po/Makefile.in > po/Makefile])
*** Makefile.in.orig	Tue Sep  7 13:54:48 1999
--- Makefile.in	Thu Sep  9 20:05:08 1999
*************** AUTOMAKE_OPTIONS = cygnus dejagnu
*** 108,114 ****
  
  SUBDIRS = po
  
! tooldir = $(exec_prefix)/$(target_alias)
  
  YACC = `if [ -f ../bison/bison ]; then echo ../bison/bison -y -
L$(srcdir)/../bison/; else echo @YACC@; fi`
  YFLAGS = -d
--- 108,114 ----
  
  SUBDIRS = po
  
! tooldir = @tooldir@
  
  YACC = `if [ -f ../bison/bison ]; then echo ../bison/bison -y -
L$(srcdir)/../bison/; else echo @YACC@; fi`
  YFLAGS = -d

--- 
Mark Elbrecht, snowball3@bigfoot.com
http://snowball.frogspace.net/

Re: Change default location of DJGPP's ld scripts

[Ian Lance Taylor]

   From: "Mark E." <snowball3@bigfoot.com>
   Date: Thu, 9 Sep 1999 20:29:23 -0400

   i386-pc-msdosdjgpp would turn into something like i386-pc-~.1 in plain DOS. This 
   will force ld to fall back to its internal linker script.

I don't understand just what you are saying here.  If the linker can
use its internal linker script, it does so.  It only uses the external
linker script if there is no appropriate internal script.  That is,
the linker never falls back to the internal linker script.  The fall
back is the other way around.

   Also, the path assumes that everyone builds their own binutils. But DJGPP users 
   typically use the official port rather than rolling their own. So including the 
   target alias in the path is somewhat redundant. Please consider this patch which 
   deletes the target alias from the default linker script  path for DJGPP only.

We don't put target_alias in the tooldir path because we expect
everybody to build their own binutils.  I'm not sure what you mean by
that.  We put target_alias there so that you can build several linkers
with different targets but the same prefix and exec_prefix.

I don't see why removing target_alias is the answer.  The answer would
seem to be using something which DOS can cope with.  Perhaps on DOS we
should simply truncate the name.

gcc uses target_alias when it finds programs like the assembler and
linker.  gcc and the binutils cooperate in that regard.  Does this
work on DOS?  Perhaps people are simply required to put those programs
on their PATH.

Ian

Re: Change default location of DJGPP's ld scripts

[Mark E.]

> use its internal linker script, it does so.  It only uses the external
> linker script if there is no appropriate internal script.  That is,
> the linker never falls back to the internal linker script.  The fall
> back is the other way around.

Then I misunderstood how this worked.

> We don't put target_alias in the tooldir path because we expect
> everybody to build their own binutils.  I'm not sure what you mean by
> that.

The statement was based on the above misunderstanding. Forget about it.

> I don't see why removing target_alias is the answer.  The answer would
> seem to be using something which DOS can cope with.  Perhaps on DOS we
> should simply truncate the name.
> 
> gcc uses target_alias when it finds programs like the assembler and
> linker.  gcc and the binutils cooperate in that regard.  Does this
> work on DOS?  Perhaps people are simply required to put those programs
> on their PATH.

What happens with gcc is the target_alias is truncated to 'djgpp', so instead of the 
egcs 1.12 backends (cc1.exe, etc.) being in:
c:/djgpp/lib/gcc-lib/i386-pc-msdosdjgpp/egcs-291.66/

they are instead in instead:
c:/djgpp/lib/gcc-lib/djgpp/egcs-291.66/

truncating the target alias in the same way as gcc for the ldscripts directory would 
be:
c:/djgpp/djgpp/lib/ldscripts/

which will work. But it kinda looks as if someone made a mistake and put in an extra 
/djgpp in the path.


--- 
Mark Elbrecht, snowball3@bigfoot.com
http://snowball.frogspace.net/

Re: Change default location of DJGPP's ld scripts

[Andreas Schwab]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1076 bytes --]

"Mark E." <snowball3@bigfoot.com> writes:

|> What happens with gcc is the target_alias is truncated to 'djgpp', so instead of the 
|> egcs 1.12 backends (cc1.exe, etc.) being in:
|> c:/djgpp/lib/gcc-lib/i386-pc-msdosdjgpp/egcs-291.66/
|> 
|> they are instead in instead:
|> c:/djgpp/lib/gcc-lib/djgpp/egcs-291.66/
|> 
|> truncating the target alias in the same way as gcc for the ldscripts directory would 
|> be:
|> c:/djgpp/djgpp/lib/ldscripts/
|> 
|> which will work. But it kinda looks as if someone made a mistake and put in an extra 
|> /djgpp in the path.

c:/djpgg seems to be ${prefix}, and tooldir is ${prefix}/${target_alias},
where ${target_alias} can be anything that is accepted by config.sub.  So
it's a matter of how you call configure what you get here.  Just pass the
appropriate --target name that fits into the ridiculous DOS file name
rules.

Andreas.

-- 
Andreas Schwab                                  "And now for something
schwab@suse.de                                   completely different."
SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg