Sorry folks false alarm. It seems that the Imake that generated the
makefiles that GNU make died on was the culprit as it wasn't being built
correctly for some reason and so generated bad rules.
Regards,
Mark Syms
> -----Original Message-----
> From: Mark Syms
> Sent: Wednesday, May 24, 2000 10:37 AM
> To: '[EMAIL PROTECTED]'
> Subject: HP-UX 64 bit bug
>
> We are having some problems using GNU make on a new HP 9000 L2000 machine
> (64 bit) having moved from using older 32 bit machines.
>
> It appears that the dependency checking is getting confused somewhere when
> trying to build a file.
>
> Makefile snippet
> ----------------
>
> transport.c: $(TRANSCOMMSRC)/transport.c
> $(RM) $@
> $(LN) $? $@
>
> TRANSCOMMSRC is ../../lib/xtrans
> transport.c is itself a symbolic link to a source tree i.e. the expected
> result is a symbolic link to a symbolic link to a real file.
>
> HP 9000 L2000 (64 bit PA RISC)
> ------------------------------
>
> Reading makefiles...
> Reading makefile `Makefile'...
> Updating makefiles....
> Makefile `Makefile' might loop; not remaking it.
> Updating goal targets....
> Considering target file `../../lib/xtrans/transport.c'.
> Looking for an implicit rule for `../../lib/xtrans/transport.c'.
> Trying pattern rule with stem `transport'.
> Trying rule dependency `/src/cascade/main/X/lib/ICE'.
> Trying implicit dependency `../../lib/xtrans//transport.c'.
> Found an implicit rule for `../../lib/xtrans/transport.c'.
> Considering target file `/src/cascade/main/X/lib/ICE'.
>
>
> HP 9000 C110 (32 bit PA-RISC)
> -----------------------------
>
> Reading makefiles...
> Reading makefile `Makefile'...
> Updating makefiles....
> Makefile `Makefile' might loop; not remaking it.
> Updating goal targets....
> Considering target file `transport.c'.
> File `transport.c' does not exist.
> Considering target file `../../lib/xtrans/transport.c'.
> Looking for an implicit rule for `../../lib/xtrans/transport.c'.
> Trying pattern rule with stem `transport'.
> Trying implicit dependency
> `../../lib/xtrans//src/cascade/main/X/lib/ICE/transport.c'.
> Trying pattern rule with stem `transport'.
> Trying implicit dependency `../../lib/xtrans/transport.y'.
>
> --------------------------------------------------------------------------
> -----------------------
>
> As can be seen from the debug information the 32 bit and 64 bit machines
> diverge on line 8 with the 64 bit trying a rule dependency and the 32
> using an implicit rule. If this continues the following happens :-
>
> Considering target file `../../lib/xtrans///transport.c'.
> Looking for an implicit rule for `../../lib/xtrans///transport.c'.
> Trying pattern rule with stem `transport'.
> Trying rule dependency `/src/cascade/main/X/lib/ICE'.
> Trying implicit dependency `../../lib/xtrans////transport.c'.
> Found an implicit rule for `../../lib/xtrans///transport.c'.
> Considering target file `/src/cascade/main/X/lib/ICE'.
> File `/src/cascade/main/X/lib/ICE' was considered already.
> Considering target file `../../lib/xtrans////transport.c'.
> Looking for an implicit rule for `../../lib/xtrans////transport.c'.
> Trying pattern rule with stem `transport'.
> Trying rule dependency `/src/cascade/main/X/lib/ICE'.
>
> As can easily be seen extra /'s are added to the rule checking, this
> continues seemingly without termination until a limit is reached
> (recursion depth possibly ?).
>
> This problem has been observed in 3.75, 3.77 and 3.79 gmake with binary
> and source (built on both 32 or 64 bit platforms) distributions. Having
> had a cursory look with a debugger on the 64 bit machine it seems that the
> rules are corrupt before the parsing operation is completed.
>
> Any assistance would be appreciated. If any further information is
> required please contact me.
>
> Mark Syms
>
> Software Engineer
> Citrix Systems (Research and Development) Ltd
> +44 1223 568 953
> [EMAIL PROTECTED]
