Re: depcomp problem [Fwd: Trying to compile latest CVS on old SCO unixware 2]
Stephen Cameron wrote:
> It's getting a bit weird now,
>
> Making all in lib
> source='argmatch.c' object='argmatch.o' libtool=no \
> depfile='.deps/argmatch.Po' tmpdepfile='.deps/argmatch.TPo' \
> depmode=none /bin/sh ../depcomp \
> ../compile cc -DHAVE_CONFIG_H -I. -I. -I.. -I../src -I../src -g -c
> -o argmatch.o `test -f argmatch.c || echo './'`argmatch.c
> UX:as: ERROR: (EOF):cannot open output file: argmatch.o: Is a directory
>
> Say what?!?
The test system probably had ofile defaulting to ./argmatch.o or somesuch...
> So now I try ineptly patching "compile" which gets me a little further, loads
> of .c files compile, but:
> --- compile.origMon Jun 18 05:09:55 2001
> +++ compile Mon Jun 18 05:11:53 2001
> @@ -47,8 +47,18 @@
> done
>
> test -z "$ofile" && {
> - echo "compile: no \`-o' option seen" 1>&2
> - exit 1
> + if [ "$cfile" = "" ]
> + then
> + echo "compile: no \`-o' option seen, and no .c file." 1>&2
> + exit 1
> + else
> + ofile=`echo "$cfile" | sed -e "s/\.c$/.o/"`
> + if [ "$ofile" = "$cfile" ]
> + then
> + echo "compile: could not guess .o file from .c file: $cfile"
> + exit 1
> + fi
> + fi
> }
> test -z "$cfile" && {
This sounds suspicious, perhaps a symptom of a bug in the makefile rules if you
realy needed it - compile is designed to work around a problem with -o and -c
being used at the same time, so it shouldn't be called without -o or -c...
> @@ -60,7 +70,7 @@
> cofile=`echo $cfile | sed -e 's|^.*/||' -e 's/\.c$/.o/'`
>
> # Create the lock directory.
> -lockdir=`echo $ofile | sed -e 's|/|_|g'`
> +lockdir=`echo "$ofile"".lock" | sed -e 's|/|_|g'`
> while true; do
> if mkdir $lockdir > /dev/null 2>&1; then
>break
Okay, but I have a nitpick. You shouldn't need the quotes around "$ofile"".lock":
$ofile.lock should be sufficient.
> Then running make again:
>
> []
> UX:mv: ERROR: version.o and version.o are identical
> ../compile cc -g -o cvs add.o admin.o annotate.o buffer.o
> checkin.o checkout.o classify.o client.o commit.o create_adm.o cvsrc.o diff.o
> edit.o entries.o error.o expand_path.o fileattr.o filesubr.o find_names.o
> hardlink.o hash.o history.o ignore.o import.o lock.o log.o login.o logmsg.o
> main.o mkmodules.o modules.o myndbm.o no_diff.o parseinfo.o patch.o rcs.o
> rcscmds.o recurse.o release.o remove.o repos.o root.o run.o scramble.o
> server.o status.o subr.o tag.o update.o vers_ts.o watch.o wrapper.o zlib.o
> ../diff/libdiff.a ../lib/libcvs.a ../zlib/libz.a version.o -lsocket -lgen
> compile: no `.c' file seen
Okay, this sounds like an Automake bug now. I suspect compile shouldn't be called
for linking... only when both -o and -c are specified. I'm cc'ing Automake again.
Automake folks: I've included a revised patch for the lockdir line as I'm pretty
sure you'll want that bit whatever else comes out of this.
> Hmmm. At this point I have to wonder if this "compile" script is all it's
> cracked up to be. It doesn't seem to be able to use cc to just link...(and my
> patch is wrong in that area too.)For that matter, "compile" may be generated by
> automake for all I know.
>
> And, BTW, that "[UX:mv: ERROR: x.o and x.o are identical" appears for pretty
> much every file that gets compiled...
>
> And I wonder about the line in the script:
>
> "$prog" $args
>
> Would that have problems with quoted arguments passed into the script? Not that
> cvs would run into that, but still.
Actually, I think it would, but the source of the problem is the loop that
constructs $args, not this call. I've included a patch for this too.
> Feel free to forward this email to the automake list, if that's a more
> appropriate destination.
Derek
--
Derek Price CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net )
--
Round up the usual suspects.
- Claude Rains as Captain Louis Renault, _Casablanca_
Index: ChangeLog
===
RCS file: /cvs/automake/automake/ChangeLog,v
retrieving revision 1.1430
diff -u -r1.1430 ChangeLog
--- ChangeLog 2001/06/18 01:08:34 1.1430
+++ ChangeLog 2001/06/18 18:29:45
@@ -1,3 +1,9 @@
+2001-06-18 Derek Price <[EMAIL PROTECTED]>
+ Stephen Cameron <[EMAIL PROTECTED]>
+
+ * lib/compile: Make sure lockdir doesn't have the same name as the
+ object file.
+
2001-06-17 Tom Tromey <[EMAIL PROTECTED]>
* automake.in (require_file_internal): Check for already-required
Index: lib/compile
===
RCS file: /cvs/automake/automake/lib/compile,v
retrieving revision 1.3
diff -u -r1.3 compile
--- compile 2000/10/16 09:01:36 1.3
+++ compile 2001/06/18 18:29:46
@@ -60,7 +60,7 @@
cofile=`echo $cfile | sed -e 's|^.*/||' -e 's/\.c$/.o/'`
Re: CPP determined incorrectly
Akim Demaille wrote: > > | > How about merging AC_PROG_CPP and AC_PROG_CC together? > | > > | > What's the point of keeping the two of them? > | * Some tools (eg. imake) apply cpp as macro-processor, even if cc is > | not available on a particular installation. Other tools might want > | to apply these tools even if not using *.c at all (Eg. using Imake > | with non-c-languages). > > Do you know such places? (A cpp and no cc). > Well, it depends on how to interpret your question. No, I do not have an actual example, but I have been using this proceedure for my own work approximately 10 years ago. Furthermore, there exist several tools which (implicitly, indirectly) apply _a_ cpp without directly needing a cc, eg. * imake * xrgb * rpcgen ... It also is fairly simple to construct such examples, e.g. * applying imake to configure a sub-package of an otherwise autoconfiscated collection of packages. * *.S -> *.o, applying /lib/cpp and $target-as (This case is a hack, but it is not as seldom as you might assume!). > | * In rare occasions, only a functional cpp is required, but a broken > | cc is tolerable (eg. to process *.S -> *.o) > > I don't think we need AC_PROG_CPP here, all you need is an > AC_CHECK_PROG, or somewhat improved if needed. But AC_PROG_CPP is > much more than this, and is completely bound to CC. E.g., > AC_CHECK_HEADERS is addressed by CPP, not CC etc. Though I agree that this is a work around to get this functional, I am inclinded to call this behavior broken. It is at least not what users will expect from using AC_PROG_XXX. They will assume AC_PROG_XXX to be specialized checks for XXX - Here: A check for CPP and not for CC. > | * Some OS do not have a functional cc, but have a functional > | /lib/cpp > | (IIRC, Solaris-2.7 by default has the infamous /usr/ucb/cc script, > | but has a functional /lib/cpp). > > Again, I believe that you just want an AC_CHECK_PROG(CPP), not > something so closely bound to the C language. Right, but this is not what I am talking about. I am talking about: * Is AC_PROG_CPP a specialized check for a cpp? If yes, it must not require cc. * Is AC_PROG_CPP a subroutine of AC_PROG_CC|CXX? If yes, it should not be public. * Do AC_PROG_CPP require CC? If yes, the logic is twisted, IMO. * Do we need to split AC_CHECK_CPP (checking for _a_ cpp) from a AC_CHECK_CC_CPP (checking for the cpp required by a particular cc)? At least I think so. More generalizing: * Is using AC_CHECK_PROG() legitimated/legal? My answer: No, unless you know what you are doing. * How to destinguish using [g]cc from directly using a particular tool (Here gcc -E vs. cpp; more general also gcc -c vs. gcc -S, $(AS) .. ) Ralf
Has automake been adapted to autoconf 2.50?
If not, I have done the necessary work and can prepare a patch (I'm not including it because I had the great idea of working directly on the installed scripts and data files, so preparing the patch might involve some work...) -- |_ _ _ __ |_)(_)| ) ,' '-._
