I am trying to build a 3rd party open source project using MinGW. One of the dependencies is wxWidgets. When I try to make the project from MSYS I get a compiler error from
/MinGW/msys/1.0/local/include/wx-2.8/wx/msw/private.h
In function 'COLORREF wxColourToRGB(const wxColour&)':
error: cannot convert 'RGB' to 'COLORREF {aka long unsigned int}' in return
This is somewhat odd given that, according to Microsoft the RGB macro returns a COLORREF.
In fact, looking in H:\MinGW\include I find wingdi.h with the following code
#define RGB(r,g,b) ((COLORREF)((BYTE)(r)|((BYTE)(g) << 8)|((BYTE)(b) << 16)))
What sort of thing would cause this error? Is there some way I can check to see if COLORREF and RGB are being included from wingdi.h and not somewhere else? Is that even worth checking?
Specifications
GCC version 4.7.2
wxWidgets version 2.8.12
(I'm new to C++ and MinGW specifically but generally computer and programming literate)
Try preprocessing the source with -E and check what is actually happening with the macro expansion or whether something is redefining the macro.
The preprocessed source undoubtedly will be very lengthy after #includeing its header dependencies. Your text editor's search function, grep and findstr are your friends here.
Related
I'm using CLion and I need to get some data from the Kinect, but when it comes to #include <Kinect.h> I get the following error:
In file included from C:/PROGRA~1/MICROS~2/Kinect/V2D305~1.0_1/inc/Kinect.h:547,
from C:\Users\fredd\CLionProjects\3D_avatar\main.cpp:19:
C:/PROGRA~1/MICROS~2/Kinect/V2D305~1.0_1/inc/Kinect.INPC.h:109:13: error: '_Out_' has not been declared
_Out_ WAITABLE_HANDLE *waitableHandle) = 0;
^~~~~
And an endless list of similar errors. I think I miss some kind of library that defines this data format, but I really don't know (if that's the problem) which one. I've searched all over the internet and googled for about 3 hours without any result.
How can I solve the error?
Also, is there a better way to make Kinect works with CLion?
I've managed to understand what was going on: MinGW couldn't compile SAL annotations, so I had to switch compiler to MSVC, bundled with Visual Studio. Also, I had to link MatLab with my project since there's no library (except for libfreenect2, which has driven me mad) that can handle a Kinect v2.
Trying to build Tink library (https://github.com/google/tink) with Bazel. Bazel installed, gcc version 7.2.0, Windows 10 x64. Visual C++ 2017.
At first, there were errors like "C++ compilation of rule '#boringssl//:crypto' failed" - I commented these lines (with compilation flags I think) in boringssl/BUILD file (sections boringssl_copts, boringssl_copts_c11) and they disappeared.
But after that, bazel said, that error is in errors.h file (https://github.com/google/tink/blob/master/cc/util/errors.h)
// from #include "absl/base/port.h"
#define PRINTF_ATTRIBUTE(string_index, first_to_check) \
__attribute__((__format__ (__printf__, string_index, first_to_check)))
// Constructs a Status object given a printf-style va list.
crypto::tink::util::Status ToStatusF(
crypto::tink::util::error::Code code, const char* format, ...)
PRINTF_ATTRIBUTE(2, 3);
} // namespace tink
} // namespace crypto
enter code here
Error C3646: unknown override specifier on line 32 (line with "PRINTF_ATTRIBUTE(2, 3);"). The most frightening thing is that in another files the same code (defining same attribute) is working.
There are another errors in this file, but mentioned is the first (and another are about the same line, so they are consequences of the first I guess).
I'm nearly a total newbie in cpp, but only cpp should be used, not java-version of library.
Thank you for your help, and sorry for possible misformatting and broken english - this is my first question here.
Unfortunately, we don't support Windows for now. It's something that we plan to support next year, please see our feature roadmap.
I need to work on png pictures for a school project using c++. I found png++ which seems pretty easy to use but I had some really hard time setting up everything to make it work (which it doesn't). I used Cygwin to properly install zlib and libpng. I properly included the png++ headers in my project (I'm using Eclipse). Here are some things that are not properly working:
If I try this line of code (as seen here ):
image img(1024,768);
I get this error after compiling on eclipse:
#error Byte-order could not be detected.
I read this answer here, but the solution is not working for me (I'm on windows 8 64 bit), and I get this other error (which is my main problem because Byte-order can be "brutally" fixed):
missing template arguments before 'img'
But even if I type a valid template argument (like < png::rgb_pixel> < png::rgba_pixel > < png::gray_pixel > < png::ga_pixel >) it says it's invalid.
I'm clearly not an expert on this and I wouldn't know what else to try. Any help would be much appreciated. If you need more info write a comment and I'll provide.
For the template arguments, I think that is actually just an Eclipse issue, it should have compiled fine. But in order to get rid of the Eclipse errors, you can see my answer here: https://stackoverflow.com/a/28400902/583620.
For the byte-order problem an easy way to solve this is to just go into the png++ header folder location (probably under /usr/local/include), open config.hpp, and put
#define _WIN32
before the // Endianness test comment. That should do it. Alternatively you can try what was mentioned in the answer you posted earlier and change _WIN32 to WIN32 although in my case WIN32 was not defined either so it was quicker to just define _WIN32.
I'm trying to compile a UTF-16BE C++ source file in g++ with -finput-charset compiler option but I'm always getting a bunch of errors. More details follow.
My environment(in CentOS Linux):
g++: 4.1.2
iconv: 2.5
Linux language(in Terminal): LANG="en_US.UTF-8"
My sample source file(stored in UTF-16BE encoding):
// main.cpp:
#include <iostream>
int main()
{
std::cout << "Hello, UTF-16" << std::endl;
return 0;
}
My steps:
I read the manual of g++ about the -finput-charset option. The g++ manual says:
-finput-charset=charset
Set the input character set, used for translation from the character set of the input file to the source character set used by
GCC. If the locale does not specify, or GCC cannot get this
information from the locale, the default is UTF-8. This can be
overridden by either the locale or this command line option.
Currently the command line option takes precedence if there’s a
conflict. charset can be any encoding supported by the system’s
"iconv" library routine.
Thus I entered the command as follows:
g++ -finput-charset=UTF-16BE main.cpp
and I got these errors:
In file included from main.cpp:1:
/usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/iostream:1:
error: stray ‘\342’ in program
/usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/iostream:1:
error: stray ‘\274’ in program
...(repeatedly, A LOT, around 4000+)...
/usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/iostream:1:
error: stray ‘\257’ in program
main.cpp: In function ‘int main()’:
main.cpp:5: error: ‘cout’ is not a member of ‘std’
main.cpp:5: error: ‘endl’ is not a member of ‘std’
The manual text suggests that the charset can be any encoding supported by 'iconv' routine, thus I guessed the compilation errors might be caused by my iconv library. I then tested the iconv:
iconv --from-code=UTF-16BE --to-code=UTF-8 --output=main_utf8.cpp main.cpp
A "main_utf8.cpp" file is generated as expected. I then tried to compile it:
g++ -finput-charset=UTF-8 main_utf8.cpp
Note that I specified the input-charset explicitly to see if I did anything wrong, but this time a "a.out" was generated without any errors. When I ran it, it could produce the correct output.
Finally...
I couldn't figure out where I did wrong. I searched in the web trying to find out some examples for this compiler option but I couldn't.
Please advise! Thanks!
Further edits:
Thanks, guys! Your replies are quick! Some updates:
When I said "UTF-16" I meant "UTF-16 + BOM". In fact I used UTF-16BE. I have updated the text above.
Some answers say the errors are caused by the non-UTF-16 header files. Here are my thoughts if this is the case: We'll always include some standard header files when writing a C/C++ project, right? Such as stdio.h or iostream. If the G++ compiler only deals with the encoding of the source files created by us but never with the source files in the standard library, then what does this -finput-charset option exist for??
Final edit:
At last, my solution is like this:
At the beginning, I changed the encoding of my source files to GB2312, as "Mr Lister" said below. This worked fine for a while, but later I found it not suitable for my situation because most of the other parts in the system still use UTF-8 for communication and interfaces, thus I must convert the encoding in many places... Not only an overhead of my work, it may also result in some performance decrease in my program.
Later I tried to convert all my source files to UTF-8 + BOM. In this way, Visual Studio in Windows could compile them happily but GCC in Linux would complain. I then wrote a shell script to remove the BOM, and before I want to compile my code with GCC, I run this script first.
Luckily, I don't have to build the code in Linux manually because TeamCity the continuous integration tool is used in my project to generate the build automatically. I could change the build steps in TeamCity to help me run this script before the daily build starts.
With this UTF-8 + BOM + script method, I decide not to edit my source code in Linux, because if I want to do so, I must make sure my code could build successfully before I commit it, which means I must run the script to remove the BOM before I build the code, which means SVN would report EVERY file is modified(BOM removed) thus make it very easy to mistakenly commit a wrong file. To solve this problem, I wrote another shell script to add the BOM back to the source files. Though I still don't edit my code very often in Linux, but when I really need to, I don't have to face the terribly long change list in the commit dialog.
Encoding Blues
You cannot use UTF-16 for source code files; because the header you are including, <iostream>, is not UTF-16-encoded. As #include includes the files verbatim, this means that you suddenly have an UTF-16-encoded file with a large chunk (approximately 4k, apparently) of invalid data.
There is almost no good reason to ever use UTF-16 for anything, so this is just as well.
Edit: Regarding problems with encoding support: The OSes themselves are not responsible for providing encoding support, this comes down to the compilers used.
g++ on Windows supports absolutely all of the same encodings as g++ on Linux, because it's the same program, unless whatever version of g++ you are using on Windows relies on a deeply broken iconv library.
Inspect your toolchain and ensure that all your tools are in working order.
As an alternative; don't use Chinese in the source files, but write them in English, using English-language literals, or simple TOKEN_STYLE_PLACEHOLDERs, using l10n and i18n to replace these in the running executable.
Threedit: -finput-charset is almost certainly a holdover from the days of codepages and other nonsense of the kind; however; an ISO-8859-n file will almost always be compatible with UTF-8 standard headers, however, see the reedit below.
Reedit: For next time; remember a simple mantra: "N'DUUH!"; "Never Don't Use UTF-8!"
I18N
A common solution to this kind of problem is to remove the problem entirely, by way of, for instance, gettext.
When using gettext, you usually end up with a function loc(char *) that abstracts away most of the translation tool specific code. So, instead of
#include <iostream>
int main () {
std::cout << "瓜田李下" << std::endl;
}
you would have
#include <iostream>
#include "translation.h"
int main () {
std::cout << loc("DEEPER_MEANING") << std::endl;
}
and, in zh.po:
msgid DEEPER_MEANING
msgstr "瓜田李下"
Of course, you could also then have a en.po:
msgid DEEPER_MEANING
msgstr "Still waters run deep"
This can be expanded upon, and the gettext package has tools for expansion of strings with variables and such, or you could use printf, to account for different grammars.
The Third Option
Instead of having to deal with multiple compilers with different requirements for file encodings, file endings, byte order marks, and other problems of the kind; it is possible to cross-compile using MinGW or similar tools.
This option requires some setup, but may very well reduce future overhead and headaches.
The error message says the problem is in the include files, so I presume what happens is that the include files are normal UTF-8, but the compiler wants to treat them as UTF-16 because of the compiler switch.
So I'm afraid the solution is to always convert the source to UTF-8 first; perhaps in the makefile. Or to find a solution that doesn't contain include files in other encodings...
Edit:
Maybe a GB encoding would work, if and only if none of the system source files contain any non-ASCII characters. Then you could tell the compiler they were GB encoded without problem.
This does not work because the compiler will also try to read the header files as UTF-16, which they are not.
UTF-16 is not an encoding for bytes. It's an encoding where your basic storage unit is 16 bits large.
When you want to store UTF-16 in a byte sequence you have to choose between UTF-16BE and UTF-16LE.
I'm currently writing a very simple game engine for an assignment and to make the code a lot nicer I've decided to use a vector math library. One of my lecturers showed me the Sony Vector Math library which is used in the Bullet Physics engine and it's great as far as I can see. I've got it working on Linux nicely but I'm having problems porting it to work on OS X (intel, Snow Leopard). I have included the files correctly in my project but the C++ version of the library doesn't seem to compile. I can get the C version of the library working but it has a fairly nasty API compared to the C++ version and the whole reason of using this library was to neaten the code in the first place.
http://glosx.blogspot.com/2008/07/sony-vector-math-library.html
This blog post that I've stumbled upon seems to suggest something's up with the compiler? It's fairly short so I couldn't take a lot of information from it.
When I try to use the C++ version I get the following errors (expanded view of each error):
/usr/include/vectormath/cpp/../SSE/cpp/vectormath_aos.h:156:0
/usr/include/vectormath/cpp/../SSE/cpp/vectormath_aos.h:156:
error: '__forceinline' does not name a type
second error:
/Developer/apps/gl test/main.cpp:7:0 In file included from /Developer/apps/gl test/main.cpp
/usr/include/vectormath/cpp/vectormath_aos.h:38:0 In file included from
/usr/include/vectormath/cpp/vectormath_aos.h
/usr/include/vectormath/cpp/../SSE/cpp/vectormath_aos.h:330:0 In file included from
/usr/include/vectormath/cpp/../SSE/cpp/vectormath_aos.h
/usr/include/vectormath/cpp/../SSE/cpp/vecidx_aos.h:45:0 Expected constructor, destructor,
or type conversion before '(' token in /usr/include/vectormath/cpp/../SSE/cpp/vecidx_aos.h
Finally two errors at the end of the main.cpp file:
Expected '}' at the end of input
Expected '}' at the end of input
I've Googled my heart out but I can't seem to find any answers or anything to point me in the right direction so any help will be greatly received.
Thanks,
__forceinline is a reserved word that is supported by only a couple compilers. Clearly, your compiler does not support the __forceinline keyword and the code in question is non-portable.
A very poor workaround would be to pass a new define to your compiler that gives the keyword the correct meaning. E.g.: -D__forceinline=inline or -D__forceinline=__attribute__((always_inline)) (Thanks Paul!)
The SSE version was assumed to be only for Microsoft Visual Studio. For other platforms (Mac etc) you can use the scalar version.
Bullet\Extras\vectormathlibrary\include\vectormath\scalar\cpp
It looks like someone's fixed this up and posted a patched version in response to this very issue.
Now GCC compliant.
Which compiler are you using on OS X ? There are 4 to choose from in the standard Xcode 3.2 install and the default is gcc 4.2. You might be better off trying gcc 4.0.