OSR5 install of 971031

OSR5 install of 971031

[Bill Walker]

With the dwarf2out.c patch installed, I had no trouble building and
using 971031 under SCO 3.2v5.0.4 ---

One minor caution:

	The "make install" will call on SCO's /usr/bin/tar if the
PATH variable is not right.  The "tar" in the install needs to
be GNU tar, since it uses a command line switch which is not
recognized by SCO tar.

	This might ultimately best be solved by proper "installation
instructions" in a README file.  (Surely everyone in the world
has GNU tar ? ) :=)



73 de Bill W5GFE


-- 
Bill Walker Ph.D.
Chairman, Dept. of Computer Science
East Central University
Ada, Oklahoma 74820-6899

e-mail:  bw@cs.ecok.edu 
phone:   580 332 8000 ext. 594
FAX:     580 332 4616

Re: OSR5 install of 971031

[Jeffrey A Law]

  In message < m0xSChp-0001jeC@student.ecok.edu >you write:
  > One minor caution:
  > 
  > 	The "make install" will call on SCO's /usr/bin/tar if the
  > PATH variable is not right.  The "tar" in the install needs to
  > be GNU tar, since it uses a command line switch which is not
  > recognized by SCO tar.
Does SCO have cpio?  If so that might be a better choice than
tar in this situation.

jeff

Re: OSR5 install of 971031

[Robert Lipe]

>   > 	The "make install" will call on SCO's /usr/bin/tar if the
>   > PATH variable is not right.  The "tar" in the install needs to
>   > be GNU tar, since it uses a command line switch which is not
>   > recognized by SCO tar.
> Does SCO have cpio?  If so that might be a better choice than
> tar in this situation.

Yes, OpenServer has cpio, as mandated by SVID II and X/Open 1992.
It also provides pax as preferred by X/open 1992.

Though I haven't done a 'make install', it looks like TAROUTOPTS
will choke on the 'B' option, which appears to be a non-standard
extention.

Isn't it jusr really sad that 25+ years later, there isn't a 
portable, efficient, safe way to copy an arbitrary directory 
tree in UNIX?

RJL

Re: OSR5 install of 971031

[Robert Lipe]

> With the dwarf2out.c patch installed, I had no trouble building and
> using 971031 under SCO 3.2v5.0.4 ---

Are you sure?

Have you dragged it through the testsuite?   If you haven't could you
please try at least one test for us?   Yes, you'll have to adjust
the source and object paths, but it's still  a lot quicker than
getting dejagnu and runtest wound up.

$ cat /tmp/c
O=/play/negcs/
S=/play/egcs-971023/gcc/

$O/gcc/xgcc -B$O/gcc/ -O0 -I$O/libraries/libio -g \
        $S/testsuite/g++.old-deja/g++.mike/net34.C -lstdc++

./a.out
(robertl) rjlhome:/play/testgcc
$ /tmp/c
bar_1::k -> 1
bar_2::k -> 2
bar_1::get_k() -> 1
bar_2::get_k() -> 2
/tmp/c[7]: 4339 Memory fault(coredump)

Re: OSR5 install of 971031

[Jeffrey A Law]

  In message < 19971103111542.55665@dgii.com >you write:
  > Yes, OpenServer has cpio, as mandated by SVID II and X/Open 1992.
  > It also provides pax as preferred by X/open 1992.
Ok.  We'll try that :-)

  > Though I haven't done a 'make install', it looks like TAROUTOPTS
  > will choke on the 'B' option, which appears to be a non-standard
  > extention.
It's a pretty common problem.  I always thought using "B" in gcc was
bogus.  Regardless, it's a one line tweak to use cpio since we've
had other systems with this exact problem.

jeff

Re: OSR5 install of 971031

[Joern Rennecke]

> It's a pretty common problem.  I always thought using "B" in gcc was
> bogus.  Regardless, it's a one line tweak to use cpio since we've
> had other systems with this exact problem.

Hmm, shouldn't we use autoconf to determine the existence of cpio?

Re: OSR5 install of 971031

[Jeffrey A Law]

  In message < 199711040023.AAA04878@phal.cygnus.co.uk >you write:
  > > It's a pretty common problem.  I always thought using "B" in gcc was
  > > bogus.  Regardless, it's a one line tweak to use cpio since we've
  > > had other systems with this exact problem.
  > 
  > Hmm, shouldn't we use autoconf to determine the existence of cpio?
If you write a test, I'll happily include it.

jeff

cpio vs. tar. was: OSR5 install of 971031

[Robert Lipe]

>   > > It's a pretty common problem.  I always thought using "B" in gcc was
>   > > bogus.  Regardless, it's a one line tweak to use cpio since we've
>   > > had other systems with this exact problem.
>   > 
>   > Hmm, shouldn't we use autoconf to determine the existence of cpio?
> If you write a test, I'll happily include it.

