How to switch android-ndk example to use gcc instead of clang? - gcc

How to switch this example here to use gcc?:
https://github.com/googlesamples/android-ndk/tree/master/other-builds/ndkbuild/hello-libs
Is there a way to set this over the gradle files?

As of the latest ndk(18), gcc is no longer supported and you are forced to use clang.
I faced some problems switching to clang and I am considering switching to cmake as it is recommended.
About the argument that gcc is better
gcc produces more optimized binaries than clang in android NDK
while there is some truth to this, there seems to be a lot of discussion on this topic that it is because of the gcc implicitly using -Bisymbolic which is bad. You can find in depth conversation on ndk github repo here
https://github.com/android-ndk/ndk/issues/495
Its quite long, but very insightful.

Related

gcc's option dose not work until newer version

I recently struggle with gcc's optimization, hope to help with performance improvement.
I found the option -freorder-blocks-and-partition.
(This option exist on very old versions of gcc, such as gcc 5.6.)
It can be used to partition cold/hot cold to separate function, together with -ffunction-sections and linker script, cold/hot code can be put into separate ELF sections (.text section and .text.cold section).
But this option only works on recent gcc version.
I test it on gcc 10.1, and use the following compiler exploration tool, make sure it works start from version 8.1:
in gcc8.1: https://godbolt.org/z/hGcnMM, the assembly code contains a function like this:
fa(int, int) [clone .cold.0]:
In gcc7.1: https://godbolt.org/z/rhqjE1, the assembly code does not contain such function.
Why does it not work on older gcc?
And is there any way to control the older version gcc to apply this optimization?

Can I use GCC compiler AND Clangd Language Server?

I am working on a project that uses a GCC library (SFML), which is not available for clang, as far as I know. I am using COC with vim for code completions, but for C++ it needs clangd. Is there a way to use GCC as my compiler, but still use the clangd language server?
I have also heard that there may be a way to make clang recognize GCC libraries/headers, but I've never been able to make it work right. If somebody could point me in the right direction there that would be helpfull too. But I'm used to GCC (I've been using it since I started programming C++), so being able to use clangd and GCC would be preferable.
Yes it is. I do it with ccls (which is clang based as well).
Given my installation of clang is not the standard one (I compile it, tune it to use libc++ by default, and I install it somewhere in my personal space) I have to inject paths to header files known by clang but unknown by other clang based tools.
I obtain them with
clang++ -E -xc++ - -Wp,-v < /dev/null
Regarding the other options related to the current project, I make sure to have a compile_commands.json compilation database (generated by CMake, or bear if I have no other choice), and ccls can work from there. I expect clangd to be quite similar in these aspects.
Ops, answered the wrong question.
But for those who use ccls:
create a .ccls file in your project directory and append --gcc-toolchain=/usr to it.
use this tool to generate a compile_commands.json file
see https://github.com/MaskRay/ccls/wiki/FAQ#compiling-with-gcc

C++11 standard library features cross compilers support

I need to verify that some specific standard library feature is implemented and since which version.
For example: std::reference_wrapper
Compilers I need to verify: gcc, clang, msvc
MSVC
I am able to find https://msdn.microsoft.com/en-us/library/bb982605(v=vs.100).aspx so since version 10.0 the reference wrapper is implemented.
clang
On their webpage http://libcxx.llvm.org/ is written that the library is 100% completed. Is it possible to find in which version was what implemented?
gcc
I found: http://en.cppreference.com/w/cpp/compiler_support (language support)
Also: https://gcc.gnu.org/onlinedocs/gcc-4.6.4/libstdc++/manual/manual/status.html#status.iso.200x
- seems reference wrapper is implemented here
But for example 4.8.5 https://gcc.gnu.org/onlinedocs/gcc-4.8.5/libstdc++/manual/manual/status.html#status.iso.2011
There is:
This page describes the C++11 support in mainline GCC SVN, not in any particular release.
I'm confused. Can someone clarify that for me?
http://en.cppreference.com/w/cpp/compiler_support is probably going to be your best shot at finding compiler support versions. From there, you'd need to drill down into standard library release notes for specific implementation versions and details.

Writing an IDE, use GCC to compile

I want to write an own c/c++ IDE with syntax-check etc. And of course I need a compiler-functionality. For this I want to use gcc, I think it is a good option, isn't it? The IDE should not call a gcc-binary to compile, it should include the gcc source code, because after compiling the IDE I want a stay alone executable.
So my question: Is there sth like a tutorial or a good hint how to realize this?
btw it's for Mac, I'll write the IDE with XCode
Thank you!
Use LLVM's Clang and its libClang API, it's built for this purpose. GCC is not made to be used as a library.
You might develop a plugin for GCC, or a GCC MELT extension. But it could be that on MacOSX GCC plugins are not supported yet. You might also look into GCCSense which might fill some of your goals (but I never used it).

Is there an advantage to upgrade Binutils from 2.16.1 to 2.19? Why?

In the PSPSDK (Homebrew) we are using the Binutils 2.16.1 to assemble and link the code for the PlayStation Portable, however that release is getting quite outdated (3 versions have superseded it). The community and me have been updating the GCC and newlib to the latest stable versions and everything seems to work with the old binutils.
Will GCC produce better code with binutils 2.19? Why?
Will binutils 2.19 produce better elf files and libs than 2.16.1? Why?
binutils 2.19 has a new ELF linker called gold which is multi-threaded, written in modern C++, and quite a bit faster than the usual ld linker. I'm not sure however about the work involved to adapt it.
Other than that, well new versions always are a good idea. Performance and bug fixes are likely to have been included, of course. I think i would certainly try it and if something goes wrong you can still backstep.
In general, you don't need to upgrade binutils unless you run into some bug fixed in a later binutils version, or need new features (such as linker build-ids).
In particular, GCC code generation is largely independent of binutils (except for constructs like __thread, which require certain level of support from binutils).

Resources