I created a C++ shared library project in Ubuntu with compiler g++ 4.6.
Some of the dependency libraries expects some preprocessor commands about compiler and operating system to properly compile, like
#elif defined(__GNUC__) || defined(__llvm__) || defined(__clang__)
However Eclipse doesn't define them automatically (at least the version I'm using), is there a setting or option in Eclipse which does this for me ?
You can set preprocessor defines in the project properties: .
However, in your case, I wouldn't use these, as they shouldn't be project specific (due to them being compiler specific). I actually think you're looking for these. I'm not sure for llvm/clang (there are ones, but I don't remember them right now), but for GCC you should use the macro __GNUC__ which will be defined by the compiler itself, without you having to worry about it. The leading underscores tell you, that they aren't part of the standard and not necessarily defined when using another compiler (e.g. MSVC).
For cross platform usage of vsprintf_s:
// this will be set on Visual Studio only, so this code is added for all other compilers
#ifndef _MSC_VER
#define vsprintf_s(b,l,f,v) vsprintf(b,f,v);
#endif
But in general, try to use functions that are available on all platforms (for this example, in this case use vsnprintf() instead).
Related
I am attempting to make a simple ToolChain for the Borland 4.5 compiler with the Pharlap extender based on instructions at the Apache website: https://netbeans.apache.org/kb/docs/cnd/toolchain.html
I am basing the ToolChain on MinGW so that I can use those tools for make.
I cannot get the new toolset to find the Borland compilers the way MinGW is automatically discovered. If I use g++ as the compiler name, Netbeans finds that OK. The issue seems to be with the directory. I'm assuming an installation directory of C:\BC45\BIN and attempting to find BCC32.EXE in that directory.
When I run (clean, build, then run) the test installation of the netbeans module, I see my new toolchain in C/C++, but the field for the C++ compiler is always empty unless I specify a program in the c:\mingw\bin (base) directory.
I have tried variations on the following in my cpp xml file, making sure from time to time that it works just fine with g++ as the name:
<cpp>
<compiler name="bcc32.exe"/>
<recognizer pattern=".*[\\/]bc45.*[\\/]bin[\\/]?$"/>
I haven't found documents beyond the Apache website. I'm basing my guesses on what I have found in: %appdata%\NetBeans\12.4\config\CND\ToolChain\MinGW.xml
The XML above was OK as far as it goes. The example at apache.org only fills in the subclass of c++ (cpp). When I also subclassed the c, assembler, and linker, I ended up with the fields in the C++ options automatically populating as expected.
vcc4n (https://sourceforge.net/p/vcc4n/wiki/Home/) has a good example of implementing the four important classes for those build tools, but really just continuing the example to create and fill in the additional XML as specified in layer.xml is straightforward enough.
I'm using MacOS 10.15.7 with Xcode 12.4, I want to use Armadillo library in my iOS Swift project. So first I installed Armadillo through Homebrew.
Armadillo was installed in path /usr/local/Cellar/armadillo/
I found header files in path /usr/local/Cellar/armadillo/10.5.1/include and library files in path /usr/local/Cellar/armadillo/10.5.1/lib
In Xcode project, Build settings I provided the above paths in Header Search path and Library search path.
I'm getting below three errors.
/usr/local/Cellar/armadillo/10.5.1/include/armadillo_bits/compiler_check.hpp:50:4: error: "*** C++11 compiler required; enable C++11 mode in your compiler, or use an earlier version of Armadillo"
/usr/local/Cellar/armadillo/10.5.1/include/armadillo:23:10: error: 'cstdlib' file not found #include <cstdlib>
<unknown>:0: error: failed to emit precompiled header
Not sure how to proceed.. Any suggestions ???
You will not be able to do this easily. Swift does not yet support C++ interop, but this is a long term goal. You can read about in the C++ Interop Manifesto in the Swift git repo. The best you will be able to do right now is write an extern "C" wrapper in C++ around any C++ functions you want to call, and then import your wrapper into Swift. Since you're using an Xcode project, I would recommend trying something like this.
Alternatively, depending on what you need Armadillo for, you might be able to by away without it. If you just need to do linear algebra, Apple includes LAPACK (see here) and BLAS (see here) inside Accelerate, which is available on all Apple platforms without installing anything. This might even be familiar to you because Armadillo does its matrix decompositions through LAPACK. There's also Quadrature (see here) if you are looking for integration. I've had good experiences with each of these.
Background: I work in a company with many preferences. We currently use makefiles for our complex build with the developer's choice of IDE (or even VIM) for editing source files.
I'm looking at CMake to clean up our un-tame-able gnu make build system. I like the integration with VS Code, but I couldn't possibly manage to dictate the IDE to many of our more prickly DSP engineers and their preferred editing environment (which I totally understand; I'm a bit of Visual Studio guy, myself).
Anyways, is the cmake-kits.json method of specifying kits or toolchains/targets/etc. the "right" way to do it? Or is that just for VS Code.
If it's just for VS Code, what's the proper CMake-y way to put in new toolchains (we do cross compiling using non-gnu tools for 3 different processors) that would work in VSCode, or eclipse, or from the command line.
Kits are part of the CMake extension for VS Code. You want to read cmake-toolchains(7). A kit is something like setting CC and CXX in the environment so CMake knows which compiler to use for Makefile and Ninja generators. It is different for the other generators as the IDE can control which exact compiler is used and you tell CMake which toolset to use and it generates the project accordingly. FYI, kits don't handle having to write your own toolchain file for cross compilers.
You can use a toolchain file for cross compiling. This can be simple to hard depending on the compiler and how well it acts like a gcc cross compiler. If it's really different a toolchain file isn't quite enough as you then need to update the platform items to get it all working. Since this gets into the area of being CMake implementation dependent it's not that well documented. But there is help at https://discourse.cmake.org/.
You could just use Ninja as the build tool. Then you setup your toolchain file. After your original run on CMake to create the Ninja project files, you can just run Ninja to build the software.
Then it's easy to set your IDE to just call Ninja to build the software.
Personally, I don't like the CMake integration in VS Code (it's just an add-on). It's always been too buggy for me to want to use it. But it was good for pulling the information out of the build to get the cpp-tools setup correctly. As for project files for Eclipse CDT4 - Ninja I've never personally used them.
I have installed the latest version of Eclipse on my Windows 7 64-bit machine and the mingw compiler. In setting up a Hello World project, all goes well until I am asked for the Cross Settings what the Prefix is and the Path. The Path is obvious, it's the path to the compiler. However, I haven't the slightest idea what the Prefix is and Googling for much of the day hasn't enlightened me other than finding that a lot of other people have asked the question. Unfortunately the answers I've found appear to be for specific hardware. All I want to do is to produce an executable that will run on a Windows 32 bit or 64 bit machine.
So, what is the Prefix and how do I find what it should be?
What is probably happening here is that CDT is not locating your MingW or GCC installations.
simple - but unlikely reason - covering bases
There can be many reasons, from the simple - but unlikely at this point:
You don't have mingw installed
You don't have GCC installed
This can be tested easily by starting a shell and running gcc --version.
CDT heuristic not working
To more complicated reasons relating to your installation not being detected because the heuristic in CDT did not work on your machine. To find the correct settings, CDT will do:
Check $MINGW_HOME/bin for existence
Check <Eclipse install location>/mingw/bin for existence
Look for mingw32-gcc.exe or x86_64-w64-mingw32-gcc.exe on the PATH
Check C:\MinGW for existence
If CDT cannot find any of the above, you may lead to the situation you are in.
So, how to fix it!
Option 1
Start Eclipse from within a mingw set up shell. i.e. the one you can successfully run gcc --version from. That way Eclipse will inherit an environment that can launch GCC successfully.
Option 2
Set your environment up so that MINGW_HOME is properly defined. You can do this at the system level or within the build settings in Eclipse CDT. For example, on my machine in the build settings for the project (Right-click on the project, choose Properties, then choose C/C++ -> Environment) I have set:
MINGW_HOME to C:\MinGW
MSYS_HOME to C:\MinGW\msys\1.0
PATH to ${MINGW_HOME}\bin;${MSYS_HOME}\bin;<my normal path>
and this allows Eclipse to launch gcc as part of the build process.
NOTE The above setting were done automatically on my machine because mingw was correctly located by the heuristic.
Here is a screenshot of the build settings if it helps:
Prefix: Under the hood
To try and answer part of your original question about what Prefix is, I provide the below information. It is unlikely to be particularly helpf
Prefix, in GCC parlance, refers to the directory under which all the related GCC files are placed. With different prefixes you can have multiple GCC installed on your machine.
From the GCC FAQ:
It may be desirable to install multiple versions of the compiler on
the same system. This can be done by using different prefix paths at
configure time and a few symlinks.
The concept comes from autotools in general. Autotools is the standard GNU make system (where you do ./configure && make - simplified). The prefix is the command line option to the configure stage (--prefix) to specify where to install the tool to. GCC above uses the --prefix to allow multiple GCCs on your system.
If you really want to know more about this, read the autobook. The section on configuring covers --prefix:
‘--prefix=prefix’
The –prefix option is one of the most frequently
used. If generated ‘Makefile’s choose to observe the argument you pass
with this option, it is possible to entirely relocate the
architecture-independent portion of a package when it is installed.
For example, when installing a package like Emacs, the following
command line will cause the Emacs Lisp files to be installed in
‘/opt/gnu/share’:
$ ./configure --prefix=/opt/gnu
It is important to stress that this behavior is dependent on the generated files making use of this
information. For developers writing these files, Automake simplifies
this process a great deal. Automake is introduced in Introducing GNU
Automake.
Additionally, Mingw takes advantage of all this prefix options. Read more about that on mingw's site. But the short of it is that the main prefix for mingw is /mingw.
I'm trying to cross-compile several libraries from OSX to iOS. I've successfully cross-compiled libjpeg and libogg.
But I can't compile libvorbis because configure insists on creating and running a small test program. This obviously fails, because it creates an armv7 binary, fails to run it, and then interprets this as missing ogg libraries.
How do you usually deal with this kind of problem? I'm tempted to hack the configure script to work around these issues, but because of this kind of failure some features may be disabled. I'm also thinking of letting configure generate a native Makefile and then convert it to use the iOS toolchain, but this seems too error prone.
Any advice?
If you are cross-compiling anything that has more dependencies than libc (glibc) it becomes much more complicated. You need to have already cross-compiled all the dependencies. And the cross-compiler toolchain and all helper build programs and scripts need to know how to find those dependencies (the cross-compiled libraries and headers).
You need to have already cross-compiled libogg (and its dependencies) and installed them into the cross-compile root directory. The headers and libraries from your build system can't be used for the host (arm7) system. They must be kept separate.
Also, if you want to have shared object libraries (*.so) and not just static libraries then there is a whole new set of complications. For example, while a cross-compiler toolchain contains a cross-compiled libc as part of the toolchain, you still need a libc for the host system. The libc that is part of the toolchain can be used for this, but the way it is structured is different than on the host system. Sometimes people copy and re-arrange the files, but often people just compile and install a new glibc for the root.
Anyways, all that to say, the two errors you are seeing are because the configure script is not able to find a cross-compiled libogg library. If you haven't already, you need to cross-compile libogg (and dependencies) and install them into your target root. Then you need to tell the configure script where your cross-compiled headers (yes, header are architecture specific) and libraries are in your target root. Usually using CFLAGS, LDFLAGS, CXXFLAGS, etc (NOT --prefix) but there may be other environment variables you need to set also to affect things like pkg-config, etc. After you have built each dependency, then you need to get the makefile to install the dependency to the root. Usually this is done with make DESTDIR=[root] install but some makefiles have their own mechanism (or no proper alternate install mechanism).
You may also need to override certain configure checks (using environment variables) that are poorly written and don't have good cross-compile defaults. These variables usually start with ac_cv_*
So the basic process is to do this for packages that you need (in dependency order):
export CFLAGS=-I[root]/usr/include LDFLAGS=-L[root]/usr/lib CXXFLAGS=-I[root]/usr/include
export ac_cv_[test1]=[yes|no] ac_cv_[test2]=[yes|no] ...
./configure --host=[arm7-blah-blah]
make
make DESTDIR=[root] install
Good luck. Once you feel comfortable with standard cross-compiling, then you will be ready to take on the real black art, the Canadian cross ;-)
I finally figured it out. I tricked configure by explicitly making it link with ogg (LDFLAGS="/usr/local/ios/lib/libogg-armv7.a" ./configure ...) and then removed the explicit reference to the library from the generated makefile.