[mysql8] compile failure on 10.6.8 x86_64

[BjarneDMat]

version:1
:debug:sysinfo Mac OS X 10.6 (darwin/10.8.0) arch i386
:debug:sysinfo MacPorts 2.6.0
:debug:sysinfo Xcode 3.2.6
:debug:sysinfo SDK 10.6
:debug:sysinfo MACOSX_DEPLOYMENT_TARGET: 10.6

[ 43%] Linking CXX static library libperfschema.a
cd /macports/var/macports/build/.../mysql8/work/build/storage/perfschema
&& /macports/bin/cmake -P CMakeFiles/perfschema.dir/cmake_clean_target.cmake
cd /macports/var/macports/build/.../mysql8/work/build/storage/perfschema
&& /macports/bin/cmake -E cmake_link_script
CMakeFiles/perfschema.dir/link.txt --verbose=ON
/macports/bin/ar qc libperfschema.a  ... lots of
CMakeFiles/perfschema.dir/{name}.cc.o ...
/macports/bin/ranlib libperfschema.a
make[2]: Leaving directory
`/macports/var/macports/build/.../mysql8/work/build'
[ 43%] Built target perfschema
make[1]: Leaving directory
`/macports/var/macports/build/.../mysql8/work/build'
make: *** [all] Error 2
make: Leaving directory `/macports/var/macports/build/.../mysql8/work/build'
Command failed:  cd "/macports/var/macports/build/.../work/build" &&
/Developer/usr/bin/make -j2 -w all VERBOSE=ON
Exit code: 2
Error: Failed to build mysql8: command execution failed

main.log here : ​https://macports.mathiesen.info/logs/databases/mysql8/main.log

[ryandesign (Ryan Carsten Schmidt)]

Looks like the relevant error in the log is:

:info:build /usr/bin/libtool: object: /macports/var/macports/build/_macports_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_databases_mysql8/mysql8/work/build/archive_output_directory/libclientlib.a(libmysql.cc.o) malformed object (unknown load command 2)
:info:build /usr/bin/libtool: object: /macports/var/macports/build/_macports_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_databases_mysql8/mysql8/work/build/archive_output_directory/libmytime.a(my_time.cc.o) malformed object (unknown load command 2)
:info:build /usr/bin/libtool: object: /macports/var/macports/build/_macports_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_databases_mysql8/mysql8/work/build/archive_output_directory/libstrings.a(ctype.cc.o) malformed object (unknown load command 2)
:info:build /usr/bin/libtool: object: /macports/var/macports/build/_macports_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_databases_mysql8/mysql8/work/build/archive_output_directory/libmysys.a(charset.cc.o) malformed object (unknown load command 2)

Try installing a newer libtool (sudo port install libtool).

[kencu (Ken)]

We might see that error quite a bit for a while. Every build on 10.6.8 with a clang > 3.9 generates objects that the system cctools can't handle. So every build will need cctools (should be depends_run on 10.6.8) and then, sometimes, you need to force the build to use it.

Usually it will go for the first cctools tool on the PATH, but cmake / libtool / qmake / etc / etc try to be helpful and do things their own way, which usually breaks things.

The absolutely easiest thing to do is to symlink all the cctools into the 10.6.8 SDK. I know you're not going to do that, but it has a certain practical approach to it :>

[BjarneDMat]

It's partly a libtool / cctools problem as described .

Partial workaround:

declare usrBin='/usr/bin'
declare devBin="/Developer${usrBin}"

while read -u 9 cctool 
do
    theTool=$( basename ${cctool} )
    echo ${theTool}
    for binDir in "${usrBin}" "${devBin}"
    do
        mv -n "${binDir}/${theTool}" "${binDir}/${theTool}.orig"
        rm "${binDir}/${theTool}"
        ln -h "${cctool}" "${binDir}/${theTool}"
    done
done 9< <( port contents cctools | fgrep /bin/ )

There're still issues :​https://macports.mathiesen.info/logs/databases/mysql8/main.log2

[kencu (Ken)]

btw, mariadb-10.2 installs without a problem for me on 10.6.8

[kencu (Ken)]

Replying to BjarneDMat:

It's partly a libtool / cctools problem as described .

So -- just a point for the future -- if you're going to do something like that, it is not fair to submit tickets and bug reports from a system that has been modified. People will lose patience with that very quickly.

When I do something like that to get over a build hiccup that I don't care to spend the time fixing properly at that exact moment, I always undo it right after so I'm back to stock.

[kencu (Ken)]

:info:build /macports/var/macports/build/_macports_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_databases_mysql8/mysql8/work/mysql-8.0.17/storage/innobase/handler/ha_innodb.cc:298:28: error: use of undeclared identifier '_SC_PHYS_PAGES'
:info:build   return (((double)sysconf(_SC_PHYS_PAGES)) *

_SC_PHYS_PAGES is not supported by sysconf on 10.6.8. I'm not sure when it was added.

Sounds like something ripe for the legacysupport PG to add though. We already do something similar in that group for a few other sysconf additions.

This file <​https://github.com/practicalswift/osx/blob/master/src/cxxfilt/cxxfilt/libiberty/physmem.c> has a bunch of workarounds for that; not exact replacements, but alternate ways of doing the same thing. It's possible that a patch to mysql could be acceptable while we work out the legacysupport PG update.

[kencu (Ken)]

All systems 10.10 and less fail to build mysql8 due to the same _SC_PHYS_PAGES error, which supports this bit of info I found // _SC_PHYS_PAGES is defined as of Apple SDK 10.11.

[kencu (Ken)]

In addition to that SC_PHYS_PAGES thing, which I have a patch for, I thought the malformed object business sounded familiar. I already fixed that once 58271 before [7e5b5898478da838a0f1373e48a650f9c06c0146/macports-ports] in mariahdb.

[kencu (Ken)]

and success

$ port -v installed mysql8
The following ports are currently installed:
  mysql8 @8.0.17_1 (active) platform='darwin 10' archs='x86_64' date='2019-09-22T17:02:11-0700'

I'll put together a PR that should fix at least all our Intel systems.

[kencu (Ken)]

Please try this <​https://github.com/macports/macports-ports/pull/5363>.

[kencu (Ken)]

In 3db241d4f40b0343a012d320b2933a7ade5353c3/macports-ports (master):

mysql8: fix build on older systems

add workaround for missing SC_PHYS_PAGES on older systems
allow a newer libtool to be used
relax the compiler blacklist to allow more c++14 compilers
especially as clang-8.0+ are not building this at present

closes: #59074