Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Improve this question
In GNU/Linux the use of GNU make and Makefiles is very common but not entirely satisfying. I am aware of tools like autotools and CMake but ultimately they still generates a Makefile, (in the case of CMake)at least on Linux. It is just automating the process of generating the Makefile.
I am wondering what build systems there are on Linux that do not require one to execute GNU make or even have GNU make installed and what advandages/disadvantages they have compared to GNU make.
Similar information related to POSIX make or non-GNU Linux or Unix in general are also welcome. It would also be nice to include historical perspectives.
I don't get your point about cmake. There is ninja, it is commonly used with cmake. CMake has multiple generators, make just being the most commonly used. More about it maybe in cmake-generators.
There is even wiki List_of_build_automation_software with list of Make-incompatible build systems, most of them work under Linux. I've seen projects with:
Maven
Ant
waf
SCons
QT Build System
Rake
Ninja
Bazel
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
So they can be run from the Linux command line. For example, I already ported SIS CAD. Is there something else? Using an X processor and its compiler. So I'll have to port the tasks on this processor. Not interested in SPEC. Need a custom task, already implemented on other platforms and written in C (
less preferred C++)
GCC developers list several benchmarks besides well-known SPEC CPU and EEMBC CoreMark. This page mentions openbench (the link on GCC site seems to be broken), a set of benchmarks, which is an attempt to create a free alternative to SPEC CPU.
SUSE is a major contributor of GCC project, they run periodic C++ benchmarks to test compiler performance (i.e., both compilation speed and generated code quality).
Phoronix also offers some sort of benchmark suite, Open Benchmarking (though their benchmarks are sometimes criticized).
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 3 years ago.
The community reviewed whether to reopen this question 12 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
What is the difference between arm-eabi, gnueabi and gnueabi-hf cross compilers?
I am kind of finding it difficult to choose the executable that is correct for my target platform.
Is there a native compiler for arm?
I'm not completely sure:
the eabi stands for the compilation of code which will run on bare metal arm core.
the gnueabi stands for the compilation of code for linux
For the gnueabi/gnueabi-hf part, I found an answer here.
gcc-arm-linux-gnueabi is the cross-toolchain package for the armel architecture. This toolchain implies the EABI generated by gcc's -mfloat-abi=soft or -mfloat-abi=softfp options.
gcc-arm-linux-gnueabihf is the cross-toolchain package for the armhf architecture. This toolchain implies the EABI generated by the gcc -mfloat-abi=hard option.
'hf' means hard-float which indicates that the compiler and its underlying libraries are using hardware floating point instructions rather than a software implementation of floating point such as fixed point software implementations.
The 'eabi' refers to what the underlying binary is going to look like.
It can be argued that these can be achieved with flags to gcc but the issue is that of bare metal pre-compiled libraries. Unless you are recompiling everything from source, it may not be feasible to use gcc with flags alone. Even in that case you might have to carefully configure each package or library with the appropriate compile options.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I am developing command line interface executables for both osx and linux using c/c++. The project will link against opencv. Should I use libc++ or libstdc++?
I would use the native library for each OS i.e. libstdc++ on GNU/Linux and libc++ on Mac OS X.
libc++ is not 100% complete on GNU/Linux, and there's no real advantage to using it when libstdc++ is more complete. Also, if you want to link to any other libraries written in C++ they will almost certainly have been built with libstdc++ so you'll need to link with that too to use them.
More info here about the completeness of libc++ on various platforms.
Major Linux distributions do not provide LLVM libc++, because:
Unlike Apple and FreeBSD, the GPL+3 is not an issue, so no need to
implement another stack here.
Linux components have been developed around GNU libstd++ for ages. Some of them
do not build on anything else.
While libc++ is strong in new features, it has some problems with legacy code.
If eventually libc++ became part of distributions, it will be as an optional component. linking against it will probably require extra options.
Like Jonathan said, you should use whatever tool is included by default. Clang is safe in Linux to use since is configured as a GCC replacement, so in that aspect you don't have to worry about 2 compilers. Also since you are targeting two platforms, you should take a look to cmake.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 3 years ago.
Improve this question
I'm looking for a list cross reference matrix of POSIX implemented functions for a specified linux kernel.
For example, I want to use linux kernel 2.6.0, but I would like to see the compmlete list of POSIX implemented functions for this kernel. Where can I find this information?
Linux follows the Linux Standard Base as opposed to POSIX. However, LSB is mostly a superset of POSIX. You can find a list of all observed conflicts between LSB and POSIX here. I doubt something as detailed as what it seems you want exists.
2.6.0 is really an old kernel (there are big differences with 2.6.38). Try using something less old.
The linux syscalls man page gives you a list of system calls and in what kernel version they appears, so answers the question for syscalls. For library functions, I have no idea.
In practice, Linux seems to me quite Posix compliant... And the Posix standard also evolved.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
I'm having difficulties understanding the structure of a Makefile. Can you point me to a good resource to look at?
The best tutorial that I have found for makefiles so far has been this one. One of your other options is to learn autotools and let them produce your makefiles for you, though a little outdated this is the tutorial that I found best to learn from.
You could also use this tutorial by example. It provides very easy examples that will work for simple projects.
This is all you need: make
While it is well and good that you learn how to read and write a Makefile, I strongly recommend that you use CMake for your C/C++ builds instead of writing your own Makefile. It is very difficult to craft a portable Makefile, which is why the C++ community shifted from hand-crafted makefiles to using the GNU Autotools (Automake, Autoconf, Autoheader, Autoreconf, Libtool, etc.).However, the extreme complexity of the GNU Autotools left much to be desired, resulting in the creation of CMake, which is quickly becoming the build tool of choice for the C/C++ community. It has already been adopted by a growing list of projects, including KDE.