1

I'm using Code::Blocks with Cygwin (GCC 5.4.0).

My code compiles and runs fine until I:

#include <iomanip> (trying to get access to cout << setprecision(int) ).

iomanip generates these errors even without a call to setprecision.

A short sample (it spits out 50 errors, all similar):

/usr/bin/locale:1:1: error: stray '\220' in program
 MZ       ÿÿ  ¸       @                                   €   º ´ Í!¸LÍ!This program cannot be run in DOS mode.
 ^
/usr/bin/locale:1:1: error: stray '\3' in program
/usr/bin/locale:1:1: error: stray '\4' in program
/usr/bin/locale:1:1: error: stray '\377' in program
/usr/bin/locale:1:1: error: stray '\377' in program
/usr/bin/locale:1:1: error: stray '\270' in program
/usr/bin/locale:1:25: error: stray '@' in program

From the searches I've done, it's obvious that the compiler is unable to interpret some kind of UTF-8 characters. I tracked down that iomanip thinks it's

#include <locale>

from the same directory. But I have retyped the code by hand (it's short) in a new file and replaced it with no change, so I'm at a loss since the error chain always starts at locale line 1 (same numbers on strays) which it reaches from my line 6 #include iomanip -> iomanip line 43 #include locale.

From yet more searches, I went to the trouble of g++ -E. Compiling that code works fine, but it's an entirely obnoxious interim step.

I'm also concerned that this error could pop up from including other headers that access a contaminated file, not necessarily just iomanip, so I'd like to be able to track things down with regularity. (Unless someone wants to blame the mirror I used to install Cygwin?)

Note

I'm aware that setprecision() is a convenience, so using other methods will likely be my workaround. My only concern is tracking down the source of the error.

The make command line that I found:

g++.exe -Wall -g -Winit-self -Wredundant-decls -Wfloat-equal -Winline -Wunreachable-code -Wmissing-include-dirs -Wswitch-enum -Wswitch-default -Wzero-as-null-pointer-constant -Wmain -std=c++0x -IC:/cygwin64 -IC:/cygwin64/bin -IC:/cygwin64/lib/gcc/x86_64-pc-cygwin/5.4.0/include/c++/bits -IC:/cygwin64/lib/gcc/x86_64-pc-cygwin/5.4.0/include/c++ -IC:/cygwin64/lib/gcc/x86_64-pc-cygwin/5.4.0/include/c++/x86_64-pc-cygwin/bits -c "C:/Users/Matthew/Desktop/Example/example iomanip/ex_iomanip.cpp" -o obj/Debug/ex_iomanip.o

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
The Poopsmith
  • 11
  • 3
  • Please post a [MCVE](http://stackoverflow.com/help/mcve). Make the shortest possible program that causes the error. (Maybe it is just a one-line program, `#include ` ? ). Verify that the error occurs from your program and then copy-paste the entire program into your question here. – M.M May 12 '17 at 09:10
  • Also show the commandline you use to compile. (If you use the codeblocks IDE you will see this in one of the output windows). At a wild guess, maybe you are putting `/usr/bin` into the list of include-file search directories when you meant to put it in the library search? – M.M May 12 '17 at 09:11
  • Here is the make command line that I found `g++.exe -Wall -g -Winit-self -Wredundant-decls -Wfloat-equal -Winline -Wunreachable-code -Wmissing-include-dirs -Wswitch-enum -Wswitch-default -Wzero-as-null-pointer-constant -Wmain -std=c++0x -IC:/cygwin64 -IC:/cygwin64/bin -IC:/cygwin64/lib/gcc/x86_64-pc-cygwin/5.4.0/include/c++/bits -IC:/cygwin64/lib/gcc/x86_64-pc-cygwin/5.4.0/include/c++ -IC:/cygwin64/lib/gcc/x86_64-pc-cygwin/5.4.0/include/c++/x86_64-pc-cygwin/bits -c "C:/Users/Matthew/Desktop/Example/example iomanip/ex_iomanip.cpp" -o obj/Debug/ex_iomanip.o` – The Poopsmith May 12 '17 at 16:25
  • I confirmed that the MCVE is indeed `#include `, as it's already included above, that seems sufficient, unless I need to make that more clear. I will poke around my settings to see if -IC:/cygwin64/bin should not be there, thanks. – The Poopsmith May 12 '17 at 16:30
  • @M.M Removing the paths worked. I think had added some things when trying to get cygwin working initially or when it was generating file not found errors. I will watch this more closely in the future. Thank you. – The Poopsmith May 12 '17 at 16:42
  • 1
    For me, I had the line `export CPATH="somethinguseful:$PATH"`, notice that the last environmetn variable that gets expanded is `$PATH` and not `$CPATH`. Tooke me a good 30 mins to find... – hmaarrfk Aug 06 '18 at 18:31
  • Re *"some kind of UTF-8 characters"*: No, the stray numbers from those would all be equal or greater than 200 (octal), 128 (decimal). It is some kind of binary data, e.g., the build system/make has imported the compiled library, not the header file. [Here is an example](https://stackoverflow.com/questions/48547750/cannot-use-sourcecpp-from-a-file#comment134363065_48547750). – Peter Mortensen May 07 '23 at 01:06
  • @The Poopsmith: Re "Removing the paths worked": Hello, [DenverCoder9](https://www.explainxkcd.com/wiki/index.php/979:_Wisdom_of_the_Ancients). What exactly did you do? – Peter Mortensen May 07 '23 at 03:03

0 Answers0