Some contribs are built without optimization about handbrake

[galad87]

I saw that Opus notice the other day, and I thought it was about intrinsics, which seemed strange because they were already compiled in. I guess I should have looked into it more.

Do you plan to open a PR or should I fix it?

[marcosfrm]

Please do it.

[marcosfrm]

With MinGW, more contribs without optimization:

---> libiconv

make[3]: Entrando no diretório '/home/marcos/Downloads/HandBrake/build/contrib/libiconv/libiconv-1.17/libcharset/lib'

/bin/sh ../libtool --mode=compile /usr/bin/x86_64-w64-mingw32ucrt-gcc -I. -I. -I.. -I./.. -I../include -I/home/marcos/Downloads/HandBrake/build/contrib/include -std=gnu89 -mfpmath=sse -msse2 -fstack-protector-strong -D_FORTIFY_SOURCE=2 -mno-ms-bitfields  -I/home/marcos/Downloads/HandBrake/build/contrib/include  -DBUILDING_LIBCHARSET -DHAVE_CONFIG_H -c ./localcharset.c
libtool: compile:  /usr/bin/x86_64-w64-mingw32ucrt-gcc -I. -I. -I.. -I./.. -I../include -I/home/marcos/Downloads/HandBrake/build/contrib/include -std=gnu89 -mfpmath=sse -msse2 -fstack-protector-strong -D_FORTIFY_SOURCE=2 -mno-ms-bitfields -I/home/marcos/Downloads/HandBrake/build/contrib/include -DBUILDING_LIBCHARSET -DHAVE_CONFIG_H -c ./localcharset.c -o localcharset.o


---> zlib

make[1]: Entrando no diretório '/home/marcos/Downloads/HandBrake/build/contrib/zlib/zlib-1.3'

/usr/bin/x86_64-w64-mingw32ucrt-gcc -I/home/marcos/Downloads/HandBrake/build/contrib/include -std=gnu99 -mfpmath=sse -msse2 -fstack-protector-strong -D_FORTIFY_SOURCE=2 -mno-ms-bitfields -D_LARGEFILE64_SOURCE=1 -I. -c -o example.o test/example.c
/usr/bin/x86_64-w64-mingw32ucrt-gcc -I/home/marcos/Downloads/HandBrake/build/contrib/include -std=gnu99 -mfpmath=sse -msse2 -fstack-protector-strong -D_FORTIFY_SOURCE=2 -mno-ms-bitfields -D_LARGEFILE64_SOURCE=1  -c -o adler32.o adler32.c


---> bzip2

make[1]: Entrando no diretório '/home/marcos/Downloads/HandBrake/build/contrib/bzip2/bzip2-1.0.8'


If compilation produces errors, or a large number of warnings,
please read README.COMPILATION.PROBLEMS -- you might be able to
adjust the flags in this Makefile to improve matters.

Also in README.COMPILATION.PROBLEMS are some hints that may help
if your build produces an executable which is unable to correctly
handle so-called 'large files' -- files of size 2GB or more.

/usr/bin/x86_64-w64-mingw32ucrt-gcc -I/home/marcos/Downloads/HandBrake/build/contrib/include -std=gnu99 -mfpmath=sse -msse2 -fstack-protector-strong -D_FORTIFY_SOURCE=2 -mno-ms-bitfields -c blocksort.c


---> xz

make[5]: Entrando no diretório '/home/marcos/Downloads/HandBrake/build/contrib/xz/xz-5.4.5/src/liblzma'

/bin/sh ../../libtool  --tag=CC   --mode=compile /usr/bin/x86_64-w64-mingw32ucrt-gcc -DHAVE_CONFIG_H -I. -I../..  -I../../src/liblzma/api -I../../src/liblzma/common -I../../src/liblzma/check -I../../src/liblzma/lz -I../../src/liblzma/rangecoder -I../../src/liblzma/lzma -I../../src/liblzma/delta -I../../src/liblzma/simple -I../../src/common -DTUKLIB_SYMBOL_PREFIX=lzma_ -I/home/marcos/Downloads/HandBrake/build/contrib/include  -Wall -Wextra -Wvla -Wc99-c11-compat -Wformat=2 -Winit-self -Wmissing-include-dirs -Wshift-overflow=2 -Wstrict-overflow=3 -Walloc-zero -Wduplicated-cond -Wfloat-equal -Wundef -Wshadow -Wpointer-arith -Wbad-function-cast -Wwrite-strings -Wdate-time -Wsign-conversion -Wfloat-conversion -Wlogical-op -Waggregate-return -Wstrict-prototypes -Wold-style-definition -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -I/home/marcos/Downloads/HandBrake/build/contrib/include -std=gnu99 -mfpmath=sse -msse2 -fstack-protector-strong -D_FORTIFY_SOURCE=2 -mno-ms-bitfields -c -o liblzma_la-tuklib_physmem.lo `test -f '../common/tuklib_physmem.c' || echo './'`../common/tuklib_physmem.c
libtool: compile:  /usr/bin/x86_64-w64-mingw32ucrt-gcc -DHAVE_CONFIG_H -I. -I../.. -I../../src/liblzma/api -I../../src/liblzma/common -I../../src/liblzma/check -I../../src/liblzma/lz -I../../src/liblzma/rangecoder -I../../src/liblzma/lzma -I../../src/liblzma/delta -I../../src/liblzma/simple -I../../src/common -DTUKLIB_SYMBOL_PREFIX=lzma_ -I/home/marcos/Downloads/HandBrake/build/contrib/include -Wall -Wextra -Wvla -Wc99-c11-compat -Wformat=2 -Winit-self -Wmissing-include-dirs -Wshift-overflow=2 -Wstrict-overflow=3 -Walloc-zero -Wduplicated-cond -Wfloat-equal -Wundef -Wshadow -Wpointer-arith -Wbad-function-cast -Wwrite-strings -Wdate-time -Wsign-conversion -Wfloat-conversion -Wlogical-op -Waggregate-return -Wstrict-prototypes -Wold-style-definition -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -I/home/marcos/Downloads/HandBrake/build/contrib/include -std=gnu99 -mfpmath=sse -msse2 -fstack-protector-strong -D_FORTIFY_SOURCE=2 -mno-ms-bitfields -c ../common/tuklib_physmem.c -o liblzma_la-tuklib_physmem.o

Why not always add the configured optimization option to CFLAGS and CXXFLAGS? There can be multiple -O options on the command line: the last one wins.

Major Linux distributions always set it. In Fedora at least they are stricter and patch the build system of projects which set their own level, removing it. (update: or used to patch, did not check recently)

[galad87]

libspeex fails to compile with -O3 on mingw, so this will require at least some exceptions.

[marcosfrm]

I suggest using -O2 by default for "speed" instead of -O3. -O2 is pretty safe. Then check if speed critical code like SVT-AV1, x264, x265, libvpx, libdav1d, and ffmpeg (libhb too?) are appending their own -O3.

[galad87]

Yes the encoding libraries are already built correctly with -O3.