Error on compilation of x264 on qnap - compilation

We are facing issues on compiling x264 on qnap.
We need to compile ffmpeg with x264 library, qnap packages have the built-in x264 0.66 library but ffmpeg-0.9.2 doesn't support too old version of x264 and produces the following error on compiling x264 from source.
[/share/MD0_DATA/.qpkg/x264-snapshot-20130208-2245] # make
gcc -Wshadow -O3 -ffast-math -m32 -Wall -I. -I. -march=i686 -mfpmath=sse -msse -std=gnu99 -I/opt/include -I/opt/include -fomit-frame-pointer -fno-tree-vectorize -c -o x264.o x264.c
x264.c: In function 'help':
x264.c:401: error: 'X264_VERSION' undeclared (first use in this function)
x264.c:401: error: (Each undeclared identifier is reported only once
x264.c:401: error: for each function it appears in.)
make: *** [x264.o] Error 1
[/share/MD0_DATA/.qpkg/x264-snapshot-20130208-2245] # cat /proc/version
Linux version 2.6.33.2 (root#NasX86-4) (gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)) #1 SMP Wed Dec 5 06:48:23 CST 2012
Can someone assist me on that ?

Probably version.sh does not have execution permission. So, chmod 744 version.sh then retry configure and make.

X264_VERSION define is generated in x264_config.h during configure script execution by calling to version.sh. So either it wasn't generated in x264_config.h (some fault of your building environment and need analyze of config.log) or you have old x264.h headers somewhere in you include path which for some reason used instead of new one.

Removing --prefix="path" from the ./configure arguments fixed this error for me.

Related

GCC undefined reference to thrd_create() in C11 mode after #include <threads.h> in Debian

I'm trying to compile a program that I've been able to compile on several other Debian environments with no issues using the C11 <threads.h> library on a relatively fresh install of Debian Bullseye with "gcc (Debian 10.2.1-6) 10.2.1 20210110" installed
with the command
gcc -o <progname> -O3 -Wall -Wextra -std=c11 -lpthread <sourcefile>
and I'm getting a string of linker errors in the form of
undefined reference to 'mtx_unlock'
as well as mtx_lock mtx_init thrd_create etc.
But I'm not getting an error saying the threads.h file is absent. I tried removing the -lpthread argument from the compilation command but this changed nothing.
What is going wrong?
The correct command line parameter seems to be -pthread without the l.

Error building ELLCC

Running the build script from ELLCC results in this error
gcc -DHAVE_CONFIG_H -I. -I../../../src/binutils/binutils -I. -I../../../src/binutils/binutils -I../bfd -I../../../src/binutils/binutils/../bfd -I../../../src/binutils/binutils/../include -I./../intl -DLOCALEDIR="\"/Library/Caches/Homebrew/ellcc--svn-HEAD/lib/share/locale\"" -Dbin_dummy_emulation=bin_vanilla_emulation -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -Wno-unused-value -Wno-shadow -MT nm.o -MD -MP -MF .deps/nm.Tpo -c -o nm.o ../../../src/binutils/binutils/nm.c
../../../src/binutils/binutils/nm.c:1690:28: error: 'sbrk' is deprecated
[-Werror,-Wdeprecated-declarations]
char *lim = (char *) sbrk (0);
^
/usr/include/unistd.h:582:7: note: 'sbrk' declared here
void *sbrk(int);
^
The following compilers have been used with the same result:
gcc 4.8
llvm-gcc 2.8
llvm 3.3
I had the same issue compiling binutils-2.24 on Mac OSX Mavericks 13.2.0 with clang. Thanks to Richard Pennington's suggestion, I was able to get binutils to compile by specifying a few other -Wno-error arguments to gcc by setting CFLAGS before running configure. Namely, these are the commands I ran to build and install binutils:
CFLAGS="-Wno-error=deprecated-declarations -Wno-error=unused-variable -Wno-error=unused-function" ./configure --prefix=/usr/local/toolchain-arm-linux-elf --target=arm-linux-elf
make
make install
EDIT: I just noticed that the binutils configure script accepts an --disable-werror argument, which disables gcc turning warnings into errors, and removes the need for the settings CFLAGS. With this argument, building could be done as follows:
./configure --prefix=/usr/local/toolchain-arm-linux-elf --target=arm-linux-elf --disable-werror
make
make install
This error is occurring because sbrk() is deprecated on OSX, -Werror is enabled for the binutils build, and the compiler (in this case "gcc" is an alias for clang) rightly complains about the use of sbrk(). I'll be looking into eliminating this error this weekend when I won't have to be at my day job. ;-)
I looked into it a bit more. This happened because the latest version of OS X (Mavericks) uses clang as its compiler and /usr/include/unistd.h has a deprecated declaration of sbrk().
The solution was to add a -Wno-error=deprecated-declarations option to the CFLAGS for binutils. I also had to make a few other changes to complete the Max OS build. You can find the latest stuff in the ELLCC subversion tree.