Is it really worth the bother?    Isn't cpio one of those utilities 
that's been around since UNIX was distributed on clay tablets?   Even 
though X/open has marked it "to be withdrawn" and SUSv2 tags it as 
"legacy" suggesting that "Applications should migrate to the pax 
utility.", would any OS vendor not ship cpio?


If we were to do anything more ambitious autoconf-ish, would it be 
any wiser to test for pax and use it instead of either tar or cpio?
Then we'd have three different install-headers-* targets, and I doubt
that would be a lot of fun, either.

Alternately, we can continue to patch this one system at a time until
we all die.    Here's one that should fix the system this was reported
on.

*** gcc/configure.in_   Sat Nov  1 00:49:10 1997
--- gcc/configure.in    Tue Nov  4 09:09:26 1997
***************
*** 933,942 ****
--- 933,943 ----
                ;;
        i[[3456]]86-*-sco3.2v5*)                # 80386 running SCO Open Server
5
                xm_file=i386/xm-sco5.h
                xmake_file=i386/x-sco5
                fixincludes=fixinc.sco
+               install_headers_dir=install-headers-cpio
                tm_file=i386/sco5.h
                tmake_file=i386/t-sco5
                extra_parts="crtbegin.o crtend.o crtbeginS.o crtendS.o"
                ;;
        i[[3456]]86-*-sco3.2v4*)                # 80386 running SCO 3.2v4 system

Re: cpio vs. tar. was: OSR5 install of 971031

[Jeffrey A Law]

  In message < 19971104091607.20107@dgii.com >you write:
  > Is it really worth the bother?    Isn't cpio one of those utilities 
  > that's been around since UNIX was distributed on clay tablets?
Yes, but many systems in the past did't have cpio.

And, my linux box doesn't seem to have it either.  I guess that's
a package I didn't install :-)


  >  Even though X/open has marked it "to be withdrawn" and SUSv2 tags
  > it as "legacy" suggesting that "Applications should migrate to the
  > pax utility.", would any OS vendor not ship cpio?
Lots used to not ship cpio, that's changed over time.

  > If we were to do anything more ambitious autoconf-ish, would it be 
  > any wiser to test for pax and use it instead of either tar or cpio?
  > Then we'd have three different install-headers-* targets, and I doubt
  > that would be a lot of fun, either.
I'd prefer to just stick with tar/cpio between those two we should
have every significant unix covered.

I wouldn't object to removing the "B" from the tar options and then
removing cpio support -- I'm not aware of a system that doesn't ship
tar (then again, maybe you are :-)

jeff

Re: cpio vs. tar. was: OSR5 install of 971031

[J. Kean Johnston]

I meant to send my reply to the whole lot of you but MUTT only sent it to
Jeff.

All this
cpio-versus-tar-and-will-autoconf-one-day-figure-out-my-preference-in-coffee
stuff is not needed. Append this line to the end of config/i386/t-sco5:
TAROUTOPTS=xpf

Alternately, fix TAROUTOPTS in makefile.in to remove the B flag. It
is NOT portable, but *EVERY* tar understands xpf, even the DOS ones.

My $0.02 worth, fix Makefile.in.  Its wrong.

JKJ

Re: cpio vs. tar. was: OSR5 install of 971031

[Gavin Koch]

J. Kean Johnston writes:
 > ... but MUTT only sent it to Jeff.

 :-)

                       -gavin...

Re: cpio vs. tar. was: OSR5 install of 971031

[teunis]

>   >  Even though X/open has marked it "to be withdrawn" and SUSv2 tags
>   > it as "legacy" suggesting that "Applications should migrate to the
>   > pax utility.", would any OS vendor not ship cpio?
> Lots used to not ship cpio, that's changed over time.
> 
>   > If we were to do anything more ambitious autoconf-ish, would it be 
>   > any wiser to test for pax and use it instead of either tar or cpio?
>   > Then we'd have three different install-headers-* targets, and I doubt
>   > that would be a lot of fun, either.
> I'd prefer to just stick with tar/cpio between those two we should
> have every significant unix covered.
> 
> I wouldn't object to removing the "B" from the tar options and then
> removing cpio support -- I'm not aware of a system that doesn't ship
> tar (then again, maybe you are :-)

WindowsNT? *ducking*

G'day, eh? ;]
	- Teunis
[so when's the next win32-capable image going to appear? :]
(don't answer - I'll watch for announcements)

Re: cpio vs. tar. was: OSR5 install of 971031

[Jeffrey A Law]

  In message <Pine.LNX.3.96.971104180258.30920A-100000@sigil.computersupportcen
tre.com>you write:
  > > I wouldn't object to removing the "B" from the tar options and then
  > > removing cpio support -- I'm not aware of a system that doesn't ship
  > > tar (then again, maybe you are :-)
  > 
  > WindowsNT? *ducking*
GCC doesn't build native on windows95 or windowsnt.  One day it
will and we'll have to cross this bridge (among many others which
are far more serious).

jeff