Compiliation failure

Compiliation failure

[Jean-Pierre Radley]

A whole lot of fixes went in these last 24 hours.

Just did a cvs update, and here on SCO OSR 5.0.4, compile's failing with:

	../../egcs/gcc/print-rtl.c: In function `print_rtx':
	../../egcs/gcc/print-rtl.c:276: incompatible types in assignment

The relevent line reads:
	
	REAL_VALUE_FROM_CONST_DOUBLE (val, in_rtx);
-- 
Jean-Pierre Radley <jpr@jpr.com>  XC/XT Custodian   Sysop, CompuServe SCOForum

Re: Compiliation failure

[Robert Lipe]

> A whole lot of fixes went in these last 24 hours.

Welcome back, Jeff. :-)

> Just did a cvs update, and here on SCO OSR 5.0.4, compile's failing with:
> 
> 	../../egcs/gcc/print-rtl.c: In function `print_rtx':
> 	../../egcs/gcc/print-rtl.c:276: incompatible types in assignment

You got lucky and hit the window between Richard & Jeff's patches to that
file.   

The fix for this problem is now in the CVS repository.  Another cvs
update is in order.  I'd suggest doing a 'cvs update' on that lone file
right now as if you update the whole thing, you'll inherit a different
build failure:

gcc -c  -DIN_GCC    -g -O2     -I. -I.. -I../../../egcs/gcc/cp -I../../../egcs/gcc/cp/.. -I../../../egcs/gcc/cp/../config ../../../egcs/gcc/cp/decl.c
../../../egcs/gcc/cp/decl.c: In function `finish_function':
../../../egcs/gcc/cp/decl.c:12517: too many arguments to function `get_vbase'

Looking at the offending code, it's probably just a typo where too many
arguments are handed to TYPE_BINFO, but I'm not certain of that.

RJL

Re: Compiliation failure

[Jean-Pierre Radley]

Robert Lipe bruited (on 07Jul):
| 
| You got lucky and hit the window between Richard & Jeff's patches to that
| file.   
| 

OK, latest cvs update got past that one, but reverts to one I never got
around to bugreport three days ago:

	Cannot open libU77/datetime_.o: No such file or directory
	libU77/datetime_.o not found

-- 
Jean-Pierre Radley <jpr@jpr.com>  XC/XT Custodian   Sysop, CompuServe SCOForum

Re: Compiliation failure

[Jeffrey A Law]

  In message < 19980707184819.U4533@jpr.com >you write:
  > Robert Lipe bruited (on 07Jul):
  > | 
  > | You got lucky and hit the window between Richard & Jeff's patches to that
  > | file.   
  > | 
  > 
  > OK, latest cvs update got past that one, but reverts to one I never got
  > around to bugreport three days ago:
Start with a fresh build directory and the datetime_.o problems ought
to go away.  I recommend starting with a fresh build directory on a
regular basis as not all the dependencies are up to date in the
Makefiles.

jeff

Re: Compiliation failure

[Robert Lipe]

> | You got lucky and hit the window between Richard & Jeff's patches to that
> 
> OK, latest cvs update got past that one, but reverts to one I never got
> around to bugreport three days ago:
> 
> 	Cannot open libU77/datetime_.o: No such file or directory
> 	libU77/datetime_.o not found

Boy, you are lucky.

The moral-low-road answer is: If you 'make' again, you won't see this
message again.


This was actually discussed in an (admittedly nonobvious) thread earlier
today about libf2c's configure failing to detect the configure changes
and propogate them into Makefiles and config.h's.

Do something like
$ cd <wherever your object dir is>
$ cd <triplet>/libf2c
$ head config.status

Blow the line that looks liek this into a file :

# /net/rjlhome/play/egcs/libf2c/configure  --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --enable-multilib --with-gcc-version-trigger=/net/rjlhome/play/egcs/gcc/version.c --srcdir=/net/rjlhome/play/egcs/libf2c --with-target-subdir=i686-pc-linux-gnu


Run that file.


For whatever reason a 'config.status --recheck' or a './config.status' will
not do the right thing right now.

Dave sounded like he was in the midst of reworking the libf2c stuff so I 
quit trying to figure out what was going on with all this.

RJL

Re: Compiliation failure

[Dave Love]

>>>>> "Jeff" == Jeffrey A Law <law@cygnus.com> writes:

 Jeff> Start with a fresh build directory and the datetime_.o problems
 Jeff> ought to go away.

