Solved Hoe to fix broken mysql81-server port?

HL1234

HL1234

Since more then two weeks, when I'm running
[/usr/ports/databases/mysql81-server] => make build
this error happens: (yes, I have not forget to update the ports tree)
[ 23%] Building CXX object storage/myisam/CMakeFiles/myisam_library.dir/mi_delete.cc.o
cd /usr/ports/databases/mysql81-server/work/.build/storage/myisam && /usr/bin/clang++ -DBOOST_NO_CXX98_FUNCTION_BASE -DHAVE_CONFIG_H -DLZ4_DISABLE_DEPRECATE_WARNINGS -DMYSQL_PROJECT -DRAPIDJSON_NO_SIZETYPEDEFINE -DRAPIDJSON_SCHEMA_USE_INTERNALREGEX=0 -DRAPIDJSON_SCHEMA_USE_STDREGEX=1 -D_USE_MATH_DEFINES -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/usr/ports/databases/mysql81-server/work/.build -I/usr/ports/databases/mysql81-server/work/.build/include -I/usr/ports/databases/mysql81-server/work/mysql-8.1.0 -I/usr/ports/databases/mysql81-server/work/mysql-8.1.0/include -isystem /usr/ports/databases/mysql81-server/work/mysql-8.1.0/extra/protobuf/protobuf-3.19.4/src -isystem /usr/local/include/editline -isystem /usr/ports/databases/mysql81-server/work/mysql-8.1.0/extra/zlib/zlib-1.2.13 -isystem /usr/ports/databases/mysql81-server/work/.build/extra/zlib/zlib-1.2.13 -isystem /usr/ports/databases/mysql81-server/work/mysql-8.1.0/extra/zstd/zstd-1.5.5/lib -isystem /usr/ports/databases/mysql81-server/work/mysql-8.1.0/extra/rapidjson/include -std=c++17 -fno-omit-frame-pointer -ftls-model=initial-exec -O2 -pipe -march=native -fPIC -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing -malign-double -isystem /usr/local/include -std=c++17 -Wall -Wextra -Wformat-security -Wvla -Wundef -Wmissing-format-attribute -Woverloaded-virtual -Wcast-qual -Wno-null-conversion -Wno-unused-private-field -Wconditional-uninitialized -Wdeprecated -Wextra-semi -Wheader-hygiene -Wnon-virtual-dtor -Wundefined-reinterpret-cast -Wrange-loop-analysis -Winconsistent-missing-destructor-override -Winconsistent-missing-override -Wshadow-field -ffunction-sections -fdata-sections -O2 -pipe -march=native -fPIC -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing -malign-double -isystem /usr/local/include -std=c++17 -DNDEBUG -fPIC -MD -MT storage/myisam/CMakeFiles/myisam_library.dir/mi_delete.cc.o -MF CMakeFiles/myisam_library.dir/mi_delete.cc.o.d -o CMakeFiles/myisam_library.dir/mi_delete.cc.o -c /usr/ports/databases/mysql81-server/work/mysql-8.1.0/storage/myisam/mi_delete.cc
--- storage/innobase/CMakeFiles/innodb_zipdecompress.dir/all ---
--- storage/innobase/CMakeFiles/innodb_zipdecompress.dir/ut/crc32.cc.o ---
/usr/ports/databases/mysql81-server/work/mysql-8.1.0/storage/innobase/ut/crc32.cc:448:10: error: always_inline function '_mm_crc32_u16' requires target feature 'crc32', but would be inlined into function 'update' that is compiled without support for 'crc32'
return _mm_crc32_u16(crc, data);
^
/usr/ports/databases/mysql81-server/work/mysql-8.1.0/storage/innobase/ut/crc32.cc:452:10: error: always_inline function '_mm_crc32_u32' requires target feature 'crc32', but would be inlined into function 'update' that is compiled without support for 'crc32'
return _mm_crc32_u32(crc, data);
^
/usr/ports/databases/mysql81-server/work/mysql-8.1.0/storage/innobase/ut/crc32.cc:456:10: error: always_inline function '_mm_crc32_u64' requires target feature 'crc32', but would be inlined into function 'update' that is compiled without support for 'crc32'
return _mm_crc32_u64(crc, data);
^
/usr/ports/databases/mysql81-server/work/mysql-8.1.0/storage/innobase/ut/crc32.cc:444:10: error: always_inline function '_mm_crc32_u8' requires target feature 'crc32', but would be inlined into function 'update' that is compiled without support for 'crc32'
return _mm_crc32_u8(crc, data);
^
4 errors generated.
*** [storage/innobase/CMakeFiles/innodb_zipdecompress.dir/ut/crc32.cc.o] Error code 1

make[2]: stopped in /usr/ports/databases/mysql81-server/work/.build
*** [all] Error code 6

make: stopped in /usr/ports/databases/mysql81-server/work/.build
1 error

