Shulou(Shulou.com)06/03 Report--

Recently, to download colleagues' Android project code and collaborate to develop some underlying Native features, you need to compile some underlying JNI code bases first. Because the project is large and depends on a large number of third-party libraries, after downloading, you compile through ndk-build, reporting some strange errors and pointing to the last line of the code file, as shown below:

Fatal error: error writing to -: Invalid argument} ^

This project source code has been colleagues in the MAC development and maintenance, in my colleague's environment is normal, and I am Windows platform, at the beginning of the suspect is the wrong file type, through the NotePad++ conversion code file format to UNIX, compilation test failed; through the msys VI editor to copy the contents of this new file code file and save as a new file, after testing is not good, so determined should not be a file format problem.

Through Google to find this error message, there is only one useful information, that is, the file path name is too long, just make it shorter. We know that the Windows system limits the maximum length of the path to 260bytes, but I see that the total length of our file path is only more than 130bytes, and the maximum length has not been checked yet, but through simple attempts, such as just shortening the length of the file name, compile. In the end, it is found that there is some effect, at least most native code files will no longer report such errors, but unfortunately, of the four ABI schemas (armeabi, armeabi-v7a, arm64-v7a, x86) compiled by NDK, the first three ABI can be compiled successfully, but the last one will still report the above errors, and the error will only be the first code file pointed to by LOCAL_SRC_FILES, and the order of the code files will remain the same. This shows that this kind of compilation error should be related to the Android.mk file, and this mk file runs normally on my colleague's MAC, but there are all kinds of errors on my Windows. In view of this problem, it seems that the simple method of shortening the code file name in the above method does not fundamentally solve the problem, by carefully examining the log information output in the process of ndk-build compilation. Found that the generated code intermediate file *. O is stored in the very deep directory of objs, right? the global path of my code file has been copied again. If you copy and paste such a folder through the shortcut keys of Windows, the system will report an error and prompt that the path length is too long. At this point, I seem to see a glimmer of hope.

It turns out that in order to ensure that the project directory can be downloaded and compiled uniformly, colleagues define a macro variable in front of the code file, such as:

ENCODER_MODULE_PATH: = $(TOP_LOCAL_PATH) / encoder-module

Then, when referencing the specified code file list, add this macro variable as a prefix, such as:

LOCAL_SRC_FILES + = $(ENCODER_MODULE_PATH) / video_encoder.c

This is equivalent to making an absolute path to this file, because the directory where the code is located is already very deep, which is equivalent to repeating the directory of the source files in the obj intermediate files directory, resulting in an overall path length of more than 260bytes, thus reporting such a strange error, while the maximum length limit of the directory under Linux defaults to 4096. No wonder colleagues' MAC systems do not report errors. OK, we know the reason. Just change the absolute path to the relative path in the source file list, such as:

LOCAL_SRC_FILES + =. / video_encoder.c

At this point, the job is done and the compilation is successful!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.