bugGNU Octave - Bugs: bug #62715, ./configure could cache more...

 
 

bug #62715: ./configure could cache more values for better performance

Submitter:  Rik <rik5>
Submitted:  Wed 06 Jul 2022 10:12:01 PM UTC
   
 
Category:  Configuration and Build System Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Performance
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sat 09 Jul 2022 05:21:02 PM UTC, comment #9: 

I made several changes to cache more of the variables in configure.  The remaining uncached ones are not simple to modify because they are associated with PKG_CONFIG.  I think enough progress has been made to close this report.

Marking as fixed.

Rik <rik5>
Group administrator
Fri 08 Jul 2022 04:38:13 AM UTC, comment #8: 

The current way of setting the integer size used by the BLAS and other Fortran libraries is to set the configure variable prior to running configure because the configure test requires running a program and that doesn't work when cross compiling.

I don't know whether it would be better to use a configure option for this particular case.  I probably wouldn't spend more time on it.

If we remove the ax_blas_f77_func_ok variable from Octave's configure script, it could also be removed from MXE Octave.  But that's a lower priority since setting the value of an unused variable there won't cause any real trouble.

John W. Eaton <jwe>
Group administrator
Thu 07 Jul 2022 06:54:35 PM UTC, comment #7: 

I pushed a change to the release branch of MXE Octave here:
https://hg.octave.org/mxe-octave/rev/b8d72e61d379

Markus Mützel <mmuetzel>
Group administrator
Thu 07 Jul 2022 06:39:48 PM UTC, comment #6: 

I suspected there might be some changes in MXE Octave.  I don't build that on my machine anymore (for years now) so I can't test.

At least variable renaming is something simple, and would be the first thing I would do.

Rik <rik5>
Group administrator
Thu 07 Jul 2022 05:57:14 PM UTC, comment #5: 

Oooh.
There is the following in the build rules for Octave in MXE Octave:

ifeq ($(ENABLE_FORTRAN_INT64),yes)
  $(PKG)_ENABLE_FORTRAN_INT64_CONFIGURE_OPTIONS := F77_INTEGER_8_FLAG=-fdefault-integer-8 ax_blas_f77_func_ok=yes ax_blas_integer_size=8 octave_cv_sizeof_fortran_integer=8
else
  $(PKG)_ENABLE_FORTRAN_INT64_CONFIGURE_OPTIONS := ax_blas_f77_func_ok=yes ax_blas_integer_size=4 octave_cv_sizeof_fortran_integer=4
endif


IIUC, you changed the name of that variable from `ax_blas_integer_size` to `ax_cv_blas_integer_size`. That probably needs adapting in the build rules now.

Markus Mützel <mmuetzel>
Group administrator
Thu 07 Jul 2022 05:48:46 PM UTC, comment #4: 

Nevermind. Just noticed that the builders that build Octave from the default branch for Windows 64-bit didn't run yet since that change. So, I don't know if they would be failing, too.

Markus Mützel <mmuetzel>
Group administrator
Thu 07 Jul 2022 05:42:24 PM UTC, comment #3: 

That builder cross-builds Octave on Ubuntu for Windows.
There are three different configurations that are routinely built on jwe's buildbot: Octave for Windows 32-bit (with 32-bit Fortran integers), Octave for Windows 64-bit with 32-bit Fortran integers and Octave for Windows 64-bit with 64-bit Fortran integers.

So, configurations with 4-byte and 8-byte Fortran integers should both make it through. And it looks like they currently do when the target is Windows 64-bit. But for some reason, it seems to be failing if the target is Windows 32-bit...

If we need to add assumptions that weren't needed before, maybe it should be that the BLAS libraries use the same size of Fortran integers that Octave was configured to use...

Markus Mützel <mmuetzel>
Group administrator
Thu 07 Jul 2022 05:32:36 PM UTC, comment #2: 

@Markus: It seems possible that the change is related.

Is there something weird about w32-on-debian build?  Is it a cross compile, for example, where some configure tests might get skipped and therefore the value for ax_cv_blas_integer_size is never set?

In configure.ac I see


OCTAVE_BLAS_WITH_F77_FUNC([], [],
  [ax_blas_ok=yes
  AC_MSG_CHECKING([BLAS can be called from Fortran])
  AC_MSG_RESULT([yes assumed for cross compilation])])