Error when installing ffmpeg-php

I am trying to install ffmpeg and ffmpeg-php and am getting an error when I try to use make. I've tried to get to the bottom of it but it has me stumped. I tried finding which file has references to swscale.h but didn't have any luck. Has anyone encountered this error before?
root#vps [/usr/local/src/ffmpeg-php-0.6.0]# make
/bin/sh /usr/local/src/ffmpeg-php-0.6.0/libtool --mode=compile gcc -I. -
I/usr/local/src/ffmpeg-php-0.6.0 -DPHP_ATOM_INC -I/usr/local/src/ffmpeg-
I/usr/local/src/ffmpeg-php-0.6.0 -DPHP_ATOM_INC -I/usr/local/src/ffmpeg-
php-0.6.0/include -I/usr/local/src/ffmpeg-php-0.6.0/main -
I/usr/local/src/ffmpeg-php-0.6.0 -I/usr/local/include/php -
I/usr/local/include/php/main -I/usr/local/include/php/TSRM -
I/usr/local/include/php/Zend -I/usr/local/include/php/ext -
I/usr/local/include/php/ext/date/lib -I/usr/local/include/libavcodec/ -
I/usr/local/include/libavformat/ -I/usr/local/include/libavutil/ -
I/usr/local/include/libswscale/ -I/usr/local/include/libavfilter/ -
I/usr/local/include/libavdevice/ -I/usr/local/include/php -DHAVE_CONFIG_H
-g -O2 -Wall -fno-strict-aliasing -c /usr/local/src/ffmpeg-php-
0.6.0/ffmpeg-php.c -o ffmpeg-php.lo
gcc -I. -I/usr/local/src/ffmpeg-php-0.6.0 -DPHP_ATOM_INC -
I/usr/local/src/ffmpeg-php-0.6.0/include -I/usr/local/src/ffmpeg-php-
0.6.0/main -I/usr/local/src/ffmpeg-php-0.6.0 -I/usr/local/include/php -
I/usr/local/include/php/main -I/usr/local/include/php/TSRM -
I/usr/local/include/php/Zend -I/usr/local/include/php/ext -
I/usr/local/include/php/ext/date/lib -I/usr/local/include/libavcodec/ -
I/usr/local/include/libavformat/ -I/usr/local/include/libavutil/ -
I/usr/local/include/libswscale/ -I/usr/local/include/libavfilter/ -
I/usr/local/include/libavdevice/ -I/usr/local/include/php -DHAVE_CONFIG_H -g
-O2 -Wall -fno-strict-aliasing -c /usr/local/src/ffmpeg-php-0.6.0/ffmpeg-
php.c -fPIC -DPIC -o .libs/ffmpeg-php.o
/usr/local/src/ffmpeg-php-0.6.0/ffmpeg-php.c:46:21: error: swscale.h: No
such file or directory
/usr/local/src/ffmpeg-php-0.6.0/ffmpeg-php.c: In function 'zm_info_ffmpeg':
/usr/local/src/ffmpeg-php-0.6.0/ffmpeg-php.c:156: error: 'LIBSWSCALE_IDENT'
undeclared (first use in this function)
/usr/local/src/ffmpeg-php-0.6.0/ffmpeg-php.c:156: error: (Each undeclared
identifier is reported only once
/usr/local/src/ffmpeg-php-0.6.0/ffmpeg-php.c:156: error: for each function
it appears in.)
make: *** [ffmpeg-php.lo] Error 1
Installing libswscale-dev helped me on Debian Squeeze
It looks like it can't find swscale.h. You should check to see if that file was included with your FFmpeg install, and, if so, that ffmpeg-php has the correct set of paths specified with -I/path/to/includes to find it. If it doesn't, you can add the correct directory with something like:
CFLAGS=-I/path/to/ffmpeg/includes ./configure
make
If you can't find swscale.h, it could be that there's some version mismatch between FFmpeg and ffmpeg-php. The former is pretty actively developed, and pieces that ffmpeg-php expects to find might no longer be present. Check the docs for ffmpeg-php to see if it's tied to a particular version.

Compiling LLVM 2.9's gcc 4.2 on kernel 3.0 with gcc 4.6

