I realize the orangepi is not the swiftest of machines, but the ld issue is more than just SOC performance. The ld process should finish within a few seconds to a minute. It is taking 20 minutes.
I am trying to build php as the current bulk build failed on so many packages. I think it is the first bulk build since clang. The other compiles and processes execute in reasonable time, but when it comes to ld something happens. As I was looking around trying to find what some clues I ran man from the serial console and it hung. Man runs fine from an ssh connection over the lan. Man on the console was hung in bqwait. What is that? PID USERNAME PRI NICE SIZE RES STATE WAIT TIME CPU COMMAND 87860 root 63 0 45M 45M run - 18:26 64.60% ld 30014 sysadmin -6 0 832K 1556K sleep bqwait 0:10 15.23% man Later when I suspect ld finished more started to run and got stuck also, probably when ld started up again. PID USERNAME PRI NICE SIZE RES STATE WAIT TIME CPU COMMAND 18030 root 59 0 46M 47M run - 23:02 54.54% ld 68435 sysadmin 58 0 257M 182M run - 0:57 42.72% more 30014 sysadmin 10 0 832K 0K idle wait 4:14 0.00% man Both man and more seem to be using cpu cycles even though they are stuck. Could ld be trying to do something with the console? -----Original Message----- From: owner-po...@openbsd.org <owner-po...@openbsd.org> On Behalf Of Mark Kettenis Sent: May 2, 2018 3:10 AM To: s_g...@telus.net Cc: po...@openbsd.org; arm@openbsd.org Subject: Re: gtk libool slow on arm > From: <s_g...@telus.net> > Date: Tue, 1 May 2018 16:30:28 -0700 > > Why is the gtk libtool so slow on arm? A typical command such as: It's not libtool, but ld, the link editor that is taking its time. > libtool: link: cc -o .libs/testentrycompletion -pthread -O2 -pipe -g > -Wall -Wl,-rpath-link -Wl,/usr/X11R6/lib -Wl,-rpath-link > -Wl,/usr/X11R6/lib testentrycompletion.o -L.libs -lgtk-3 -lgdk-3 > -lpangocairo-1.0 -lpango-1.0 > -lgobject-2.0 -lglib-2.0 -liconv -lpcre -lintl -lffi -lc++abi > -lgthread-2.0 -lfribidi -lm -lcairo -lpthread -lpixman-1 -lfontconfig > -lfreetype -lz -lexpat -lpng -lxcb-shm -lxcb -lxcb-render -lXrender > -lX11 -lXext > -lpangoft2-1.0 -lharfbuzz -lgraphite2 -lgdk_pixbuf-2.0 -lgmodule-2.0 > -lgio-2.0 -lcairo-gobject -lXinerama -lXi -lXrandr -lXcursor -lXfixes > -lXcomposite -lXdamage -lepoxy -latk-1.0 -latk-bridge-2.0 -ldbus-1 > -latspi -Wl,-rpath-link,/usr/local/lib,-rpath-link,/usr/X11R6/lib That is linking in quite a number of libraries, some of which are fairly sizeable. > takes from 15 to 20 minutes on arm. It is all cpu time, not i/o: The binutils linker is quite crappy. The LLVM linker is better. > load averages: 2.03, 2.02, 2.00 op1bsdsnap.graf.lan > 16:26:21 > > 78 processes: 1 running, 76 idle, 1 on processor up 4 days, > 7:42 > > CPU states: 99.6% user, 0.0% nice, 0.4% system, 0.0% interrupt, > 0.0% idle > > Memory: Real: 59M/234M act/tot Free: 259M Cache: 98M Swap: 11M/516M > > > > PID USERNAME PRI NICE SIZE RES STATE WAIT TIME CPU COMMAND > > 12051 root 64 0 7680K 8532K run - 6:44 99.12% ld > > 27209 sysadmin 2 0 972K 984K idle select 0:49 0.00% sshd > > 65728 _pflogd 4 0 716K 172K sleep bpf 0:29 0.00% pflogd > > I set up an i386 virtual system with one cpu at 3 GHz and the whole > gtk build including all the dependencies took a few hours. My gtk > build on an arm orangepi with a 1.2GHz cpu has been running for over > 48 hours, all due to libtool. A cc compile finishes in seconds. The orangepi probably runs at a lower speed since DVFS isn't implemented yet. And the Cortex-A7 simply isn't a very powerful CPU as it is completely in-order. Memory bandwidth on the orangepi is probably limited as well.