I'm not sure which build directory that means, but when I tried
deleting just the library one it definitely didn't DTRT, possibly
under some specific condition I don't recall.

If someone expert at configuration stuff could volunteer quickly to
sort out the libf2c configure/build to Craig's satisfaction, it would
be very helpful.

Re: Compiliation failure

[Jeffrey A Law]

  In message < rzq90m4piwh.fsf@djlvig.dl.ac.uk >you write:
  > I'm not sure which build directory that means, but when I tried
  > deleting just the library one it definitely didn't DTRT, possibly
  > under some specific condition I don't recall.
  > 
  > If someone expert at configuration stuff could volunteer quickly to
  > sort out the libf2c configure/build to Craig's satisfaction, it would
  > be very helpful.
What issues need to be resolved for libf2c?  I thought we took care of
all the configury junk a long time ago.
jeff

libf2c configure/build issues was: Compiliation failure

[Robert Lipe]

>   > I'm not sure which build directory that means, but when I tried
>   > deleting just the library one it definitely didn't DTRT, possibly
>   > under some specific condition I don't recall.
>   > 
>   > If someone expert at configuration stuff could volunteer quickly to
>   > sort out the libf2c configure/build to Craig's satisfaction, it would
>   > be very helpful.
> What issues need to be resolved for libf2c?  I thought we took care of
> all the configury junk a long time ago.

Other than the absence of multilibbing (and if anyone can point me to a 
document or a tractable example, I can kick in some brain cycles) I said
the following in a private discussion with Dave Love:

	(robertl) rjlgemini:/home/robertl/tmp/negcs
	$ touch /net/rjlhome/play/egcs/libf2c/libU77/configure.in
	(robertl) rjlgemini:/home/robertl/tmp/negcs
	$ make
	[ configure doesn't get run, config.h doesn't get touched, 
		nothing compiled ]
	(robertl) rjlgemini:/home/robertl/tmp/negcs
	$ touch /net/rjlhome/play/egcs/libf2c/libU77/configure.in
	(robertl) rjlgemini:/home/robertl/tmp/negcs
	$ make
	[ configure doesn't get run, config.h doesn't get touched, 
		nothing compiled ]

        Of course, this means that changes like the ones recently made
        don't actually get compiled in unless a fresh build happens.

        I made a couple of attempts to fix it, but can't seem to make it
        go.  There's code in the Makefiles that tries to recognize the
        dependency, but I can't see why it isn't recognizing this.

Re: Compiliation failure

[Craig Burley]

>  In message < rzq90m4piwh.fsf@djlvig.dl.ac.uk >you write:
>  > I'm not sure which build directory that means, but when I tried
>  > deleting just the library one it definitely didn't DTRT, possibly
>  > under some specific condition I don't recall.
>  > 
>  > If someone expert at configuration stuff could volunteer quickly to
>  > sort out the libf2c configure/build to Craig's satisfaction, it would
>  > be very helpful.
>What issues need to be resolved for libf2c?  I thought we took care of
>all the configury junk a long time ago.

I got the stuff to configure and build purely in a "minimalist" way,
to pattern g77 0.5.23, as part of trying to learn all these twisty
mazes of tools and dependencies.  My main goal was trying to get
libf2c to build properly in a normal build, along with being sure
I understood each step of the process.

Dave (and most everyone else) properly wants the libf2c build process
to work from whatever subdirectory it is built from and to properly
recognize when individual things need to be rebuilt.

I've expressed concerns about a patch he sent to me to rework lots
of it, initially just ones that reflect old bugs it took me a long
time to fix and I don't want to see resurface.

But there's evidence that they won't with his approach, so if it's
still okay, I'd like for his work to go into egcs 1.1, though I
have yet to send him the more minor comments I had.  He'll probably
send his "final" patch to egcs-patches first.

        tq vm, (burley)

P.S. The main concern I had was to not regress to where g77 was
awhile ago, namely, `make install' under normal, post-build
circumstances rebuilding anything.  If it does that, then `root'
cannot reliably do `make install' from an NFS-mounted build tree
without adequate write permissions in the build tree.  g77's
approach to handling the warts relating to trying to have multiple
Makefiles contribute to a single archive, libf2c.a, used to result
in `make install' always doing `$(AR) rc libf2c.a ...', which
resulted from fixing other bugs relating to not always properly
rebuilding libf2c-related targets and adding .o's to the archive.