Re: headache on build repeatibility: octave vs BLODA ?

[Marco Atzeri <marco dot atzeri at gmail dot com>]

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