I'm trying to get llvm-gcc 4.2.2.9 to compile on this x86_64 system which runs the 3.0.0-21-generic kernel. llvm 2.9 itself builds fine. I suspected the downloadable version of llvm-gcc was causing some other problems, so I decided to build llvm-gcc myself.
Like suggested in the README.LLVM I configured with
../llvm-gcc-4.2-2.9.source/configure \
--prefix=/opt/llvm-gcc4.2-2.9/../llvm-gcc4.2-2.9-install \
--disable-multilib \
--program-prefix=llvm- \
--enable-llvm=/opt/llvm-2.9 \
--host=x86_64-generic-linux-gnu
--enable-languages=c,c++
I'm running this from the /opt/llvm-gcc4.2-2.9 directory, while the sources are sitting in /opt/llvm-gcc-4.2-2.9.source and my llvm 2.9 lives in /opt/llvm-2.9. Note that I'm setting the --host instead of the --target as this implicitly sets the --target to the same architecture.
make does build a lot of stuff (producing a sizeable amount of warnings) when finally stopping at this error:
make[3]: Entering directory `/opt/llvm-gcc4.2-2.9/gcc'
/opt/llvm-gcc4.2-2.9/./gcc/xgcc -B/opt/llvm-gcc4.2-2.9/./gcc/ -B/opt/llvm-gcc4.2-2.9/../llvm-gcc4.2-2.9-install/x86_64-generic-linux-gnu/bin/ -B/opt/llvm-gcc4.2-2.9/../llvm-gcc4.2-2.9-install/x86_64-generic-linux-gnu/lib/ -isystem /opt/llvm-gcc4.2-2.9/../llvm-gcc4.2-2.9-install/x86_64-generic-linux-gnu/include -isystem /opt/llvm-gcc4.2-2.9/../llvm-gcc4.2-2.9-install/x86_64-generic-linux-gnu/sys-include -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I. -I../../llvm-gcc-4.2-2.9.source/gcc -I../../llvm-gcc-4.2-2.9.source/gcc/. -I../../llvm-gcc-4.2-2.9.source/gcc/../include -I../../llvm-gcc-4.2-2.9.source/gcc/../libcpp/include -I../../llvm-gcc-4.2-2.9.source/gcc/../libdecnumber -I../libdecnumber -I/opt/llvm-2.9/include -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-toplevel-reorder -fno-omit-frame-pointer -fno-asynchronous-unwind-tables \
-c ../../llvm-gcc-4.2-2.9.source/gcc/crtstuff.c -DCRT_BEGIN \
-o crtbegin.o
In file included from /usr/include/stdio.h:28,
from ../../llvm-gcc-4.2-2.9.source/gcc/tsystem.h:90,
from ../../llvm-gcc-4.2-2.9.source/gcc/crtstuff.c:68:
/usr/include/features.h:323:26: error: bits/predefs.h: No such file or directory
/usr/include/features.h:356:25: error: sys/cdefs.h: No such file or directory
/usr/include/features.h:388:23: error: gnu/stubs.h: No such file or directory
I find it a bit odd that the include path goes from my system's stdio.h back to llvm-gcc headers and then tries again to include system headers. But maybe that's normal?
After that error hundreds of lines with more errors follow from the same compilation unit.
Could it be that my system's gcc 4.6.1 or my system's headers maybe grew incompatible with the dated llvm-gcc 4.2 headers? Then again, I know that on a different system (running the 2.6 kernel) gcc 4.5.2 plays well with llvm 2.7's gcc 4.2.
I'm at a loss here, because I do need a recent llvm 2.*, and the other two acceptable llvm versions (2.7, 2.8) didn't show any result more helpful.
It seems that /usr/include on your system provides 32-bit headers, thus the compilation fails since you do not have all multilib headers installed. You might need to patch llvm-gcc the same way as your distribution patches gcc in order to find the headers locations.
Alternatively, you might try to install 32-bit headers and try multilib build of llvm-gcc.
But the best way will be switch to LLVM 3.1 and clang :)

How do I fix the DoS String#hash vulnerability for ruby-enterprise-1.8.7-2009.10?

The problem is described here.
There have been patches for 1.8, JRuby and later version of ree, but I can't find anything for this version.
I tried applying this patch.
But compiling fails with an error that doesn't make sense since there are no changes to the compiler directives that I can see:
gcc -g -Os -fno-strict-aliasing -DRUBY_EXPORT -D_GNU_SOURCE=1 -I. -I. -c st.c
st.c:230:49: error: '#' is not followed by a macro parameter
make: *** [st.o] Error 1

Resources