make: stopped in /usr/ports/databases/mysql81-server/work/.build
===> Compilation failed unexpectedly.
Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
the maintainer.
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/databases/mysql81-server
*** Error code 1

Stop.
make: stopped in /usr/ports/databases/mysql81-server
Click to expand...
% set MAKE_JOBS_UNSAFE=yes
doesn't help.

../mysql-8.1.0/storage/innobase/ut/crc32.cc:448:10:
error: always_inline function '_mm_crc32_u16' requires target feature 'crc32', ???

I have write a bug Bug 277726 but nothing its been done yet now.

Does anyone know how, and where in the code, I could fix this?
 
How do you get to the conclusion this "affects many people"? It doesn't. Official package builds are perfectly fine.

I see some -march=native here. Any other "funny" settings in your /etc/make.conf?
 
zirias@ said:
How do you get to the conclusion this "affects many people"? It doesn't. Official package builds are perfectly fine.

I see some -march=native here. Any other "funny" settings in your /etc/make.conf?
Click to expand...
many people who use the ports...and compile the code.

I have some other settings in make.conf. For this I had notices a long time ago:
# Intel® Xeon® Processor E5-2630 v3 Code Name: Haswell
# Broadwell is Intel's codename for the 14 nanometer die shrink of its Haswell microarchitecture.
#CPUTYPE?=sandybridge
#CPUTYPE?=Haswell
#CPUTYPE?=skylake
#CPUTYPE?=ivybridge
#CPUTYPE?=broadwell
#error: Child process pid terminated abnormally: Illegal instruction
# FORUM: "the error suggests that You are/have compiled some binary which is for different CPU"
# HL: it doesn't work : maybe because of the virtual simulated real CPU.
# CPUTYPE=native == let the compiler figure it out. It will automatically to the right thing
# Using -march=native will enable all instruction subsets supported by
# the local machine (hence the result might not run on different machines).
CPUTYPE?=native
Click to expand...
I tried to build the code for the right CPU, but I failed. So I have used the tip from the forum.

Some more:
# BUILD_OPTIMIZED is set to enable compiler optimizations. It's used for better speed.
BUILD_OPTIMIZED=YES
WITH_OPTIMIZATION=YES
#
# BUILD_STATIC is set to build static versions of the binaries. It's used for even better speed.
BUILD_STATIC=YES
#
WITHOUT_DEBUG=YES
WITH_CPUFLAGS=YES

OPTIMIZED_COPTFLAGS=YES
OPTIMIZED_CXXFLAGS=YES

#HL-240313 added for MySQL
# -----------------------------------------------------------------------------
# Possible values: 8.0, 8.1, 10.5m, 10.6m, 10.11m
# 2024 latest version = MySQL 8.3. But in the ports the latest is version 8.1
# DEFAULT_VERSIONS+= mysql=8.0
DEFAULT_VERSIONS+= mysql=8.1
Click to expand...
 
HL1234 said:
many people who use the ports...and compile the code.
Click to expand...
Outright wrong.

Dump your whole /etc/make.conf, rebuild all your ports, problem solved.

edit: Seriously???
# BUILD_STATIC is set to build static versions of the binaries. It's used for even better speed.
Click to expand...

A combination of this (do you even understand the consequences?) with some "optimized" CFLAGS requesting a lot of inlining could very well be the cause for the specific compilation issue you reported.

It does remind me of some old and partially famous bug report on Gentoo's bugzilla ...

Use /etc/make.conf and port options to adapt ports to your need, functionally. Stay away from any fiddling with compiler flags, linker flags, whatever you think will "optimize" your builds, unless you know exactly what these do and what will be the consequences. It's certainly turbo speed to broken builds.
 
zirias@ I have tested the compile without CPUTYPE?=native and the error has gone. But I don't understand why? All other ports has compiled with it. And how I've been told: "native == let the compiler figure it out. It will automatically to the right thing" So what is wrong with this setting? May be it is no longer available. In /usr/share/mk/bsd.cpu.mk I haven't found it.

But at lease thanks for the advice. "I see some -march=native". I forget these old setting in make.conf.
 
HL1234 CPUTYPE=native is pretty safe, but like any optimization, it can trigger issues. What's "wrong" with it is just that binary code won't run any more on any other CPU model (so it can certainly never be used to build a package repo shared for multiple machines, unless they are all identical). In practice, the vast majority of software doesn't profit from it at all (like, you won't be able to even measure a speed benefit). Some software does profit, but these are special cases, so I personally wouldn't enable it globally. Little to gain, and a risk to break your builds or even your applications after building "fine" ...

I'd be more worried about forcing static building for everything. It can cause build failures for sure. It will increase binary sizes a lot. It might be a security issue, as every dependency is "baked in", and some important fix in a library might never make it to the one application using it you built statically, because someone forgot to "bump" that port. And finally, it won't speed up anything (except maybe the first launch of something, again in a range barely measurable).
 
You must log in or register to reply here.
Back
Top