Sun 04 Mar 2012 05:10:45 PM UTC, comment #12:
I updated the summary line. I have no idea what's going on but from what I see it's not a problem in make so I'm closing this bug.
|
Thu 21 Oct 2010 04:00:55 PM UTC, comment #11:
> I just thought a more appropriate name might help others in my position
And it might well do. (I too can't see how to change the name.) I just feared that you were hoping that someone would look at a gcc issue here.
> could you point me towards the right bug database for g++ and cc1plus?
http://gcc.gnu.org/bugzilla/ perhaps, although, if it's MinGW-specific, I fear they won't care too much and might even turn you away. http://www.mingw.org/Reporting_Bugs has some suggestions and even invites mailing list postings in a friendly fashion.
|
Thu 21 Oct 2010 03:46:50 PM UTC, comment #10:
Thanks Martin. Fair enough, I just thought a more appropriate name might help others in my position (even if it's marked "not a make bug" or whatever).
Apparently my searching has led me to the wrong place, so could you point me towards the right bug database for g++ and cc1plus?
|
Thu 21 Oct 2010 03:40:50 PM UTC, comment #9:
Drilling deeper into this, I see cc1plus.exe is silently giving me errors even though I specified "-v".
"
cc1plus.exe: error: argument to "-gdwarf-" should be a non-negative integer
"
Hmm. Must be referring to "-gdwarf-2", which is a perfectly valid compiler option. Looks like it's not chopping up the command line properly. Also we have:
"
C:\Users\buildbot\Reu2\bin\bga120\build\Reu2\SmallTestLib\src\SmallTestLib.cc:1:
0: error: bad value (i686-auxbase-strip) for -march= switch
"
Now, what on earth is that all about? I haven't specified "-march". Here it is though, in the arguments passed to cc1plus, "-march=i686".
So g++.exe and cc1plus.exe are broken? Humm. It's possible I have a bad MinGW install. I did update it fairly recently. I'll take the "nuke it from orbit" option and reinstall the whole MinGW package, see if that fixes things.
|
Thu 21 Oct 2010 03:34:34 PM UTC, comment #8:
If your bug isn't in make, then it doesn't belong in make's bug database, under any name.
|
Thu 21 Oct 2010 02:59:29 PM UTC, comment #7:
Thanks Paul. I thought make might be managing intermediate files but you say no. Ok, that's progress.
I'm downloading make-3.82-3-mingw32-bin.tar.lzma now, though I believe it will be fruitless. I'll try something else in the meantime.
Seems to me there are only three players here: make, cc1plus and as, and we've just ruled out make. My next suspect is cc1plus.exe. Would you agree that cc1plus is likely the culprit?
Perhaps the name of the bug should be changed to "something deletes intermediate file prematurely". I don't see a button to do that. Can you do it?
|
Thu 21 Oct 2010 02:26:30 PM UTC, comment #6:
Nothing I've seen so far indicates that this is a bug in make. Make has no visibility into, or even concept of, intermediate files created by your compiler, and it's certainly not going to be deleting them. From what I've seen it's your compiler that's doing the creating AND the deleting, not make, so I don't see how this is a make bug.
Have you tried this with the latest version of GNU make (3.82)?
|
Thu 21 Oct 2010 02:12:46 PM UTC, comment #5:
Is it possible to change the name of the bug to "MinGW make deletes intermediate file prematurely" or something similar, please? The inaccurate bug name might be putting people off.
|
Tue 19 Oct 2010 08:41:04 AM UTC, comment #4:
I think this is a make timing issue. It looks like the file is created and then deleted before as is invoked. Why would this happen?
It seems cc1plus doesn't have any more verbosity options than "-v". That might be a moot point though, since here is a Filemon log of the make run, filtered to "C:\tempdir\*.s", seemingly showing that cc1plus completes long before the file is deleted:
https://dreamtrack.dnsalias.com/downloads/make1.log
Could it be a delay starting as? Does make depend on split-nanosecond timing?
|
Mon 18 Oct 2010 01:33:53 PM UTC, comment #3:
Thanks Eli. From my make output, make is already passing -v to cc1plus. It doesn't mention anything about not writing the file (or writing it and then deleting it).
I see from this:
COLLECT_GCC_OPTIONS='-v' '-DSmallTestLib_EXPORTS' '-Wwrite-strings' '-std=c++0x' '-pedantic-errors' '-pedantic' '-Wall' '-W' '-Weffc++' '-Wmain' '-Wextra' '-DBUILD_DLL' '-s' '-o' 'CMakeFiles\SmallTestLib.dir\src\SmallTestLib.cc.obj' '-c' '-mtune=generic' '-march=i686'
c:/programs/mingw/bin/../libexec/gcc/i686-pc-mingw32/4.5.1/cc1plus.exe -quiet -v -iprefix c:\programs\mingw\bin\../lib/gcc/i686-pc-mingw32/4.5.1/ -DSmallTestLib_EXPORTS -DBUILD_DLL C:\Users\buildbot\Reu2\bin\bga120\build\Reu2\SmallTestLib\src\SmallTestLib.cc -quiet -dumpbase SmallTestLib.cc -mtune=generic -march=i686 -auxbase-strip CMakeFiles\SmallTestLib.dir\src\SmallTestLib.cc.obj -Wwrite-strings -pedantic-errors -pedantic -Wall -W -Weffc++ -Wmain -Wextra -std=c++0x -version -o C:\Users\ARICHA~1\Temp\ccZ6Tt4P.s
that make also passes -quiet (twice in fact), will this prevent cc1plus telling me about the output file? If so, how can I configure make to stop it passing -quiet?
|
Mon 18 Oct 2010 01:12:38 PM UTC, comment #2:
Pass the -v option to gcc (or g++ or cc1plus) to have it provide more information.
But this is no longer a Make issue...
|
Mon 18 Oct 2010 12:22:59 PM UTC, comment #1:
I found the random filename elsewhere in the results file. Looks like cc1plus produces Assembler output in a temp location and then as compiles it into machine code. Ok, so that's how the build system works. Fine.
Invoking cc1plus by hand, I find the Assembler output in the temporary location. So maybe this is a cc1plus problem rather than a make problem. Or is it? I'm confused now.
Is there a way to get more output from cc1plus? I need to find out why the command doesn't produce the Assembler output when called by make. I think it's a make problem because cc1plus works fine when I use Code::Blocks to do the compiling. (Code::Blocks does not use make, it calls cc1plus directly.)
|
Mon 18 Oct 2010 11:58:08 AM UTC, original submission:
Please see http://cmake.org/Bug/view.php?id=11315 . To summarize: from an initial cause of "g++.exe: CreateProcess: No such file or directory", I have narrowed the issue down to MinGW make (32-bit).
It appears make is invoking as.exe, trying to Assemble a non-existent randomly-named temporary file, thus producing the "no such file" error.
C:\Users\buildbot\Reu2\bin\bga120\build\Reu2\cmake>make --version
GNU Make version 3.78.1, by Richard Stallman and Roland McGrath.
Built for Windows32
<snip>
C:\Users\buildbot\Reu2\bin\bga120\build\Reu2\cmake>
A sample of output:
https://dreamtrack.dnsalias.com/downloads/makefile-release.txt
And my simplified makefile:
https://dreamtrack.dnsalias.com/downloads/Makefile.simple
I see 3.78.1 is an old version, so I will try upgrading my make.exe.
|