Long build?

Tue Nov 6 15:15:20 UTC 2018

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.gieseking at 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 <lists at 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 <dersh at 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.webuse at 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 <dersh at alum.mit.edu> wrote:
>>>> 
>>>> 
>>>> 
>>>>> On Nov 6, 2018, at 1:17 AM, Mojca Miklavec <mojca at 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
>>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-users/attachments/20181106/dd46e387/attachment.html>