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[@]/martin.giesek...@uos.de/g' dvisvgm.txt.in >dvisvgm.txt touch -r dvisvgm.txt.in dvisvgm.txt --Adam > On Nov 6, 2018, at 9:52 AM, Marius Schamschula <li...@schamschula.com> wrote: > > I also ran into this on my High Sierra machine this morning. I halted the > job, restarted it in verbose mode, and it finished. > >> On Nov 6, 2018, at 8:49 AM, Adam Dershowitz <de...@alum.mit.edu> wrote: >> >> 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. >> The beginning of the call chain is: >> 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 >> >> >> >>> On Nov 6, 2018, at 9:36 AM, Ken Cunningham >>> <ken.cunningham.web...@gmail.com> wrote: >>> >>> As 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 >>> >>>> On Nov 6, 2018, at 06:31, Adam Dershowitz <de...@alum.mit.edu> wrote: >>>> >>>> >>>> >>>>> On Nov 6, 2018, at 1:17 AM, Mojca Miklavec <mo...@macports.org> wrote: >>>>> >>>>> Dear Adam, >>>>> >>>>>> On Tue, 6 Nov 2018 at 05:24, Adam Dershowitz wrote: >>>>>> >>>>>> 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. >>>> >>>> >>>>> >>>>>> Should 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. >>>> >>>> >>>>> >>>>>> Also, 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 >>>>> packages.macports.org, for example: >>>>> http://packages.macports.org/gcc7/ >>>>> >>>>> However the folder for dvisvgm doesn't exist due to: >>>>> >>>>> $ 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 >>>> >> >
