4.17.85 configure w/ relative path fails to build bfd/dwarf1.c

4.17.85 configure w/ relative path fails to build bfd/dwarf1.c

[Todd Whitesel]

Tried to build 4.17.85 for my sparc (solaris 2.5.1) tonight and found that
if one configures using a path to configure, like ../blah/blah/configure or
/blah/blah/configure then:

	- GDB does not build bfd/dwarf1.c, but attempts to archive it in
		libbfd, and fails.

	- dejagnu-19990209 gets the following error during 'make install':

 /usr/local/gnu/bin/install -c -m 644 ../../../toddpw/dejagnu-19990209/dejagnu/baseboards/arm-ice.exp /net/alabama/alabama2/gdb41785/share/dejagnu/baseboards/../../../toddpw/dejagnu-19990209/dejagnu/baseboards/arm-ice.exp
/usr/local/gnu/bin/install: /net/alabama/alabama2/gdb41785/share/dejagnu/baseboards/../../../toddpw/dejagnu-19990209/dejagnu/baseboards/arm-ice.exp: No such file or directory
*** Error code 1

Sorry to not include patches but I am not much of a configure wizard yet.

If more info than this is needed to fix the problem, let me know.

I usually keep read-only copies of GNU tarballs on my machine for reference,
and do all builds in 'sandbox' directories. I am running 'make check' on the
results of a build/install from writable copies of the source, and will send
that in when I get back in tomorrow. G'night.

-- 
Todd Whitesel
toddpw @ wrs.com

Re: 4.17.85 configure w/ relative path fails to build bfd/dwarf1.c

[Stan Shebs]

   From: toddpw@wrs.com (Todd Whitesel)
   Date: Wed, 10 Mar 1999 20:15:29 -0800 (PST)

   Tried to build 4.17.85 for my sparc (solaris 2.5.1) tonight and found that
   if one configures using a path to configure, like ../blah/blah/configure or
   /blah/blah/configure then:

This is the normal way that I configure, so it does get tested...

	   - GDB does not build bfd/dwarf1.c, but attempts to archive it in
		   libbfd, and fails.

Are you sure this is a clean set of sources?  The dwarf1 need comes from

	elf="elf.lo elflink.lo dwarf2.lo dwarf1.lo"

in bfd/configure, so it's curious that dwarf1 would be a problem, and not
the other three files.

	   - dejagnu-19990209 gets the following error during 'make install':

    /usr/local/gnu/bin/install -c -m 644 ../../../toddpw/dejagnu-19990209/dejagnu/baseboards/arm-ice.exp /net/alabama/alabama2/gdb41785/share/dejagnu/baseboards/../../../toddpw/dejagnu-19990209/dejagnu/baseboards/arm-ice.exp
   /usr/local/gnu/bin/install: /net/alabama/alabama2/gdb41785/share/dejagnu/baseboards/../../../toddpw/dejagnu-19990209/dejagnu/baseboards/arm-ice.exp: No such file or directory
   *** Error code 1

This is also suspicious, since the file is definitely there, and is handled
identically to scores of other files in baseboards.

								Stan

Re: 4.17.85 configure w/ relative path fails to build bfd/dwarf1.c

[Todd Whitesel]

> 	   - GDB does not build bfd/dwarf1.c, but attempts to archive it in
> 		   libbfd, and fails.
> 
> Are you sure this is a clean set of sources?  The dwarf1 need comes from

Generally I download the tarball from private/gdb, extract it into a
directory (/alabama2/toddpw/gdb-4.17.85 in this case) and chmod -R -w it.

Perhaps the read-only-ness has something to do with it?

I also tend not to have GNU stuff early in my path, so if some recent
change depends on updated, sane tool binaries, perhaps the fault lies
there.

Unfortunately I don't have a lot of time to diagnose this right now.
I'm getting lots of failures from 'make check' too, and when I ran
make check again (because I forgot to tee the output the first time)
it hung...

toddpw 28308 28305 99 12:12:36 pts/7   111:46 /alabama2/sandbox/gdb/testsuite/gdb.hp/more-steps

-- 
Todd Whitesel
toddpw @ wrs.com

Re: 4.17.85 configure w/ relative path fails to build bfd/dwarf1.c

[Jim Blandy]

