Trying it verbose was a good suggestion. For me, it still hangs, but I did get some more info. Here are the last few lines, where it finally just hangs:
/bin/sh ../libtool --tag=CXX --mode=link /usr/bin/clang++ -std=gnu++11 -Wall -Wnon-virtual-dtor -Wno-mismatched-tags -I../libs/clipper -I../libs/variant/include -I/opt/local/include/freetype2 -I/opt/local/include/libpng16 -I../libs/xxHash -pipe -Os -stdlib=libc++ -arch x86_64 -L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64 -o dvisvgm dvisvgm.o libdvisvgm.a ../libs/clipper/libclipper.a -L/opt/local/lib -lfreetype ../libs/xxHash/libxxhash.a ../libs/ff-woff/libfontforge.a -L/opt/local/lib -lwoff2enc -lbrotlienc -L/opt/local/lib -lbrotlienc -L/opt/local/lib -lcrypto -lz -lpotrace -lgs -lkpathsea
libtool: link: /usr/bin/clang++ -std=gnu++11 -Wall -Wnon-virtual-dtor -Wno-mismatched-tags -I../libs/clipper -I../libs/variant/include -I/opt/local/include/freetype2 -I/opt/local/include/libpng16 -I../libs/xxHash -pipe -Os -stdlib=libc++ -arch x86_64 -Wl,-headerpad_max_install_names -arch x86_64 -o dvisvgm dvisvgm.o -L/opt/local/lib libdvisvgm.a ../libs/clipper/libclipper.a -lfreetype ../libs/xxHash/libxxhash.a ../libs/ff-woff/libfontforge.a -lwoff2enc -lbrotlienc -lcrypto -lz -lpotrace -lgs -lkpathsea
make[2]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_dvisvgm/dvisvgm/work/dvisvgm-2.6.1/src'
Making all in tests
make[2]: Entering directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_dvisvgm/dvisvgm/work/dvisvgm-2.6.1/tests'
Making all in data
make[3]: Entering directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_dvisvgm/dvisvgm/work/dvisvgm-2.6.1/tests/data'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_dvisvgm/dvisvgm/work/dvisvgm-2.6.1/tests/data'
make[3]: Entering directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_dvisvgm/dvisvgm/work/dvisvgm-2.6.1/tests'
make[3]: Nothing to be done for `all-am'.
make[3]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_dvisvgm/dvisvgm/work/dvisvgm-2.6.1/tests'
make[2]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_dvisvgm/dvisvgm/work/dvisvgm-2.6.1/tests'
Making all in doc
make[2]: Entering directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_dvisvgm/dvisvgm/work/dvisvgm-2.6.1/doc'
sed -e 's/@VERSION[@]/2.6.1/g' -e 's/@PACKAGE_BUGREPORT[@]/***@uos.de/g' dvisvgm.txt.in >dvisvgm.txt
touch -r dvisvgm.txt.in dvisvgm.txt
--Adam
Post by Marius SchamschulaI also ran into this on my High Sierra machine this morning. I halted the job, restarted it in verbose mode, and it finished.
Iâve done that. It just shows make at 98.8% cpu. When Iâve tried to sample, I get a call chain that has a lot of ??? (in make). I tried to add a screen shot of the call chain, since activity monitor wonât allow me to copy, but the message ended up being too large.
100.000% Thread_2395191 DispatchQueue_1: com.apple.main-thread (serial)
100.000% start (in libdyld.dylib) + 1 [0x7fff58345015]
100.000% ??? (in make) load addressâŠ(Iâm not typing these out)
93.103% ??? (in make) load addressâŠ
etc
So, it is hanging up in âmakeâ.
Very strange.
--Adam
Post by Ken CunninghamAs it seems so far you're the only one with the hiccup, you have to see what's happening. When it's stuck, run top to see what's eating up the clock. Activity Monitor or ps to see what's running. Possibly sample the process that's stuck .to see what it's doing.
Ken
Post by Mojca MiklavecDear Adam,
Iâm upgrading dvisvgm from to 2.3.4_4 to 2.6.1_0. Iâm on a fairly recent MacBook pro, and it has been building for 13 hours! The process is âmakeâ and itâs taking 100% of just one CPU. Does this sound correct?
No. Anything longer than a couple of minutes sounds wrong. The build
is not super fast as for some lightweight ports, but it's not
particularly heavy either.
Thatâs what I thought.
Post by Mojca MiklavecShould I just kill it and clean the port, then retry?
Yes.
I tried again, and got the same result after cleaning. Any other suggestions? Iâll file a ticket, although this port doesnât have a Maintainer, and there wonât be final log to attach, since it just hangs.
Post by Mojca MiklavecAlso, is there a way to determine which ports are available as binaries from the buildbots?
I agree that it would be cool to have a command to check that
automatically, but at the moment you can check it manually on
http://packages.macports.org/gcc7/
$ port_binary_distributable.tcl -v dvisvgm
"dvisvgm" is not distributable because its license "GPL-3+"
conflicts with license "GPL-2" of dependency "libpaper"
(I wasn't aware that not ever GPL-2 is compatible with GPL-3+? Doesn't
that sound particularly strange?)
Sometimes the binary would not be available due to the builders not
being able to keep up with the queue fast enough, in particular when
someone submits a patch to all gcc compilers at once :), but this
clearly wasn't the case here.
Mojca