I found that providing few options to llvm-clang I can compile to other platform. This for example will compile for ios:
clang -cc1 -triple arm-apple-darwin -emit-obj -mrelax-all -disable-free -main-file-name six.c -pic-level 1 -mdisable-fp-elim -masm-verbose -target-abi apcs-gnu -target-cpu arm7tdmi -msoft-float -mfloat-abi soft -target-feature +soft-float -target-feature +soft-float-abi -target-feature -neon -ferror-limit 1 -fmessage-length 122 -stack-protector 1 -mstackrealign -fblocks -fsjlj-exceptions -fcolor-diagnostics prog.c -o -c
As a result you get the prog.o, which you need to copy to native platform and link with native ld. But object file is already compiled for that platform!
Now the last step is to avoid using native linker on the remote. I need a cross-linker for that. But where to get one? Or does llvm contain one and I just need to use the right options? Or I need to compoile GNU LD with the support of cross-platform? From my experience, compiling LD is not possible without expert knowledge of it.
I have versions of the gnu tools that I use with clang at http://ellcc.org. I build under Linux (you didn't mention a host OS). I build assemblers, ld and other utilities, as well as gdb to support the ARM, i386, Microblaze, Mips, PowerPC, PowerPC64, and X86_64. The cool thing about my build is that I take advantage of the GNU tools ability to be compiled to support multiple targets. ld, gdb, and most of the utilites support all the processors. Only as needs a separate binary for each target.
Related
I am new to c++. Today, I installed llvm, clang and libc++ as https://clang.llvm.org/get_started.html instructed.
$ llvm-config --version
6.0.0svn-r311975
$ clang --version
clang version 6.0.0 (trunk 311975)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/jzhu/build/bin
I tried to follow the example http://clang.llvm.org/docs/RAVFrontendAction.html by creating files called FindClassDecls.cpp and CMakeLists.txt The only difference is I used <> instead of "" to include the clang header files.
Then when I tried to compile the .ccp file with
clang++ -v -std=c++11 -stdlib=libc++ -I/home/jzhu/llvm/tools/clang/include -I/home/jzhu/llvm/include -I/home/jzhu/build/include -I/home/jzhu/build/tools/clang/include -L/home/jzhu/build/lib FindClassDecls.cpp
It gives
clang version 6.0.0 (trunk 311975)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/jzhu/build/bin
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.0.0
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.0
Candidate multilib: .;#m64
Selected multilib: .;#m64
"/home/jzhu/build/bin/clang-6.0" -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name FindClassDecls.cpp -mrelocation-model static -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64 -v -dwarf-column-info -debugger-tuning=gdb -resource-dir /home/jzhu/build/lib/clang/6.0.0 -I /home/jzhu/build/include -I /home/jzhu/build/tools/clang/include -internal-isystem /home/jzhu/build/bin/../include/c++/v1 -internal-isystem /usr/local/include -internal-isystem /home/jzhu/build/lib/clang/6.0.0/include -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -std=c++11 -fdeprecated-macro -fdebug-compilation-dir /home/jzhu/sandbox -ferror-limit 19 -fmessage-length 140 -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/FindClassDecls-71cf4e.o -x c++ FindClassDecls.cpp
clang -cc1 version 6.0.0 based upon LLVM 6.0.0svn-r311975 default target x86_64-unknown-linux-gnu
ignoring nonexistent directory "/include"
#include "..." search starts here:
#include <...> search starts here:
/home/jzhu/build/include
/home/jzhu/build/tools/clang/include
/home/jzhu/build/bin/../include/c++/v1
/usr/local/include
/home/jzhu/build/lib/clang/6.0.0/include
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
"/usr/bin/ld" -z relro --hash-style=gnu --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o a.out /usr/lib/gcc/x86_64-linux-gnu/5.4.0/../../../x86_64-linux-gnu/crt1.o /usr/lib/gcc/x86_64-linux-gnu/5.4.0/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/5.4.0/crtbegin.o -L/usr/lib/gcc/x86_64-linux-gnu/5.4.0 -L/usr/lib/gcc/x86_64-linux-gnu/5.4.0/../../../x86_64-linux-gnu -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/5.4.0/../../.. -L/home/jzhu/build/bin/../lib -L/lib -L/usr/lib /tmp/FindClassDecls-71cf4e.o -lc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/x86_64-linux-gnu/5.4.0/crtend.o /usr/lib/gcc/x86_64-linux-gnu/5.4.0/../../../x86_64-linux-gnu/crtn.o
/tmp/main-3a7b68.o: In function `main':
main.cpp:(.text+0xa0): undefined reference to `clang::tooling::runToolOnCode(clang::FrontendAction*, llvm::Twine const&, llvm::Twine const&, std::__1::shared_ptr<clang::PCHContainerOperations>)'
/tmp/main-3a7b68.o: In function `clang::ASTFrontendAction::ASTFrontendAction()':
main.cpp:(.text._ZN5clang17ASTFrontendActionC2Ev[_ZN5clang17ASTFrontendActionC2Ev]+0x1b): undefined reference to `clang::FrontendAction::FrontendAction()'
main.cpp:(.text._ZN5clang17ASTFrontendActionC2Ev[_ZN5clang17ASTFrontendActionC2Ev]+0x21): undefined reference to `vtable for clang::ASTFrontendAction'
/tmp/main-3a7b68.o: In function `clang::ASTConsumer::ASTConsumer()':
main.cpp:(.text._ZN5clang11ASTConsumerC2Ev[_ZN5clang11ASTConsumerC2Ev]+0x6): undefined reference to `vtable for clang::ASTConsumer'
/tmp/main-3a7b68.o: In function `clang::RecursiveASTVisitor<FindNamedClassVisitor>::TraverseCapturedDecl(clang::CapturedDecl*)':
...
more undefined reference errors
...
/tmp/main-3a7b68.o:(.data+0x0): undefined reference to `llvm::EnableABIBreakingChecks'
/tmp/main-3a7b68.o:(.rodata._ZTV20FindNamedClassAction[_ZTV20FindNamedClassAction]+0x28): undefined reference to `clang::ASTFrontendAction::ExecuteAction()'
/tmp/main-3a7b68.o:(.rodata._ZTV20FindNamedClassAction[_ZTV20FindNamedClassAction]+0x38): undefined reference to `clang::FrontendAction::shouldEraseOutputFiles()'
/tmp/main-3a7b68.o:(.rodata._ZTI20FindNamedClassAction[_ZTI20FindNamedClassAction]+0x10): undefined reference to `typeinfo for clang::ASTFrontendAction'
/tmp/main-3a7b68.o:(.rodata._ZTV22FindNamedClassConsumer[_ZTV22FindNamedClassConsumer]+0x28): undefined reference to `clang::ASTConsumer::HandleTopLevelDecl(clang::DeclGroupRef)'
/tmp/main-3a7b68.o:(.rodata._ZTV22FindNamedClassConsumer[_ZTV22FindNamedClassConsumer]+0x38): undefined reference to `clang::ASTConsumer::HandleInterestingDecl(clang::DeclGroupRef)'
/tmp/main-3a7b68.o:(.rodata._ZTV22FindNamedClassConsumer[_ZTV22FindNamedClassConsumer]+0x60): undefined reference to `clang::ASTConsumer::HandleTopLevelDeclInObjCContainer(clang::DeclGroupRef)'
/tmp/main-3a7b68.o:(.rodata._ZTV22FindNamedClassConsumer[_ZTV22FindNamedClassConsumer]+0x68): undefined reference to `clang::ASTConsumer::HandleImplicitImportDecl(clang::ImportDecl*)'
/tmp/main-3a7b68.o:(.rodata._ZTI22FindNamedClassConsumer[_ZTI22FindNamedClassConsumer]+0x10): undefined reference to `typeinfo for clang::ASTConsumer'
clang-6.0: error: linker command failed with exit code 1 (use -v to see invocation)
Questions:
Do I suppose to build the .cpp file with such arguments?
How to avoid manually enter the path to the header files every time I run the clang++ compiler.
Have I done something wrong?
Do I need a -L for which library do I need to link (crt1.o? crti.o?)
/home/jzhu/build/lib$ ls
Analysis libc++.so.1.0
libLLVMHexagonInfo.a libLLVMSparcCodeGen.a AsmParser
libDynamicLibraryLib.a libLLVMInstCombine.a
libLLVMSparcDesc.a BinaryFormat libgtest.a
libLLVMInstrumentation.a libLLVMSparcDisassembler.a Bitcode
libgtest_main.a libLLVMInterpreter.a
libLLVMSparcInfo.a BugpointPasses.so
libLLVMAArch64AsmParser.a libLLVMipo.a
libLLVMSupport.a clang
libLLVMAArch64AsmPrinter.a libLLVMIRReader.a
libLLVMSymbolize.a cmake
libLLVMAArch64CodeGen.a libLLVMLanaiAsmParser.a
libLLVMSystemZAsmParser.a CMakeFiles
libLLVMAArch64Desc.a libLLVMLanaiAsmPrinter.a
libLLVMSystemZAsmPrinter.a cmake_install.cmake
libLLVMAArch64Disassembler.a libLLVMLanaiCodeGen.a
libLLVMSystemZCodeGen.a CodeGen
libLLVMAArch64Info.a libLLVMLanaiDesc.a
libLLVMSystemZDesc.a DebugInfo
libLLVMAArch64Utils.a libLLVMLanaiDisassembler.a
libLLVMSystemZDisassembler.a Demangle
libLLVMAMDGPUAsmParser.a libLLVMLanaiInfo.a
libLLVMSystemZInfo.a ExecutionEngine
libLLVMAMDGPUAsmPrinter.a libLLVMLibDriver.a
libLLVMTableGen.a FuzzMutate
libLLVMAMDGPUCodeGen.a libLLVMLineEditor.a
libLLVMTarget.a IR libLLVMAMDGPUDesc.a
libLLVMLinker.a libLLVMTestingSupport.a IRReader
libLLVMAMDGPUDisassembler.a libLLVMLTO.a
libLLVMTransformUtils.a libc++.a
libLLVMAMDGPUInfo.a libLLVMMC.a
libLLVMVectorize.a libc++abi.a
libLLVMAMDGPUUtils.a libLLVMMCDisassembler.a
libLLVMWindowsManifest.a libc++abi.so
libLLVMAnalysis.a libLLVMMCJIT.a
libLLVMX86AsmParser.a libc++abi.so.1
libLLVMARMAsmParser.a libLLVMMCParser.a
libLLVMX86AsmPrinter.a libc++abi.so.1.0
libLLVMARMAsmPrinter.a libLLVMMipsAsmParser.a
libLLVMX86CodeGen.a libc++experimental.a
libLLVMARMCodeGen.a libLLVMMipsAsmPrinter.a
libLLVMX86Desc.a libclangAnalysis.a libLLVMARMDesc.a
libLLVMMipsCodeGen.a libLLVMX86Disassembler.a
libclangARCMigrate.a libLLVMARMDisassembler.a
libLLVMMipsDesc.a libLLVMX86Info.a libclangAST.a
libLLVMARMInfo.a libLLVMMipsDisassembler.a
libLLVMX86Utils.a libclangASTMatchers.a libLLVMARMUtils.a
libLLVMMipsInfo.a libLLVMXCoreAsmPrinter.a libclangBasic.a
libLLVMAsmParser.a libLLVMMIRParser.a
libLLVMXCoreCodeGen.a libclangCodeGen.a
libLLVMAsmPrinter.a libLLVMMSP430AsmPrinter.a
libLLVMXCoreDesc.a libclangDriver.a
libLLVMBinaryFormat.a libLLVMMSP430CodeGen.a
libLLVMXCoreDisassembler.a libclangDynamicASTMatchers.a
libLLVMBitReader.a libLLVMMSP430Desc.a
libLLVMXCoreInfo.a libclangEdit.a
libLLVMBitWriter.a libLLVMMSP430Info.a
libLLVMXRay.a libclangFormat.a libLLVMBPFAsmPrinter.a
libLLVMNVPTXAsmPrinter.a libLTO.so libclangFrontend.a
libLLVMBPFCodeGen.a libLLVMNVPTXCodeGen.a
libLTO.so.6 libclangFrontendTool.a libLLVMBPFDesc.a
libLLVMNVPTXDesc.a libLTO.so.6.0.0svn libclangIndex.a
libLLVMBPFDisassembler.a libLLVMNVPTXInfo.a LineEditor
libclangLex.a libLLVMBPFInfo.a
libLLVMObjCARCOpts.a Linker libclangParse.a
libLLVMCodeGen.a libLLVMObject.a
LLVMHello.so libclangRewrite.a libLLVMCore.a
libLLVMObjectYAML.a LTO libclangRewriteFrontend.a
libLLVMCoroutines.a libLLVMOption.a Makefile
libclangSema.a libLLVMCoverage.a
libLLVMOrcJIT.a MC libclangSerialization.a
libLLVMDebugInfoCodeView.a libLLVMPasses.a Object
libclang.so libLLVMDebugInfoDWARF.a
libLLVMPowerPCAsmParser.a ObjectYAML libclang.so.6
libLLVMDebugInfoMSF.a libLLVMPowerPCAsmPrinter.a Option
libclang.so.6.0 libLLVMDebugInfoPDB.a
libLLVMPowerPCCodeGen.a Passes libclangStaticAnalyzerCheckers.a
libLLVMDemangle.a libLLVMPowerPCDesc.a
ProfileData libclangStaticAnalyzerCore.a libLLVMDlltoolDriver.a
libLLVMPowerPCDisassembler.a Support libclangStaticAnalyzerFrontend.a
libLLVMExecutionEngine.a libLLVMPowerPCInfo.a TableGen
libclangTooling.a libLLVMFuzzMutate.a
libLLVMProfileData.a Target libclangToolingASTDiff.a
libLLVMGlobalISel.a libLLVMRuntimeDyld.a Testing
libclangToolingCore.a libLLVMHexagonAsmParser.a
libLLVMScalarOpts.a ToolDrivers libclangToolingRefactor.a
libLLVMHexagonCodeGen.a libLLVMSelectionDAG.a Transforms
libc++.so libLLVMHexagonDesc.a
libLLVMSparcAsmParser.a WindowsManifest libc++.so.1
libLLVMHexagonDisassembler.a libLLVMSparcAsmPrinter.a XRay
ps: I installed llvm in my home folder e.g. ~/llvm and ~/build for more details please see the arguments that I passed in to help the compiler find those header files above.
Much appreciated for any suggestion that can point me to the right direction.
I'm on a project where I need to use libc++. I'm come up with the following problem:
When I try to compile the following code:
#include <string>
int main()
{
std::string::size_type (std::string::*function)() const = &std::string::size;
return 0;
}
I get the following error:
ld: symbol(s) not found for architecture x86_64
If I use the libstdc++ instead of libc++ I get no errors so the issue should to be related with libc++.
Full output below:
clang++ --stdlib=libc++ -v main.cpp
Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.1.0
Thread model: posix
"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang" -cc1 -triple x86_64-apple-macosx10.10.0 -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name main.cpp -mrelocation-model pic -pic-level 2 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 241.9 -v -resource-dir /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.0 --stdlib=libc++ -fdeprecated-macro -fdebug-compilation-dir /Users/filipe/Downloads -ferror-limit 19 -fmessage-length 197 -stack-protector 1 -mstackrealign -fblocks -fobjc-runtime=macosx-10.10.0 -fencode-extended-block-signature -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -vectorize-slp -o /var/folders/8k/34ll5dcj3c5c9sph_bwk1zr00000gn/T/main-5b89bb.o -x c++ main.cpp
clang -cc1 version 6.0 based upon LLVM 3.5svn default target x86_64-apple-darwin14.1.0
ignoring nonexistent directory "/usr/include/c++/v1"
#include "..." search starts here:
#include <...> search starts here:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1
/usr/local/include
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.0/include
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
/usr/include
/System/Library/Frameworks (framework directory)
/Library/Frameworks (framework directory)
End of search list.
"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld" -demangle -dynamic -arch x86_64 -macosx_version_min 10.10.0 -o a.out /var/folders/8k/34ll5dcj3c5c9sph_bwk1zr00000gn/T/main-5b89bb.o -lc++ -lSystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.0/lib/darwin/libclang_rt.osx.a
Undefined symbols for architecture x86_64:
"std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::size() const", referenced from:
_main in main-5b89bb.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
This looks like a libc++ bug by this thread: _LIBCPP_INLINE_VISIBILITY and std::string::length which doing something similar and Howard Hinnant's response is:
I believe this is due to a poor interaction in the compiler between
extern templates and __attribute__ ((__always_inline__)). If
std::string is not declared extern template, then the compiler will
outline a size() member and you won't get this link error.
In my opinion, clang should not assume that extern templates have
definitions for inlined members, especially those marked
always_inline, and the fact that it does is a clang bug resulting in
the link error you see.
The rationale for the use of always_inline in libc++ is to control the
ABI of libc++. In the past I have watched compilers use different
heuristics from release to release on making the inline/outline
decision. This can cause code to be silently added to and removed
from a dylib. With the use of always_inline, I am telling the
compiler to never add that code to the libc++.dylib binary.
Each of the macros defined and used by libc++ can be overridden.
_LIBCPP_INLINE_VISIBILITY controls how an inlined function is attributed and defaults to:
#ifndef _LIBCPP_INLINE_VISIBILITY
#define _LIBCPP_INLINE_VISIBILITY __attribute__ ((__visibility__("hidden"), __always_inline__))
#endif
You can turn this off with:
-D_LIBCPP_INLINE_VISIBILITY=""
And extern templates are done with:
#ifndef _LIBCPP_EXTERN_TEMPLATE
#define _LIBCPP_EXTERN_TEMPLATE(...) extern template __VA_ARGS__;
#endif
This latter one is more difficult to "turn off". The incantation is:
-D'_LIBCPP_EXTERN_TEMPLATE(...)='
Using either (or both) of these workarounds will silence your link
error. But a bug report against clang might be a better long term
solution.
I can not reproduce this on coliru but I can on wandbox and using optimization which uses the -O2 flag makes the problem go away. I was not able to make wandbox accept the -D options suggested above, so not sure if that works.
On my local machine Howard's solution works:
clang++ -D_LIBCPP_INLINE_VISIBILITY="" -D'_LIBCPP_EXTERN_TEMPLATE(...)='
I have not found a bug report, if I don't find one it may make sense to file one.
After looking into Shafik Yaghmour information, I found a solution that doesn't require modifying the compilation flags.
The solution is forcing the compiler to instantiate the extern template class. The final code is the following:
#include <string>
template class std::basic_string<char>;
int main()
{
std::string::size_type (std::string::*function)() const = &std::string::size;
return 0;
}
More information here: using extern template (C++11)
I have the following program:
#include <stdio.h>
int bob() {
printf("bob\n");
return 0;
}
int main() {
printf("main\n");
return 0;
}
On Linux, I can enable a custom entry point via:
gcc test.c -Wl,-e,bob
When I run the resulting program, I get:
./a.out
bob
On OS X, however, this doesn't work:
clang test.c -Wl,-e,bob
./a.out
main
I've tried everything to get this to work. I think it might be a bug. Here's the output with the -v option:
clang test.c -Wl,-e,bob -v
Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin13.3.0
Thread model: posix
"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang" -cc1 -triple x86_64-apple-macosx10.9.0 -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name test.c -mrelocation-model pic -pic-level 2 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 236.3 -v -resource-dir /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/5.1 -fdebug-compilation-dir /Users/mfichman/jogo -ferror-limit 19 -fmessage-length 125 -stack-protector 1 -mstackrealign -fblocks -fobjc-runtime=macosx-10.9.0 -fencode-extended-block-signature -fdiagnostics-show-option -fcolor-diagnostics -vectorize-slp -o /var/folders/4z/q41by0256hjc7s6v8ljmfpw8lywh5g/T/test-9b80a6.o -x c test.c
clang -cc1 version 5.1 based upon LLVM 3.4svn default target x86_64-apple-darwin13.3.0
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/5.1/include
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
/usr/include
/System/Library/Frameworks (framework directory)
/Library/Frameworks (framework directory)
End of search list.
"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld" -demangle -dynamic -arch x86_64 -macosx_version_min 10.9.0 -e bob -o a.out /var/folders/4z/q41by0256hjc7s6v8ljmfpw8lywh5g/T/test-9b80a6.o -lSystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/5.1/lib/darwin/libclang_rt.osx.a
You can see that clang is correctly passing -e to ld, so maybe this is a problem with Apple's ld. If that's the case, I'd be interested in workaround solutions.
The default entry point overridden by the -e argument is not _main but rather start, which is responsible for setting up and calling _main, then passing the return value of _main to _exit. If you specify your own entry point you'll need to perform these steps yourself. There's currently no way to have this initialization performed for you but use a different main function as use of _main is hard-coded into the tools.
The reason your -e argument is ignored is due to a change in 10.8. Prior to this release the implementation of start was linked into each application via crt1.o. In 10.8 the start processing can be performed by dyld and the LC_MAIN load command specifies the offset to the main function within the program. Changing this offset appears to be what you want, but this is not currently possible as when the LC_MAIN startup method is used ld always uses _main and disregards the -e argument. To specify your own entry point you need to tell ld to use the old method of program startup, which you can do for an application with a deployment target of 10.8 or later by passing -no_new_main to the linker. This is the default behavior for applications with a deployment target earlier than 10.8.
while compiling in our test environment i encountered the following problem:
Despite the already working windows our build failed on Freebsd 9 with the following error message:
error: no member named 'all_of' in namespace 'std'
Given that i added -std=c++11 to our Cmake flags i wonder why this is not working.
clang version 3.4 (tags/RELEASE_34/final)
Target: i386-portbld-freebsd9.1
Thread model: posix
Heres the function
#include <algorithm>
...
inline bool is_positive_number(const std::string & str)
{
if (str.empty())
return false;
return std::all_of(str.begin(), str.end(), ::isdigit);
}
Installer Log from pkg install clang34
Installing libexecinfo: 1.1_3
Installing llvm34: 3.4_1
Installing clang34: 3.4_2
Help appreciated i thought this function was implemented some ages ago but apparently im using it wrong or maybe i totally misunderstood something both is possible im quite new to clang.
Edit: Details of the process.
Selected GCC installation:
"/usr/local/llvm34/bin/clang" -cc1 -triple i386-portbld-freebsd9.1 -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name main.cpp -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -target-cpu i486 -target-linker-version 2.17.50 -v -v -g -coverage-file /home/source/release/server/game/CMakeFiles/game_r4708M_32.dir/src/main.cpp.o -resource-dir /usr/local/llvm34/bin/../lib/clang/3.4 -D "__SVN_VERSION__=\"\"" -I /home/source/release/server/game/../../extern/include/boost -I /home/source/release/server/game/../../extern/include -I /home/source/release/server/game/../libmysql/mysql-connector-c-6.1.5-src/output/freebsd/include -I /home/source/release/server/game/../liblua/include -I /home/source/release/server/game/../libdevil -internal-isystem /usr/include/c++/4.2 -internal-isystem /usr/include/c++/4.2/backward -Wno-invalid-source-encoding -W -Wno-invalid-source-encoding -W -std=c++11 -fdeprecated-macro -fdebug-compilation-dir /home/source/release/server/game -ferror-limit 19 -fmessage-length 237 -mstackrealign -fobjc-runtime=gnustep -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -vectorize-slp -o CMakeFiles/game_r4708M_32.dir/src/main.cpp.o -x c++ /home/source/release/server/game/src/main.cpp
clang -cc1 version 3.4 based upon LLVM 3.4 default target i386-portbld-freebsd9.1
ignoring duplicate directory "/usr/include/c++/4.2"
ignoring duplicate directory "/usr/include/c++/4.2"
ignoring duplicate directory "/usr/include/c++/4.2/backward"
#include "..." search starts here:
#include <...> search starts here:
/home/source/release/server/game/../../extern/include/boost
/home/source/release/server/game/../../extern/include
/home/source/release/server/game/../libmysql/mysql-connector-c-6.1.5-src/output/freebsd/include
/home/source/release/server/game/../liblua/include
/home/source/release/server/game/../libdevil
/usr/include/c++/4.2
/usr/include/c++/4.2/backward
/usr/local/llvm34/bin/../lib/clang/3.4/include
After switching to "-stdlib=libc++" as suggested by Steve Wills, I assume its selecting the right include path (v1) but its still not found or conflicted.
clang version 3.4 (tags/RELEASE_34/final)
Target: i386-portbld-freebsd9.1
Thread model: posix
Selected GCC installation:
"/usr/local/llvm34/bin/clang" -cc1 -triple i386-portbld-freebsd9.1 -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name main.cpp -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -target-cpu i486 -target-linker-version 2.17.50 -v -v -g -coverage-file /home/source/release/server/game/CMakeFiles/game_r4708M_32.dir/src/main.cpp.o -resource-dir /usr/local/llvm34/bin/../lib/clang/3.4 -D "__SVN_VERSION__=\"\"" -I /home/source/release/server/game/../../extern/include/boost -I /home/source/release/server/game/../../extern/include -I /home/source/release/server/game/../libmysql/mysql-connector-c-6.1.5-src/output/freebsd/include -I /home/source/release/server/game/../liblua/include -I /home/source/release/server/game/../libdevil -internal-isystem /usr/include/c++/v1 -Wno-invalid-source-encoding -W -Wno-invalid-source-encoding -W -std=c++11 -fdeprecated-macro -fdebug-compilation-dir /home/source/release/server/game -ferror-limit 19 -fmessage-length 237 -mstackrealign -fobjc-runtime=gnustep -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -vectorize-slp -o CMakeFiles/game_r4708M_32.dir/src/main.cpp.o -x c++ /home/source/release/server/game/src/main.cpp
clang -cc1 version 3.4 based upon LLVM 3.4 default target i386-portbld-freebsd9.1
ignoring duplicate directory "/usr/include/c++/4.2"
#include "..." search starts here:
#include <...> search starts here:
/home/source/release/server/game/../../extern/include/boost
/home/source/release/server/game/../../extern/include
/home/source/release/server/game/../libmysql/mysql-connector-c-6.1.5-src/output/freebsd/include
/home/source/release/server/game/../liblua/include
/home/source/release/server/game/../libdevil
/usr/include/c++/v1
/usr/include/c++/4.2
/usr/include/c++/4.2/backward
/usr/local/llvm34/bin/../lib/clang/3.4/include
/usr/include
End of search list.
In file included from /home/source/release/server/game/src/main.cpp:1:
In file included from /home/source/release/server/game/src/stdafx.h:12:
/home/source/release/server/game/src/../../common/utils.h:120:14: error: no member named 'all_of' in namespace 'std'
This error is likely a result of a missing:
set( CMAKE_CXX_STANDARD 11 )
It would appear that there is something in your Cmake setup.
Or maybe that Cmake isn't very good at recognizing Clang?
The following minimal example;
#include <algorithm>
#include <string>
bool is_positive_number(const std::string & str);
int main(int argc, char *argv[]) {
is_positive_number("12");
}
bool is_positive_number(const std::string & str)
{
if (str.empty())
return false;
return std::all_of(str.begin(), str.end(), ::isdigit);
}
compiles without warnings using c++ or clang++ without any special directives;
c++ -Wall foo.cpp
For reference (reformatted for convenience):
c++ -### foo.cpp
FreeBSD clang version 3.4 (tags/RELEASE_34/final 197956) 20140216
Target: x86_64-unknown-freebsd10.0
Thread model: posix
"/usr/bin/c++" "-cc1" "-triple" "x86_64-unknown-freebsd10.0"
"-emit-obj" "-mrelax-all" "-disable-free" "-disable-llvm-verifier"
"-main-file-name" "foo.cpp" "-mrelocation-model" "static"
"-mdisable-fp-elim"
"-masm-verbose" "-mconstructor-aliases" "-munwind-tables"
"-target-cpu" "x86-64" "-resource-dir" "/usr/bin/../lib/clang/3.4"
"-internal-isystem" "/usr/include/c++/v1" "-fdeprecated-macro"
"-fdebug-compilation-dir" "/home/rsmith/tmp" "-ferror-limit" "19"
"-fmessage-length" "105" "-mstackrealign" "-fobjc-runtime=gnustep"
"-fcxx-exceptions" "-fexceptions" "-fdiagnostics-show-option"
"-fcolor-diagnostics" "-vectorize-slp" "-o" "/tmp/foo-206692.o"
"-x" "c++" "foo.cpp"
"/usr/bin/ld" "--eh-frame-hdr" "-dynamic-linker"
"/libexec /ld-elf.so.1" "--hash-style=both" "--enable-new-dtags"
"-o" "a.out" "/usr/lib/crt1.o" "/usr/lib/crti.o"
"/usr/lib/crtbegin.o" "-L/usr/lib" "/tmp/foo-206692.o"
"-lc++" "-lm" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed"
"-lc" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed"
"/usr/lib/crtend.o" "/usr/lib/crtn.o"
Notice how this only uses "-internal-isystem" "/usr/include/c++/v1", while your invocation also uses /usr/include/c++/4.2" (which is from the old GCC c++ version 4.2).
to run all_of function you need c++11 complier
if you run the program in codeblocks then go to
setting --> compliers --> c++11 ISO c++ language standard [-std=c++11]
it will surely work
thank you good luck
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
Here is the kind of errors I get, that is definitely not related to my code
/usr/bin/c++ -D_TIMER -g -I/usr/local/Cellar/boost/1.54.0/include -I/Users/issam/include -o output.o -c project.cpp
In file included from project.cpp:756:
In file included from /Users/issam/include/project.hpp:123:
In file included from /usr/local/Cellar/boost/1.54.0/include/boost/regex.hpp:31:
In file included from /usr/local/Cellar/boost/1.54.0/include/boost/regex/v4/regex.hpp:39:
In file included from /usr/local/Cellar/boost/1.54.0/include/boost/regex/regex_traits.hpp:27:
In file included from /usr/local/Cellar/boost/1.54.0/include/boost/regex/v4/regex_traits.hpp:39:
In file included from /usr/local/Cellar/boost/1.54.0/include/boost/regex/v4/cpp_regex_traits.hpp:40:
/usr/local/Cellar/boost/1.54.0/include/boost/regex/pending/object_cache.hpp:39:17: error: no type named 'list' in namespace 'std'
typedef std::list<value_type> list_type;
~~~~~^
if I compile a file that only includes:
#include "boost/regex.hpp"
It compiles without any problem and creates the .o file. Here is the verbose output of the compilation
/usr/bin/c++ -D_TIMER -g -I/usr/local/Cellar/boost/1.54.0/include -o output.o -c newFile.cpp -v
Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)
Target: x86_64-apple-darwin12.5.0
Thread model: posix
"/usr/bin/clang" -cc1 -triple x86_64-apple-macosx10.8.0 -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name newFile.cpp -pic-level 2 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 136 -v -g -coverage-file /Users/issam/folder/output.o -resource-dir /usr/bin/../lib/clang/4.2 -D _TIMER -I /usr/local/Cellar/boost/1.54.0/include -fmodule-cache-path /var/folders/pd/kcfk19hd5mv9vjwsvpqtk_tc0000gq/T/clang-module-cache -fdeprecated-macro -fdebug-compilation-dir /Users/issam/folder -ferror-limit 19 -fmessage-length 168 -stack-protector 1 -mstackrealign -fblocks -fobjc-runtime=macosx-10.8.0 -fobjc-dispatch-method=mixed -fobjc-default-synthesize-properties -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o output.o -x c++ newFile.cpp
clang -cc1 version 4.2 based upon LLVM 3.2svn default target x86_64-apple-darwin12.5.0
ignoring nonexistent directory "/usr/include/c++/4.2.1/i686-apple-darwin10/x86_64"
ignoring nonexistent directory "/usr/include/c++/4.0.0"
ignoring nonexistent directory "/usr/include/c++/4.0.0/i686-apple-darwin8/"
ignoring nonexistent directory "/usr/include/c++/4.0.0/backward"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/Cellar/boost/1.54.0/include
/usr/include/c++/4.2.1
/usr/include/c++/4.2.1/backward
/usr/local/include
/usr/bin/../lib/clang/4.2/include
/usr/include
/System/Library/Frameworks (framework directory)
/Library/Frameworks (framework directory)
boost/regex/pending/object_cache.hpp has the following on line 23:
#include <list>
so for an error such as "error: no type named 'list' in namespace 'std'", it seems likely that your installation of Boost or your compiler toolchain has a problem.
What happens if you try to compile a C++ source file that contains only:
#include "boost/regex.hpp"
I looked it up - the mentioned header file includes <list>, so everything is ok there.
Chances are that you messed up the namespaces by including either boost/regex.hpp or your own project.hpp inside a namespace or by using directives before the #include of either header.
The compiler tells you about an error at the location where it actually sees there was an error, in this case somewhere deep in the guts of the boost headers. Often, when an error is made, you don't notice it immediately, but much later when things look screwed up. It's the same for the compiler this time. It can't say exactly where you messed up, but only how it knows something is wrong.