HDTenEightyP/NetNews huggingface dataset:
From: darylm@illian.mnet.COM (Daryl V. McDaniel)
Subject: Bug in make 3.62
Reply-To: darylm@illian.mnet.com
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 4 Oct 1992 17:08:59 GMT

Bug Report for GNU make-3.62

	System:	i486-66 based desktop PC clone (Zeos)
	OS:	UHC SVR4.0.3.6
	Compiler:	GCC 2.2.2

	Build environment:
		UFS disk partition with 87MB free
		GNU C compiler
		/usr/ccs/bin/make
		16MB physical memory
		800MB virtual memory (swap space size)
		6 users
		Load Average 0.01

When compiling make-3.62 with gcc 2.2.2, I got two groups of warnings:

    1)	main.c: line 347: arguments 2 and 3 of setvbuf are of wrong type
    2)	function.c: local declaration of fork does not match global

gcc -DUSG -DHAVE_DUP2 -DPOSIX -O   -c function.c -o function.o
function.c: In function `expand_function':
function.c:329: warning: type mismatch with previous external decl
/usr/local/lib/gcc-lib/i486-zeos-sysv4/2.2.2/include/unistd.h:186: warning: previous external decl of `fork'
function.c:329: warning: local declaration of `fork' doesn't match global one

The version produced from this build dumps core upon invocation.
Examination of the error messages showed that the setvbuf() call in main.c
had the second and third arguments reversed, as per the on-line
documentation for setvbuf().  Swapping these two arguments eliminated the
error message from subsequent builds.  The "make" produced from fixing this
bug works on all makefiles I have subsequently tried it on.

Problem 2 stems from fork() being declared as "extern int fork();" in
function.c, while the system header files declare fork as "pid_t fork();".
Fixing this problem, while a good thing, is cosmetic instead of functional.

I have enclosed relevant portions of the Makefile and main.c to show what I
have changed.  Fixes to function.c are left as an exercise to the student.
8-) Lots of smileys.


>From the Makefile:
#
#	Makefile for GNU Make
#

CC=gcc					# Add compiler definition for GCC

CFLAGS = $(defines) -O			# Don't need symbols any more
LDFLAGS = -g

defines =-DUSG -DHAVE_DUP2 -DPOSIX	# Other defines invoke bad things

LOAD_AVG =-DKERNEL_FILE_NAME=\"/unix\"

LOADLIBES =-lelf			# This is where nlist lives

# If your system doesn't have alloca, or the one provided is bad,
# get it from the Emacs distribution and define these.
#ALLOCA = alloca.o			# Seems to work without this
#ALLOCASRC = alloca.c


>From main.c:

  /* Make sure stdout is line-buffered.  */

#if	(defined (USGr3) || defined (HPUX) || defined (hpux) \
	 || defined (M_XENIX) || defined (APOLLO))
  setvbuf (stdout, (char *) 0, _IOLBF, BUFSIZ);
#else	/* Not USGr3 and not HPUX et al.  */
#ifdef	USG
#ifdef	sgi
  setvbuf (stdout, _IOLBF, xmalloc (BUFSIZ), BUFSIZ);
#else
  setvbuf (stdout, (char *) 0, _IOLBF, BUFSIZ);	/* BUGFIX: Swap 2nd & 3rd args */
#endif
#else	/* Not USG.  */
  setlinebuf (stdout);
#endif	/* USG.  */
#endif	/* USGr3.  */

-=-=-=-=-=-=-=-=-=-=-
Daryl V. McDaniel			(503) 643-6137
Micronetics			darylm@mnet.com
Aloha Research Group		...sun.com!nosun!illian!darylm
Beaverton, Oregon, USA		...{qiclab, sopwith, tessi}!illian!darylm

Newsgroups: gnu.utils.bug
From: rwp@hprwp.fc.hp.com (Bob Proulx)
Subject: GNU tar-1.11 problems
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 25 Sep 1992 11:56:35 GMT

Hello GNU tar person!

I just pulled prep.ai.mit.edu:/pub/gnu/tar-1.11.tar.Z (or something to
that effect) and compiled it up on a couple of different systems
(HP-UX and Linux).  For the most part it compiled up easily and ran
okay.  Good Job!

The pertinent information:

GNU tar 1.11
HP-UX 8.07 HP cc on a 9000/720               \__ Both exhibit same behavior.
Linux 0.97.1 with gcc 2.2.2d on a 386SX-25   /

However, I have been having some difficulty and have found what
appears to be a couple of bugs.  I would like to know, "Do I actually
have the latest version?"  (I don't want to spend too much time
debugging something that has already been fixed.)

There are three problems that I have run into so far.

1. The utime(2) system call seems to be different for these systems
   from what the code was developed for.  This causes compile time
   incompatibilities on these systems.  From the available man pages:
      #include <utime.h>
      int utime(const char *path, const struct utimbuf *times);
   This appears to be true on SunOS 4.1.2, HP-UX 8.07, Linux 0.97.1.
   Unfortunately on your systems it must be an array[2] of time_t
   values instead of this struct.
      int utime(const char *path, const time_t *times);  ???
   This is an easy problem for me to fix.  I would be happy to supply
   the patch for this.

2. The normal mode for me to create tar files is "tar cvf file.tar *".
   The verbose flag 'v' prints the filename as it archives the file.
   This does not work.  Tracking the problem down it appears that the
   variable current_file_name is used to print the name. Unfortunately
   this variable is not set during the create archive operation and so
   happens to be <NULL> on my systems.  The filename is not printed.
   
3. Next is a flakey problem that I don't understand.  Sometimes I get
   the contents of the file echoed to the screen on archive creation.
   I think this is related to the current_file_name not being set as
   described above.  This then happens to print file contents instead
   of the filename because it just happens to point there.  I am not
   convinced of this since in the debugger it never does this.  I
   don't understand it and only mention it because I am seeing the
   problem.

I would be happy to send in patches for these problems if it would
help in any way.  If there is a newer version I would love to get a
copy of it.

Thanks

Bob Proulx
rwp@fc.hp.com

Newsgroups: gnu.utils.bug
From: pinard@icule.UUCP (Francois Pinard)
Subject: GNU `sort -s' not working as documented
Reply-To: pinard@iro.umontreal.ca
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 26 Sep 1992 12:47:41 GMT

