I tried to use erl_errno as described in the erlang document: http://erlang.org/doc/man/erl_error.html#.
However, I'm getting a symbol not found problem during linking. I'm running on Mac and here's the how the program is linked:
g++ -L/usr/local/lib/erlang/lib/erl_interface-3.9.3/lib -o "roserl" ./src/driver.o ./src/erl_bridge.o -lei -lm -lerl_interface
I have already linked with libei and liberl_interface. What else is needed?
It is weird but you will have to do this in your header:
#ifndef _REENTRANT
#define _REENTRANT /* For some reason __erl_errno is undefined unless _REENTRANT is defined */
#endif
#include "erl_interface.h"
#include "ei.h"
This fixed the problem for me. Now I can use erl_errno.
Related
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.
I'm using QtCreator 4.11.2 , installed via MSYS2, with ClangCodeModel enabled.
Here is my program (this is the result of creating a New Non-QT Plain C Application):
#include <stdio.h>
#include <stdbool.h>
_Bool a;
bool b;
int main()
{
printf("Hello World!\n");
return 0;
}
The .pro file is unchanged from the default:
TEMPLATE = app
CONFIG += console
CONFIG -= app_bundle
CONFIG -= qt
SOURCES += \
main.c
The annotation compiler highlights an error saying stdbool.h cannot be found.
But it does not give an error for _Bool a; , so it is clearly running in C99 mode but has some problem with include paths. The "Follow symbol under cursor" option works, opening stdbool.h.
My question is: How do I configure include paths for the annotation compiler or otherwise fix this problem?
I have been unable to figure out how to set options for the annotation compiler or even which compiler binary it is using . Under Tools > Options > C++ > Code Model > Diagnostic Configuration it lets me add -W flags but does not let me add -I flags, a red message pops up saying the option is invalid.
Under Tools > Options > C++ Code Model inspector, there are no diagnostic messages, and the Code Model Inspecting Log shows stdbool.h being correctly found and parsed, as msys64/mingw64/lib/gcc/x86_64-w64-mingw32/9.3.0/include/stdbool.h.
If I disable the ClangCodeModel plugin then there are no errors , but I would like to use the clang version if it can be made to work as in general it has good diagnostics.
The result of clang --version in a shell prompt is:
clang version 10.0.0 (https://github.com/msys2/MINGW-packages.git 3f880aaba91a3d9cdfb222dc270274731a2119a9)
Target: x86_64-w64-windows-gnu
Thread model: posix
InstalledDir: F:\Prog\msys64\mingw64\bin
and if I compile this same source code using clang outside of QtCreator, it compiles and runs correctly with no diagnostics. So the annotation compiler is clearly not the same as the commandline clang?
The Kit I have selected in QtCreator is the autodetected Desktop Qt MinGW-w64 64bit (MSYS2)
The exact same symptoms occur if I make a Plain C++ project and try to include stdbool.h (which is required to exist by the C++ Standard, although deprecated), although interestingly it does accept <cstdbool>.
I have found a workaround of sorts: including in the .pro file the line:
INCLUDEPATH += F:/Prog/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/9.3.0/include/
causes the annotation compiler to work correctly, however this is undesirable as I'd have to keep changing it whenever I switch Kits because it also passes this to the actual build compiler, not just the annotation compiler.
Create file stdbool.h in C:\msys64\mingw64\x86_64-w64-mingw32\include and copy paste this code:
/* Copyright (C) 1998-2017 Free Software Foundation, Inc.
This file is part of GCC.
GCC is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 3, or (at your option)
any later version.
GCC is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
Under Section 7 of GPL version 3, you are granted additional
permissions described in the GCC Runtime Library Exception, version
3.1, as published by the Free Software Foundation.
You should have received a copy of the GNU General Public License and
a copy of the GCC Runtime Library Exception along with this program;
see the files COPYING3 and COPYING.RUNTIME respectively. If not, see
<http://www.gnu.org/licenses/>. */
/*
* ISO C Standard: 7.16 Boolean type and values <stdbool.h>
*/
#ifndef _STDBOOL_H
#define _STDBOOL_H
#ifndef __cplusplus
#define bool _Bool
#define true 1
#define false 0
#else /* __cplusplus */
/* Supporting _Bool in C++ is a GCC extension. */
#define _Bool bool
#if __cplusplus < 201103L
/* Defining these macros in C++98 is a GCC extension. */
#define bool bool
#define false false
#define true true
#endif
#endif /* __cplusplus */
/* Signal that all the definitions are present. */
#define __bool_true_false_are_defined 1
#endif /* stdbool.h */
Note
Creating a manual file stdbool.h works for me but its a sketchy and a temporary solution for now. Don't use this if you feel its too sketcy. I would rather use a alternative solution than this hack if it exist. This solution might not be good but it still works for me.
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 know there are other questions with that same title, but none of them have the same problem than me.
I have two projects. One of them builds a library, the other one builds an app that uses that library.
When I build the library it's all ok. It creates a .a file which contains the library. When I try to build the second project, I get the following message:
Undefined symbols for architecture armv7:
"_SPLite3_rtree_geometry_callback", referenced from:
_register_spatialite_sql_functions in liblibspatialite.a(spatialite.o)
ld: symbol(s) not found for architecture armv7
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Thats bad. At first I did not know what it was talking about, but after some research, found that the library may have not be built for armv7, so I used the lipo command to check the architecture:
lipo -info liblibspatialite.a
This produces the following output.
Non-fat file: liblibspatialite.a is architecture: armv7
Ok so the architecture is right. Then what? Maybe check for the symbols of the .o files that will conform the library. For that I used the nm command:
nm spatialite.o | grep SPLite3_rt
Which produces the following output:
U _SPLite3_rtree_geometry_callback
I checked the manpage for nm and saw that the U before the symbol means it's undefined. So it seems that's it. The symbol appears as undefined. I have another version of the project in another workspace. I've checked, and it produces a working library. The nm command returns the following on that other version:
0000e5f6 T _SPLite3_rtree_geometry_callback
0018c668 S _SPLite3_rtree_geometry_callback.eh
So, with this library it's working and it's fine. I've tried to find differences in the build options of both projects but they look the same to me.
I can build with the first version of the library if I include the source files of the library in the compiler section of the properties of the project. (Select target -> Build phases -> Compile sources), but I think that's not the point of using a library.
So, I'd like to know what can I do so that the _SPLite3_rtree_geometry_callback gets included in the library.
Thanks in advance.
EDIT:
Some more info. In spatialite.c, there is the following code:
#define sqlite3_rtree_geometry_callback SPLite3_rtree_geometry_callback
SQLITE_API int sqlite3_rtree_geometry_callback(
sqlite3 *db,
const char *zGeom,
int (*xGeom)(sqlite3_rtree_geometry *, int nCoord, double *aCoord, int *pRes),
void *pContext
);
EDIT 2:
Code for the method:
/*
** Register a new geometry function for use with the r-tree MATCH operator.
*/
SQLITE_API int sqlite3_rtree_geometry_callback(
sqlite3 *db,
const char *zGeom,
int (*xGeom)(sqlite3_rtree_geometry *, int, double *, int *),
void *pContext
){
RtreeGeomCallback *pGeomCtx; /* Context object for new user-function */
/* Allocate and populate the context object. */
pGeomCtx = (RtreeGeomCallback *)sqlite3_malloc(sizeof(RtreeGeomCallback));
if( !pGeomCtx ) return SQLITE_NOMEM;
pGeomCtx->xGeom = xGeom;
pGeomCtx->pContext = pContext;
/* Create the new user-function. Register a destructor function to delete
** the context object when it is no longer required. */
return sqlite3_create_function_v2(db, zGeom, -1, SQLITE_ANY,
(void *)pGeomCtx, geomCallback, 0, 0, doSqlite3Free
);
}
Check that spacialite.c is added to the library's target.
You have to specify SQLITE_ENABLE_RTREE in preproccessor macro
Ok. This seems weird but it looks like I finally fixed it. Everything is correctly defined, so why it is not working I don't know.
I was using the xcode target preferences to define the preprocessor macros. Instead of that, I changed the SQLITE_ENABLE_RTREE to the .pch file, and after that the build contains the missing symbol.
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?