I am working on a Ubuntu 13.10 64bit OS.
I've downloaded and built LLVM 3.4 with make.
Compiler: gcc 4.8.1
Shell: zsh
In the process of configuring it, a used the default prefix /usr/local/. I did not use any other custom options.
The source code and the build is in my home folder:
~/llvm_workdir/build
~/llvm_workdir/llvm
When I tried the First Function tutorial I faced a bunch of problems. The first problems had to do with the fact that they have made some changes in the source tree. They moved some header files (e.g. Function.h) in the IR directory. (The tutorial is for the 2.4 version of llvm.) I corrected the includes in the tutorial source code file and new errors came to life. The first category is something like these:
1]
zsh: command not found: llvm-config : I'm using the `zsh shell`, which is compatible with bash.
2]
In file included from /usr/include/llvm/Support/type_traits.h:20:0,
from /usr/include/llvm/ADT/StringRef.h:13,
from /usr/include/llvm/PassRegistry.h:20,
from /usr/include/llvm/PassSupport.h:26,
from /usr/include/llvm/Pass.h:366,
from /usr/include/llvm/PassManager.h:20,
from tut1_first_function.cpp:6:
/usr/include/llvm/Support/DataTypes.h:49:3: **error: #error "Must #define __STDC_LIMIT_MACROS before #including Support/DataTypes.h"
# error "Must #define __STDC_LIMIT_MACROS before #including Support/DataTypes.h"**
^
/usr/include/llvm/Support/DataTypes.h:53:3: error: #error "Must #define __STDC_CONSTANT_MACROS before " "#including Support/DataTypes.h"
# error "Must #define __STDC_CONSTANT_MACROS before " \
3]
In file included from /usr/include/llvm/ADT/SmallVector.h:19:0,
from /usr/include/llvm/PassAnalysisSupport.h:22,
from /usr/include/llvm/Pass.h:367,
from /usr/include/llvm/PassManager.h:20,
from tut1_first_function.cpp:6:
/usr/include/llvm/Support/MathExtras.h: In function ‘bool llvm::isInt(int64_t)’:
/usr/include/llvm/Support/MathExtras.h:259:33: **error: there are no arguments to ‘INT64_C’ that depend on a template parameter, so a declaration of ‘INT64_C’ must be available [-fpermissive]
return N >= 64 || (-(INT64_C(1)<<(N-1)) <= x && x < (INT64_C(1)<<(N-1)));**
The second category has to do with the change of signatures in some methods internally:
tut1_first_function.cpp:44:26: note: candidate is:
In file included from /usr/include/llvm/IR/GlobalValue.h:22:0,
from /usr/include/llvm/IR/Function.h:25,
from /usr/include/llvm/IR/Module.h:19,
from tut1_first_function.cpp:7:
/usr/include/llvm/IR/DerivedTypes.h:58:23: note: static llvm::IntegerType* **llvm::IntegerType::get(llvm::LLVMContext&, unsigned int)
static IntegerType *get(LLVMContext &C, unsigned NumBits);
^
/usr/include/llvm/IR/DerivedTypes.h:58:23: note: candidate expects 2 arguments, 1 provided**
I do not know what other parameter to pass in get. I'm new in LLVM, I'm starting learning it now. I haven't found any new tutorials that correspond to the new LLVM version.
How can I solve the above problems? Is there a workaround?
LLVM is under active development. An attempt to apply a tutorial written to version 2.4 - which is over 5 years old - to an up-to-date version will be a lesson in frustration.
The Kaleidoscope tutorial is up-to-date and usually maintained as such with new versions, so I recommend using it instead. In particular, lesson 3 looks like it covers the topics in the page you linked.
Related
I'd like to run the ARToolKitX Calibration app on iOS. Unfortunately, the app isn't available in the App Store, so I assume I'd have to compile it myself. Luckily, I have an active Apple Developer account...
So I got the source code from GitHub:
git clone https://github.com/artoolkitx/artoolkitx-calibration
cd artoolkitx-calibration
Then I downloaded the ARToolKitX iOS library from https://github.com/artoolkitx/artoolkitx/releases/download and I followed the steps in the iOS section of the build.sh script to link this SDK to the Xcode project.
I opened the project with Xcode 9.3 on macOS High Sierra 10.13.3.
I downloaded the opencv2.framework library from SourceForge and linked it: https://sourceforge.net/projects/opencvlibrary/files/opencv-ios/
Xcode reported an issue in line 61 of prefs.hpp:
cv::Size getPreferencesCalibrationPatternSize(void *preferences);
'getPreferencesCalibrationPatternSize' has C-linkage specified, but returns user-defined type 'cv::Size' (aka 'Size_') which is incompatible with C
Any pointer to get a step further in this compilation process would be greatly appreciated!
I just had the same problem today. You need to make sure that your source code files, usually the '.c' and the '.h' files, are interpreted as C++ headers and sources. For this specific error, trace back which file calls cv::Size and change its type to C++ header/source.
The compilation issue was fixed by removing the following lines around the error-generating usage of cv::Size:
#ifdef __cplusplus
extern "C" {
#endif
...
#ifdef __cplusplus
}
#endif
I'm trying to compile the EOS blockchain/smart contract project on GitHub on Ubuntu 14.04:
https://github.com/EOSIO/eos
After getting Clang 4.0 to install, installing build_essentials, and upgrading CMake to 3.5, I was able to run the build process without any missing dependencies. However, now I get the errors shown below when I build the EOS source. This seems to me like another general issue with the configuration of the tools on my system since many people are able to compile the EOS code, although usually on Ubuntu 14.04.
Can anyone tell by looking at the errors I'm getting what tool or library I need to install or upgrade?
In file included from /usr/lib/llvm-4.0/include/clang/AST/Decl.h:31:
/usr/lib/llvm-4.0/include/llvm/Support/TrailingObjects.h:259:33: error: 'BaseTy' does not refer to a value
static_assert(LLVM_IS_FINAL(BaseTy), "BaseTy must be final.");
^
/usr/lib/llvm-4.0/include/llvm/Support/TrailingObjects.h:233:20: note: declared here
template <typename BaseTy, typename... TrailingTys>
^
/usr/lib/llvm-4.0/include/llvm/Support/TrailingObjects.h:259:19: error: expected expression
static_assert(LLVM_IS_FINAL(BaseTy), "BaseTy must be final.");
^
/usr/lib/llvm-4.0/include/llvm/Support/type_traits.h:104:45: note: expanded from macro 'LLVM_IS_FINAL'
#define LLVM_IS_FINAL(Ty) std::is_final<Ty>()
^
Linking CXX executable codegen
/home/robert/Documents/GitHub/eos/programs/launcher/main.cpp:405:18: error: no template named 'underlying_type_t' in namespace 'std'; did you mean
'underlying_type'?
using T = std::underlying_type_t <enum_type>;
~~~~~^~~~~~~~~~~~~~~~~
underlying_type
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/type_traits:1855:12: note: 'underlying_type' declared here
struct underlying_type
^
/home/robert/Documents/GitHub/eos/programs/launcher/main.cpp:435:17: error: no member named 'put_time' in namespace 'std'
dstrm << std::put_time(std::localtime(&now_c), "%Y_%m_%d_%H_%M_%S");
~~~~~^
[ 64%] Building CXX object libraries/chain/CMakeFiles/eos_chain.dir/chain_controller.cpp.o
/home/robert/Documents/GitHub/eos/programs/launcher/main.cpp:406:39: error: no matching conversion for static_cast from 'allowed_connection' to 'T'
(aka 'underlying_type<allowed_connection>')
return lhs = static_cast<enum_type>(static_cast<T>(lhs) | static_cast<T>(rhs));
^~~~~~~~~~~~~~~~~~~
The Missing _t alias names look like you’re having issues with C++14. The header paths in the error messages look like you’re using the standard library from GCC 4.8 (the default compiler on Ubuntu 14.04), which is simply too old.
I can see two solutions:
Switch from GCC’s libstdc++ to an up-to-date version of LLVM’s libc++. I’m not familiar enough with Ubuntu to tell you how to install it. For the compilation of EOSIO you must pass the -stdlib=libc++ option to Clang to switch to the different stdlib. EOSIO looks like it’s using CMake, so you have to include -DCMAKE_CXX_FLAGS=-stdlib=libc++ in your CMake command line.
Use the Toolchain test builds PPA to install a newer GCC and and libstdc++ in addition to your system’s default one. For Ubuntu 14.04 GCC 7.2.0 is the latest version available, which is perfectly C++14 capable. Add the PPA to your package sources and then do a:
sudo apt-get install gcc-7 g++-7
This installs both the GCC C compiler and C++ compiler along with the stdlib. Your default compiler is still going to be the old GCC 4.8, so you’ll have to tell CMake about the newer versions:
-DCMAKE_CXX_COMPILER=g++-7 -DCMAKE_C_COMPILER=gcc-7
Note that now you compile EOSIO with GCC (and the new stdlib) instead of Clang. Instructing Clang to use a specific version of libstdc++ should be possible, but I don’t know how.
Official support is for Ubuntu 16.10. Consider upgrading.
(EDITED: I mistakenly said 14.10)
Source: https://github.com/EOSIO/eos/wiki/Local-Environment#211-ubuntu-1610
I'm trying to build OpenCV 3.2.0 vc14 from its sources with MinGW 5.3.0 32 bit in order to use its functionality from Qt 5.8. My platform is Windows 7 64 bit.
The main instruction I follow is here, on Qt's wiki. On several steps, I encounter errors for which I haven't found solutions yet. As I am a newbie, I apologize for my helplessness and will appriciate any suggestions.
Error 1. On the stage of generating build files.
In cmake-gui (cmake-3.2.1-win32-x86), I precisely follow the steps specified in the Qt wiki article mentioned above. However, during the final generation, the following CMake error occurs at the end:
CMake Error in modules/highgui/CMakeLists.txt:
No known features for CXX compiler
"GNU"
version 5.3.0.
Generating done
I wonder how it affects the project files and if it causes the next errors.
Error 2. When trying to build OpenCV
The build process is interrupted midway, logging the following:
In file included from C:/Qt/Tools/mingw530_32/i686-w64-
mingw32/include/c++/type_
traits:35:0,
from C:/Qt/5.8/mingw53_32/include/QtCore/qglobal.h:45,
from C:/Qt/5.8/mingw53_32/include/QtCore/QtCore:4,
from C:/Qt/5.8/mingw53_32/include/QtOpenGL/QtOpenGLDepends:3,
from C:/Qt/5.8/mingw53_32/include/QtOpenGL/QtOpenGL:3,
from C:/opencv/sources/modules/highgui/src/window_QT.h:46,
from C:\opencv\sources\modules\highgui\src\window_QT.cpp:47:
C:/Qt/Tools/mingw530_32/i686-w64-
mingw32/include/c++/bits/c++0x_warning.h:32:2:
error: #error This file requires compiler and library support for the ISO
C++ 2011 standard. This support is currently experimental, and must be
enabled with the -std=c++11 or -std=gnu++11 compiler options.
(...)
C:/Qt/5.8/mingw53_32/include/QtCore/qcompilerdetection.h:562:6: error:
#error Qt requires a C++11 compiler and yours does not seem to be that.
(...)
^
C:/Qt/5.8/mingw53_32/include/QtCore/qtypeinfo.h:62:40: error: expected
primary-expression before '>' token isIntegral = std::is_integral<T>::value,
^
C:/Qt/5.8/mingw53_32/include/QtCore/qtypeinfo.h:62:41: error: '::value' has
not been declared isIntegral = std::is_integral<T>::value,
NOTE: I also had sprintf() family security error. So I followed Alex's suggestion to add add_definitions(-DSTRSAFE_NO_DEPRECATE) to the beginning of CMakeLists.txt to suppress the error.
Thank you for your time.
I downloaded boost and am doing this
admin#US01WKS03044 /cygdrive/c/Users/admin/Downloads/boost_1_49_0
$ ./bootstrap.bat gcc
Building Boost.Build engine
filent.c:35:21: fatal error: direct.h: No such file or directory
# include <direct.h>
^
compilation terminated.
jam.c: In function ‘main’:
jam.c:181:25: error: ‘environ’ undeclared (first use in this function)
#define use_environ environ
^
jam.c:417:22: note: in expansion of macro ‘use_environ’
var_defines( use_environ, 1 );
^
jam.c:181:25: note: each undeclared identifier is reported only once for each function it appears in
#define use_environ environ
^
jam.c:417:22: note: in expansion of macro ‘use_environ’
var_defines( use_environ, 1 );
^
jam.c: In function ‘executable_path’:
jam.c:628:18: warning: comparison between pointer and integer
if (argv0[0] == "/")
^
pathunix.c:276:19: fatal error: tchar.h: No such file or directory
#include <tchar.h>
^
compilation terminated.
builtins.c:39:0: warning: "WIFEXITED" redefined
# define WIFEXITED(w) (((w) & 0XFFFFFF00) == 0)
^
In file included from /usr/include/cygwin/stdlib.h:14:0,
from /usr/include/stdlib.h:25,
from jam.h:89,
from builtins.c:7:
/usr/include/cygwin/wait.h:34:0: note: this is the location of the previous definition
#define WIFEXITED(w) ((__wait_status_to_int(w) & 0xff) == 0)
^
builtins.c:40:0: warning: "WEXITSTATUS" redefined
# define WEXITSTATUS(w)(w)
^
In file included from /usr/include/cygwin/stdlib.h:14:0,
from /usr/include/stdlib.h:25,
from jam.h:89,
from builtins.c:7:
/usr/include/cygwin/wait.h:39:0: note: this is the location of the previous definition
#define WEXITSTATUS(w) ((__wait_status_to_int(w) >> 8) & 0xff)
^
Failed to build Boost.Build engine.
Please consult bootstrap.log for furter diagnostics.
You can try to obtain a prebuilt binary from
http://sf.net/project/showfiles.php?group_id=7586&package_id=72941
Also, you can file an issue at http://svn.boost.org
Please attach bootstrap.log in that case.
Any suggestions on why I might be getting this error ?
The file bootstrap.bat is for building Boost from the Windows command prompt in order to create a native Windows version of Boost. If you want to build a Cygwin version of Boost from the Cygwin shell you should follow the instructions for building Boost on Unix-type systems.
Or as this message at the top of Boost's Getting Started on Windows page says:
A note to Cygwin and MinGW users
If you plan to use your tools from the Windows command prompt, you're in the
right place. If you plan to build from the Cygwin bash shell, you're actually
running on a POSIX platform and should follow the instructions for
getting started on Unix variants.
Short version
When I compile even a simple code using a feature of the C++11 standard (the std::stod function), GCC 4.9.1 fails with the following error:
example.cpp: In function 'int main()':
example.cpp:10:18: error: 'stod' is not a member of 'std'
double earth = std::stod (orbits,&sz);
^
example.cpp:11:17: error: 'stod' is not a member of 'std'
double moon = std::stod (orbits.substr(sz));
^
What?
The command I use is g++ -std=c++11 example.cpp.
This is the test code (which compiles fine on other systems):
// stod example from http://www.cplusplus.com/reference/string/stod/
#include <iostream> // std::cout
#include <string> // std::string, std::stod
int main ()
{
std::string orbits ("365.24 29.53");
std::string::size_type sz; // alias of size_t
double earth = std::stod (orbits,&sz);
double moon = std::stod (orbits.substr(sz));
std::cout << "The moon completes " << (earth/moon) << " orbits per Earth year.\n";
return 0;
}
details
I am using a version of GCC 4.9.1 I compiled myself on two different clusters running CentOS 6.5 (I use the modules system on stuff in my home dir since I'm not an admin).
I will call them cluster 1 and cluster 2: cluster 1 is where the failure happens.
The GCCs were compiled in the same way and at the same time, and loaded using identical module files (save for a minor difference in the base path). The installations are, as far as I can easily check, identical (the same include files exist on both clusters, and have the same contents).
The output from g++ -v is the same on both clusters (again, except for the install path):
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/andyras/bin/gcc-4.9.1/libexec/gcc/x86_64-unknown-linux-gnu/4.9.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.9.1/configure --prefix=/home/andyras/bin/gcc-4.9.1 --enable-languages=c,c++,fortran
Thread model: posix
gcc version 4.9.1 (GCC)
g++ -v using the system GCC gives the same output on both clusters, except on cluster 1 it says it is gcc version 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC) and on cluster 2 says gcc version 4.4.7 20120313 (Red Hat 4.4.7-4) (GCC)
I am trying to debug using g++ -std=c++11 -save-temps -MD example.cpp for more info... this gives some clues, but I don't know where to go from here.
The intermediate (.ii) files on cluster 1 are missing some lines, for example (excerpt from diffing the .ii files):
< # 277 "/opt/gcc-4.9.1/include/c++/4.9.1/cwchar" 3
---
> # 277 "/home/andyras/bin/gcc-4.9.1/include/c++/4.9.1/cwchar" 3
961,963c934,936
< using std::wcstold;
< using std::wcstoll;
< using std::wcstoull;
---
>
>
>
As I interpret it, GCC on both clusters tries to include files like cwchar, but on cluster 1 there are blank lines instead of things being defined. On cluster 2 the stod function is in the intermediate file, but not on cluster 1.
Could it be a preprocessor error?
Now looking at the .d (dependency) files, I also see a concrete difference. There are some files listed on cluster 2 that are not listed on cluster 1. Here is the list (I processed the contents of the .d files to account for the different base paths; // stands in for the install path):
85a86,108
> //gcc-4.9.1/include/c++/4.9.1/ext/string_conversions.h
> //gcc-4.9.1/include/c++/4.9.1/cstdlib
> /usr/include/stdlib.h
> /usr/include/bits/waitflags.h
> /usr/include/bits/waitstatus.h
> /usr/include/sys/types.h
> /usr/include/sys/select.h
> /usr/include/bits/select.h
> /usr/include/bits/sigset.h
> /usr/include/sys/sysmacros.h
> /usr/include/alloca.h
> //gcc-4.9.1/include/c++/4.9.1/cstdio
> /usr/include/libio.h
> /usr/include/_G_config.h
> /usr/include/bits/stdio_lim.h
> /usr/include/bits/sys_errlist.h
> //gcc-4.9.1/include/c++/4.9.1/cerrno
> /usr/include/errno.h
> /usr/include/bits/errno.h
> /usr/include/linux/errno.h
> /usr/include/asm/errno.h
> /usr/include/asm-generic/errno.h
> /usr/include/asm-generic/errno-base.h
I was curious if cpp was looking for includes in all the wrong places, but this seems legit (cpp -v):
#include <...> search starts here:
/home/andyras/bin/gcc-4.9.1/include
/home/andyras/bin/gcc-4.9.1/include/c++/4.9.1/
/home/andyras/bin/gcc-4.9.1/include/c++/4.9.1/x86_64-unknown-linux-gnu/
/home/andyras/bin/gcc-4.9.1/lib/gcc/x86_64-unknown-linux-gnu/4.9.1/include
/usr/local/include
/home/andyras/bin/gcc-4.9.1/lib/gcc/x86_64-unknown-linux-gnu/4.9.1/include-fixed
/usr/include
End of search list.
This has been a very frustrating couple of hours trying to track down the source of the problem. I could, of course, use something like atof(myString.c_str()) instead of std::stod, but I am wondering if there is an underlying issue that will foul up future projects using other bits of C++11.
Any more clues or insight would be very much appreciated.
You have already done all the necessary footwork to determine the root cause. You already know the answer: you have posted clear differences between how custom gcc installs behave on your "cluster 1" and "cluster 2", a non-working and a working build.
So, something is obviously different between these two gcc installs; if one compiles, links, and runs some code, and the other one chokes on the exact same piece of code. Unfortunately, it's hard to pinpoint where things go off the rails. Having built gcc myself before, previously, I can say that gcc is a hellishly difficult, and very fickle package to install. For example, after several days chasing a mysterious failure when linking some C++ code, I ended up chasing it down to gcc picking up the wrong version of binutils, in gcc's configure script, and internally turning off some obscure feature, that eventually manifested itself as a link failure not of gcc, but of stuff that got built with gcc. gcc itself got built, and installed, with nary a complaint, but it was broken.
So, I find it completely unsurprising, and entirely plausible, the proposition that gcc itself got built and installed without an apparent issue, but it's broken, and will choke on valid code, in this fashion.
My guess would be that your busted gcc build is using a broken default include path -- it's looking for headers in /usr/include, instead of your own custom installation directory. That's the most likely answer, but it could really be anything.
Well, you obviously have (like you wrote yourself) two different versoins of gcc (one time 4.4.7-3 and the other 4.4.7-4), and It seems that they have (even though slightly) differences in compiling the code.
As I've read somewhere, the C++11-standard is not yet included completely in all compilers, so this seems to be the cause on the one Cluster. The other has (you might know why) a version where more of the new standard is included and since you want you use exactly this feature I'd recommend installing this version on the other Cluster too.