I'm trying to use SIMD intrinsics on Clang compiler for Windows and I'm getting undefined symbol error. What am I missing? There is no such a library for intrinsics, the compiler should just know how to put them into the code.
I'm also getting this erro with the MSVC linker.
Just a example code.
#include <xmmintrin.h>
extern inline float
pmath_Sinf(float radians)
{
__m128 radians_ps = _mm_set_ps(0.0f, 0.0f, 0.0f, radians);
return 0.0f;
}
extern inline float
pmath_Cosf(float radians)
{
__m128 radians_ps = _mm_set_ps(0.0f, 0.0f, 0.0f, radians);
return 0.0f;
}
These are the command line output with verbosity.
clang version 12.0.0
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Program Files\LLVM\bin
"C:\\Program Files\\LLVM\\bin\\clang-cl.exe" -cc1 -triple x86_64-pc-windows-msvc19.28.29333 -emit-obj -mrelax-all -mincremental-linker-compatible --mrelax-relocations -disable-free -main-file-name windows_main.c -mrelocation-model pic -pic-level 2 -mframe-pointer=none -relaxed-aliasing -menable-no-infs -menable-no-nans -menable-unsafe-fp-math -fno-signed-zeros -mreassociate -freciprocal-math -fno-trapping-math -ffp-contract=fast -fno-rounding-math -ffp-exception-behavior=ignore -ffast-math -ffinite-math-only -mconstructor-aliases -munwind-tables -target-cpu x86-64 -mllvm -x86-asm-syntax=intel -tune-cpu generic -D_MT -flto-visibility-public-std -D_VC_NODEFAULTLIB -fno-rtti-data -fms-volatile -fdiagnostics-format msvc -gno-column-info -gcodeview -debug-info-kind=limited -v -nobuiltininc -resource-dir "C:\\Program Files\\LLVM\\lib\\clang\\12.0.0" -D DEVELOPMENT -internal-isystem "C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\Community\\VC\\Tools\\MSVC\\14.28.29333\\include" -internal-isystem "C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\Community\\VC\\Tools\\MSVC\\14.28.29333\\atlmfc\\include" -internal-isystem "C:\\Program Files (x86)\\Windows Kits\\10\\Include\\10.0.19041.0\\ucrt" -internal-isystem "C:\\Program Files (x86)\\Windows Kits\\10\\include\\10.0.19041.0\\shared" -internal-isystem "C:\\Program Files (x86)\\Windows Kits\\10\\include\\10.0.19041.0\\um" -internal-isystem "C:\\Program Files (x86)\\Windows Kits\\10\\include\\10.0.19041.0\\winrt" -O0 -Weverything -Werror -Wno-missing-prototypes -Wno-missing-variable-declarations -Wno-cast-align -Wno-language-extension-token -Wno-error=unused-parameter -Wno-error=unused-variable --std=c99 -fdebug-compilation-dir "C:\\Users\\Leonardo\\Desktop\\Projects\\Primal Library\\src\\windows" -ferror-limit 19 -fmessage-length=120 -mstack-probe-size=9999999 -fno-use-cxa-atexit -fms-extensions -fms-compatibility -fms-compatibility-version=19.28.29333 -fdelayed-template-parsing -finline-hint-functions -fcolor-diagnostics -faddrsig -o "C:\\Users\\Leonardo\\AppData\\Local\\Temp\\windows_main-c555fe.obj" -x c windows_main.c
clang -cc1 version 12.0.0 based upon LLVM 12.0.0-6923b0a7 default target x86_64-pc-windows-msvc
ignoring nonexistent directory "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.28.29333\atlmfc\include"
#include "..." search starts here:
#include <...> search starts here:
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.28.29333\include
C:\Program Files (x86)\Windows Kits\10\Include\10.0.19041.0\ucrt
C:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\shared
C:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\um
C:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\winrt
End of search list.
In file included from windows_main.c:8:
./../math.c(17,10): warning: unused variable 'radians_ps' [-Wunused-variable]
__m128 radians_ps = _mm_set_ps(0.0f, 0.0f, 0.0f, radians);
^
./../math.c(27,10): warning: unused variable 'radians_ps' [-Wunused-variable]
__m128 radians_ps = _mm_set_ps(0.0f, 0.0f, 0.0f, radians);
^
windows_main.c(174,14): warning: unused parameter 'argc' [-Wunused-parameter]
int main(int argc, char* argv[])
^
windows_main.c(174,26): warning: unused parameter 'argv' [-Wunused-parameter]
int main(int argc, char* argv[])
^
4 warnings generated.
"C:\\Program Files\\LLVM\\bin\\lld-link" "-out:..\\..\\build\\windows_development_x64\\primal.exe" "-libpath:C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\Community\\VC\\Tools\\MSVC\\14.28.29333\\lib\\x64" "-libpath:C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\Community\\VC\\Tools\\MSVC\\14.28.29333\\atlmfc\\lib\\x64" "-libpath:C:\\Program Files (x86)\\Windows Kits\\10\\Lib\\10.0.19041.0\\ucrt\\x64" "-libpath:C:\\Program Files (x86)\\Windows Kits\\10\\Lib\\10.0.19041.0\\um\\x64" "-libpath:C:\\Program Files\\LLVM\\lib\\clang\\12.0.0\\lib\\windows" -nologo -debug /INCREMENTAL:NO /NODEFAULTLIB /OPT:REF /STACK:0x100000,0x100000 /SUBSYSTEM:CONSOLE /WX "C:\\Users\\Leonardo\\AppData\\Local\\Temp\\windows_main-c555fe.obj" kernel32.lib
lld-link: error: undefined symbol: _mm_set_ps
>>> referenced by C:\Users\Leonardo\Desktop\Projects\Primal Library\src\math.c:17
>>> C:\Users\Leonardo\AppData\Local\Temp\windows_main-c555fe.obj:(pmath_Sinf)
>>> referenced by C:\Users\Leonardo\Desktop\Projects\Primal Library\src\math.c:27
>>> C:\Users\Leonardo\AppData\Local\Temp\windows_main-c555fe.obj:(pmath_Cosf)
clang-cl: error: linker command failed with exit code 1 (use -v to see invocation)
I got it working.
Since I have both Clang and MSVC installed, both of them has its own xmmintrin.h header file in their include path, since it is compiler specific. I realized that with #include <xmmintrin.h>, Clang was including the MSVC version, probably because it found first in the PATH. So all I did was use /X compiler option that makes it stoping searching for include paths, and I created a new xmmintrin.h file by coping and pasting all I needed from the actual Clang xmmintrin.h into it.
Thanks everyone for your comments.
Related
I used ClangTool to develop a code generate tool, but I found Clang code parser can't preprocess macro with short-circuit evaluation.
Here is the minimal reproducible code
#include <clang/ASTMatchers/ASTMatchers.h>
#include <clang/Frontend/FrontendActions.h>
#include <clang/Tooling/Tooling.h>
#include <gtest/gtest.h>
using namespace clang::tooling;
using namespace clang::ast_matchers;
using namespace clang;
using namespace llvm::cl;
const char *simpleCode = R"(
#if defined(__MINGW32__)
class A {B}
#endif
#if defined(__MINGW32__) && __has_include(<pthread.h>)
class C {D}
#endif
class X {};
)";
TEST(runToolOnCode, CanSyntaxCheckCode)
{
EXPECT_TRUE(runToolOnCode(std::make_unique<clang::SyntaxOnlyAction>(), simpleCode));
}
I expect to be able to parse correctly, but I got
input.cc:5:43: fatal error: cannot open file '/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1/pthread.h': No such file or directory
Running main() from /Volumes/Demon/Demo/Polaris/cmake-build-debug/_deps/googletest-src/googletest/src/gtest_main.cc
#if defined(__MINGW32__) && __has_include(<pthread.h>)
^
1 error generated.
/Volumes/Demon/Demo/Polaris/tests/hello.cpp:28: Failure
Value of: runToolOnCode(std::make_unique<clang::SyntaxOnlyAction>(), simpleCode)
Actual: false
Expected: true
About my environment
MaxOSX 11.3.1
XCode 12.5.1
➜ ~ clang++ -E -x c++ - -v
Homebrew clang version 12.0.0
Target: x86_64-apple-darwin20.4.0
Thread model: posix
InstalledDir: /usr/local/opt/llvm/bin
(in-process)
"/usr/local/Cellar/llvm/12.0.0_1/bin/clang-12" -cc1 -triple x86_64-apple-macosx11.0.0 -Wundef-prefix=TARGET_OS_ -Werror=undef-prefix -Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-usage -E -disable-free -disable-llvm-verifier -discard-value-names -main-file-name - -mrelocation-model pic -pic-level 2 -mframe-pointer=all -fno-rounding-math -munwind-tables -fcompatibility-qualified-id-block-type-checking -fvisibility-inlines-hidden-static-local-var -target-cpu penryn -tune-cpu generic -debugger-tuning=lldb -target-linker-version 650.9 -v -resource-dir /usr/local/Cellar/llvm/12.0.0_1/lib/clang/12.0.0 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk -stdlib=libc++ -internal-isystem /usr/local/opt/llvm/bin/../include/c++/v1 -internal-isystem /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/local/include -internal-isystem /usr/local/Cellar/llvm/12.0.0_1/lib/clang/12.0.0/include -internal-externc-isystem /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include -fdeprecated-macro -fdebug-compilation-dir /Users/abao -ferror-limit 19 -stack-protector 1 -fblocks -fencode-extended-block-signature -fregister-global-dtors-with-atexit -fgnuc-version=4.2.1 -fcxx-exceptions -fexceptions -fmax-type-align=16 -fcolor-diagnostics -o - -x c++ -
clang -cc1 version 12.0.0 based upon LLVM 12.0.0 default target x86_64-apple-darwin20.4.0
ignoring nonexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/local/include"
ignoring nonexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/Library/Frameworks"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/opt/llvm/bin/../include/c++/v1
/usr/local/Cellar/llvm/12.0.0_1/lib/clang/12.0.0/include
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks (framework directory)
End of search list.
use llvm 11.1.0 could circumvent this problem, this may be a bug in version 12.0.0
Closed - see the end of the entry
I want to make a C callable library using the zig language.
I decided to start with the two examples in the Zig documentation. "Exporting a C Library" and "Mixing Object Files".
In each case I copied the three relevant files(from 0.6.0 docs).
A C file called test.c,
a zig file called respectively mathtest.zig (for the Exporting a C Library example) and base64.zig (for the Mixing Object Files example), and
a build.zig file.
Both examples fail to build.
The Exporting a C Library example fails to compile test.c with a message cannot find mathtest.h
The Mixing Object Files example fails to compile test.c with cannot find base64.h
Here are the three files for the Exporting C Libary example:
mathtest.zig
export fn add(a: i32, b: i32) i32 {
return a + b;
}
test.c
// This header is generated by zig from mathtest.zig
#include "mathtest.h"
#include <stdio.h>
int main(int argc, char **argv) {
int32_t result = add(42, 1337);
printf("%d\n", result);
return 0;
}
build.zig
const Builder = #import("std").build.Builder;
pub fn build(b: *Builder) void {
const lib = b.addSharedLibrary("mathtest", "mathtest.zig", b.version(1, 0, 0));
const exe = b.addExecutable("test", null);
exe.addCSourceFile("test.c", &[_][]const u8{"-std=c99"});
exe.linkLibrary(lib);
exe.linkSystemLibrary("c");
b.default_step.dependOn(&exe.step);
const run_cmd = exe.run();
const test_step = b.step("test", "Test the program");
test_step.dependOn(&run_cmd.step);
}
Part of the error message
~/Projects/zig/z-c-lib $ zig build test
/home/robert/Projects/zig/z-c-lib/test.c:2:10: fatal error: 'mathtest.h' file not found
#include "mathtest.h"
^~~~~~~~~~~~
1 error generated.
The following command failed:
/home/robert/zig/zig clang -c -nostdinc -fno-spell-checking -target x86_64-unknown-linux-gnu -isystem /home/robert/zig/lib/zig/include -isystem /home/robert/zig/lib/zig/libc/include/x86_64-linux-gnu -isystem /home/robert/zig/lib/zig/libc/include/generic-glibc -isystem /home/robert/zig/lib/zig/libc/include/x86_64-linux-any -isystem /home/robert/zig/lib/zig/libc/include/any-linux-any -Xclang -target-cpu -Xclang znver2 -Xclang -target-feature -Xclang -3dnow -Xclang -target-feature -Xclang -3dnowa -Xclang -target-feature -Xclang +64bit -Xclang -target-feature -Xclang +adx -Xclang -target-feature -Xclang +aes -Xclang -target-feature -Xclang +avx -Xclang -target-feature -Xclang +avx2 -Xclang -target-feature -Xclang -avx512bf16 -Xclang -target-feature -Xclang -avx512b
I cannot find a file named mathtest.h on my system so I assume it was not generated, contrary to the claim in the test.c file.
What am I missing ? Help gratefully accepted.
Answers and More questions
I discovered the -femit-h options:
zig build-lib mathtest.zig -femit-h
will create a mathtest.h file and then
zig build
will be successful.
I further discovered that
these lines in the build.zig files
const lib = b.addSharedLibrary('mathtest', 'mathtest.zig', b.version(1, 0, 0));
lib.femit_h = true;
will ensure that
zig build test
will be successful and generate the answer 1379 as indicated in the docs.
BUT - this mod to the build.zig file does not leave a mathtest.h file around after it runs.
That seems to be the final hurdle to generating a usable C library from a Zig code.
Final piece in the puzzle
If I add
lib.setOutputDir("build");
to the build.zig file. The mathtest.h and libmathtest.a (or .so) files will be saved into a build dir.
Call this one close
Ok so part of the answer is simple, but maybe obscure, the -femit-h options.
The command
zig build-lib mathtest.zig -femti-h
will generate a mathtest.h file.
But how do I add that options to the
const lib = b.addSharedLibrary("mathtest", "mathtest.zig", b.version(1, 0, 0));
line in the build.zig file.
my aim is to install cjson with luarocks on Windows 10 (64 Bit), what i've done so far:
Try the installation via make:
put this luajit installation on the path "C:\torch" and set all the following path variables manually (see issues)
Path = "C:\torch\bin;"%PATH%
LUA_CPATH="C:\torch\bin\?.dll;;"
LUA_DEV="C:\torch;"
LUA_PATH="C:\torch\lua\?;C:\torch\lua\?.lua;C:\torch\lua\?\init.lua;;"
put this version of lua-cjson-2.1.0 on the following folder: "C:\Users\username\Desktop\lua-cjson-2.1.0"
install mingw with make version 3.81, cmake 3.13.2 and add "C:\MinGW\msys\1.0\bin\" and "C:\Program Files\CMake\bin\" to the Path variable
uncomment variables for Windows(MingGW) and setting the PREFIX = C:\torch\ in the Makefile of lua-cjson-2.1.0
go via admin-shell to "C:\Users\username\Desktop\lua-cjson-2.1.0"
"make install" yields the following output:
cc -c -O3 -Wall -pedantic -DNDEBUG -IC:\torch CJSON_CFLAGS = -DDISABLE_INVALID_NUMBERS/include -fpic -o lua_cjson.o lua_cjson.c
make: cc: Command not found
make: *** [lua_cjson.o] Error 127`
Another try with luarocks doesn´t work too:
call ""C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64"
then call "luarocks make" as described in the cjson-manual
this yields the following output:
cl /nologo /MD /O2 -c -Folua_cjson.obj -IC:/torch/include lua_cjson.c -DDISABLE_INVALID_NUMBERS lua_cjson.c
cl /nologo /MD /O2 -c -Fostrbuf.obj -IC:/torch/include strbuf.c -DDISABLE_INVALID_NUMBERS strbuf.c
strbuf.c(98): warning C4311: "type conversion": pointer truncation from "strbuf_t *" to "long"
strbuf.c(172): warning C4311: "type conversion": pointer truncation from "strbuf_t *" to"long"
cl /nologo /MD /O2 -c -Fofpconv.obj -IC:/torch/include fpconv.c -DDISABLE_INVALID_NUMBERS fpconv.c
link -dll -def:cjson.def -out:cjson.dll C:/torch/lib/libluajit.lib lua_cjson.obj strbuf.obj fpconv.obj
Microsoft (R) Incremental Linker Version 14.10.25019.0
Copyright (C) Microsoft Corporation. All rights reserved.
Bibliothek "cjson.lib" und Objekt "cjson.exp" werden erstellt.
lua_cjson.obj : error LNK2019: Reference to unresolved external symbol "strncasecmp" in function "json_is_invalid_number".
cjson.dll : fatal error LNK1120: 1 nicht aufgelöste Externe
Error: Build error: Failed compiling module cjson.dll`
Whats wrong with the installation procedure?
I'm writing my own Makefile to compile my minimum standalone clang tool consisting of the following code:
#include "clang/Tooling/CommonOptionsParser.h"
#include "clang/Tooling/Tooling.h"
using namespace clang;
using namespace clang::driver;
using namespace clang::tooling;
static llvm::cl::OptionCategory ToolingSampleCategory("MetaLift Clang Frontend");
int main (int argc, const char **argv)
{
CommonOptionsParser op(argc, argv, ToolingSampleCategory);
ClangTool Tool(op.getCompilations(), op.getSourcePathList());
return 0;
}
Is there a "proper" order to import the clang libraries? My current order is:
-lclangTooling -lclangSerialization -lclangFrontend
But I keep running into undefined symbols issues.
I find using CMake to be the easiest way to build a libTooling-based application. Here is a minimalistic snippet to compile your example:
# CMakeLists.txt
cmake_minimum_required(VERSION 3.12)
# Find CMake file for Clang
find_package(Clang REQUIRED)
# Add path to LLVM modules
set(CMAKE_MODULE_PATH
${CMAKE_MODULE_PATH}
"${LLVM_CMAKE_DIR}"
)
# import LLVM CMake functions
include(AddLLVM)
include_directories(${LLVM_INCLUDE_DIRS})
include_directories(${CLANG_INCLUDE_DIRS})
add_definitions(${LLVM_DEFINITIONS})
add_definitions(${CLANG_DEFINITIONS})
add_llvm_executable(myTool main.cpp)
set_property(TARGET myTool PROPERTY CXX_STANDARD 11)
target_link_libraries(myTool PRIVATE clangTooling)
// main.cpp
#include "clang/Tooling/CommonOptionsParser.h"
#include "clang/Tooling/Tooling.h"
using namespace clang;
using namespace clang::driver;
using namespace clang::tooling;
static llvm::cl::OptionCategory
ToolingSampleCategory("MetaLift Clang Frontend");
int main(int argc, const char **argv) {
CommonOptionsParser op(argc, argv, ToolingSampleCategory);
ClangTool Tool(op.getCompilations(), op.getSourcePathList());
return 0;
}
I checked the actual commands happening during the build:
c++ -DGTEST_HAS_RTTI=0 -I${CLANG}/include -O3 -DNDEBUG -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -fno-exceptions -fno-rtti -std=gnu++11 -o CMakeFiles/myTool.dir/main.cpp.o -c /Users/vsavchenko/source/c++/clang-makefile/main.cpp
c++ -O3 -DNDEBUG -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk -Wl,-search_paths_first -Wl,-headerpad_max_install_names -Wl,-dead_strip CMakeFiles/myTool.dir/main.cpp.o -o myTool -Wl,-rpath,#loader_path/../lib -Wl,-rpath,${CLANG}/lib ${CLANG}/lib/libclangTooling.a ${CLANG}/lib/libclangASTMatchers.a ${CLANG}/lib/libclangFormat.a ${CLANG}/lib/libclangFrontend.a ${CLANG}/lib/libclangDriver.a ${CLANG}/lib/libclangParse.a ${CLANG}/lib/libLLVMMCParser.a ${CLANG}/lib/libclangSerialization.a ${CLANG}/lib/libclangSema.a ${CLANG}/lib/libclangEdit.a ${CLANG}/lib/libclangAnalysis.a ${CLANG}/lib/libLLVMBitReader.a ${CLANG}/lib/libLLVMProfileData.a ${CLANG}/lib/libclangToolingCore.a ${CLANG}/lib/libclangAST.a ${CLANG}/lib/libclangRewrite.a ${CLANG}/lib/libclangLex.a ${CLANG}/lib/libclangBasic.a ${CLANG}/lib/libLLVMCore.a ${CLANG}/lib/libLLVMBinaryFormat.a ${CLANG}/lib/libLLVMMC.a ${CLANG}/lib/libLLVMOption.a ${CLANG}/lib/libLLVMSupport.a -lz -lcurses -lm /Users/vsavchenko/bin/clang/lib/libLLVMDemangle.a
It looks like the problem is not with the order of Clang libraries, but rather an insufficient set of them. The following command finishes without linking errors:
LIBRARY_PATH=${CLANG}/lib clang++ -std=c++11 -lclangTooling -lclangASTMatchers -lclangFormat -lclangFrontend -lclangDriver -lclangParse -lLLVMMCParser -lclangSerialization -lclangSema -lclangEdit -lclangAnalysis -lLLVMBitReader -lLLVMProfileData -lclangToolingCore -lclangAST -lclangRewrite -lclangLex -lclangBasic -lLLVMCore -lLLVMBinaryFormat -lLLVMMC -lLLVMOption -lLLVMSupport -lz -lcurses -lLLVMDemangle -I${CLANG}/include main.cpp
Happy hacking with Clang!
ESP8266 NONOS SDK: How to compile C++ code?
I'm somehow not able to compile C++ code using the ESP8266 NONOS SDK.
I use the gen_misc.sh-script to configure and compile the program,
but it outputs the following error:
start...
make[1]: Entering directory '/repos/esp/ESP8266_NONOS_SDK/diplomarbeit-firmware/user'
xtensa-lx106-elf-g++ -Os -g -Wpointer-arith -Wundef -Werror -Wl,-EL -fno-inline-functions -nostdlib -mlongcalls -mtext-section-literals -ffunction-sections -fdata-sections -fno-builtin-printf -DICACHE_FLASH -DSPI_FLASH_SIZE_MAP=3 -I include -I ./ -I ../../include/ets -I ../include -I ../../include -I ../../include/eagle -I ../../driver_lib/include -o .output/eagle/debug/obj/user_main.o -c user_main.cpp
xtensa-lx106-elf-ar ru .output/eagle/debug/lib/libuser.a .output/eagle/debug/obj/user_main.o
make[1]: Leaving directory '/repos/esp/ESP8266_NONOS_SDK/diplomarbeit-firmware/user'
xtensa-lx106-elf-gcc -L../lib -nostdlib -T../ld/eagle.app.v6.ld -Wl,--no-check-sections -Wl,--gc-sections -u call_user_start -Wl,-static -Wl,--start-group -lc -lgcc -lhal -lphy -lpp-lnet80211 -llwip -lwpa -lcrypto -lmain -ldriver user/.output/eagle/debug/lib/libuser.a -Wl,--end-group -o .output/eagle/debug/image/eagle.app.v6.out
../lib/libmain.a(app_main.o): In function `user_uart_wait_tx_fifo_empty':
(.irom0.text+0x6a0): undefined reference to `user_pre_init'
../lib/libmain.a(app_main.o): In function `user_uart_wait_tx_fifo_empty':
(.irom0.text+0x6b8): undefined reference to `user_init'
../lib/libmain.a(app_main.o): In function `flash_data_check':
(.irom0.text+0x718): undefined reference to `user_pre_init'
../lib/libmain.a(app_main.o): In function `flash_data_check':
(.irom0.text+0xac1): undefined reference to `user_init'
collect2: error: ld returned 1 exit status
../Makefile:398: recipe for target '.output/eagle/debug/image/eagle.app.v6.out' failed
make: *** [.output/eagle/debug/image/eagle.app.v6.out] Error 1
My code looks like that:
user_main.cpp
#include "user_interface.h"
#include "osapi.h"
#include "partition.h"
void ICACHE_FLASH_ATTR user_pre_init ()
{
// register partition table here
if (!system_partition_table_regist(partition_table,
sizeof(partition_table) / sizeof(partition_table[0]),
SPI_FLASH_SIZE_MAP))
{
os_printf("FAIL TO REGISTER PARTITION TABLE");
while (1) {}
}
}
class MyClass {
};
void user_init ()
{
os_printf("Hello world!\n");
}
I really don't know how to fix this problem.
The header files you are including are C header files, not C++. The C++ compiler will mangle the function names, leading to the above error you see. You need to wrap them in an extern block like this to tell the compiler not to mangle them:
extern "C" {
#include "user_interface.h"
#include "osapi.h"
#include "partition.h"
}