Interesting, what is the output of the following? $ which -a sed
Cheers! Frank > On Nov 6, 2018, at 8:15 AM, Adam Dershowitz <de...@alum.mit.edu> wrote: > > 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 > <mailto: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 >> <mailto: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 >>> <mailto: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 <mailto: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 >>>>> <mailto:de...@alum.mit.edu>> wrote: >>>>> >>>>> >>>>> >>>>>> On Nov 6, 2018, at 1:17 AM, Mojca Miklavec <mo...@macports.org >>>>>> <mailto: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 <http://packages.macports.org/>, for example: >>>>>> http://packages.macports.org/gcc7/ <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 >>>>> >>> >> >
