You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stdcxx.apache.org by Martin Sebor <se...@roguewave.com> on 2007/03/12 19:05:08 UTC
missing build line for 22.locale.codecvt.out
I'm trying to figure out why 22.locale.codecvt.out is reported
as having failed to compile with Sun C++ 5.8 on Solaris 8 among
other compilers but I don't the command line in the log (there
is a line that says that dependencies were generated for it but
no compilation or link line). Other 22.locale.*.cpp tests are
there so I'm stumped why this one would be missing. Andrew, do
you have any idea what might have happened to it?
http://people.apache.org/~sebor/stdcxx/results/solaris8-sunpro-32b-5.8-8d-log.gz.txt
Martin
Re: missing build line for 22.locale.codecvt.out
Posted by Travis Vitek <vi...@roguewave.com>.
Travis Vitek wrote:
>
> So now we are pretty sure we know what is happening. All target names that
> end in .out will match to the pattern rule for generating .out files
> first. The question is how to fix it. Here are the options I see.
>
> 1. rename the source file so the generated executable will not end in
> .out
> 2. change the .out rule to generate output files with some other
> extension
> 3. create an rule that is a better match than %.out so that rule is
> selected for 22.locale.codecvt.out
> 4. create a new makefile that includes the original GNUmakefile.tst,
> but defines the more explicit rule mentioned in 3
>
> I dislike option 3 the most, and from the sound of it you won't want to
> use option 1. So how does option 2 sound?
>
> Travis
>
Another option would be to change the extension for executables. i.e.
[%.exe: %.o]
--
View this message in context: http://www.nabble.com/missing-build-line-for-22.locale.codecvt.out-tf4385887.html#a13715331
Sent from the stdcxx-dev mailing list archive at Nabble.com.
Re: [PING] Re: missing build line for 22.locale.codecvt.out
Posted by Martin Sebor <se...@roguewave.com>.
In the absence of further feedback I'll be checking in the following patch
as the fix for https://issues.apache.org/jira/browse/STDCXX-650.
Index: etc/config/makefile.rules
===================================================================
--- etc/config/makefile.rules (revision 602767)
+++ etc/config/makefile.rules (working copy)
@@ -87,9 +87,17 @@
endif # ifneq ($(AS_EXT),".")
endif # ifneq ($(AS_EXT),)
+# make the rule match for sources matching *.out.cpp
+%.out.o: %.out.cpp
+ $(CXX) -c $(CPPFLAGS) $(CXXFLAGS) $(call CXX.repo,$<) $<
+
%.o: %.cpp
$(CXX) -c $(CPPFLAGS) $(CXXFLAGS) $(call CXX.repo,$<) $<
+# make the rule match for objects matching *.out.o
+%.out: %.out.o
+ $(LD) $< -o $@ $(LDFLAGS) $(LDLIBS) $(call CXX.repo,$<)
+
%: %.o
$(LD) $< -o $@ $(LDFLAGS) $(LDLIBS) $(call CXX.repo,$<)
Martin Sebor wrote:
>
> Well, what do you think?
>
> Martin
>
>
> Martin Sebor wrote:
>>
>> Travis Vitek wrote:
>> [...]
>>> So now we are pretty sure we know what is happening. All target names
>>> that
>>> end in .out will match to the pattern rule for generating .out files
>>> first.
>>> The question is how to fix it. Here are the options I see.
>>
>> Thanks for the analysis!
>>
>>>
>>> 1. rename the source file so the generated executable will not end
>>> in
>>> .out
>>> 2. change the .out rule to generate output files with some other
>>> extension
>>> 3. create an rule that is a better match than %.out so that rule is
>>> selected for 22.locale.codecvt.out
>>> 4. create a new makefile that includes the original GNUmakefile.tst,
>>> but
>>> defines the more explicit rule mentioned in 3
>>>
>>> I dislike option 3 the most,
>>
>> Between 2 and 3 I think I actually like 3 better. It seems general
>> enough to eliminate all ill-effects of the overly generic %.out: %
>> rule. And it's very simple (at least in my tests it was):
>>
>> %.foo: %.foo.c
>> touch $@
>>
>>> and from the sound of it you won't want to use
>>> option 1. So how does option 2 sound?
>>
>> Another possibility might be to enable the %.out: % rule only for
>> examples and disable it for tests and everything else work? We don't
>> need to create .out files anywhere else, do we?
>>
>> Martin
>>
>>
>
>
--
View this message in context: http://www.nabble.com/missing-build-line-for-22.locale.codecvt.out-tp12503279p14245955.html
Sent from the stdcxx-dev mailing list archive at Nabble.com.
[PING] Re: missing build line for 22.locale.codecvt.out
Posted by Martin Sebor <se...@roguewave.com>.
Well, what do you think?
Martin
Martin Sebor wrote:
>
> Travis Vitek wrote:
> [...]
>> So now we are pretty sure we know what is happening. All target names
>> that
>> end in .out will match to the pattern rule for generating .out files
>> first.
>> The question is how to fix it. Here are the options I see.
>
> Thanks for the analysis!
>
>>
>> 1. rename the source file so the generated executable will not end in
>> .out
>> 2. change the .out rule to generate output files with some other
>> extension
>> 3. create an rule that is a better match than %.out so that rule is
>> selected for 22.locale.codecvt.out
>> 4. create a new makefile that includes the original GNUmakefile.tst,
>> but
>> defines the more explicit rule mentioned in 3
>>
>> I dislike option 3 the most,
>
> Between 2 and 3 I think I actually like 3 better. It seems general
> enough to eliminate all ill-effects of the overly generic %.out: %
> rule. And it's very simple (at least in my tests it was):
>
> %.foo: %.foo.c
> touch $@
>
>> and from the sound of it you won't want to use
>> option 1. So how does option 2 sound?
>
> Another possibility might be to enable the %.out: % rule only for
> examples and disable it for tests and everything else work? We don't
> need to create .out files anywhere else, do we?
>
> Martin
>
>
--
View this message in context: http://www.nabble.com/missing-build-line-for-22.locale.codecvt.out-tf4385887.html#a13828127
Sent from the stdcxx-dev mailing list archive at Nabble.com.
Re: missing build line for 22.locale.codecvt.out
Posted by Martin Sebor <se...@roguewave.com>.
Travis Vitek wrote:
[...]
> So now we are pretty sure we know what is happening. All target names that
> end in .out will match to the pattern rule for generating .out files first.
> The question is how to fix it. Here are the options I see.
Thanks for the analysis!
>
> 1. rename the source file so the generated executable will not end in
> .out
> 2. change the .out rule to generate output files with some other
> extension
> 3. create an rule that is a better match than %.out so that rule is
> selected for 22.locale.codecvt.out
> 4. create a new makefile that includes the original GNUmakefile.tst, but
> defines the more explicit rule mentioned in 3
>
> I dislike option 3 the most,
Between 2 and 3 I think I actually like 3 better. It seems general
enough to eliminate all ill-effects of the overly generic %.out: %
rule. And it's very simple (at least in my tests it was):
%.foo: %.foo.c
touch $@
> and from the sound of it you won't want to use
> option 1. So how does option 2 sound?
Another possibility might be to enable the %.out: % rule only for
examples and disable it for tests and everything else work? We don't
need to create .out files anywhere else, do we?
Martin
Re: missing build line for 22.locale.codecvt.out
Posted by Travis Vitek <vi...@roguewave.com>.
Martin Sebor wrote:
>
> Ugh. I really don't want to hack around it by renaming the test.
> If it bothers you that much why don't you take the time to figure
> out what's behind the make behavior we don't understand? We'll
> all learn something :)
>
No problem. Here is a simple makefile testcase...
[vitek@robot vitek]$ cat GNUmakefile
%.c:
touch $@
%: %.c
touch $@
%.out: %
touch $@
[vitek@robot vitek]$ gmake a.c b.out.c
touch a.c
touch b.out.c
[vitek@robot vitek]$ gmake a
touch a
[vitek@robot vitek]$ gmake b.out
gmake: *** No rule to make target `b.out'. Stop.
[vitek@robot vitek]$
You're probably asking why this happens. Well, here is the output of `gmake
-d a'...
Updating goal targets....
Considering target file `a'.
File `a' does not exist.
Looking for an implicit rule for `a'.
Trying pattern rule with stem `a'.
Trying implicit prerequisite `a.c'.
Found an implicit rule for `a'.
Considering target file `a.c'.
Looking for an implicit rule for `a.c'.
Trying pattern rule with stem `a'.
Found an implicit rule for `a.c'.
Finished prerequisites of target file `a.c'.
No need to remake target `a.c'.
Finished prerequisites of target file `a'.
Must remake target `a'.
touch a
Putting child 0x00535ff0 (a) PID 27247 on the chain.
Live child 0x00535ff0 (a) PID 27247
Got a SIGCHLD; 1 unreaped children.
Reaping winning child 0x00535ff0 PID 27247
Removing child 0x00535ff0 PID 27247 from chain.
Successfully remade target file `a'.
We can see that gmake looks for `a', and finds the rule with prerequisite
`a.c'. The target `a.c' is evaluated and gmake discovers that it is up to
date, so it avoids remaking `a.c'. Now that the prerequisites exist, `a' is
generated.
Now look at the output of `gmake -d b.out'...
Considering target file `b.out'.
File `b.out' does not exist.
Looking for an implicit rule for `b.out'.
Trying pattern rule with stem `b'.
Trying implicit prerequisite `b'.
Trying pattern rule with stem `b.out'.
Trying implicit prerequisite `b.out,v'.
Trying pattern rule with stem `b.out'.
Trying implicit prerequisite `RCS/b.out,v'.
Trying pattern rule with stem `b.out'.
Trying implicit prerequisite `RCS/b.out'.
Trying pattern rule with stem `b.out'.
Trying implicit prerequisite `s.b.out'.
Trying pattern rule with stem `b.out'.
Trying implicit prerequisite `SCCS/s.b.out'.
Trying pattern rule with stem `b'.
Trying implicit prerequisite `b'.
Looking for a rule with intermediate file `b'.
Avoiding implicit rule recursion.
Trying pattern rule with stem `b'.
Trying implicit prerequisite `b,v'.
Trying pattern rule with stem `b'.
Trying implicit prerequisite `RCS/b,v'.
Trying pattern rule with stem `b'.
Trying implicit prerequisite `RCS/b'.
Trying pattern rule with stem `b'.
Trying implicit prerequisite `s.b'.
Trying pattern rule with stem `b'.
Trying implicit prerequisite `SCCS/s.b'.
No implicit rule found for `b.out'.
Finished prerequisites of target file `b.out'.
Must remake target `b.out'.
gmake: *** No rule to make target `b.out'. Stop.
when trying to match the target `b.out', make sees the pattern rule to
generate `b.out' from `b' [%.out: %]. There is also the pattern rule to
generate `b.out' from `b.c' [%: %.c]. According to step 3 of the make
implicit rule search algorithm
[http://www.gnu.org/software/make/manual/html_node/Implicit-Rule-Search.html#Implicit-Rule-Search],
the latter of these rules will be discarded because the former is
essentially a 'better match'.
So this leaves gmake trying to generate `b.out' from `b'. According to the
docs, it attempts to find if the prerequisite `b' should exist or not. If
`b' is an explicit prerequisite for `b.out' or `b' is mentioned as a target,
then `b' should exist, otherwise it should not. I'm under the impression
that the pattern rule to generate `b' is not considered, so it is done. The
rule to make `b.out' from `b' cannot build `b.out', so it isn't a valid rule
to make `b.out' and you get the error message that we see above.
A simple makefile can be used to verify that this is correct.
[vitek@robot t]$ cat GNUmakefile
%:
touch $@
%.foo: %.bar
touch $@
[vitek@robot t]$ gmake a.foo
gmake: *** No rule to make target `a.foo'. Stop.
So now we are pretty sure we know what is happening. All target names that
end in .out will match to the pattern rule for generating .out files first.
The question is how to fix it. Here are the options I see.
1. rename the source file so the generated executable will not end in
.out
2. change the .out rule to generate output files with some other
extension
3. create an rule that is a better match than %.out so that rule is
selected for 22.locale.codecvt.out
4. create a new makefile that includes the original GNUmakefile.tst, but
defines the more explicit rule mentioned in 3
I dislike option 3 the most, and from the sound of it you won't want to use
option 1. So how does option 2 sound?
Travis
--
View this message in context: http://www.nabble.com/missing-build-line-for-22.locale.codecvt.out-tf4385887.html#a13659042
Sent from the stdcxx-dev mailing list archive at Nabble.com.
Re: missing build line for 22.locale.codecvt.out
Posted by Martin Sebor <se...@roguewave.com>.
Travis Vitek wrote:
>
>
> Martin Sebor wrote:
>> It looks like the implicit rules are somehow causing it. Passing
>> -r to make to disable them make it work:
>>
>> $ rm -f 22.locale.codecvt.out.o 22.locale.codecvt.out; \
>> make 22.locale.codecvt.out && ls -l 22.locale.codecvt.out \
>> || rm -f 22.locale.codecvt.out.o 22.locale.codecvt.out; \
>> make -r 22.locale.codecvt.out && ls -l 22.locale.codecvt.out
>> make: Nothing to be done for `22.locale.codecvt.out'.
>> 22.locale.codecvt.out: No such file or directory
>> gcc -c -I/build/sebor/stdcxx/include/ansi -D_RWSTDDEBUG
>> -D_RWSTD_USE_CONFIG -I/build/sebor/stdcxx/include
>> -I/build/sebor/stdcxx-gcc-4.1.0-11s/include
>> -I/build/sebor/stdcxx/../rwtest -I/build/sebor/stdcxx/../rwtest/include
>> -I/build/sebor/stdcxx/tests/include -pedantic -nostdinc++ -g -W -Wall
>> -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long
>> /build/sebor/stdcxx/tests/localization/22.locale.codecvt.out.cpp
>> gcc 22.locale.codecvt.out.o -o 22.locale.codecvt.out
>> -L/build/sebor/stdcxx-gcc-4.1.0-11s/rwtest -lrwtest11s
>> -L/build/sebor/stdcxx-gcc-4.1.0-11s/lib -lstd11s -lsupc++ -lm
>> rm 22.locale.codecvt.out.o
>> -rwxr-xr-x 1 sebor devel 3032001 Mar 12 12:31
>> 22.locale.codecvt.out
>>
>
> Well `gmake -r 22.locale.codecvt.out' doesn't work on AIX with gmake v3.80.
> If I remove the %.out rule from makefile.rules, I can use -r and the problem
> goes away.
I can confirm the same behavior with GNU make 3.81 on Linux.
I don't understand the why -r switch works. This is the output
I get from make -d after disabling the %.out: % rule:
$ ls -l 22.locale.codecvt.* \
|| make -d 22.locale.codecvt.out 2>&1 | tail -n 11 \
&& ls -l 22.locale.codecvt.*
ls: 22.locale.codecvt.*: No such file or directory
No implicit rule found for `22.locale.codecvt.out'.
Considering target file
`/build/sebor/stdcxx-gcc-4.1.2-15S/lib/libstd15S.a'.
Finished prerequisites of target file
`/build/sebor/stdcxx-gcc-4.1.2-15S/lib/libstd15S.a'.
No need to remake target
`/build/sebor/stdcxx-gcc-4.1.2-15S/lib/libstd15S.a'.
Considering target file
`/build/sebor/stdcxx-gcc-4.1.2-15S/rwtest/librwtest15S.a'.
Finished prerequisites of target file
`/build/sebor/stdcxx-gcc-4.1.2-15S/rwtest/librwtest15S.a'.
No need to remake target
`/build/sebor/stdcxx-gcc-4.1.2-15S/rwtest/librwtest15S.a'.
Finished prerequisites of target file `22.locale.codecvt.out'.
Must remake target `22.locale.codecvt.out'.
Successfully remade target file `22.locale.codecvt.out'.
make: Nothing to be done for `22.locale.codecvt.out'.
ls: 22.locale.codecvt.*: No such file or directory
>
> I find this issue particularly annoying because it happens across the board
> and it isn't caused by a compiler bug or even an issue with the code itself.
> If we refuse to rename the test to eliminate this issue, then we should do
> _something_ to eliminate the error. I realize that renaming the test is a
> less than ideal solution, but something is definitely better than nothing.
Ugh. I really don't want to hack around it by renaming the test.
If it bothers you that much why don't you take the time to figure
out what's behind the make behavior we don't understand? We'll
all learn something :)
Martin
Re: missing build line for 22.locale.codecvt.out
Posted by Travis Vitek <vi...@roguewave.com>.
Martin Sebor wrote:
>
> It looks like the implicit rules are somehow causing it. Passing
> -r to make to disable them make it work:
>
> $ rm -f 22.locale.codecvt.out.o 22.locale.codecvt.out; \
> make 22.locale.codecvt.out && ls -l 22.locale.codecvt.out \
> || rm -f 22.locale.codecvt.out.o 22.locale.codecvt.out; \
> make -r 22.locale.codecvt.out && ls -l 22.locale.codecvt.out
> make: Nothing to be done for `22.locale.codecvt.out'.
> 22.locale.codecvt.out: No such file or directory
> gcc -c -I/build/sebor/stdcxx/include/ansi -D_RWSTDDEBUG
> -D_RWSTD_USE_CONFIG -I/build/sebor/stdcxx/include
> -I/build/sebor/stdcxx-gcc-4.1.0-11s/include
> -I/build/sebor/stdcxx/../rwtest -I/build/sebor/stdcxx/../rwtest/include
> -I/build/sebor/stdcxx/tests/include -pedantic -nostdinc++ -g -W -Wall
> -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long
> /build/sebor/stdcxx/tests/localization/22.locale.codecvt.out.cpp
> gcc 22.locale.codecvt.out.o -o 22.locale.codecvt.out
> -L/build/sebor/stdcxx-gcc-4.1.0-11s/rwtest -lrwtest11s
> -L/build/sebor/stdcxx-gcc-4.1.0-11s/lib -lstd11s -lsupc++ -lm
> rm 22.locale.codecvt.out.o
> -rwxr-xr-x 1 sebor devel 3032001 Mar 12 12:31
> 22.locale.codecvt.out
>
Well `gmake -r 22.locale.codecvt.out' doesn't work on AIX with gmake v3.80.
If I remove the %.out rule from makefile.rules, I can use -r and the problem
goes away.
I find this issue particularly annoying because it happens across the board
and it isn't caused by a compiler bug or even an issue with the code itself.
If we refuse to rename the test to eliminate this issue, then we should do
_something_ to eliminate the error. I realize that renaming the test is a
less than ideal solution, but something is definitely better than nothing.
Travis
--
View this message in context: http://www.nabble.com/missing-build-line-for-22.locale.codecvt.out-tf4385887.html#a13638627
Sent from the stdcxx-dev mailing list archive at Nabble.com.
Re: missing build line for 22.locale.codecvt.out
Posted by Martin Sebor <se...@roguewave.com>.
Martin Sebor wrote:
> Andrew Black wrote:
>> Greetings Martin.
>>
>> I would hazard a guess that it has to do with the name of the test and
>> our pattern rules. In particular, the rules reading '%.out: %' and
>> '%: %.cpp'. I suspect that gmake is thinking that the target
>> 22.locale.codecvt.out is dependent on 22.locale.codecvt, rather than
>> 22.locale.codecvt.out.cpp.
>
> Interesting idea. I hadn't thought of the .out pattern rules.
>
> I just tried commenting out the rule and the behavior is the
> same. I think something else is going on. From the output of
> make 22.locale.codecvt.out printvars it looks like
> 22.locale.codecvt.out.cpp is in ALL_FILES and SRCS, and
> 22.locale.codecvt.out.o is in OBJS, but there is no
> 22.locale.codecvt.out.d in DEPS and no 22.locale.codecvt.out
> in TARGET. Very mysterious...
I wonder if the periods in the names of our tests have something
to do with it. We're using the GNU make $basename function which
strips everything including and after the first period from file
names.
[...experimenting...]
It looks like the implicit rules are somehow causing it. Passing
-r to make to disable them make it work:
$ rm -f 22.locale.codecvt.out.o 22.locale.codecvt.out; \
make 22.locale.codecvt.out && ls -l 22.locale.codecvt.out \
|| rm -f 22.locale.codecvt.out.o 22.locale.codecvt.out; \
make -r 22.locale.codecvt.out && ls -l 22.locale.codecvt.out
make: Nothing to be done for `22.locale.codecvt.out'.
22.locale.codecvt.out: No such file or directory
gcc -c -I/build/sebor/stdcxx/include/ansi -D_RWSTDDEBUG
-D_RWSTD_USE_CONFIG -I/build/sebor/stdcxx/include
-I/build/sebor/stdcxx-gcc-4.1.0-11s/include
-I/build/sebor/stdcxx/../rwtest -I/build/sebor/stdcxx/../rwtest/include
-I/build/sebor/stdcxx/tests/include -pedantic -nostdinc++ -g -W -Wall
-Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long
/build/sebor/stdcxx/tests/localization/22.locale.codecvt.out.cpp
gcc 22.locale.codecvt.out.o -o 22.locale.codecvt.out
-L/build/sebor/stdcxx-gcc-4.1.0-11s/rwtest -lrwtest11s
-L/build/sebor/stdcxx-gcc-4.1.0-11s/lib -lstd11s -lsupc++ -lm
rm 22.locale.codecvt.out.o
-rwxr-xr-x 1 sebor devel 3032001 Mar 12 12:31 22.locale.codecvt.out
Martin
Re: missing build line for 22.locale.codecvt.out
Posted by Martin Sebor <se...@roguewave.com>.
Andrew Black wrote:
> Greetings Martin.
>
> I would hazard a guess that it has to do with the name of the test and
> our pattern rules. In particular, the rules reading '%.out: %' and '%:
> %.cpp'. I suspect that gmake is thinking that the target
> 22.locale.codecvt.out is dependent on 22.locale.codecvt, rather than
> 22.locale.codecvt.out.cpp.
Interesting idea. I hadn't thought of the .out pattern rules.
I just tried commenting out the rule and the behavior is the
same. I think something else is going on. From the output of
make 22.locale.codecvt.out printvars it looks like
22.locale.codecvt.out.cpp is in ALL_FILES and SRCS, and
22.locale.codecvt.out.o is in OBJS, but there is no
22.locale.codecvt.out.d in DEPS and no 22.locale.codecvt.out
in TARGET. Very mysterious...
> Perhaps we need to rename this test?
I'd really hate to do that. The .out rules are only necessary
for our examples so we should be able to disable them for tests
but since it doesn't look like it's the problem I'm hoping to
figure out a way how to keep the name and get it to work in
general.
Martin
>
> --Andrew Black
>
> Martin Sebor wrote:
>> I'm trying to figure out why 22.locale.codecvt.out is reported
>> as having failed to compile with Sun C++ 5.8 on Solaris 8 among
>> other compilers but I don't the command line in the log (there
>> is a line that says that dependencies were generated for it but
>> no compilation or link line). Other 22.locale.*.cpp tests are
>> there so I'm stumped why this one would be missing. Andrew, do
>> you have any idea what might have happened to it?
>>
>> http://people.apache.org/~sebor/stdcxx/results/solaris8-sunpro-32b-5.8-8d-log.gz.txt
>>
>>
>> Martin
Re: missing build line for 22.locale.codecvt.out
Posted by Andrew Black <ab...@roguewave.com>.
Greetings Martin.
I would hazard a guess that it has to do with the name of the test and
our pattern rules. In particular, the rules reading '%.out: %' and '%:
%.cpp'. I suspect that gmake is thinking that the target
22.locale.codecvt.out is dependent on 22.locale.codecvt, rather than
22.locale.codecvt.out.cpp. Perhaps we need to rename this test?
--Andrew Black
Martin Sebor wrote:
> I'm trying to figure out why 22.locale.codecvt.out is reported
> as having failed to compile with Sun C++ 5.8 on Solaris 8 among
> other compilers but I don't the command line in the log (there
> is a line that says that dependencies were generated for it but
> no compilation or link line). Other 22.locale.*.cpp tests are
> there so I'm stumped why this one would be missing. Andrew, do
> you have any idea what might have happened to it?
>
> http://people.apache.org/~sebor/stdcxx/results/solaris8-sunpro-32b-5.8-8d-log.gz.txt
>
>
> Martin