Faild to build clang with ninja [duplicate] - clang

This question already has an answer here:
Building clang taking forever
(1 answer)
Closed 4 years ago.
There was a problem when I've tried to build clang with ninja.I've executed all commands one after another from the link:
http://clang.llvm.org/docs/LibASTMatchersTutorial.html
but after running ninja where the tutorial says "Okay.Now we’ll build Clang!" it takes 2 hours to build half of the objects and after that OS stuck and I couldn't even move the cursor.I did the job on both my laptop and PC but the result was the same.What is attract my attention is that, the size of the folder is so huge (18.3GB).
Is there any way to solve the problem?

I have already answered the same question on StackOverflow here. I will suggest a deeper search in future before asking the same question.
Including information here in case link is lost. What is happening is that building clang in debug mode (that's by default) a lot of debug information is also being generated for each compilation unit the file sizes are becoming big.
The solution is to turn off all the debug info that's been attached by default. You probably are not going to debug clang, so won't need it. So instead of just doing this
cmake -G Ninja ../llvm -DLLVM_BUILD_TESTS=ON
What you should do is
cmake -G Ninja ../llvm -DLLVM_BUILD_TESTS=ON -DCMAKE_BUILD_TYPE=Release
All the other steps remain the same.

Related

Produce all possible errors with Clang/Ninja / Keep going with Ninja / Ninja equivalent of make -k

I am compiling a fairly large library with many outside dependencies that I need to pull in. Each time I attempt a compilation I get a new error about a missing header file. I then have to go and track down where to find that header/library and add it to the project includes. This process of compilation-then-find-header/source is repeated and takes a lot of time.
I would like the compiler to continue trying to build and output all missing headers in one error list. Is this possible using Clang and if so how can I control it? On a related note, once I have all headers is it possible to tell Clang to report all linker errors/undefined references, so I don't have to repeat this process with source files?
I am looking for compiler flags to print out all possible errors (missing headers) and all undefined references. In other words, I want the compilation to continue passed the first file with errors and attempt to compile all files in the project. The compiler is Clang (C/C++) version 8.0.2. The make tool is ninja (1.5.3). Make files are generated with CMake (3.6.4).
Update:
Looking back, my original question was asking for a solution in the wrong tool. Instead of passing a flag to Clang, I needed to pass a flag to my make tool, Ninja.
From ninja --help:
-k N keep going until N jobs fail [default=1]
so i'd run ninja command like:
ninja -k 100
to continue until 100 errors are found or the build succeeds. One thing to note is that some errors may just stop the entire build if the erroneous file is necessary to continue the build process.

Xcode export localization throws error "Argument list too long"

I've got a very curious error to share regarding Xcode localization process. I will try to share as much detail as legally possible.
From Xcode, I am trying to export an XLIFF file to send to our translators, via "Editor > Export for Localizations". However, this immediately throws error with the message:
The operation couldn't be completed. Argument list too long
This is indeed confusing, as I cannot find a more verbose log anywhere (I have already tried checking my Console.app). So, I spent quite a few time googling – to no avail. I couldn't find similar case like this. The error itself happens only when I am trying to export for localization. I can build and run the app just fine.
Facts
~ $ xcodebuild -version
Xcode 8.2
Build version 8C38
~ $ xcode-select -version
xcode-select version 2347.
~ $ echo $PATH
/Users/david.christiandy/.rbenv/shims:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Users/david.christiandy/arctools/arcanist/bin:/usr/local/go/bin:/Library/Frameworks/Mono.framework/Versions/Current/Commands
I am using Xcode 8.2 on macOS Sierra 10.12.5.
The error happens only when I try exporting from localization. This is also true when I run the localization process via xcodebuild -exportLocalizations.
I can build and run the app just fine. (I believe) there's no problem with my header search paths.
Attempts
Thought there was something wrong in the code, so I tried to run the export process (via xcodebuild command) in a CI. Somehow, it's working. For the record, I am using Bitrise CI with the same stack as my system (Xcode 8.2.x, macOS 10.12)
Asked colleagues to run export process on their machines, and they have the same error.
This leads me to think that there must be something wrong with the configuration. So I made a standalone project to confirm that the export process fails consistently. Turns out, it works just fine!
So, the hypothesis I got currently is:
There's probably something wrong in the code, and
There might be tools/software (that most of our iOS engineers installed) that might contribute to the error (since the CI completes just fine).
I don't know why the CI can run the export process just fine, and I don't know when it might suddenly stop functioning (just like our local machines).
Appreciate any help on this matter. Thank you!
I also asked this question on Apple developer forums, here is the link: https://forums.developer.apple.com/thread/86762
“Argument list too long” sounds like E2BIG, which you get when you try to run a child process with a huge argument list (I believe the current limit is 256 KiB). I suspect that Export for Localizations is running some sort of command line tool to do that work (probably the extractLocStrings tool, which you’ll find lurking within Xcode’s app bundle) and passing it full paths to each of the files in your project. Depending on how many files you have and how long those paths are, it’s easy to run into problems like this.
One of the ‘fun’ things about bugs like this is that they are dependent on where you place your project. Things might work if the project is at the top of your home directory but fail if it’s nested deep inside a subdirectory.
That also suggests a potential workaround, namely, to move your project further up in the directory hierarchy.
Finally, you should definitely file a bug about this. I believe we’ve seen this before (r. 30703294) but your report will help reinforce that this is causing problems for developers in the field. Please post your bug number, just for the record.
Several days ago before I read this answer, I managed to get the export working by deleting some folders via Xcode (remove references only). Initially I suspected that there's an invalid format within the folders that I deleted, but when I tried deleting other folders, the export process works just fine.
I also tried exporting strings using Xcode 9, and I didn't encounter the problem. So hopefully this bug is only for Xcode 8.3.3 and below.

Suppress xcodebuild output or make less verbose [duplicate]

This question already has answers here:
How to filter the xcodebuild command line output?
(11 answers)
Closed 7 years ago.
I am building my app in teamcity with xcodebuild command line tools. I am looking for a way to suppress or make the output less verbose but still show errors or failures if they happen. The build log becomes very large and the browser has a hard time loading it.
Are there optional parameters I can pass in or a way to stream it to a log file?
It's not possible. However You can make the log more readable with xctool or xcpretty - not sure the size is also changed. Probably, it is.
If you use xcpretty https://github.com/supermarin/xcpretty you will have something readable and less verbose, the size will be smaller. It's a great tool, especially if you have unit test. You can take a look to the github they show exemples.

compiling and running c/c++ programs in-memory [closed]

Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
Can we compile and run a C/C++ program completely in the memory without need of disk access?
Normally one writes a C/C++ program in editor, saves to disk(in file) and then compiles it. Compiling creates executable file on disk, which one runs to see if it works correctly. What I want to do is to write a program, save to file, invoke gcc/g++ in such a way that it creates machine code but directly loads that on memory to run. So once I am satisfied with program output, I can again invoke gcc/g++(as done usually) to create executable file on disk.
You can use gcc -pipe to avoid some temporary files. And you can pipe the source code into GCC by gcc -xc -. You can even have GCC write its output to stdout:
echo 'int main() {}' | gcc -xc - -S -o -
Once you've done all that, you are left with a couple issues: where to get GCC from (usually it's on disk!), and where to get the #include and library files you need (ditto). You could install GCC (it comes with a standard library) onto a RAM disk (look at /dev/shm), but is that really what you're trying to accomplish?
You aren't going to speed up compilation this way. The GCC docs say as much regarding -pipe. If you want faster compilation, improve your source code, implement a parallel build system (make -j), and/or use a faster linker, like Gold instead of classic BFD.
Yes, you can. An easy way is to use tmpfs.