This pertains to GNU sort from GNU textutils 1.3, compiled with GNU C
1.40 under COFF encapsulation on this 386/ix 2.0.2 system, waiting for
Hurd to be available :-).  The documentation says:

     Finally, as a last resort when all keys compare equal (or if no
     ordering options were specified at all), sort compares the lines
     byte by byte in machine collating sequence.  The -s option
     disables this last resort comparison, producing a stable sort.

So, a mere `sort -s FILE' should behave the same as `cat FILE'.  But:

	~/8c) { echo b; echo a } | sort -s
	a
	b
	~/8c) type sort
	sort is hashed (/usr/local/gnubin/sort)
	~/8c) grep ersion /usr/local/gnubin/sort
	GNU textutils version 1.3
	~/8c) 

-- 
Franc,ois Pinard        ``Vivement GNU!''        pinard@iro.umontreal.ca
(514) 588-4656                                    ...!uunet!iros1!pinard
Consider joining the League for Programming Freedom.  Email for details!

Newsgroups: gnu.utils.bug
From: olson@anchor.ESd.SGi.COM (Dave Olson)
Subject: Re: fileutils-3.3 dd bug on SGI machines [ fix masks some other bug ]
Organization: Silicon Graphics, Inc.  Mountain View, CA
Distribution: gnu
Date: Sun, 27 Sep 1992 05:00:50 GMT

In <9209251551.AA08880@pitstop.UCSD.EDU> spl@pitstop.ucsd.edu (Steve Lamont) writes:
| I discovered what appears to be a bug when reading tapes using the dd(1) 
| utility.  The command line
| 
| 	dd if=/dev/tape > foo
| 
| produces the following error message from dd:
| 
| 	dd: /dev/tape: I/O error
| 	0+0 records in
| 	0+0 records out
| 
| After a certain amount of investigation, I discovered that the read(2)
| function at about line 525 in function copy() was failing when
| attempting to read the first block.  This appears to be due to the
| fact that the buffer ibuf is on a non-sizeof( double ) boundary
| (because of slop required for byte swapping).

There is *no* requirement that i/o for tape (or anything else that
I know of, and I do a *lot* of SGI driver and other kernel work!) be
double aligned on SGI systems.

So there may be a bug in the gnu dd, but the double alignment
change you have made is masking the real bug, which must be
somewhere else...
--
Let no one tell me that silence gives consent,  |   Dave Olson
because whoever is silent dissents.             |   Silicon Graphics, Inc.
    Maria Isabel Barreno                        |   olson@sgi.com



