When I run the make world command I got this error.
Anyone know what is causing this? I think it is related to my gcc version, but I could not upgrade it in debian. My gcc version is 4.7.2
numa.c: In function ‘acpi_parse_slit’:
numa.c:99:6: error: variable ‘localities’ set but not used [-Werror=unused-but-set- variable]
numa.c: In function ‘acpi_parse_srat’:
numa.c:152:26: error: variable ‘srat’ set bbut not used [-Werror=unused-but-set- variable]
It's caused by two variables being defined, set to a value, and then never used - the error messages pretty much say that... In addition, you have -Werror or one of its variants set, that turns what would normally be just a warning for a useless construct into an error, which causes the build to terminate.
Either remove the definitions of those two variables (probably not the best solution), or fix your build flags to get rid of the -Werror bits that escalate warnings into errors...
Try adding "KBUILD_CFLAGS += -Wno-error=unused-but-set-variable" to your Makefile(found in Xen root).
Related
I am trying to build FFMPEG 4.2 using Android NDK r20 and I am having an issue with configure.
I followed Ilia Kosynkin's blog post (https://medium.com/#ilja.kosynkin/building-ffmpeg-4-0-for-android-with-clang-642e4911c31e) and with a few minor changes to build.sh I successfully built FFMPEG 4.0.2 using Android NDK r17c for API level 14 on an Ubuntu 16 VM.
I updated FFMPEG to 4.2 and the Android NDK to r20 and got these and other compiler errors.
~/android-ndk/sysroot/usr/include/stdlib.h:61:7: error: expected identifier or '('
char* getenv(const char* __name);
^
./config.h:17:19: note: expanded from macro 'getenv'
#define getenv(x) NULL
^
~/android-ndk/toolchains/llvm/prebuilt/linux-x86_64/lib64/clang/8.0.7/include/stddef.h:105:18: note: expanded from macro 'NULL'
# define NULL ((void*)0)
and many like this:
./libavutil/libm.h:54:32: error: static declaration of 'cbrt' follows non-static declaration
static av_always_inline double cbrt(double x)
^
~/android-ndk/sysroot/usr/include/math.h:191:8: note: previous declaration is here
double cbrt(double __x);
^
In addition to cbrt there were about a dozen or so other math related functions redefined (e.g. lrint, round, trunc, inet_aton). I opened the generated config.h, commented out #define getenv(x) NULL and changed a bunch of defines like #define HAVE_CBRT 0 to #define HAVE_CBRT 1. I ran make and make install and the build was successful.
So my question is, are there ffmpeg options that I can pass to configure that will generate a config.h that I don't have to modify in order to get a successful build?
EDIT: Additional information from config.log.
It appears that check_mathfunc in configure is failing for NDK r20 but I can't tell why. Here is an example of a link command failing for the check for truncf. The error does not make any sense to me.
~/android-ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-ld
-L~/android-ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/lib/gcc/arm-linux-androideabi/4.9.x
-L~/android-ndk/platforms/android-29/arch-arm/usr/lib
--fix-cortex-a8 -lc --sysroot=~/android-ndk/sysroot -fPIE -pie
-o /tmp/ffconf.1OTX8pa8/test /tmp/ffconf.1OTX8pa8/test.o -lgcc
~/android-ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-ld:
fatal error: -f/--auxiliary may not be used without -shared
EDIT 2: The error seems to be caused by the -pie option (Create a position independent executable). Previous version of FFMPEG did not have these 2 lines in the configure script for android:
add_cflags -fPIE
add_ldexeflags -fPIE, -pie
If I add -shared to add_ldexeflags I get the error "-shared and -pie are incompatible". If I replace -pie with -shared, check_mathfunc succeeds but I don't know if that is the correct thing to do. It seems odd that -fPIE requires -shared but -pie cannot be used with it.
Replacing -pie with -shared seems to fix the config.h file but now I get 'sys/sysctl.h' file not found during the build of libavutil. NDK r20 has 2 instances of sysctl.h and NDK r17c has 1 but none of them are in a directory named sys.
EDIT 3: I am going to chalk this one up to a bug in the FFMPEG configure script. configure checks for the existence of a function by generating a small source file that uses the function and then compiling and linking the generated file. If anything fails the function is not available. For NDK r17c, check_func sysctl fails and the build excludes sysctl functionality. For some reason, the test succeeds for NDK r20 because check_func does not verify whether or not sys/sysctl.h exists it just prototypes sysctl() and calls it. I solved this issue by adding a function to configure named check_sysfunc that tries to include sys/sysctl.h. I now get past this error and have a new one about an implicit declaration being invalid. I have to assume it is also a deficiency in configure and hopefully there won't be too many more of these.
I'm currently trying to do the same thing as you. Apparently, this guy (not me) manage to compile ffmpeg4.2 with NDK r20. So far it seem to work with ARCH=armv7a
[Youtube] https://www.youtube.com/watch?v=RP8SEAhcq5M
[Github] https://github.com/binglingziyu/ffmpeg-android-build
[P.s. I don't have enough reputation to post as a comment... so yeah...]
Passing -fPIE to ld directly is wrong. That's a compiler flag. The linker flag is spelled -pie. -fPIE is -f PIE, which is a completely different argument:
https://linux.die.net/man/1/ld
-f name
--auxiliary=name When creating an ELF shared object, set the internal DT_AUXILIARY field to the specified name. This tells the dynamic
linker that the symbol table of the shared object should be used as an
auxiliary filter on the symbol table of the shared object name. If you
later link a program against this filter object, then, when you run
the program, the dynamic linker will see the DT_AUXILIARY field. If
the dynamic linker resolves any symbols from the filter object, it
will first check whether there is a definition in the shared object
name. If there is one, it will be used instead of the definition in
the filter object. The shared object name need not exist. Thus the
shared object name may be used to provide an alternative
implementation of certain functions, perhaps for debugging or for
machine specific performance.
This option may be specified more than once. The DT_AUXILIARY entries
will be created in the order in which they appear on the command line.
As for the other issue:
NDK r20 has 2 instances of sysctl.h and NDK r17c has 1 but none of them are in a directory named sys.
I just filed https://github.com/android-ndk/ndk/issues/1068, but I'm not sure if we'll fix that one. Apparently its use is strongly discouraged. Fixing the source to not use that is probably the better call.
TLDR: Getting fatal error 'failed to get process times' on cross-native build of gcc. Can I remove report_times code from gcc.c OR use gcc command line option to disable report_times OR build gcc without libiberty (which contains pex_get_times used by report_times
DETAIL
After beating my head against various problems I've (finally) successfully used the Android NDK standalone toolchain to build binutils 2.23 and gcc 4.70.
My current problem is getting it to run on my device.
I've written a standard 'hello world' (copied from here) to test gcc on my device. When I run:
arm-linux-eabi-gcc hello.c -o hello
or:
arm-linux-eabi-gcc hello.c
I get the following error:
arm-linux-eabi-gcc: fatal error: failed to get process times: No such file or directory.
Google did not return much except for links to gcc.c source. Examining the source, I found the error in a function (module? extension?) called report_times. The error is returned by the function (module? extension?) pex_get_times....I'm guessing it does so if it can't get the process times.
The pex_get_times function (module? extension? I'm not sure what it is) is defined in libiberty. I can use --disable-build-libiberty, but it doesn't help for the host (my NookHD) gcc build.
My question(s):
Can this portion of gcc.c be safely (and easily) removed...i.e. the report_times function and everything associated with it?
or
Is there a command line option to tell arm-linux-eabi-gcc NOT to use report_times?
or
Is there a way to disable build of libiberty for host/target for both gcc and binutils, and would that fix the error?
As always...I'll keep researching while awaiting an answer.
Found this about an hour after posting this question. Maybe two.
Apparently report_times is part of debugging symbols (?) for GCC. To exclude report_times (which causes the 'failed to get process times' from the original question) you have to build the non-debug...or release...version of gcc.
To do this, I used info from this link: http://www-gpsg.mit.edu/~simon/gcc_g77_install/build.html
BUT, I omitted the -g from the LIBCXXFLAGS and LIBCFLAGS and I added LIBCPPFLAGS without -g just in case. Ran make DESTDIR=/staging/install/path install-host, tarballed and transferred to device. No more 'failed to get process times' error.
I am seeing another error, but it is not related to this question
I am developing a BREW application. When compiling the application to get a MOD file, I am continuously getting this error:
cc1.exe: warnings being treated as errors
I want to disable this warning. I have googled it, and many say disabling -werror will help, but how can I do that?
The compiler is CodeSourcery ARM.
You need to remove -Werror from CFLAGS, CPPFLAGS etc.; these are usually set in Makefile's or build scripts.
However, I'd strongly advice to fix the actual warnings instead, which will produce more stable and error-free code.
Run this Command in Terminal to say, not to consider warning as error
make CFLAGS="-Wno-error=format-truncation"
I am trying to build a pass using llvm and I have finished building llvm and its associated components. However, when I run make after following all the steps to build a pass including the makefile, I get the following
relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
After tyring to find a fix by googling the error message, I came to know that this is not specific to llvm. A few solutions suggested that I should use "--enable-shared" while running configure but that didn't help my case. Now I want to re-build llvm using fPIC, as the error says. But how do I do this using the makefile?
Looks like you could add the -fPIC (for position-independent code, something you want for a shared library that could be loaded at any address) by setting shell variables:
export CFLAGS="$CFLAGS -fPIC"
export CXXFLAGS="$CXXFLAGS -fPIC"
Looking at Makefile.rules, these will be picked up and used. Seems strange that it wasn't there to begin with.
EDIT:
Actually, reading more in the makefiles, I found this link to the LLVM Makefile Guide. From Makefile.rules, setting either SHARED_LIBRARY=1 or LOADABLE_MODULE=1 (which implies SHARED_LIBRARY) in Makefile will put -fPIC in the compiler flags.
If you are moderately convinced that you should use '-fPIC' everywhere (or '-m32' or '-m64', which I need more frequently), then you can use the 'trick':
CC="gcc -fPIC" ./configure ...
This assumes a Bourne/Korn/POSIX/Bash shell and sets the environment variable CC to 'gcc -fPIC' before running the configure script. This (usually) ensures that all compilations are done with the specified flags. For setting the correct 'bittiness' of the compilation, this sometimes works better than the various other mechanisms you find - it is hard for a compilation to wriggle around it except by completely ignoring the fact you specified the C compiler to use.
Another option is to pass -fPIC directly to make in the following way:
make CFLAGS='-fPIC' CXXFLAGS='-fPIC'
I get this warning from GCC:
warning: cannot pass objects of non-POD type 'class Something' through '...'; call will abort at runtime
It's pretty deadly, especially since it calls an abort. Why isn't this an error? I would like to make it an error, but:
How do I make a specific warning an error?
Which warning is it? According to 3.8 Options to Request or Suppress Warnings, -Wno-invalid-offsetof, it looks like the flag to hide it, but it doesn't.
I'm not sure what the correct warning is, but once you've found it, you can change its disposition with the following (using 'format' as the example):
#pragma GCC diagnostic error "-Wformat"
Or as strager points out:
gcc -Werror=format ...
I've checked the gcc source for this and this specific warning cannot be disabled via command line flags.
-Werror=specific-warning will turn the specified -Wspecific-warning into an error in GCC 4.3.x or newer. In 4.1.2, only -Werror-implicit-function-declaration works. Note the hyphen instead of equals sign -- it works for that specific case only and no others. This is one of the more serious common warnings and it's definitely handy to make it into an error.
Apart from that, older versions of GCC only seem to provide the -Werror sledgehammer of making every last warning an error.
It sounds like there are a bunch of other warnings that you don't want to be turned into errors (using the -Werror flag). In general, it's good practice to fix all warnings. Using -Werror forces this.
You can use the -Werror compiler flag to turn all or some warnings into errors.
You can use -fdiagnostics-show-option to see the -W option that applies to a particular warning.
Unfortunately, in this case there isn't any specific option that covers that warning.
It appears that there will be better support for this in GCC 4.5.