On Nov 26, 2021, at 19:45, Uli Wienands wrote: > A number of ports apparently want to install perl5.26. In this specific case > it is fricas. For reasons I cannot fathom prl5.26 fails during the destroot > phase on my system (SL, 10.6.8). > > So I try installing perl5.26 by itself; it fails with a message that > "clang-3.7" cannot be updated. > I try updating clang-3.7; it fails with (you guessed it) a dependency on > perl5.26 not updating. > I upgrade clang-3.7 with the -n option, and that seems to work. But perl5.26 > still refuses to update. > Trying to update perl5.26 with the -n option: no luck either. It always fails > in the destroot phase. Trying an extra cleean beforehand also does not help. > > Attached is the main log for the attempt to install perl5.26 with the -n > option. > > The fricas port incidentally installed with the -n option just fine using > whichever version of Perl I have, which actually seems to be perl 5, version > 26, subversion 3. > > So, can someone shed light on this?
Sure. The log says: :debug:configure Using compiler 'MacPorts Clang 3.7' :debug:configure Executing org.macports.configure (perl5.26) :debug:configure Environment: :debug:configure CC='/opt/local/bin/clang-mp-3.7' :info:destroot /usr/bin/cc -c -I/opt/local/include/db48 -fno-common -DPERL_DARWIN -pipe -Os -fno-strict-aliasing -fstack-protector-strong -I/opt/local/include -DPERL_USE_SAFE_PUTENV -Wall -Werror=declaration-after-statement -Wextra -Wc++-compat -Wwrite-strings -Wthread-safety -O3 -DVERSION=\"1.840\" -DXS_VERSION=\"1.84\" "-I../.." -D_NOT_CORE -DmDB_Prefix_t=size_t -DmDB_Hash_t=u_int32_t version.c :info:destroot cc1: error: unrecognized command line option "-Wthread-safety" :info:destroot cc1: error: unrecognized command line option "-fstack-protector-strong" So the port is trying to build something in the destroot phase using /usr/bin/cc, which is not correct; it should use the compiler MacPorts asked it to use (in this case /opt/local/bin/clang-mp-3.7). /usr/bin/cc does not understand the flags -Wthread-safety and -fstack-protector-strong which are being passed to it. Presumably if the port were using the correct compiler at this point, it would work, because presumably the correct compiler understands these flags. Presumably the configure phase used the right compiler and determined that it supported these flags, and the build phase used the right compiler to compile the software, and then for some reason in the destroot phase something else is trying to build using the compiler and MacPorts does not normally specify what compiler to use during the destroot phase because things are not normally compiled during the destroot phase. The correct fix may be to fix the build system so that this version.c and anything else that's getting built during the destroot phase gets built during the build phase instead.