Newsgroups: gnu.utils.bug
From: schwab@lamothe.informatik.uni-dortmund.de (Andreas Schwab)
Subject: Improvements for patch 2.0 12g8
Reply-To: schwab@ls5.informatik.uni-dortmund.de (Andreas Schwab)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 6 Oct 1992 15:01:17 GMT

Here is a patch to patch which i find very useful: when backing up the
patched file, automagically make the necessary directories. This
allows e.g.:

patch -B orig/ < patchfile

without worrying about directories to be created.
I also added code for systems having the mkdir system call, so that it
isn't necessary to call mkdir via system().

diff -ur orig/configure.in ./configure.in
--- orig/configure.in	Tue Jul 14 08:40:33 1992
+++ ./configure.in	Tue Oct  6 13:59:29 1992
@@ -16,7 +16,7 @@
 AC_UNISTD_H
 AC_USG
 AC_REPLACE_FUNCS(rename)
-AC_HAVE_FUNCS(strerror)
+AC_HAVE_FUNCS(strerror mkdir)
 AC_ALLOCA
 AC_LONG_FILE_NAMES
 AC_XENIX_DIR
diff -ur orig/util.c ./util.c
--- orig/util.c	Tue Sep 15 04:04:31 1992
+++ ./util.c	Tue Oct  6 13:59:30 1992
@@ -91,7 +91,10 @@
 	if (debug & 4)
 	    say3("Moving %s to %s.\n", to, bakname);
 #endif
