Long story short, I'm building jsoncpp through another library's build system (webrtc's, which to say is behemoth would be an understatement). What that means is that I'm navigating through a build system I have little control over and have little familiarity with.
Suffice to say that when I build libjsoncpp.a on MacOS, the resulting file works perfectly fine. When I compile on Linux, linking with the resulting .a results in undefined reference for everything I use. Diving into the file, I noticed that while the MacOS version appears "normal", like so (excerpt):
0000000000001c10 T __ZNK4Json5ValueeqERKS0_
0000000000001c00 T __ZNK4Json5ValuegeERKS0_
0000000000001bc0 T __ZNK4Json5ValuegtERKS0_
0000000000003d10 T __ZNK4Json5ValueixEPKc
0000000000003de0 T __ZNK4Json5ValueixERKNSt3__112basic_stringIcNS1_11char_traitsIcEENS1_9allocatorIcEEEE
the same portion for the one built for Linux looks like this:
0000000000000000 T _ZNK4Json5ValuegeERKS0_
0000000000000000 T _ZNK4Json5ValuegtERKS0_
0000000000000000 T _ZNK4Json5ValueixEi
0000000000000000 T _ZNK4Json5ValueixEj
0000000000000000 T _ZNK4Json5ValueixEPKc
0000000000000000 T _ZNK4Json5ValueixERKNSt3__112basic_stringIcNS1_11char_traitsIcEENS1_9allocatorIcEEEE
Note that all the values are zero. I suspect that that's a clue to my problem but I just don't know what I'm supposed to conclude from it. I believe my issue with building on Linux is some compilation switch somewhere in the bowels of the build system and knowing what all the zeroes mean could help zero in on what to look for.
Edit: this has nothing to do with jsoncpp specifically. I'm hitting the same issue with other libs. I just picked that as an example.
Edit: Breakthrough. Here's a sample of the command line that's ultimately used to build one the three .o file and the linker command afterwards. Hope that helps.
[3/4] ../../../src/third_party/llvm-build/Release+Asserts/bin/clang++ -MMD -MF obj/third_party/jsoncpp/jsoncpp/json_reader.o.d -DJSON_USE_EXCEPTION=0 -DV8_DEPRECATION_WARNINGS -DUSE_UDEV -DUSE_AURA=1 -DUSE_GLIB=1 -DUSE_NSS_CERTS=1 -DUSE_X11=1 -DFULL_SAFE_BROWSING -DSAFE_BROWSING_CSD -DSAFE_BROWSING_DB_LOCAL -DOFFICIAL_BUILD -DCHROMIUM_BUILD -DFIELDTRIAL_TESTING_ENABLED -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DCR_CLANG_REVISION=\"332335-1\" -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D_FORTIFY_SOURCE=2 -D_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS -D_LIBCXXABI_DISABLE_VISIBILITY_ANNOTATIONS -DCR_LIBCXX_REVISION=332543 -DCR_LIBCXXABI_REVISION=331450 -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -I../../../src/third_party/jsoncpp/source/src/lib_json -I../../../src -Igen -I../../../src/third_party/jsoncpp/overrides/include -I../../../src/third_party/jsoncpp/source/include -fno-strict-aliasing --param=ssp-buffer-size=4 -fstack-protector -funwind-tables -fPIC -pipe -B../../../src/third_party/binutils/Linux_x64/Release/bin -pthread -fcolor-diagnostics -fmerge-all-constants -Xclang -mllvm -Xclang -instcombine-lower-dbg-declare=0 -no-canonical-prefixes -m64 -march=x86-64 -Wall -Wextra -Wimplicit-fallthrough -Wthread-safety -Wno-missing-field-initializers -Wno-unused-parameter -Wno-c++11-narrowing -Wno-covered-switch-default -Wno-unneeded-internal-declaration -Wno-undefined-var-template -Wno-nonportable-include-path -Wno-address-of-packed-member -Wno-unused-lambda-capture -Wno-user-defined-warnings -Wno-enum-compare-switch -Wno-null-pointer-arithmetic -Wno-ignored-pragma-optimize -O2 -fno-ident -fdata-sections -ffunction-sections -fno-omit-frame-pointer -g2 -ggnu-pubnames -fvisibility=hidden -Xclang -load -Xclang ../../../src/third_party/llvm-build/Release+Asserts/lib/libFindBadConstructs.so -Xclang -add-plugin -Xclang find-bad-constructs -Xclang -plugin-arg-find-bad-constructs -Xclang enforce-in-thirdparty-webkit -Xclang -plugin-arg-find-bad-constructs -Xclang check-enum-max-value -Xclang -plugin-arg-find-bad-constructs -Xclang check-ipc -Wheader-hygiene -Wstring-conversion -Wtautological-overlap-compare -std=gnu++11 -fno-exceptions -fno-rtti -nostdinc++ -isystem../../../src/buildtools/third_party/libc++/trunk/include -isystem../../../src/buildtools/third_party/libc++abi/trunk/include -fvisibility-inlines-hidden -c ../../../src/third_party/jsoncpp/overrides/src/lib_json/json_reader.cpp -o obj/third_party/jsoncpp/jsoncpp/json_reader.o
[4/4] python "../../../src/build/toolchain/gcc_ar_wrapper.py" --output=obj/third_party/jsoncpp/libjsoncpp.a --ar="../../../src/third_party/llvm-build/Release+Asserts/bin/llvm-ar" " -r -c -s -D" #"obj/third_party/jsoncpp/libjsoncpp.a.rsp"
There's actually nothing wrong with the values being 0. Presumably, its a by-product of link-time optimization. When a final executable gets produced, the symbols will see their value addresses) assigned.
My actual problem was that I was mixing libraries built with libc++ and other with libstdc++. The unresolved symbols referred to function that had things like std::string or std::unique_ptr as parameters. In this instance, libjsoncpp.a had symbols like Json::Value(std::__1::basic_string) (a constructor that takes a string) because it was build with clang and expecting to be linked with LLVM's libc++ but I was ultimately attempting to link the final executable with GNU's libstdc++ and the symbol Json::Value(std::basic_string) was unresolved.
Related
The image for my embedded (ARM Cortex-M) firmware is significantly bloated from what looks like symbol names, some of which are very long due to C++ templates instantiated with lambda closures. The code is compiled with ARM GCC 10.1 with:
-Os -ffunction-sections -fdata-sections -fno-exceptions -fno-rtti -g0
I have made sure that there are no stray occurences of __PRETTY_FUNCTION__ or similar scattered around.
The strings are found using the arm-none-eabi-strings program, which basically just looks for byte sequences looking like strings. It is run on the binary image, which does not contain debug symbols.
What could be causing strings of type names to be embedded in the image? The code does make use of virtual methods, so vtables are generated. However, I had assumed that -fno-rtti would prevent the generation of type info structures.
EDIT: The compilation process is handled by CMake, but these are the commands run by CMake (with absolute paths removed for readability):
# compile
arm-none-eabi-g++
-I<SDK-includes>
-mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mthumb -mabi=aapcs -mfloat-abi=hard
-Wall -Werror
-ffunction-sections -fdata-sections
-fno-rtti -fconcepts-diagnostics-depth=3 -fno-exceptions
-Os -DNDEBUG -g3 -ftemplate-backtrace-limit=0
-fcoroutines -fno-use-cxa-atexit -std=c++2a -o main.cpp.obj -c main.cpp
# link
arm-none-eabi-g++
-mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mthumb -mabi=aapcs -mfloat-abi=hard
-Werror
-ffunction-sections -fdata-sections
-fno-rtti -fconcepts-diagnostics-depth=3 -fno-exceptions
-Os -DNDEBUG -g3
--specs=nosys.specs -Tlinker-script.ld
-static -Wl,--gc-sections,--entry,Reset_Handler
-Wl,--start-group -lm -lc -lgcc -Wl,--end-group
main.cpp.obj -o main.elf
# extract binary
arm-none-eabi-objcopy
-O binary main.elf main.bin
I have tried with -g0 as-well, but after objcopy, the debug symbols are stripped anyway.
The compiler is GCC 10.1:
arm-none-eabi-g++ (GNU Arm Embedded Toolchain 10-2020-q2-preview) 10.1.1 20200529 (release)
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
I'm building a library (libproj) using g++-9 and CMake (on Xenial, on Travis), so I can statically link it in a Rust crate. My build.rs sets up and runs CMake with the following config:
cmake proj-7.0.1
-DBUILD_SHARED_LIBS=ON
-DBUILD_TESTING=OFF
-DCMAKE_BUILD_TYPE=Release
-DCMAKE_CXX_FLAGS="-std=c++11 -fPIC"
-DCMAKE_INSTALL_PREFIX=[path snipped]/out
-DCMAKE_C_FLAGS= -ffunction-sections -fdata-sections -fPIC -m64
-DCMAKE_C_COMPILER=/usr/bin/gcc-9
-DCMAKE_CXX_COMPILER=/usr/bin/g++-9
-DCMAKE_ASM_FLAGS= -ffunction-sections -fdata-sections -fPIC -m64
-DCMAKE_ASM_COMPILER=/usr/bin/gcc-9
Which builds and installs libproj successfully.
I then tell cargo to statically link it:
cargo:root=[path snipped]/out
cargo:rustc-link-search=native=[path snipped]/out/lib
cargo:rustc-link-lib=static=proj
However, the link step fails, saying I can't use relocation in a shared object:
note: /usr/bin/ld: [path snipped]/out/lib/libproj.a(4D_api.cpp.o): relocation
R_X86_64_32 against `.rodata.str1.8' can not be used when making a
shared object; recompile with -fPIC`
[path snipped]/out/lib/libproj.a(4D_api.cpp.o): error adding symbols: Bad value
collect2: error: ld returned 1 exit status
What am I doing wrong here? I've also tried to build libproj as a static lib by setting BUILD_SHARED_LIBS to OFF as per the install instructions, but that hasn't had any effect.
UPDATE:
I've managed to enable PIC for g++ (by default it's only enabled for gcc)
running: "cmake" "-Wdev" "--debug-output" "[snipped]/proj-7.0.1" "-DCMAKE_CXX_FLAGS=-std=c++11" "-DCMAKE_CXX_FLAGS=-fPIC" "-DBUILD_SHARED_LIBS=OFF" "-DCMAKE_INSTALL_PREFIX=[snipped]/out" "-DCMAKE_C_FLAGS= -ffunction-sections -fdata-sections -fPIC -m64" "-DCMAKE_C_COMPILER=/usr/bin/gcc-9" "-DCMAKE_CXX_COMPILER=/usr/bin/g++-9" "-DCMAKE_ASM_FLAGS= -ffunction-sections -fdata-sections -fPIC -m64" "-DCMAKE_ASM_COMPILER=/usr/bin/gcc-9" "-DCMAKE_BUILD_TYPE=Debug" "-DCMAKE_VERBOSE_MAKEFILE:BOOL=ON"
Resulting in the following g++-9 invocation, which includes -fPIC:
/usr/bin/g++-9 -DCURL_ENABLED -DMUTEX_pthread -DPROJ_LIB=\"/[snip]/proj\" -DTIFF_ENABLED -I/[snip]/src -I/[snip]/include -I/[snip]/src -I/usr/include/x86_64-linux-gnu -fPIC -g -fvisibility=hidden -Wall -Wextra -Wswitch -Wshadow -Wunused-parameter -Wmissing-declarations -Wformat -Wformat-security -std=c++11 -o CMakeFiles/proj.dir/aasincos.cpp.o -c /[snip]/proj/proj-7.0.1/src/aasincos.cpp
However, I know get a completely different error (thousands of lines), that looks like my static library hasn't been correctly linked to the c++11 stdlib:
Error:
undefined reference to std::allocator<char>::allocator()
UPDATE 2:
I've managed to remove the -nodefaultlibs flag from ld. The latest g++ invocation:
/usr/bin/g++-9 -I/[snipped]/src -I/[snipped]/include -I/[snipped]/src -isystem /[snipped]/include -isystem /[snipped]/googletest -fPIC -g -fvisibility=hidden -Wall -Wextra -Wswitch -Wshadow -Wunused-parameter -Wmissing-declarations -Wformat -Wformat-security -pthread -std=c++11 -o CMakeFiles/proj_context_test.dir/proj_context_test.cpp.o -c /[snipped]/proj_context_test.cpp
And I've managed to add lstdc++ to the linker invocation:
"cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-L" "/[snip]/lib" "/home/travis/build/georust/proj-sys/target/debug/deps/proj_sys-95cbd73f2c3f0bde.20tasg77xuhsj5z6.rcgu.o" "/home/travis/build/georust/proj-sys/target/debug/deps/proj_sys-95cbd73f2c3f0bde.57y4784ihm3qw715.rcgu.o" "-o" "/[snip]/deps/proj_sys-95cbd73f2c3f0bde" "/home/travis/build/georust/proj-sys/target/debug/deps/proj_sys-95cbd73f2c3f0bde.3kiafs23968zh4mj.rcgu.o" "-Wl,--gc-sections" "-pie" "-Wl,-zrelro" "-Wl,-znow" "-L" "/home/travis/build/georust/proj-sys/target/debug/deps" "-L" "/home/travis/build/georust/proj-sys/target/debug/build/proj-sys-aff2ac9d43b77886/out/lib" "-L" "/home/travis/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-lsqlite3" "-lcurl" "-ltiff" "-lstdc++" "-Wl,-Bstatic" "-Wl,--whole-archive" "-lproj" "-Wl,--no-whole-archive" [trimmed rlib details] "-Wl,--end-group" "/home/travis/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-2541f1e09df1c67d.rlib" "-Wl,-Bdynamic" "-ldl" "-lrt" "-lpthread" "-lgcc_s" "-lc" "-lm" "-lrt" "-lpthread" "-lutil" "-lutil"
But the undefined reference error remains.
As I can see from your example, you have quotation marks around CMAKE_CXX_FLAGS and do not have ones around CMAKE_C_FLAGS. It looks odd.
I have built libgproj myself with cmake + your flags and with make VERBOSE=1.
I can see, that C-files compiled without fPIC, m64 and fdata-sections. I suppose, that the cause is in the quotation marks around CMAKE_C_FLAGS. I saw your log in Travis, and there is configuration for cmake from cargo:
"cmake" "/home/travis/build/georust/proj-sys/PROJSRC/proj/proj-7.0.1" "-DBUILD_SHARED_LIBS=ON" "-DBUILD_TESTING=OFF" "-DCMAKE_BUILD_TYPE=Release" "-DCMAKE_CXX_FLAGS=-std=c++11 -fPIC" "-DCMAKE_INSTALL_PREFIX=/home/travis/build/georust/proj-sys/target/debug/build/proj-sys-03a5fe6428bb060a/out" "-DCMAKE_C_FLAGS= -ffunction-sections -fdata-sections -fPIC -m64" "-DCMAKE_C_COMPILER=/usr/bin/gcc-9" "-DCMAKE_CXX_COMPILER=/usr/bin/g++-9" "-DCMAKE_ASM_FLAGS= -ffunction-sections -fdata-sections -fPIC -m64" "-DCMAKE_ASM_COMPILER=/usr/bin/gcc-9"
Note, that -DCMAKE_C_FLAGS and CMAKE_CXX_FLAGS escaped with their values, and not values by itself. I suppose, that these options become in the shell:
cmake -DCMAKE_C_FLAGS= -ffunction-sections -fdata-sections -fPIC -m64 -DCVMAKE_CXX_FLAGS=-std=c++11 -fPIC
I have tried this command, without quotation marks and cmake just ignored unknown options. So it will not fail.
I suggest you to add cmake option -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON to cmake configuration or VERBOSE=1 to the make options, if you can, and then you can see real compile options passed to gcc in Travis.
You will see somethig like this:
[ 19%] Building C object src/CMakeFiles/proj.dir/wkt1_generated_parser.c.o
cd [some path]/PROJ/cmake_build/src && /usr/bin/cc -DCURL_ENABLED -DMUTEX_pthread
-DPROJ_LIB=\"/usr/local/share/proj\" -DTIFF_ENABLED -I[some path]PROJ/src -I[some
path]/PROJ/include -I[some path]/PROJ/cmake_build/src -O3 -DNDEBUG -
fvisibility=hidden -Wall -Wextra -Wswitch -Wshadow -Wunused-parameter -Wmissing-
declarations -Wformat -Wformat-security -Wmissing-prototypes -std=c99 -o
CMakeFiles/proj.dir/wkt1_generated_parser.c.o -c [some
path]/PROJ/src/wkt1_generated_parser.c
Conclusion:
You can try adding verbosity to see real compile options.
You can try to escape options properly, if it's necessary after first step.
Also I want to note, that SHARED_BUILD_LIBS=ON in my test forbids building static lib, which you want to link. When I set shared libs building setting option to OFF, static lib was built.
I am trying to write a script that uses a library compiled with clang and another library compiled with G++, I get the following error:
ld.lld: error: undefined symbol: myFunction()
Which (according to this Difference between string and char[] types in C++) is apparently due to std::string meaning different things in different versions of G++ and clang.
Does this mean I have to rewrite the Makefile of my target library to use the same version of G++/Clang? Because that seems like an awful amount of effort just to link a prewritten library, and I think I must be missing something here.
More info
I am compiling v8_shell using ninja -C out/debug
defines = -DUSE_UDEV -DUSE_AURA=1 -DUSE_GLIB=1 -DUSE_NSS_CERTS=1 -DUSE_X11=1 -DNO_TCMALLOC -DMEMORY_TOOL_REPLACES_ALLOCATOR -DMEMORY_SANITIZER_INITIAL_SIZE -DADDRESS_SANITIZER -DFULL_SAFE_BROWSING -DSAFE_BROWSING_CSD -DSAFE_BROWSING_DB_LOCAL -DCHROMIUM_BUILD -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_GNU_SOURCE -DCR_CLANG_REVISION=\"353250-1\" -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -DCOMPONENT_BUILD -D_LIBCPP_ABI_UNSTABLE -D_LIBCPP_ABI_VERSION=Cr -DCR_LIBCXX_REVISION=349080 -DCR_LIBCXXABI_REVISION=347903 -D_LIBCPP_ENABLE_NODISCARD -DCR_SYSROOT_HASH=e7c53f04bd88d29d075bfd1f62b073aeb69cbe09 -D_DEBUG -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DWTF_USE_DYNAMIC_ANNOTATIONS=1 -DENABLE_DISASSEMBLER -DV8_TYPED_ARRAY_MAX_SIZE_IN_HEAP=64 -DENABLE_GDB_JIT_INTERFACE -DENABLE_MINOR_MC -DOBJECT_PRINT -DVERIFY_HEAP -DV8_TRACE_MAPS -DV8_ENABLE_ALLOCATION_TIMEOUT -DV8_ENABLE_FORCE_SLOW_PATH -DV8_INTL_SUPPORT -DENABLE_HANDLE_ZAPPING -DV8_USE_SNAPSHOT -DV8_USE_EXTERNAL_STARTUP_DATA -DV8_CONCURRENT_MARKING -DV8_CHECK_MICROTASKS_SCOPES_CONSISTENCY -DV8_EMBEDDED_BUILTINS -DV8_ENABLE_CHECKS -DV8_DEPRECATION_WARNINGS -DV8_IMMINENT_DEPRECATION_WARNINGS -DV8_TARGET_ARCH_X64 -DDEBUG -DDISABLE_UNTRUSTED_CODE_MITIGATIONS -DUSING_V8_SHARED -DV8_ENABLE_CHECKS -DV8_DEPRECATION_WARNINGS -DV8_IMMINENT_DEPRECATION_WARNINGS -DU_USING_ICU_NAMESPACE=0 -DU_ENABLE_DYLOAD=0 -DUSE_CHROMIUM_ICU=1 -DICU_UTIL_DATA_IMPL=ICU_UTIL_DATA_FILE -DUCHAR_TYPE=uint16_t -DUSING_V8_BASE_SHARED -DUSING_V8_PLATFORM_SHARED
include_dirs = -I../.. -Igen -I../.. -Igen -I../../include -Igen/include -I../../third_party/icu/source/common -I../../third_party/icu/source/i18n -I../../include
cflags = -fno-strict-aliasing --param=ssp-buffer-size=4 -fstack-protector -Wno-builtin-macro-redefined -D__DATE__= -D__TIME__= -D__TIMESTAMP__= -funwind-tables -fPIC -B../../third_party/binutils/Linux_x64/Release/bin -pthread -fcolor-diagnostics -fmerge-all-constants -Xclang -mllvm -Xclang -instcombine-lower-dbg-declare=0 -no-canonical-prefixes -fcomplete-member-pointers -m64 -march=x86-64 -Wall -Werror -Wextra -Wimplicit-fallthrough -Wthread-safety -Wno-missing-field-initializers -Wno-unused-parameter -Wno-c++11-narrowing -Wno-unneeded-internal-declaration -Wno-undefined-var-template -Wno-ignored-pragma-optimize -fno-omit-frame-pointer -g2 -gsplit-dwarf -ggnu-pubnames -gcolumn-info -fsanitize=address -fsanitize-address-use-after-scope -fsanitize-blacklist=../../tools/memory/asan/blacklist.txt -fvisibility=hidden -Wheader-hygiene -Wstring-conversion -Wtautological-overlap-compare -Wmissing-field-initializers -Wextra-semi -Winconsistent-missing-override -Wunreachable-code -Wshorten-64-to-32 -O2 -fno-ident -fdata-sections -ffunction-sections
cflags_cc = -Wno-undefined-bool-conversion -Wno-tautological-undefined-compare -std=c++14 -fno-exceptions -fno-rtti -nostdinc++ -isystem../../buildtools/third_party/libc++/trunk/include -isystem../../buildtools/third_party/libc++abi/trunk/include --sysroot=../../build/linux/debian_sid_amd64-sysroot -fvisibility-inlines-hidden
label_name = v8_shell
target_out_dir = obj
target_output_name = v8_shell
build obj/v8_shell/shell.o: cxx ../../samples/shell.cc || obj/generate_bytecode_builtins_list.stamp obj/run_torque.stamp obj/v8_dump_build_config.stamp obj/src/inspector/protocol_generated_sources.stamp obj/third_party/icu/icudata.stamp
build ./v8_shell: link obj/v8_shell/shell.o obj/build/config/sanitizers/liboptions_sources.a | ./libv8.so.TOC ./libv8_libbase.so.TOC ./libv8_libplatform.so.TOC ./libicui18n.so.TOC ./libicuuc.so.TOC ./libc++.so.TOC || obj/build/win/default_exe_manifest.stamp obj/v8_dump_build_config.stamp obj/build/config/executable_deps.stamp
ldflags = -pie -Wl,--fatal-warnings -fPIC -Wl,-z,noexecstack -Wl,-z,relro -fuse-ld=lld -Wl,--color-diagnostics -m64 -Werror -Wl,--gdb-index -rdynamic -nostdlib++ --sysroot=../../build/linux/debian_sid_amd64-sysroot -L../../build/linux/debian_sid_amd64-sysroot/usr/local/lib/x86_64-linux-gnu -Wl,-rpath-link=../../build/linux/debian_sid_amd64-sysroot/usr/local/lib/x86_64-linux-gnu -L../../build/linux/debian_sid_amd64-sysroot/lib/x86_64-linux-gnu -Wl,-rpath-link=../../build/linux/debian_sid_amd64-sysroot/lib/x86_64-linux-gnu -L../../build/linux/debian_sid_amd64-sysroot/usr/lib/x86_64-linux-gnu -Wl,-rpath-link=../../build/linux/debian_sid_amd64-sysroot/usr/lib/x86_64-linux-gnu -fsanitize=address -fsanitize-address-use-after-scope -pie -Wl,-rpath-link=. -Wl,--disable-new-dtags -Wl,-rpath=\$$ORIGIN/. -Wl,-rpath-link=. -Wl,-O2 -Wl,--gc-sections -Wl,-u_sanitizer_options_link_helper -fsanitize=address -fsanitize-address-use-after-scope
libs = -L . -ldl -lpthread -lrt
output_extension =
output_dir = .
solibs = ./libtester.so ./libv8.so ./libv8_libbase.so ./libv8_libplatform.so ./libicui18n.so ./libicuuc.so ./libc++.so
Link to code is here:
https://github.com/v8/v8/blob/master/samples/shell.cc
All I have done is add a test library that returns a std::string and this is called from shell.cc.
This test library is compiled with
clang++ -shared -o libtester tester.cpp -fPIC -L . -lpthread
Which yields undefined symbol errors.
I can get it to compile by forcing libc++ that v8 seems to use, but then I get a whole host of core dumps and other errors at runtime, so I don't think thats a legitimate fix.
clang++ -shared -o libtester.so tester.cpp -fPIC -std=c++11 -L . -stdlib=libc++ -lpthread
Example code snippet:
tester.cpp
std::string myFunction() {
std::string newstring;
// do something
return newstring;
}
shell.cc
std::string test = myFunction();
cout << test;
Update please see these posts that document it further C++ Undefined symbol related to std::string in static lib
Can't link libFuzzer.a using clang with libc++
Theres no real answer apart from use libstdc++ rather than libc++ for everything, but thats not really an option to convert an entire project like v8 to libstdc++
The build recipe you use for V8 builds it with -D_LIBCPP_ABI_UNSTABLE -D_LIBCPP_ABI_VERSION=Cr -DCR_LIBCXX_REVISION=349080 -DCR_LIBCXXABI_REVISION=347903. According to libc++ ABI stability, these macros affect the library ABI. Your separate compilation uses just -stdlib=libc++, so it does not enable the incompatible ABI.
You might get better results if you use a different recipe for building V8, something that uses the system C++ standard library with its default (stable) ABI.
This is the solution for compiling v8 with libstdc++.
Type the following command
gn args out/stdc
Add the following arguments to the args file:
is_clang = true
use_custom_libcxx_for_host=false
use_custom_libcxx=false
libcxx_abi_unstable=false
Build with
ninja -C out/stdc
I am compiling an example application from the SDK repository of a third party vendor. I receive an error that one of the C++ header's (algorithm) cannot be found:
if [ ! -d .deps/ ]; then mkdir -p .deps/; fi
/opt/llvm-3.8.0/bin/clang++ -M -isystem/opt/tbricks/sdk/include64 -I../../.. -I../../../.. -I./../../../.. -DLINUX -DLINUX64 -DTB_USE_RCU -DURCU_INLINE_SMALL_FUNCTIONS -DU_USING_ICU_NAMESPACE=0 -DNDEBUG -D_POSIX_PTHREAD_SEMANTICS -fPIC -D_GNU_SOURCE -DTB_USE_RCU -DTB_USE_RCU -D_GLIBCXX_USE_CXX11_ABI=0 -m64 --gcc-toolchain=/opt/gcc-5.2.0 -flto=full -std=gnu++14 -D_GLIBCXX_DEPRECATED= -pipe -fno-omit-frame-pointer -ffast-math -fno-finite-math-only -pthread -march=core2 -mtune=corei7 -g -O3 -Qunused-arguments -fnon-call-exceptions -fvisibility=hidden -fvisibility-inlines-hidden -Wall -Wextra -Wshadow -Wpointer-arith -Wno-self-assign -Wno-unused-function -Wno-gnu-empty-initializer -Wno-unused-parameter -Wno-ignored-qualifiers -Wno-mismatched-tags -Wno-unused-local-typedef -Wno-parentheses-equality -Wno-unused-private-field -Wno-missing-field-initializers -Wno-missing-braces -Werror=return-type -Werror=overloaded-virtual -DSTRATEGY_BUILD_PROFILE=\"release\" ../../../../shared/Helpers.cpp > .deps/Helpers.o.d
../../../../shared/Helpers.cpp:14:10: fatal error: 'algorithm' file not found
#include <algorithm>
What sets the location path to search for C++ header files, such as algorithm? Is there anything I can grep for within makefiles?
Either install g++ alongside (you need libstdc++) or use LLVM libc++ and specify it with -stdlib=libc++
I have this standalone C++ code
that I'm trying to wrap in an R
package.
My problem is that I absolutely
want it to be compiled with the
-O3 flag on.
So in the src/Makevars file
I put:
PKG_CPPFLAGS = -I../inst/include
PKG_CXXFLAGS = -O3
CXX_STD = CXX11
and still when I install my package on my
machine, I see:
g++ -std=c++0x -I/usr/share/R/include -DNDEBUG -I../inst/include -O3 -fpic -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security -D_FORTIFY_SOURCE=2 -g -c mycppfunctions.cpp -o mycppfunctions.o
g++ -std=c++0x -shared -Wl,-Bsymbolic-functions -Wl,-z,relro -o mycppfunctions.so mycppfunctions.o -L/usr/lib/R/lib -lR
(the dreaded -O2 flag appears to the right)
so my question is: how can I overwrite the
cpp flags used when g++ is invoked by R CMD?
Edit:
Recently, in another package, I found a way to do
something similar for a F77 code (also in an R package).
Basically, by adding this to the Makevars:
PKG_FFLAGS = $(FPICFLAGS) $(SHLIB_FFLAGS)
all: $(SHLIB)
otherf77foo.o: otherf77foo.f
$(F77) $(PGK_FFLAGS) -O3 -pipe -g -c -o otherf77foo.o otherf77foo.f
but I don't know how to do the same for a cpp code...
Edit2:
So, doing this is totally possible. Dirk Eddelbuettel question 'b)' from his answer below
guided me to the solution. So, all I had to do was to
place this in the src/Makevars file:
mycppfoo.o: mycppfoo.cpp
g++ -std=c++0x -I/usr/share/R/include -DNDEBUG -I../inst/include -fpic -g -O3 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security -D_FORTIFY_SOURCE=2 -g -c mycppfoo.cpp -o mycppfoo.o
g++ -std=c++0x -shared -Wl,-Bsymbolic-functions -Wl,-z,relro -o mycppfoo.so mycppfoo.o -L/usr/lib/R/lib -lR
and my problem was solved!
You can't (as per a comment by Simon Urbanek on r-devel a while back).
But it should not matter as AFAIK the right-most value wins. And R puts its values to the left, and lets you add your values (eg via CXX_FLAGS from, say, ~/.R/Makevars or PKG_CXXFLAGS from the src/Makevars in your package) to the right.
So just override with -O3 and it should be -O3.
For what it is worth, my current values in ~/.R/Makevars are:
CFLAGS += -O3 -Wall -pipe -pedantic -std=gnu99
CXXFLAGS += -O3 -Wall -pipe -Wno-unused -pedantic
and you could of course throw in -mnative or your specific CPU identifier.
Lastly, if you really wanted you could edit /etc/R/Makeconf but you'd have to do that
after each upgrade of the R package. And as I argue here you do not need to as the scheme suggested here should work.
Edit: In response to your edit:
a) The clear recommendation on r-devel (please check the archives) is that you should avoid Makefile logic if you can. IIRC this echoed in the Writing R Extension manual.
b) You declared a rule to build an .o (object) file from an .f (source) file. Did you try doing the same with cpp instead of f?
Lastly, you have not explained exactly why the world is coming to an end if your file is built with -O2 rather than -O3. You should understand that as an author of source, you can't fully control with which compiler options (let alone compiler versions) people will build your package.
newedit: Okay I'm a fool. It solved the problem for Rcpp (which I don't care about), but it doesn't work for the github.com/ohdsi/cyclops.git package that I do care about. That one still gets -O2 stuck right-most. This is ridiculous. Control over command-line parameters might be the single most important piece of this entire operation. R needs a better build system.
edit: Of course after days of trouble, I figure it out right after posting. My problem was that I was using the CXX_STD = CXX11 flag. Apparently with this flag you need to use CXX11FLAGS += .... So if your Makevars file contains CXX11FLAGS += -O0 -Wall it will correctly put this to the right of the -O2 flag if you're using C++11.
No matter what I do I can't get -O0 to show up on the right. I have the following in my ~/.R/Makevars:
CFLAGS += -O0 -Wall
CXXFLAGS += -O0 -Wall
CPPFLAGS += -O0 -Wall
PKG_CFLAGS += -O0 -Wall
PKG_CXXFLAGS += -O0 -Wall
PKG_CPPFLAGS += -O0 -Wall
I have installed Rcpp from source (as a test...I'm not interested in it directly) using
install.packages(getwd(), repos = NULL, type = "source")
and that did correctly use -O0.
With my current configuration, I end up getting three different -O0's to the left and final -O2 on the right. Has anyone else run into this problem?
The software I'm installing is at github.com/ohdsi/cyclops.git, though I'm not sure what that would be important.