mysql57, boost and postgresql84

[Bill Cole]

On 5 Nov 2019, at 20:39, Michael Newman via macports-users wrote:

> Maybe I’m just not smart enough to play with MacPorts….

Unlikely.

> This on an iMac still running Mojave.
>
> This morning I did selfupdate and upgrade outdated with the following 
> result:
>
> Error: mysql57 cannot be built while boost is active.
> Error: Please forcibly deactivate boost, e.g. by running:
> Error:
> Error:     sudo port -f deactivate boost
> Error:
> Error: Then try again. You can reactivate boost again later.
>
> I deactivated boost as instructed and ran upgrade outdated again.

This is a quirk of MySQL and its use of the Boost suite of C++ 
libraries, which have weak version compatibility discipline. Basically, 
it's not safe to build MySQL without having its build tools download and 
build a specific version of Boost. Since Boost is used by many other 
open source packages, you almost certainly will need to reactivate the 
port now that you have MySQL updated.

> This time mysql built OK, but I got:
>
> Error: Failed to configure postgresql84,

Yes. It does that on Snow Leopard and High Sierra too. I don't think it 
can be fixed in a safe and maintainable way. See below...

The postgresql8* ports really should all be removed. PostgreSQL 8.4 is 4 
major versions and 5+ years obsolete and the MacPorts ports have no 
maintainer. You should figure out why you have postgresql84 installed 
and update to a currently supported version. See 
https://www.postgresql.org/support/versioning/ for more information. 
Since postgresql84 is just the client components of PostgreSQL, updating 
to a current version shouldn't have much risk. If you also have 
postgresql84-server installed, that would imply that you have a 
PostgreSQL server running (i.e. with a database) and that may require 
substantial work that MacPorts can't do for you.

> consult 
> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_databases_postgresql84/postgresql84/work/postgresql-8.4.22/config.log
> Error: Failed to configure postgresql84: configure failure: command 
> execution failed
>
> The config.log file referred to is just under 1000 lines long. Is 
> there anything in particular I should look for?

It is unlikely to be worth your time, but the failure I get shows up in 
that log starting at line 694:

694: configure:8671: checking for SSL_library_init in -lssl
695: configure:8706: /usr/bin/clang -no-cpp-precomp -o conftest -pipe 
-Os -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk 
-arch x86_64 -Wa    ll -Wmissing-prototypes -Wpointer-arith 
-Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing 
-fwrapv -fexcess-precision=standard -I/opt/lo    cal/include 
-I/opt/local/include/ossp 
-isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk 
-I/opt/local/include/libxml2  -I/opt/local/incl    ude -L/opt/local/lib 
-Wl,-headerpad_max_install_names 
-Wl,-syslibroot,/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk 
-arch x86_64 -L/opt/loca    l/lib -L/opt/local/lib -L/opt/local/lib 
-L/opt/local/lib  -L/opt/local/lib conftest.c -lssl  -lcrypto -lz 
-lreadline -lm  >&5
696: clang: warning: optimization flag '-fexcess-precision=standard' is 
not supported [-Wignored-optimization-argument]
697: Undefined symbols for architecture x86_64:
698:   "_SSL_library_init", referenced from:
699:       _main in conftest-ad294e.o
700: ld: symbol(s) not found for architecture x86_64

Your line numbers may vary.

The cause of this is that "SSL_library_init" is a function that does not 
exist in OpenSSL v1.1.x. It MAY be possible to install an old OpenSSL 
and fix the Portfile or write a patch to make the configure and build 
work, but then you'll have an obsolete PostgreSQL linked to an obsolete 
OpenSSL, and you really do not want that.

-- 
Bill Cole
bill at scconsult.com or billcole at apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)