Am 29.01.2020 um 01:02 schrieb Hans-Bernhard Bröker:
Am 25.01.2020 um 17:55 schrieb Marco Atzeri:
The problem occurs the same way, here, running Win10 Pro 1909 fully
updated (a.k.a. Version 10.0.18363.592), no extra AntiVirus running
besides Defender.
Be aware that build time is very long (~ 4 hours) and requires
a ton of mathematical libraries.
The build itself completed in ~30 minutes, here ;-). But then this is a
fresh i9, 8-core, 16-thread box.
Nice toy. Here just a notebook with i5 4-core
cygport install took ages to complete, though, because objcopy takes
spectacularly long to strip those DLLs --- longer than it took to build
the whole package! And it does them one at a time. That could profit
from some parallelization.
there are only 2 gigant dll`s
$ find . -name "cyg*dll" -exec du -sh {} \;
55M ./libgui/.libs/cygoctgui-5.dll
536M ./libinterp/.libs/cygoctinterp-7.dll
213M ./liboctave/.libs/cygoctave-7.dll
the rest is penauts
$ find . -name "*oct" -exec du -sh {} \;
67M ./libgui/graphics/__init_qt__.oct
1.3M ./libinterp/dldfcn/amd.oct
3.0M ./libinterp/dldfcn/audiodevinfo.oct
1.8M ./libinterp/dldfcn/audioread.oct
1.4M ./libinterp/dldfcn/ccolamd.oct
1.6M ./libinterp/dldfcn/chol.oct
1.5M ./libinterp/dldfcn/colamd.oct
1.4M ./libinterp/dldfcn/convhulln.oct
1.2M ./libinterp/dldfcn/dmperm.oct
1.2M ./libinterp/dldfcn/fftw.oct
1.3M ./libinterp/dldfcn/gzip.oct
1.7M ./libinterp/dldfcn/qr.oct
1.3M ./libinterp/dldfcn/symbfact.oct
1.3M ./libinterp/dldfcn/symrcm.oct
1.4M ./libinterp/dldfcn/__delaunayn__.oct
2.6M ./libinterp/dldfcn/__eigs__.oct
1.3M ./libinterp/dldfcn/__fltk_uigetfile__.oct
1.4M ./libinterp/dldfcn/__glpk__.oct
3.8M ./libinterp/dldfcn/__init_fltk__.oct
2.8M ./libinterp/dldfcn/__init_gnuplot__.oct
2.5M ./libinterp/dldfcn/__ode15__.oct
1.5M ./libinterp/dldfcn/__voronoi__.oct
on the x86 build takes longer :-(
So while I waited, I decided to try it with the distributed octave.exe
instead.
It passes the critical tests without issue.
my experience also. I was not able to make crash the old (by one month)
version
Next step, after cygport inst is done: run the test with the executable
in cygport's "inst" directory (to bypass libtool): Success, again!
So I tried running the test via libtool, i.e. the run-octave script. And
boom it goes.
So re-run it in gdb, via libtool (run-octave -g ...). Still crashes,
but I didn't manage to get around the SIGSEGV handler in octave. It
always caught the SEGV before gdb managed to get there.
So my finding, so far, would be that this is related to libtool. Maybe
some update to Windows broke the way libtool interacts with
not-quite-finished executables...
I had also the fresh executable installed and it also can fail.
My guess is that it is in someplace different as behaviour than the old
one.
So libtool can help to trigger but it is not necessary.
Regards
Marco
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
