we are trying to build AOSP (android-4.4.2_r1) on our CENTOS 5.10 x86_64 standard server b/c it has a lot of processors and ram. soon after we run make -j32 2> error.log the build stops. the error.log shows the following errors. can anyone tell us why?
find: src: No such file or directory
/usr/bin/m4: unrecognized option `--gnu'
Try `/usr/bin/m4 --help' for more information.
/root/android/source/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.7/bin/../lib/gcc/arm-linux-androideabi/4.7/../../../../arm-linux-androideabi/bin/as: /lib64/libz.so.1: no version information available (required by /root/android/source/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.7/bin/../lib/gcc/arm-linux-androideabi/4.7/../../../../arm-linux-androideabi/bin/as)
/root/android/source/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.7/bin/../lib/gcc/arm-linux-androideabi/4.7/../../../../arm-linux-androideabi/bin/as: /lib64/libz.so.1: no version information available (required by /root/android/source/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.7/bin/../lib/gcc/arm-linux-androideabi/4.7/../../../../arm-linux-androideabi/bin/as)
/root/android/source/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.7/bin/../lib/gcc/arm-linux-androideabi/4.7/../../../../arm-linux-androideabi/bin/as: /lib64/libz.so.1: no version information available (required by /root/android/source/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.7/bin/../lib/gcc/arm-linux-androideabi/4.7/../../../../arm-linux-androideabi/bin/as)
/root/android/source/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.7/bin/../lib/gcc/arm-linux-androideabi/4.7/../../../../arm-linux-androideabi/bin/as: /lib64/libz.so.1: no version information available (required by /root/android/source/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.7/bin/../lib/gcc/arm-linux-androideabi/4.7/../../../../arm-linux-androideabi/bin/as)
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
/root/android/source/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.7/bin/../lib/gcc/arm-linux-androideabi/4.7/../../../../arm-linux-androideabi/bin/as: /lib64/libz.so.1: no version information available (required by /root/android/source/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.7/bin/../lib/gcc/arm-linux-androideabi/4.7/../../../../arm-linux-androideabi/bin/as)
/usr/bin/m4: unrecognized option `--gnu'
Try `/usr/bin/m4 --help' for more information.
make: *** [out/host/linux-x86/obj/EXECUTABLES/checkpolicy_intermediates/policy_parse.cpp] Broken pipe
make: *** Waiting for unfinished jobs....
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
to fix this issue we upgraded our centos server from 5.10 to 6.5. however, we didn't follow source.android.com instructions on how to prep the server. instead we simply ran make -j32 and then fixed any subsequent errors.
one thing we noticed was we had to install 32bit packages on a 64bit server. we also ended up ditching AOSP for CM.
lastly, and this was more a business decision, we bought a cheap tablet that had an official CM11 ROM: http://wiki.cyanogenmod.org/w/Build_for_p3110 so we could at least have some instruction set.
Related
I'm trying to compile some C code against a 32-bit DLL file that was provided to me. However, I get the following errors from ld (edited for conciseness) using the MSYS2 MinGW-32 environment:
/usr/x86_64-pc-msys/bin/ld: skipping incompatible /<some_path>/mtipli.lib when searching for -lmtipli
/usr/x86_64-pc-msys/bin/ld: skipping incompatible /<some_path>/mtipli.dll when searching for -lmtipli
/usr/x86_64-pc-msys/bin/ld: skipping incompatible /<some_path>/mtipli.lib when searching for -lmtipli
/usr/x86_64-pc-msys/bin/ld: skipping incompatible /<some_path>/mtipli.dll when searching for -lmtipli
/usr/x86_64-pc-msys/bin/ld: skipping incompatible /<some_path>/mtipli.lib when searching for -lmtipli
/usr/x86_64-pc-msys/bin/ld: cannot find -lmtipli
The last time I got these types of error messages was when I was trying to use a 32-bit library in a 64-bit project. But this time I am as sure as I can be that my compiler is 32-bit.
Does anyone know if there's a way I can get more information so that I can troubleshoot this? I tried using -Wl,--verbose, but ld's verbose messages didn't have anything helpful in them.
More details:
I actually have three incarnations of MinGW on my computer. The first is the basic 32-bit MinGW compiler that I installed using mingw-get several years ago. I later installed the MSYS2 environment, which came with a 32-bit and a 64-bit MinGW. In other words, I have two 32-bit version of MinGW.
I am forced to use the MSYS2 version of the 32-bit MinGW for my project because the basic one doesn't have some headers/libs that I depend on (i.e. stuff I need in addition to the mtipll.dll file shown above). However, if I make a minimal project using only mtipll.dll, the basic MinGW is actually able to compile it, but the MSYS2 MinGW gives me this same error. I am so confused with all these MinGWs floating around!!!
I think I found the explanation, though I don't have a solution yet.
By using objdump, I discovered that the mtipli.dll has file format pe-i386, and so do any executables that I've compiled with the basic MinGW-32. However, all code compiled with the MSYS2 version of MinGW-32 have file format pe-x86-64.
I will ask about this in a new Stack Overflow question and post the link in the comments.
I am building Swift compiler from source on CentOS 6, and am running into a library issue. After fighting with the build script for a while I have got where running ./utils/build-script eventually gives:
+ /home/src/cmake-3.4.1-Linux-x86_64/bin/cmake --build /home/src/swift/build/Ninja-DebugAssert/cmark-linux-x86_64 -- all
ninja: no work to do.
llvm: using standard linker
+ cd /home/src/swift/build/Ninja-DebugAssert/llvm-linux-x86_64
+ /home/src/cmake-3.4.1-Linux-x86_64/bin/cmake -G Ninja -DCMAKE_C_COMPILER:PATH=clang -DCMAKE_CXX_COMPILER:PATH=clang++ '-DCMAKE_C_FLAGS= ' '-DCMAKE_CXX_FLAGS= ' -DCMAKE_BUILD_TYPE:STRING=Debug -DLLVM_ENABLE_ASSERTIONS:BOOL=TRUE -DLLVM_TOOL_SWIFT_BUILD:BOOL=NO '-DLLVM_TARGETS_TO_BUILD=X86;ARM;AArch64' -DLLVM_INCLUDE_TESTS:BOOL=TRUE -LLVM_INCLUDE_DOCS:BOOL=TRUE -DCMAKE_INSTALL_PREFIX:PATH=/usr -DINTERNAL_INSTALL_PREFIX=local /home/src/swift/llvm
CMake Error at cmake/modules/CheckAtomic.cmake:36 (message):
Host compiler appears to require libatomic, but cannot find it.
Call Stack (most recent call first):
cmake/config-ix.cmake:296 (include)
CMakeLists.txt:403 (include)
-- Configuring incomplete, errors occurred!
See also "/home/src/swift/build/Ninja-DebugAssert/llvm-linux-x86_64/CMakeFiles/CMakeOutput.log".
See also "/home/src/swift/build/Ninja-DebugAssert/llvm-linux-x86_64/CMakeFiles/CMakeError.log".
./utils/build-script: command terminated with a non-zero exit status 1, aborting
(gcc-4.8.2 was what I compiled llvm with)
libatomic is there:
$ locate libatomic
/opt/gcc-4.8.2/lib64/libatomic.a
/opt/gcc-4.8.2/lib64/libatomic.la
/opt/gcc-4.8.2/lib64/libatomic.so
/opt/gcc-4.8.2/lib64/libatomic.so.1
/opt/gcc-4.8.2/lib64/libatomic.so.1.0.0
I just don't know how to tell the build system where to look. I have tried the usual CMAKE_LIBRARY_PATH (exporting on the command line - I am not sure if cmake works like the way LD_LIBRARY_PATH, LIBRARY_PATH work) but it can't seem to find it.
I also don't have root on the machine.
I had not tried building from source on CentOS 6 until I saw this question, but I have been able to build Swift 2.2 on CentOS 7.1 and Ubuntu 14.04, with partial success. A few things to think about:
You will need numerous dependencies required to build Swift, and unless
they happen to be already on the system, you will need root access to
install them.
Use -R flag with the build-script to create a release build.
Building in DebugAssert (the default) will require a lot of memory. In my case even 14 GB was not sufficient. A release build
can be done with about 6 GB.
As for your specific problem, it is related to Clang's dependency on GCC-related packages for headers and libraries. See, for example, Fedora 21 with clang, without gcc.
Even if you installed GCC 4.8.2 and adjusted the path to use gcc and g++ from 4.8.2, Clang may still be looking in the old GCC directories for headers and libraries. CMake first tries to compile a C++ test file that includes the header atomic, which does not exist in the old GCC. So, it then tries to link a C test program that uses the library libatomic, which again doesn't exist in the old GCC. You can see this by looking at llvm/cmake/modules/CheckAtomic.cmake mentioned by usr1234567. CMakeError.log and CMakeOutput.log can also provide valuable insight. BTW, when I was building Swift on CentOS 7.1, I didn't run into this problem because GCC 4.8.2 was used by Clang for headers and libraries and the atomic header was found, so the C++ file got compiled. However, had the libatomic check been done, it would have failed, because libatomic.so in the repository-provided 4.8.2 has INPUT ( <name of some non-existent file> ), so trying to link with libatomic errors out.
I'm sure there are various ways of dealing with this issue, but what solved the problem for me was setting the following environment variables, please adjust to your specific setup:
export CPLUS_INCLUDE_PATH=/opt/gcc-4.8.2/include/c++/4.8.2:/opt/gcc-4.8.2/include/c++/4.8.2/x86_64-unknown-linux-gnu
export LIBRARY_PATH=/opt/gcc-4.8.2/lib64:/opt/gcc-4.8.2/lib/gcc/x86_64-unknown-linux-gnu/4.8.2
Also make sure that your 4.8.2 version of libstdc++.so is available to the dynamic linker at runtime. Since you don't have root, do
export LD_LIBRARY_PATH=/opt/gcc-4.8.2/lib64
If you had root, you could use ldconfig.
Before you start building Swift, you may want to try building, using Clang, a simple C program linking it with libatomic (the code doesn't actually have to use any symbols from the lib) and a simple C++ program that includes the <atomic> header. When compiling the C++ program, use the -std=c++11 compiler flag. If the C++ program compiles successfully, then it is not necessary for the libatomic linking test to be successful.
Interestingly, the CMakeOutput.log file still did not report finding GCC 4.8.2 as a candidate GCC installation, but the configuration/build worked well past the error.
Hopefully this helps. Please let us know if you run into something else.
CheckAtomic.cmake seems to be part of LLVM. I found a file at Github and it tries to find '__atomic_fetch_add_4' from libatomic
check_library_exists(atomic __atomic_fetch_add_4 "" HAVE_LIBATOMIC)
This fails for you. Check CMakeFiles/CMakeError.log to get more details why this test failed. Or try this line in a new project.
I have 64-bit Mac, OS X 10.8.5, and I have xcode installed. I can also verify gcc works from the command line. When I type mex -setup I get
The options files available for mex are:
1: /Applications/MATLAB_R2013a.app/bin/mexopts.sh :
Template Options file for building MEX-files
0: Exit with no changes
This is unhelpful. And when I type make, with all of the relevant libsvm files in my folder of choice, I get
make
xcodebuild: error: SDK "macosx10.7" cannot be located.
xcrun: error: unable to find utility "clang", not a developer tool or in PATH
mex: compile of ' "libsvmread.c"' failed.
If make.m fails, please check README about detailed instructions.
Is anyone able to help me with this?
The quickest thing is to edit the mexopts.sh file directly, using your favorite text editor (you may need to do this with "Administrator Privileges"). The file:
/Applications/MATLAB_R2013a.app/bin/mexopts.sh
defines a bunch of paths and flags for invoking the C/C++ compiler on your system. It tends not to keep up with revisions to the MacOS.
On my system, I had to make the following changes:
lines 258-260
CC='gcc'
SDKROOT='/Developer/SDKs/MacOSX10.6.sdk'
MACOSX_DEPLOYMENT_TARGET='10.6'
line 273
CXX=g++
There will be many references to "CC=" in the file; you're looking for the ones that follow the line
maci64)
But the correct values for your system depend on which gcc/g++ you have and where they are installed. As you can see, I have the MacOS 10.6 Developer tools installed under /Develop. You will need an install of the Developer tools (XCode) - see
How to use/install gcc on Mac OS X 10.8 / Xcode 4.4
In more recent versions of the XCode tools, the path might look more like:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk
But compiling MEX code with more recent versions of XCode might cause other problems - I had issues with char16_t, see:
MEX compile error: unknown type name 'char16_t'
I am using memcached-1.4.5 in our project. I am new to this & trying to compile it for mips architecture. I am getting below error:
checking for egrep... /bin/grep -E
checking for icc in use... no
checking for Sun cc in use... configure: error: in `$HOME/MEMCACHED':
configure: error: cannot run test program while cross compiling
See `config.log' for more details.
configure memcached failed, bailing out
If anybody has encountered such issues can help me out to fix this problem.
There are a lot of bugs in configure.ac for 1.4.5 that prevents you from doing a successful cross compilation. I believe they are fixed in the upcoming engine branch.. you may give that a shot..
A friend of mine asked me if it would be possible to port the Octave project to the iPhone. I haven't compiled an external package for an iPhone project before, so I downloaded the source code, and then used some scripts found on a couple of different Web sites (one, two) to try and build the libraries. However, when I try either of these scripts (which are nearly identical), they eventually die during the configure phase with the following error output:
[...snip checks...]
checking whether we are using the GNU Fortran 77 compiler... no
checking whether accepts -g... no
checking how to get verbose linking output from ... configure: WARNING: compilation failed
checking for Fortran 77 libraries of ... rm: conftest.dSYM: is a directory
checking for dummy main to link with Fortran 77 libraries... rm: conftest.dSYM: is a directory
none
checking for Fortran 77 name-mangling scheme... configure: error: cannot compile a simple Fortran program
See `config.log' for more details.
Is the problem that the iPhone SDK/Xcode doesn't include a Fortran cross-compiler, or am I doing something wrong?
The iPhone SDK does not include a FORTRAN compiler. Apple's last FORTRAN product was for the Apple ][, although 3rd party and/or open source compilers have existed for most systems Apple has built.
You could configure and build gfortran, but it's going to be a PITA. You'll likely need to merge in changes from Apple's customized GCC 4.2 fork found under iPhone here with a recipe for building it for Darwin, such as this.
You might try f2c as the Octave project suggests.