And in octave_blas_f77_func.m4 I see this in the documentation


#   AX_BLAS_F77_FUNC([ACTION-IF-PASS[, ACTION-IF-FAIL[, ACTION-IF-CROSS-COMPILING]])


Also, at the top of the code for the Autoconf macro I see


if test "$cross_compiling" = yes ; then
        ifelse($3, ,$1,$3)


So, this is very likely related to the cross compiling.  I don't know what the desired result is here.  Should we just assume 4-byte BLAS library when cross compiling?

Rik <rik5>
Group administrator
Thu 07 Jul 2022 02:16:51 PM UTC, comment #1: 

The 32-bit builder failed during the checks for Fortran integer size:
http://buildbot.octave.org:8010/#/builders/14/builds/1464/steps/8/logs/stdio

Could that be related to the recent changes?
https://hg.savannah.gnu.org/hgweb/octave/rev/1077a1c277fb

Markus Mützel <mmuetzel>
Group administrator
Wed 06 Jul 2022 10:12:01 PM UTC, original submission:  

Apparently the configure script used in building Octave is not caching as many variables as it could.  I ran configure with the '-C' option to generate a cache and then immediately re-ran configure.  I made a list of the items that did not have "(cached)" next to them indicating that the value had been pulled from the cache.  I'm attaching that list and also putting it in the text of the bug report.  It shouldn't be too difficult to edit configure.ac or m4/acinclude.m4 to make use of the AC_CACHE_CHECK macro.


checking whether build environment is sane... yes
checking whether UID '1000' is supported by ustar format... yes
checking whether GID '1000' is supported by ustar format... yes
checking whether make supports the include directive... yes (GNU style)
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking pkg-config is at least version 0.9.0... yes
checking for bison 3.0 or newer... 3.8.2, ok
checking for options to make reproducible archives with GNU tar... --owner=0 --group=0 --numeric-owner --sort=name
checking whether ln -s works... yes
checking for python... no
checking C++ compiler version number... 11.2.0
checking C compiler version number... 11.2.0
checking whether a usable Fortran compiler was found... yes
checking whether pthreads work with "-pthread" and "-lpthread"... yes
checking how to print strings... printf
checking for dlltool... no
checking for sysroot... no
checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
checking how to run the C++ preprocessor... g++ -E
checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking how to hardcode library paths into programs... immediate
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
checking whether the gfortran linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking how to hardcode library paths into programs... immediate
checking if sgemm_ is being linked in already... no
checking for sgemm_ in -framework vecLib... no
checking whether LSAME is called correctly from Fortran... yes
checking whether ISAMAX is called correctly from Fortran... yes
checking whether SDOT is called correctly from Fortran... yes
checking whether DDOT is called correctly from Fortran... yes
checking whether CDOTU is called correctly from Fortran... yes
checking whether ZDOTU is called correctly from Fortran... yes
checking BLAS library integer size... 4
checking whether POSIX threads API is available... yes
checking for ld... /usr/bin/ld -m elf_x86_64
checking for multithread API to use... posix
checking for MAP_ANONYMOUS... yes
checking for freetype2... yes
checking for FreeType2 version >= 9.03... yes
checking Qt version 5... checking for Qt5Core Qt5Gui Qt5Help Qt5Network Qt5PrintSupport Qt5Xml... yes
checking for moc-qt5... no
checking for uic-qt5... no
checking for rcc-qt5... no
checking for lrelease-qt5... no
checking for qcollectiongenerator-qt5... no
checking for qhelpgenerator-qt5... no
checking whether SUNDIALS API provides the necessary functions... yes
checking for Java version... 11.0.15
checking for libjvm.so... /usr/lib/jvm/java-11-openjdk-amd64/lib/server
checking for include file <jni.h>... /usr/lib/jvm/java-11-openjdk-amd64/include


Rik <rik5>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #53403:  configure_cache.list added by rik5 (3KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by rik5
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by rik5 (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-07-09 rik5 StatusConfirmed Fixed
        Open/ClosedOpen Closed
    2022-07-07 rik5 Carbon-Copy- Added jwe
    2022-07-06 rik5 Attached File- Added configure_cache.list, #53403

    Back to the top

    Powered by Savane 3.13-f14d.
    Corresponding source code