-	if (rename(to, bakname) < 0) {
+	if (rename(to, bakname) < 0
+	    && (errno != EPATH
+		|| (makedirs (bakname, TRUE),
+		    rename (to, bakname) < 0))) {
 	    say4("Can't backup %s, output is in %s: %s\n", to, from,
 		 strerror(errno));
 	    return -1;
@@ -337,6 +340,7 @@
     if (dirvp < 0)
 	return;
 
+#ifndef HAVE_MKDIR
     strcpy(buf, "mkdir");
     s = buf;
     for (i=0; i<=dirvp; i++) {
@@ -351,6 +355,20 @@
     }
     if (s != buf)
 	system(buf);
+#else
+    for (i = 0; i <= dirvp; i++)
+      {
+	struct stat sbuf;
+	if (stat (tmpbuf, &sbuf))
+	  {
+	    if (errno != ENOENT || mkdir (tmpbuf, 0777))
+	      return;
+	  }
+	else if (!S_ISDIR (sbuf.st_mode))
+	  return;
+	*dirv[i] = '/';
+      }
+#endif
 }
 
 /* Make filenames more reasonable. */
--
Andreas Schwab
schwab@ls5.informatik.uni-dortmund.de

Newsgroups: gnu.utils.bug
From: warrend@sptekwv3.wv.tek.COM (Warren Dodge)
Subject: find-3.7 configure program
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 2 Oct 1992 16:15:39 GMT

There is no way in the configure switches to set the
binprefix and manprefix variables.

I would assume there should be so you don't have to 
edit the Makefile.in.

Newsgroups: gnu.utils.bug
From: beatty@cs.cmu.edu (Derek Beatty)
Subject: (none)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 30 Sep 1992 10:45:03 GMT

These don't work together.  It seems that on my NeXT, if I use the backup
scripts from the 1.11.1 distribution, everything that has been accessed since
the time of the level-0 dump will also be included on the level-1 dump.  Since
this includes all files on the level-0 dump, the level-1 dump won't really be
incremental.

Also your manual writer might want to include yet another hint for the NeXT
floppy drive: use --info-script='/usr/etc/disk -e /dev/rfd0a', and add the
same command at the bottom of the backup-dirs loop and the bottom of the
backup-files conditional.  (Blocking of 4 works.  Blocking of 48, which is
twice as fast, doesn't, even though 48 divides 1344, which is the floppy's
1440 blocks minus its 96-block front porch.  I guess I don't understand multi-
volume dumps.)
--
Derek_Beatty@cmu.edu   ABD   Comp Sci, CMU, 5000 Forbes, Pgh, PA 15213 USA


Newsgroups: gnu.utils.bug
From: stevedav@netcom.com (Steve Davidson)
Subject: Bug in AT&T netlib distribution for PIC
Keywords: pic gpic gnu ATT netlib
Organization: Netcom - Online Communication Services  (408 241-9760 guest)
Distribution: gnu
Date: Tue, 6 Oct 1992 19:16:21 GMT

There is a bug in your distribution of '116 from research/cstr'.
My request was based on the following:
 
     AT&T Bell Laboratories, Computing Science  Technical  Report
     No. 116,  PIC  - A Graphics Language for Typesetting.  (This
     can   be   obtained   by   sending   a   mail   message   to
     netlib@research.att.com       with       a      body      of
     `send 116 from research/cstr'.)

It comes in two shar parts.  Although the shar program re-concatenates
the two parts, the result is not successful.  Only part one prints to
page 18 (first 20 pages), and then part two is lost.

On a postscript viewer, part two reappears on page 21 but the postscript
printer does not print anything beyond page 18.  On viewer, parts of
page 18 and all of 19, 20 are lost.

There is no obvious problem in the postscript source.

It is hard to test because everytime I run the job I get the same
20 pages of output.

Could you please correct this distribution and email me?
 
FYI, here are the checksums and wordcounts of the files:
Mail header removed to line "#!/bin/sh".
Blank line at end remains:

sum pic116*
05286   127 pic116
19143    97 pic116.shar1
07341    31 pic116.shar2

wc pic116*
    5355   27520  129254 pic116
    4020   20983   98609 pic116.shar1
    1359    6620   31225 pic116.shar2
   10734   55123  259088 total


Suggestions for fix:
1) Test the distribution yourself before posting.
2) Send files with a checksum
3) Do not split file
                                         
Steve Davidson
steved@cfcl.com                          
415-355-6535                          


Newsgroups: gnu.utils.bug
From: howard@hal.com (Howard Gayle)
Subject: GNU make 3.62.20 won't build on Solaris 2.0
Reply-To: howard@hal.com
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 2 Oct 1992 18:33:30 GMT

Trying to build GNU make 3.62.20 on Solaris 2.0 gives the error
messages
   "job.c", line 121: identifier redeclared: _sys_siglist
   "job.c", line 910: cannot recover from previous errors

The problem is a typo in make.h line 49:
   #if !defined (HAVE_SYS_SIGLIST) && defined (HAVE__SYS_SIGLIST)
should actually read
   #if !defined (HAVE_SYS_SIGLIST) && !defined (HAVE__SYS_SIGLIST)

Once this is done, make builds fine using LDFLAGS=-lkvm.
--
Howard Gayle
HAL Computer Systems, Inc.
1315 Dell Avenue
Campbell, California 95008
USA
howard@hal.com
Phone: +1 408 379 7000 extension 1080
FAX  : +1 408 379 5022

Newsgroups: gnu.utils.bug
From: eck@saul.cis.upenn.edu (Brian J. Eck)
Subject: Bug with GNU Finger 1.35
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 1 Oct 1992 16:46:05 GMT

   First, the info...

I was using Finger 1.35, obtained from
gatekeeper.dec.com:/pub/GNU/finger-1.35.tar.Z on 9/21/92.

The server was running on a Sun Sparcstation 2 under SunOS 4.1.1.  Clients
included a SPARCserver 690MP running SunOS 4.1.2 and a Sparcstation 1
running 4.1.2.

I used gcc 2.1, with the -O flag.

   We've experienced some strange behavior.  Some users cannot be
fingered without the -l flag; this is after the server had been up
and running about a day, so it certainly should have been all set up
by then.

   Here's a script of the bug:

[saul] 4:26pm -> finger chip

There is no user named chip here; check your spelling. Feel free
to contact postmaster@central.cis.upenn.edu for further
assistance in locating this person. You can also try to use part
of the real name, if known. E.g., ``finger stallman@gnu.ai.mit.edu''.

It is also quite possible that chip is a mail alias. In that case,
you can finger it by giving the ``-l'' option to your finger program
(or --info if you're using the GNU Finger client). Aliases are not
looked up without this option due to the extra processing involved.

[saul] 4:26pm -> finger -l chip

Charles H. Buchholtz (chip)
Home: /home/chip
Shell: /bin/csh
No mail.

User chip has never logged on.
Last login on ttys0 from ENIAC.SEAS.UPENN, on Thu Sep 17 09:34:11 1992

Plan file exists, but is unreadable.
Project file exists, but is unreadable.
[saul] 4:26pm -> finger chip

There is no user named chip here; check your spelling. Feel free
to contact postmaster@central.cis.upenn.edu for further
assistance in locating this person. You can also try to use part
of the real name, if known. E.g., ``finger stallman@gnu.ai.mit.edu''.

It is also quite possible that chip is a mail alias. In that case,
you can finger it by giving the ``-l'' option to your finger program
(or --info if you're using the GNU Finger client). Aliases are not
looked up without this option due to the extra processing involved.

brian

Newsgroups: gnu.utils.bug
From: lwv26@cas.ORG (Larry W. Virden, x2487)
Subject: Anyone compiled shellutils-1.7 on SunOS 4.1.2?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 5 Oct 1992 16:43:39 GMT

If anyone has built shellutils version 1.7 on a Sun, would you drop me an
email ?  I am having problems getting the lib directory to compile.

I am getting the following:
gcc -O -c -g  -DHAVE_LIMITS_H=1 -DHAVE_SYSLOG_H=1 -DSTDC_HEADERS=1 -DHAVE_UNISTD_H=1 -DHAVE_FTIME=1 -DHAVE_UT_HOST=1 -DHAVE_C_LINE=1 -DHAVE_VPRINTF=1 -DHAVE_ALLOCA_H=1 -DHAVE_TM_ZONE=1 -DDIRENT=1 -I. strtoul.c
In file included from /projects/gnu/sun4/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/include/stdlib.h:10, from ./strtol.c:33, from strtoul.c:21:
/usr/include/sys/stdtypes.h:27: redefinition of `size_t'
/projects/gnu/sun4/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/include/stddef.h:82: `size_t' previously declared here
/usr/include/sys/stdtypes.h:28: redefinition of `ptrdiff_t'
/projects/gnu/sun4/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/include/stddef.h:45: `ptrdiff_t' previously declared here
/usr/include/sys/stdtypes.h:30: redefinition of `wchar_t'
/projects/gnu/sun4/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/include/stddef.h:120: `wchar_t' previously declared here
gmake[1]: *** [strtoul.o] Error 1
making all in src
gmake[1]: *** No way to make target `../lib/libshu.a'.  Stop.
making all in man
gmake[1]: Nothing to be done for `all'.
-- 
Larry W. Virden                 UUCP: osu-cis!chemabs!lvirden
Same Mbox: BITNET: lvirden@cas  INET: lvirden@cas.org
Personal: 674 Falls Place,   Reynoldsburg, OH 43068-1614
America Online: lvirden@aol.com

Newsgroups: gnu.utils.bug
From: jtc@gain.COM (J.T. Conklin)
Subject: bison-1.19: install info files when not compiling in srcdir
Reply-To: jtc@gain.com
Organization: GAIN Technology Inc., Palo Alto, CA
Distribution: gnu
Date: Mon, 28 Sep 1992 09:45:41 GMT

The install of the info files fail if you are not compiling in srcdir.
The following patch (method stolen from diff-2.0) fixes the problem.

	--jtc

diff -c gnu/bison/Makefile.in:1.2 gnu/bison/Makefile.in:1.3
*** gnu/bison/Makefile.in:1.2	Mon Sep 28 16:43:25 1992
--- gnu/bison/Makefile.in	Mon Sep 28 16:43:25 1992
***************
*** 107,115 ****
  	-chmod a+r $(datadir)/$(PFILE) $(datadir)/$(PFILE1)
  	-$(INSTALL_DATA) $(srcdir)/bison.1 $(mandir)/bison.$(manext)
  	-chmod a+r $(mandir)/bison.$(manext)
! 	for file in $(srcdir)/bison.info*; \
! 	do $(INSTALL_DATA) $$file $(infodir)/$$file; \
! 	done

  uninstall:
  	rm -f $(bindir)/bison
--- 107,114 ----
  	-chmod a+r $(datadir)/$(PFILE) $(datadir)/$(PFILE1)
  	-$(INSTALL_DATA) $(srcdir)/bison.1 $(mandir)/bison.$(manext)
  	-chmod a+r $(mandir)/bison.$(manext)
! 	cd $(srcdir); for f in bison.info*; \
! 	do $(INSTALL_DATA) $$f $(infodir)/$$f; done

  uninstall:
  	rm -f $(bindir)/bison

Newsgroups: gnu.utils.bug
From: leisner@wrc.xerox.COM ( Marty Leisner)
Subject: Using RCS for multple users
Reply-To: leisner.henr801c@xerox.com
Organization: Xerox
Distribution: gnu
Date: Tue, 6 Oct 1992 19:21:54 GMT

I've been using RCS for a number of years for single-user projects.

Now, I want to figure out how to use this for multiple user projects.

I see a has_setuid macro, but no real instructions (I assume if an access list
is used, the files are owned by root and the rcs programs have to be setuid to root?)

PVCS (never used it, just help install it) has a scheme where all the programs/files
are owned by a special user...

Will this also work with rcs?

Anyone, pointers on how to do this or where to look would be helpful.
--
marty
leisner.henr801c@xerox.com  
Member of the League for Programming Freedom

Newsgroups: gnu.utils.bug
From: jtc@gain.COM (J.T. Conklin)
Subject: bison-1.19: Makefile doesn't pass $(DEFS) when compiling files.c
Reply-To: jtc@gain.com
Organization: GAIN Technology Inc., Palo Alto, CA
Distribution: gnu
Date: Mon, 28 Sep 1992 04:44:46 GMT

Build of bison-1.19 failed on Solaris2, since -DSTDC_HEADERS wasn't
passed to the compile of files.c.

This small patch fixes the problem.

diff -c gnu/bison/Makefile.in:1.1.1.1 gnu/bison/Makefile.in:1.2
*** gnu/bison/Makefile.in:1.1.1.1	Mon Sep 28 11:40:44 1992
--- gnu/bison/Makefile.in	Mon Sep 28 11:40:44 1992
***************
*** 145,151 ****

  # This file is different to pass the parser file names to the compiler.
  files.o: files.c
! 	$(CC) -c $(CFLAGS) $(PFILES) $(srcdir)/files.c $(OUTPUT_OPTION)

  LR0.o: system.h machine.h new.h gram.h state.h
  closure.o: system.h machine.h new.h gram.h
--- 145,152 ----

  # This file is different to pass the parser file names to the compiler.
  files.o: files.c
! 	$(CC) -c $(CFLAGS) $(CPPFLAGS) $(DEFS) $(PFILES) \
! 		$(srcdir)/files.c $(OUTPUT_OPTION)

  LR0.o: system.h machine.h new.h gram.h state.h
  closure.o: system.h machine.h new.h gram.h

Newsgroups: gnu.utils.bug
From: asmith@synoptics.com (Andrew Smith)
Subject: Mix'n match with GLD/binutils-2.0
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 30 Sep 1992 20:29:56 GMT

I am trying to mix architectures and file formats as input to GLD and
have some problems.

I want to persuade GLD to link a "coff-a29k-big" file containing only
a .data section into a 68k program which is otherwise 
"a.out-sunos-big"/"m68k:68020" input files. e.g.

gld -o test m68k.o -b coff-a29k.big a29kdata.o  -T memmap.sc etc.

"memmap.sc" script file specifies OUTPUT_FORMAT("a.out-sunos-big") 
and OUTPUT_ARCH("m68k:68020"). 

GLD is perfectly happy with this and it produces an output file and
link map (with -M). The link map looks fine - GLD seems to have done
the correct thing with relocations, and has placed my 29k .data input
file into the output with the correct address/size.
In fact, everyone is happy with this, including nm,objdump and my own
utilities which use BFD to read binary files.

But, I need m68k-coff output files and I normally use 
OUTPUT_FORMAT("m68k-coff") in my .sc file. This works fine normally 
(except a bunch of debug info is lost, but that is another story) 
except when I link in my 29k data file. 
Then, the file output by GLD is bad: all the other binutils 
(nm,objdump etc.) as well as my own tools which use BFD complain 
that the output file is "not an object file". 

It seems that GLD has written the wrong (or illegal) file type 
into the output file when it got confused 
about the OUTPUT_FORMAT/TARGET formats. Any "-b" input switches
specified on the command line seem also to affect the OUTPUT_FORMAT
currently being generated which is wrong - the documentation says
that "-b" applies to input file format, not output format.


Any ideas? I think the problem is in the A.OUT -> COFF mapping.
Does anyone have a newer binutils/BFD version which fixes this
problem (Ian?). Or a GAS which correctly produces COFF output for m68k?
Does the new hot-off-the-press/super-vintage-shrink-wrapped Cygnus
release have any improvements in this area?

I think it is a reasonable thing to want to do: it is only
.data from different processor architectures that I am trying to mix,
not .text.


Also, minor gripe, GLD sends warning messages to stdout, not to stderr.
Is this a bug or a feature?


Andrew Smith
SynOptics Communications Inc.

Newsgroups: gnu.utils.bug