/usr/bin/sed --Adam
> On Nov 6, 2018, at 11:49 AM, <m...@macports.org> <m...@macports.org> wrote: > > 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 >> <mailto: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 >>>>>> >>>> >>> >> >
