In a wasm source code, when an undefined function is used, the compile will add this function into module named "env".
I want to change the name "env" to another like "myenv"
#include <stdio.h>
extern int butt();
int main()
{
butt();
printf("123\n");
}
the wast file looks like this
(import "env" "butt" (func $butt (result i32)))
How to change my c-code so that the "butt" is under "myenv".
That's what I expect for.
(import "myenv" "butt" (func $butt (result i32)))
I'm using clang compiler to generate wasm file.
Currently there is no way to change the default, but for a given symbol you can use the import_name attribute:
https://clang.llvm.org/docs/AttributeReference.html#import-module
Related
In reading the documentation for zig, I was under the impression that zig could compile both C and C++ code. Consequently, I thought you could import a C++ file's header via #cImport and have zig build succeed. However, I can't seem to get this to work for a C++ library integration.
I first create my project, zig init-lib and then add my import to src/main.zig via the #cImport directive. Specifically, I #cInclude("hooks/hooks.h") the C++ header file of this library. If I attempt to zig build at this point, the build fails, unable to find the header. I fix this by modifying build.zig to lib.addIncludeDir("/usr/include/library").
Since this C++ library is now being parsed and uses the C++ standard library, the next error I get when I zig build is that the stdexcept header is not found. To fix this, I modify build.zig to lib.linkSystemLibrary("c++").
Lastly, and the error I'm stuck on now, is an assortment of errors in /path/to/zig-linux-x86_64-0.9.1/lib/libcxx/include/<files>. I get stuff like unknown type name '__LIBCPP_PUSH_MACROS, unknown type name 'namespace', or unknown type name 'template'.
Googling this, the only thing of partial relevance that I could find was that this is due to clang's default interpretation of .h files is as C files which obviously don't have namespace or template keywords, but I don't know what to do with that knowledge. LLVM on MacOs - unknown type name 'template' in standard file iosfwd
Does anyone have any insight as to how to actually integrate with a C++ (not pure C) library through zig?
Specifically, I #cInclude("hooks/hooks.h") the C++ header file of this library.
#cImport() is for translating C header files into zig so they can be used without writing bindings. Unfortunately, it does not support C++ headers. To use a C++ library, you'll have to write C bindings for it and then #cImport() those headers.
// src/bindings.cpp
#include <iostream>
extern "C" void doSomeCppThing(void) {
std::cout << "Hello, World!\n";
}
// src/bindings.h
void doSomeCppThing(void);
// build.zig
const std = #import("std");
pub fn build(b: *std.build.Builder) void {
const target = b.standardTargetOptions(.{});
const mode = b.standardReleaseOptions();
const exe = b.addExecutable("tmp", "src/main.zig");
exe.setTarget(target);
exe.setBuildMode(mode);
exe.linkLibC();
exe.linkSystemLibrary("c++");
exe.addIncludeDir("src");
exe.addCSourceFile("src/bindings.cpp", &.{});
exe.install();
}
// src/main.zig
const c = #cImport({
#cInclude("bindings.h");
});
pub fn main() !void {
c.doSomeCppThing();
}
I have a solution with 2 projects, one is a static library and the other is an application that
links to it. In the static library I have a pre-compiled header file with the following code:
#pragma once
//C standard Library
#include <stdio.h>
//C++ Standard Library
#include <iostream>
#include <fstream>
#include <sstream>
#include <memory>
#include <functional>
//Data Structures
#include <string>
#include <vector>
#include <array>
#include <map>
#include <set>
#include <unordered_map>
#include <unordered_set>
I have also added the necessary .cpp file and configured the project properties to use this specific pre-
compiled header. I also added the .h file to the top of every .cpp file as required. I proceeded to my
latter project and properly referenced the static library and wrote some simple code, here is an
example:
class Test : public Craft::Application
{
public:
Test()
{
}
~Test()
{
}
};
Craft::Application* Craft::CreateApplication()
{
return new Test;
}
This returned Test object will be linked with an entry point and proceeds through the pipeline and
encounters code from the std library, that's when I get these errors:
error C2039: 'string': is not a member of 'std'
message : see declaration of 'std'
error C3646: 'Title': unknown override specifier
error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
error C2039: 'string': is not a member of 'std'
message : see declaration of 'std'
error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
error C2143: syntax error: missing ',' before '&'
error C2065: 'title': undeclared identifier
error C2065: 'width': undeclared identifier
error C2065: 'height': undeclared identifier
error C2614: 'Craft::Window::WindowProps': illegal member initialization: 'Title' is not a base or member
error C2039: 'unique_ptr': is not a member of 'std'
message : see declaration of 'std'
error C2143: syntax error: missing ';' before '<'
error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
error C2238: unexpected token(s) preceding ';'
I understand that this project doesn't recognize the header files in my pre-compiled header. I can
confirm that as I included these files in the application and this resolved all errors. This sparks many
questions though: This project links to the library, so why doesn't it recognize this pre-compiled
header? What's the best solution for this? Is it a pre-compiled header per project? Is it something
entirely else?
The solution is simply including your pch in every source file and adding any necessary headers used by the header file. The compiler will still use the pch but will also be able to define your functions in the header file.
My static library is an engine depending on other headers.
For example, in XXXEngine.h
#include "CommonUtil.h"
#include "DebugLogger.h"
All of these files are added when I build the static library. So I only export XXXEngine.h as the API and hide my implementations.
But the problem is that when I import that header file into another project and the .a file is already added as well, I get some errors saying that "CommonUtil.h" cannot be found. It can find XXXEngine.h, but just not the headers inside this file. But I didn't want to expose those header files.
What should I do to fix this? Thanks!
Any header files that you #include in the header files that define your
library's API become part of your library's API. If the compiler ever has to
find MyLib.h then it has to find every header that is (recursively) #include-ed
in MyLib.h.
So if you don't want to expose a particular header file and don't want your
library's users to need it, then you just can't include it in MyLib.h.
Instead of, e.g:-
MyLib.h
...
...
#include "private_header.h"
#include "public_header.h"
...
...
and
MyLib.m
#include "MyLib.h"
...
...
you need to refactor like:
MyLib.h
...
...
#include "public_header.h"
...
...
and
MyLib.m
#include "MyLib.h"
#include "private_header.h"
...
...
If your project will not compile like that, then it proves that MyLib.h
does need declarations from private_header.h, which you do not want it to expose.
In that case, rethink and refactor your code until it doesn't.
I would like to use Clang to get to its AST to get some information about the variables and methods in a particular source file. However, I do not want to use the LibTooling facilities. I would like to, by hand, to write to code that would call the methods to parse the .cpp and then get the tree. I can not find any resources that tell me how to do this. Can anybody help?
If your goal is to learn how to drive Clang components to work with the compilation database, configure the compiler instance, and so on, then the Clang source code is a resource. Perhaps the source for the ClangTool::buildASTs() method would be a good place to start: see Tooling.cpp in the lib/Tooling/ directory of the source tree.
If your goal is to do an analysis that LibTooling doesn't support, and you just want to get the AST with minimal fuss, then either ClangTool::buildASTs or clang::tooling::buildASTFromCode might be of service. The ClangTool approach would be better if you need the compilation database to express compiler options, include paths, and so on. buildASTFromCode is fine if you have a standalone bit of code for lightweight tests. Here's an example of the ClangTool approach:
#include "clang/Tooling/CommonOptionsParser.h"
#include "clang/Tooling/Tooling.h"
#include "llvm/Support/CommandLine.h"
#include <memory>
#include <vector>
static llvm::cl::OptionCategory MyOpts("Ignored");
int main(int argc, const char ** argv)
{
using namespace clang;
using namespace clang::tooling;
CommonOptionsParser opt_prs(argc, argv, MyOpts);
ClangTool tool(opt_prs.getCompilations(), opt_prs.getSourcePathList());
using ast_vec_t = std::vector<std::unique_ptr<ASTUnit>>;
ast_vec_t asts;
tool.buildASTs(asts);
// now you the AST for each translation unit
...
Here's an example of buildASTFromCode:
#include "clang/Frontend/ASTUnit.h"
#include "clang/Tooling/Tooling.h"
...
std::string code = "struct A{public: int i;}; void f(A & a}{}";
std::unique_ptr<clang::ASTUnit> ast(clang::tooling::buildASTFromCode(code));
// now you have the AST for the code snippet
clang::ASTContext * pctx = &(ast->getASTContext());
clang::TranslationUnitDecl * decl = pctx->getTranslationUnitDecl();
...
are there any lua bindings for libbullet?
tried using swig and simply %includeing the BulletDynamicsCommon.h:
%module ybullet
%{
#include <btBulletDynamicsCommon.h>
%}
%include "%BULLET_inc_path%/btBulletDynamicsCommon.h"
but that doesn't work, as it also just includes other files, which is ignored by swig:
ybullet/helloWorld.lua:4: attempt to call field 'btDbvtBroadphase' (a nil value)
my lua file is ported from http://bulletphysics.org/mediawiki-1.5.8/index.php/Hello_World
found out a way using swig and a zsh script to automagically extract the %includes from the header files to get this: https://github.com/nonchip/YEngine/blob/master/ybullet/ybullet.i.tpl