force cmake to compile openCV with llvm

Background
My goal is to compile OpenCV for ios with support for the armv7s (the s is the hard part) architecture but have been unable to make any progress. My most recent theory is that the problem is that the cmake files that come with the library use gcc as a compiler which I do not think supports armv7s (if I am wrong please tell me). I am completely new to cmake however and have not been able to change the compiler.
The reason I suspect the compiler is because of the line
set (CMAKE_OSX_ARCHITECTURES "$(ARCHS_STANDARD_32_BIT)" CACHE string "Build architecture for iOS")
which as far as I know should include armv7s. Changing that line to
set (CMAKE_OSX_ARCHITECTURES "armv6;armv7;armv7s;i386" CACHE string "Build architecture for iOS")
had no effect.
I know there are explanations of how to set the compiler here, here, and here. My problem is that I am trying to change an existing cmake system and don't know what ramifications my changes could have. The code in question can be downloaded here. To build the framework I run the python script in OpenCV-2.4.2/ios
python build_framework.py ~/Desktop
from what I can tell the relevant cmake files are located in OpenCV-2.4.2/ios/cmake. There are only 3 and all are fairly short. My most recent attempt was to change two lines in the toolchains
CMAKE_FORCE_C_COMPILER (gcc gcc)
CMAKE_FORCE_CXX_COMPILER (g++ g++)
to
SET (DEVROOT "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer")
SET (CC "${DEVROOT}/usr/bin/llvm-gcc-4.2")
SET (CXX "${DEVROOT}/usr/bin/llvm-g++-4.2")
CMAKE_FORCE_C_COMPILER (${CC} CLang)
CMAKE_FORCE_CXX_COMPILER (${CXX} CLang)
in an attempt to copy this SO question.
Question
My first and most important question is if this is out of my depth. I have been assuming that changing the compiler/target architecture would be a simple flag set somewhere but I am becoming less convinced that is true. Also, there is an entire directory OpenCV-2.4.2/cmake filled with much larger cmake files that I have been avoiding in the hopes I don't need to worry about their contents. Is this a problem I am going to be able to solve in less than 10 hours?
If you answered yes to the previous question, can you give me any direction? Suggested reading? Am I justified in ignoring the contents of OpenCV-2.4.2/cmake? I have been shooting in the dark for quite a while now without success.
If it turns out this is as simple as I originally hoped, how do I do it?
Update
I never did figure out how to do this, but there is an xcode version of the library here from which the compiling settings can be changed easily.
Set CMAKE_C_COMPILIER and CMAKE_CXX_COMPILIER to what you need.
Edit: this supposes you already had success with building this for armv7.
Edit2: this will just change the compiler.
I see a lot of links in your question, but didn't find original link with information how to cross compile with CMake.
You should not change anything in existing build system.
In general you need to create toolchain file for your target architecture and run cmake with it.
cmake -DCMAKE_TOOLCHAIN_FILE=< your toolchain file > < path to CMakeLists.txt from opencv >

Resources