> Tried to build 4.17.85 for my sparc (solaris 2.5.1) tonight and found that
> if one configures using a path to configure, like ../blah/blah/configure or
> /blah/blah/configure then:
> 
> 	- GDB does not build bfd/dwarf1.c, but attempts to archive it in
> 		libbfd, and fails.
> 
> 	- dejagnu-19990209 gets the following error during 'make install':
> 
>  /usr/local/gnu/bin/install -c -m 644 ../../../toddpw/dejagnu-19990209/dejagnu/baseboards/arm-ice.exp /net/alabama/alabama2/gdb41785/share/dejagnu/baseboards/../../../toddpw/dejagnu-19990209/dejagnu/baseboards/arm-ice.exp
> /usr/local/gnu/bin/install: /net/alabama/alabama2/gdb41785/share/dejagnu/baseboards/../../../toddpw/dejagnu-19990209/dejagnu/baseboards/arm-ice.exp: No such file or directory
> *** Error code 1

This is mysterious to me; I always build using a path to configure,
just as you said.  Here's the config.status from my Solaris 2.5.1
tests:

#!/bin/sh
# This file was generated automatically by configure.  Do not edit.
# This directory was configured as follows:
../../configure --host=sparc-sun-solaris2.5.1 --prefix=/stone/jimb/gdb-4.18 --norecursion 
# using "mh-frag"

What is dejagnu doing in there?  That's not a part of the GDB
distribution.


> If more info than this is needed to fix the problem, let me know.

I think so.

Re: 4.17.85 configure w/ relative path fails to build bfd/dwarf1.c

[Todd Whitesel]

> This is mysterious to me; I always build using a path to configure,
> just as you said.  Here's the config.status from my Solaris 2.5.1
> tests:
> 
> #!/bin/sh
> # This file was generated automatically by configure.  Do not edit.
> # This directory was configured as follows:
> ../../configure --host=sparc-sun-solaris2.5.1 --prefix=/stone/jimb/gdb-4.18 --norecursion 
> # using "mh-frag"

Mine (when I got the error) was basically equivalent, except that my build
tree was not inside the source tree. My path to configure was
	../toddpw/gdb-4.17.85/configure

> What is dejagnu doing in there?  That's not a part of the GDB
> distribution.

I got it from gdb/private so I could try 'make check'. In the past I have
downloaded GDB+dejagnu from gdb/private but I have never been able to get
'make check' to totally succeed. With straight 4.17 I think only the solaris
thread tests failed though.

> > If more info than this is needed to fix the problem, let me know.
> 
> I think so.

Looks like it, although I have a sinking feeling that it is some deficiency
in the sh/sed/grep/find/etc. binaries I have in my path, which is something
that only I can track down, and I don't know when I can get around to that.

I could always re-do the bad configure and send someone the tarball, but
the efficiency of that is questionable and there's no guarantee it will
yield results.

-- 
Todd Whitesel
toddpw @ wrs.com

Re: 4.17.85 configure w/ relative path fails to build bfd/dwarf1.c

[Jim Blandy]

> Mine (when I got the error) was basically equivalent, except that my build
> tree was not inside the source tree. My path to configure was
> 	../toddpw/gdb-4.17.85/configure

I did my 4.17.86 Solaris and Linux builds in sibling trees, with no
ill effects.

Re: 4.17.85 configure w/ relative path fails to build bfd/dwarf1.c

[Todd Whitesel]

Tonight I switched to 4.17.86 and played around with my path some.

Putting a bunch of recently built GNU stuff early in my path fixed it.

Then arranging for just /usr/ccs/bin/make to appear first in the path
made the problem come back.

Is there any way for configure to detect & complain about this, or am I
now in RTFM land?

-- 
Todd Whitesel
toddpw @ wrs.com

Re: 4.17.85 configure w/ relative path fails to build bfd/dwarf1.c

[Tom Tromey]

>>>>> "Todd" == Todd Whitesel <toddpw@wrs.com> writes:

Todd> Is there any way for configure to detect & complain about this,
Todd> or am I now in RTFM land?

Builddir!=srcdir builds are only supported with GNU make.  This is a
longstanding limitation of basically any GNU-style utility.  That's
because most vendor makes incorrectly implement VPATH (whether yours
is one such I don't know offhand, but based on your reports I would
say yes).

You cannot detect this at configure time because you don't know which
`make' the user is going to run.  E.g. you might do `configure; gmake'
-- in which case any configure complaint would be incorrect.

It might be possible to detect this at `make' time, but I haven't
given it any thought.  If you know of a way to do it, I'd like to know
-- I'll add it to automake.

Tom