I know this theme often turns up on stackoverflow, but the case here is different:
The following code compiles with MsVC++ 2013 but not with win32-g++. Is there any way of making it work with both compilers?
#include <iostream>
#include <algorithm>
#include <vector>
using namespace std;
int main()
{
vector<int>my_vector;
for(int i=0; i < 6; i++)
my_vector.push_back(i);
for_each( my_vector.begin(), my_vector.end(), [ ](int n){cout<<n;});
return 0;
}
The errors reported are
||=== stdtest, Debug ===|
D:\dev\CplusPlus\stdtest\main.cpp||In function 'int main()':|
D:\dev\CplusPlus\stdtest\main.cpp|13|warning: lambda expressions only available with -std=c++11 or -std=gnu++11 [enabled by default]|
D:\dev\CplusPlus\stdtest\main.cpp|13|error: no matching function for call to 'for_each(std::vector<int>::iterator, std::vector<int>::iterator, main()::<lambda(int)>)'|
D:\dev\CplusPlus\stdtest\main.cpp|13|note: candidate is:|
c:\program files (x86)\codeblocks\mingw\bin\..\lib\gcc\mingw32\4.7.1\include\c++\bits\stl_algo.h|4436|note: template<class _IIter, class _Funct> _Funct std::for_each(_IIter, _IIter, _Funct)|
D:\dev\CplusPlus\stdtest\main.cpp|13|error: template argument for 'template<class _IIter, class _Funct> _Funct std::for_each(_IIter, _IIter, _Funct)' uses local type 'main()::<lambda(int)>'|
D:\dev\CplusPlus\stdtest\main.cpp|13|error: trying to instantiate 'template<class _IIter, class _Funct> _Funct std::for_each(_IIter, _IIter, _Funct)'|
||=== Build finished: 3 errors, 1 warnings (0 minutes, 0 seconds) ===|
I should add that I am assuming that the C++11 standard is turned on because "enabled by default". In case I am wrong, I am having a hard time finding out how to change the compiler switches from Code::Blocks.
it turns out that I was misled by the statement that -sdd=C++11 was "enabled by default".
I ended up finding a way of turning it on with the Project > Build Options> compiler settings
and then I clicked on the checkbox "have g++ follow the c++11 ISO C++ language settings" checkbox.
For those who are working with QtCreator add the following line to the project file:
QMAKE_CXXFLAGS += -std=c++11
Related
Please check my short code below.
pwrapper.h
#include <stdio.h>
#include <stdarg.h>
extern"C" int mm_printfA(const char *fmt, ...);
extern"C" int mm_printfW(const wchar_t *fmt, ...);
pwrapper.cpp
#include "pwrapper.h"
int mm_printfA(const char *fmt, ...)
{
va_list args;
va_start(args, fmt);
int ret = vprintf(fmt, args);
va_end(args);
return ret;
}
int mm_printfW(const wchar_t *fmt, ...)
{
va_list args;
va_start(args, fmt);
int ret = vwprintf(fmt, args);
va_end(args);
return ret;
}
main.cpp
#include "pwrapper.h"
// cl /MT /D _NO_CRT_STDIO_INLINE main.cpp pwrapper.cpp
void main()
{
mm_printfA("What is %d?\n", 123);
}
#if 0
void usedull()
{
vprintf(NULL, NULL);
vwprintf(NULL, NULL);
}
#endif
For some reason, I need to compile it with _NO_CRT_STDIO_INLINE, like this:
cl /MT /D _NO_CRT_STDIO_INLINE main.cpp pwrapper.cpp
But link stage fails saying unresolved external symbol vwprintf and vprintf .
A very weird workaround I find out is: Enable the usedull() function body -- although never be called, and, link through pwrapper.lib, using bb.bat below:
#setlocal EnableDelayedExpansion
#set CFLAGS=/D _NO_CRT_STDIO_INLINE
cl /nologo /c /MT %CFLAGS% pwrapper.cpp
#if errorlevel 1 exit /b 4
lib /nologo /out:pwrapper.lib pwrapper.obj
#if errorlevel 1 exit /b 4
cl /nologo /c /MT main.cpp
#if errorlevel 1 exit /b 4
link /nologo main.obj pwrapper.lib
#if errorlevel 1 exit /b 4
Well, this really works, but why?
This is not a pleasant workaround, because each exe project needs to include a "useless" usedull() function. So, is there any better way?
I really can't tell why this workaround works, an explanation of it is very welcome.
==== Some Clarification ====
There were two main.cpp in my original post. Let me name them separately for later reference in case someone would bother to answer this weird question.
main.0.cpp refers to the one without usedull().
main.1.cpp refers to the one with usedull().
In this question, I use VC++ headers and libs for application(not for kernel), and
I compile main.0.cpp and main.1.cpp without _NO_CRT_STDIO_INLINE.
I always compile pwrapper.cpp with _NO_CRT_STDIO_INLINE.
Whether having pwrapper.obj go through pwrapper.lib produce the same result in this issue.
In short:
compiling pwrapper.cpp with -D _NO_CRT_STDIO_INLINE tells the compiler you are going to provide your own implementation of vprintf and vwprintf at link time, and
compiling main.cpp without -D _NO_CRT_STDIO_INLINE tells the compiler to include implementations of vprintf and vwprintf which are used at link time to satisfy both the references from usedull and mm_printfA/mm_printfW
so, this particular combination works to resolve all undefined symbols at link time. See below for more discussion however.
Discussion
In stdio.h, vprintf (which I'll focus on, but vwprintf is configured in the same way) is defined like so:
_Check_return_opt_
_CRT_STDIO_INLINE int __CRTDECL vprintf(
_In_z_ _Printf_format_string_ char const* const _Format,
va_list _ArgList
)
#if defined _NO_CRT_STDIO_INLINE
;
#else
{
return _vfprintf_l(stdout, _Format, NULL, _ArgList);
}
#endif
Note that
if _NO_CRT_STDIO_INLINE is defined, this becomes a forward declaration
whereas if it is not defined, the full body is included in the compilation of the including translation unit.
Additionally, in corecrt_stdio_config.h whether _NO_CRT_STDIO_INLINE is defined determines the value of _CRT_STDIO_INLINE; if it is defined, _CRT_STDIO_INLINE is defined as empty, otherwise it is defined as __inline.
Putting these together,
if _NO_CRT_STDIO_INLINE is not defined, these functions will be candidates for inline expansion,
otherwise a separate implementation of that function will need to be provided at link time.
Default Compilation (no /O1, /O2, no _NO_CRT_STDIO_INLINE)
The above works with the specific compile and link invocations you are using, as without optimization the compiler will simply include the function body in the compilation of main.1.obj. You can see this using dumpbin; running dumpbin -symbols main.1.obj | find "| vprintf" prints:
01D 00000000 SECT8 notype () External | vprintf
showing that main.1.obj provides vprintf as an externally available symbol.
Checking pwrapper.obj, we get:
00A 00000000 UNDEF notype () External | vprintf
showing that vprintf is undefined in this object file, and will need to be provided at link time.
Optimisation for Inline Expansion
However, if we change the optimisation option for inline expansion, we get different results. Using even the first level of optimisation (-Ob1, included in -O1 and -O2) like so:
cl -c -Ob1 main.1.cpp
causes the compiler to incorporate the body of vprintf directly into usedull, and remove the separate implementation of vprintf, which can be confirmed using dumpbin. So, as you would now expect, attempting to link main.1.obj and pwrapper.obj together will once again give your original error:
pwrapper.obj : error LNK2019: unresolved external symbol vwprintf referenced in function mm_printfW
pwrapper.obj : error LNK2019: unresolved external symbol vprintf referenced in function mm_printfA
main.exe : fatal error LNK1120: 2 unresolved externals
Multiple Implementations?
So, following on from that it is apparent that compiling both files with -D _NO_CRT_STDIO_INLINE will fail as there will be no implementations of the relevant methods. What about if both are compiled without this definition?
If we check the object files, both have defined symbols for vprintf:
01D 00000000 SECT8 notype () External | vprintf
and:
01A 00000000 SECT7 notype () External | vprintf
which under normal circumstances would result in errors due both to multiple definitions of a symbol and violations of the One Definition Rule. However, when performing inline expansion, the compiler and linker have your back. As per 2:
Rather than expand an inline function defined in a header file, the compiler may create it as a callable function in more than one translation unit. The compiler marks the generated function for the linker to prevent one-definition-rule (ODR) violations.
First question here.
I have some troubles with the XCode Build System, specifically with preprocessor definitions.
I'm trying to define a macro for the objective-c runtime to avoid enforcing the dispatch functions to be cast to an appropriate function pointer type. The usual way to go would be to use #define OBJC_OLD_DISPATCH_PROTOTYPES and then include the header on the next line. Once the header gets included, the macro is already defined and the header is configured accordingly.
But that's where it starts to get weird!
The macro is not recognized at all and the header gets included as if the #define statement was not there so it fails to #define OBJC_OLD_DISPATCH_PROTOTYPES and it gets (re?)defined as 0.
main.c
#include <stdio.h>
#define OBJC_OLD_DISPATCH_PROTOTYPES 1
#include <objc/objc-runtime.h>
int main(int argc, const char * argv[]) {
// From there:
// - Build System: OBJC_OLD_DISPATCH_PROTOTYPES is always 0, except if defined in build settings
// - Clang (only): OBJC_OLD_DISPATCH_PROTOTYPES is 1
printf("%d\n", OBJC_OLD_DISPATCH_PROTOTYPES);
}
The build system acts as expected when the preprocessor macro is defined in the project build settings under the "Apple Clang - Preprocessing" section. It defines the global macro using the -D parameter of clang making it available to any files used by the project.
However, source code compiles correctly when I use clang from a terminal using clang main.c.
Could someone tell me what I need to configure for the build system to behave normally?
It gives a warning when building with Xcode IDE:
Ambiguous expansion of macro 'OBJC_OLD_DISPATCH_PROTOTYPES'
and the output is indeed 0 using Xcode directly, but 1 with clang main.c. The difference is that Xcode uses clang with enabled modules by default: You get the same warning on the command line if you enable modules there:
clang -fmodules main.c
Solution
In Xcode, select the target, go to the "Build Settings" tab and in the "Apple Clang - Language - Modules" section, switch the "Enable Modules (C and Objective-C)" entry to 'NO':
Then you get the expected result in both cases, regardless of whether you use Xcode or Clang on the command line.
Explanation:
If you use modules the following happens:
instead of the preprocessor including the text and compiling the result, a binary representation of the module is used
modules are (independently) precompiled, i.e. they use the definitions from the time the module was precompiled
consequently, preprocess definitions from the code before the include/import statement have no effect on the module (nor on other imported modules).
if modules are enabled, not only #imports are affected, but also #includes are translated into module imports under the hood
So you have a contradictory definitions for the OBJC_OLD_DISPATCH_PROTOTYPES.
The precompiled module uses a 0 for OBJC_OLD_DISPATCH_PROTOTYPES and you redefine it as 1.
BTW: if you use
#define OBJC_OLD_DISPATCH_PROTOTYPES 0
then you use the same definition that the precompiled module is using and therefore there is no warning about an ambiguous expansion of the macro even if modules are enabled.
Without enabled modules, the preprocessor includes the text, compiles the result and returns the expected result, i.e. in objc.h the desired typedef are used.
After compiling an application with clang 3.6 using -fsanitize=undefined,
I'm trying to start the instrumented program while using a suppression file to ignore some of the errors:
UBSAN_OPTIONS="suppressions=ubsan.supp" ./app.exe
The suppression file ubsan.supp contains:
signed-integer-overflow:example.c
This leads to an error message:
UndefinedBehaviorSanitizer: failed to parse suppressions
The same occurs with a gcc 4.9 build.
The only documentation I can find is http://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html, which is for clang 3.9, while I use 3.6 (which doesn't have documentation for ubsan included).
Can anyone provide working examples for ubsan suppression files, that work in clang 3.6?
Edit: By browsing the source code of ubsan, I found that the only valid suppression type might be "vptr_check" - dunno which version I was looking at though.
Can anyone confirm that in clang 3.9 more suppression types are available?
I didn't spend the time to find out exactly which suppressions were available in clang-3.6, but it appears that in clang-3.7 only vptr_check is available as a suppression. Starting in clang-3.8, the suppressions list is defined to be the list of checks, plus vptr_check.
In clang-3.9 the checks available are:
"undefined"
"null"
"misaligned-pointer-use"
"alignment"
"object-size"
"signed-integer-overflow"
"unsigned-integer-overflow"
"integer-divide-by-zero"
"float-divide-by-zero"
"shift-base"
"shift-exponent"
"bounds"
"unreachable"
"return"
"vla-bound"
"float-cast-overflow"
"bool"
"enum"
"function"
"returns-nonnull-attribute"
"nonnull-attribute"
"vptr"
"cfi"
"vptr_check"
I'd tried it by creating three files, compile.sh, main.cpp and suppressions.supp as shown below. The unsigned-integer-overflow is not a part of undefined that's why it needs to be included specifically. This works on my machine with clang-3.9.
So, I'd guess more suppression types are valid in clang-3.9.
# compile.sh
set -x
UBSAN_OPTIONS=suppressions=suppressions.supp:print_stacktrace=1 #:help=1
export UBSAN_OPTIONS
clang++-3.9 -g -std=c++11 -fsanitize=undefined -fno-omit-frame-pointer -fsanitize=unsigned-integer-overflow main.cpp
./a.out
// main.cpp
#include <bits/stdc++.h>
#include <bits/stl_tree.h>
using namespace std;
int main(int argc, char **argv) {
unsigned int k = UINT_MAX;
k += 1;
return 0;
}
# suppressions.supp
unsigned-integer-overflow:main.cpp
I am using Flex and Bison to create a compiler. As I am trying to create an AST (Abstract Syntax Tree) for my program, I need to port it to C++. So far I have been successful, until a encountered a rather obscure error from my compiler:
Kraken.o: In function Kraken::FlexScanner::FlexScanner()':
Kraken.cc:(.text._ZN6Kraken11FlexScannerC2Ev[_ZN6Kraken11FlexScannerC5Ev]+0x26): undefined reference to vtable for Kraken::FlexScanner'
Kraken.o: In function Kraken::FlexScanner::~FlexScanner()':
Kraken.cc:(.text._ZN6Kraken11FlexScannerD2Ev[_ZN6Kraken11FlexScannerD5Ev]+0xb): undefined reference to vtable for Kraken::FlexScanner'
Here is all the relevant code:
Kraken.cc:
#include "KrakenScanner.hh"
#include "KrakenParser.hh"
int main(int argc, char * argv[]) {
Kraken::Parser parser;
return parser.parse();
}
KrakenScanner.hh:
#ifndef KRAKENSCANNER_HH_
#define KRAKENSCANNER_HH_
#if ! defined(yyFlexLexerOnce)
#include <FlexLexer.h>
#endif
#undef YY_DECL
#define YY_DECL int Kraken::FlexScanner::yylex()
#include "parser.hh"
namespace Kraken {
class FlexScanner : public yyFlexLexer {
public:
int yylex(Kraken::BisonParser::semantic_type* lval);
private:
int yylex();
Kraken::BisonParser::semantic_type* yylval;
};
}
#endif /* KRAKENSCANNER_HH_ */
KrakenScanner.cc:
#include "KrakenScanner.hh"
int Kraken::FlexScanner::yylex(Kraken::BisonParser::semantic_type* lval) {
yylval = lval; return yylex();
}
Makefile:
OBJS := Kraken.o parser.o scanner.o KrakenScanner.o KrakenParser.o
%.cc: %.y
bison -o $(#:%.o=%.d) $<
%.cc: %.l
flex -o$(#:%.o=%.d) -i $<
all: $(OBJS)
g++ -okraken $(OBJS)
Kraken.o: Kraken.cc KrakenScanner.o KrakenParser.o
KrakenScanner.o: KrakenScanner.hh KrakenScanner.cc parser.o
parser.o: parser.hh parser.cc
parser.cc: parser.y
scanner.o: scanner.cc
scanner.cc: scanner.l
KrakenParser.o: KrakenParser.hh KrakenParser.cc KrakenScanner.o`
I don't know if this will help, but FlexLexer.h defines the classes FlexLexer and yyFlexLexer. FlexLexer declares just a virtual destructor, and yyFlexLexer defines both a constructor and destructor. Also, when I attempt to overload the constr. and destr. in Kraken.cc, I get an error saying that the two are "implicitly defined".
Try a clean rebuild (rm *.o) and recompile. The compiler is supposed to generate this stuff automatically. Some compilers have special non-portable magic to influence v-table linking, but I don't see anything like that in your code.
Also, I see in your makefile that you've written a rule for linking with g++, but you haven't written any rule for compilation. So make is using its built-in rules, which might by the C++ compiler provided by your OS, not g++.
Another thing is that makefile rules should put the primary source first. For example:
wrong:
KrakenScanner.o: KrakenScanner.hh KrakenScanner.cc parser.o
right:
KrakenScanner.o: KrakenScanner.cc KrakenScanner.hh
Finally, object files aren't used to build other object files, only during linking.
First off, that error message is from your linker, not your compiler. It looks like you aren't linking in KrakenScanner.o. It also helps to apply the name demangler for your compiler to your compiler/linker error output.
What compiler are you using?
I am trying to compile the following program with mingw:
#include <pthread.h>
#include <errno.h>
#include <unistd.h>
#include <iostream>
#include <cstdio>
void *hello(void *id) {
int nid = *static_cast<int*>(id);
std::printf("Hello from thread %d\n", nid);
return 0;
}
int main(int argc, char **argv) {
pthread_t ids[2];
int *params[2];
for (int i = 0; i < 2; ++i) {
params[i] = new int;
*params[i] = i;
pthread_create(&ids[i], 0, hello, params[i]);
}
for (int i = 0; i < 2; ++i)
pthread_join(ids[i], 0);
for (int i = 0; i < 2; ++i)
delete params[i];
return 0;
}
using this command:
g++ -lpthread -ohello.exe hello.cc
And I get the following message:
C:\Users\XXXXXX~1\AppData\Local\Temp\cczPlv0w.o:hello.cc:(.text+0xad): undefined
reference to `_imp__pthread_create'
C:\Users\XXXXXX~1\AppData\Local\Temp\cczPlv0w.o:hello.cc:(.text+0xe9): undefined
reference to `_imp__pthread_join'
collect2: ld returned 1 exit status
But with an older version of MingGW I had no problems running pthreads programs. (This is just the simple of all the programs that failed, but basically everything that uses pthreads ends up with the same error, C and C++)
Move -lpthread to the end of that command:
g++ -ohello.exe hello.cc -lpthread
The order of the arguments is important. (Using -pthread throughout instead of -lpthread for linking is actually recommended, since it sets flags both for the preprocessor and the linker.)
Library specifications are position dependent with gcc, it will only bring in unresolved symbols at the point where the library is listed.
Because you haven't listed your main object file at that point, the only unresolved symbol is main. You need to move the library specifications to the point where there will be unresolved symbols they can satisfy.
I've never really understood why gcc chose this path since it sometimes leads to situations where you have to list libraries more than once (such as with circular dependencies). The only reason I've ever thought of is to keep control as to what libraries are allowed to resolve specific symbols.
I've seen more "intelligent" linkers where they simply batch up all the libraries till the end then go through them over and over again until either all symbols are satisfied or there is no chance that they can be. This saves a lot of effort but you do lose that aforementioned control.