Discussion:
Long build?
Adam Dershowitz
2018-11-06 04:24:45 UTC
Permalink
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? Should I just kill it and clean the port, then retry? Even building gcc from source doesn’t take this long.

Also, is there a way to determine which ports are available as binaries from the buildbots? This one clearly wasn’t available as a binary this morning, because I know that macports would have found it. I’m just using the default variant on 10.13.6.

Thanks,

--Adam
Mojca Miklavec
2018-11-06 06:17:38 UTC
Permalink
Dear Adam,
Post by Adam Dershowitz
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.
Post by Adam Dershowitz
Should I just kill it and clean the port, then retry?
Yes.
Post by Adam Dershowitz
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
Ryan Schmidt
2018-11-06 06:46:14 UTC
Permalink
Post by Mojca Miklavec
$ 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?)
Each developer can decide what version(s) of what license(s) their project is released under. libpaper is apparently released under GPL version 2 only, while dvisvgm is released under GPL 3 or later. "2" is not "3 or later" so we can't legally distribute a binary of dvisvgm. The LGPL was designed to solve this kind of problem, but libpaper is not released under the LGPL.
Adam Dershowitz
2018-11-06 14:31:07 UTC
Permalink
Post by Mojca Miklavec
Dear Adam,
Post by Adam Dershowitz
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 Miklavec
Post by Adam Dershowitz
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.
Post by Mojca Miklavec
Post by Adam Dershowitz
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
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
Ken Cunningham
2018-11-06 14:36:09 UTC
Permalink
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
Post by Adam Dershowitz
Post by Mojca Miklavec
Dear Adam,
Post by Adam Dershowitz
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 Miklavec
Post by Adam Dershowitz
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.
Post by Mojca Miklavec
Post by Adam Dershowitz
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
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
Adam Dershowitz
2018-11-06 14:49:53 UTC
Permalink
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
Post by Ken Cunningham
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
Post by Adam Dershowitz
Post by Mojca Miklavec
Dear Adam,
Post by Adam Dershowitz
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 Miklavec
Post by Adam Dershowitz
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.
Post by Mojca Miklavec
Post by Adam Dershowitz
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
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
Marius Schamschula
2018-11-06 14:52:42 UTC
Permalink
I also ran into this on my High Sierra machine this morning. I halted the job, restarted it in verbose mode, and it finished.
Post by Adam Dershowitz
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 Cunningham
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
Post by Adam Dershowitz
Post by Mojca Miklavec
Dear Adam,
Post by Adam Dershowitz
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 Miklavec
Post by Adam Dershowitz
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.
Post by Mojca Miklavec
Post by Adam Dershowitz
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
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
Adam Dershowitz
2018-11-06 15:15:20 UTC
Permalink
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 Schamschula
I 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 Cunningham
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
Post by Mojca Miklavec
Dear 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 Miklavec
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.
Post by Mojca Miklavec
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
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
m***@macports.org
2018-11-06 16:49:38 UTC
Permalink
Interesting, what is the output of the following?

$ which -a sed


Cheers!
Frank
Post by Adam Dershowitz
/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'
touch -r dvisvgm.txt.in dvisvgm.txt
--Adam
Post by Marius Schamschula
I 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 Cunningham
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
Post by Mojca Miklavec
Dear 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 Miklavec
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.
Post by Mojca Miklavec
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
http://packages.macports.org/gcc7/ <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
Adam Dershowitz
2018-11-06 17:23:39 UTC
Permalink
/usr/bin/sed

--Adam
Post by m***@macports.org
Interesting, what is the output of the following?
$ which -a sed
Cheers!
Frank
Post by Adam Dershowitz
/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'
touch -r dvisvgm.txt.in dvisvgm.txt
--Adam
Post by Marius Schamschula
I 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 Cunningham
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
Post by Mojca Miklavec
Dear 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 Miklavec
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.
Post by Mojca Miklavec
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
http://packages.macports.org/gcc7/ <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
Adam Dershowitz
2018-11-06 17:25:10 UTC
Permalink
Post by Adam Dershowitz
touch -r dvisvgm.txt.in dvisvgm.txt
Hangs on a touch, it appears.
When I’ve seen this in the past, disabling parallel building usually fixes it.
K
That worked!

Very strange that it should make a difference, and only for this port.

Thanks,

--Adam

Loading...