Quantcast

Re: CXSPARSE includes

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: CXSPARSE includes

Rik-4
On 02/08/2017 09:00 AM, [hidden email] wrote:
ubject:
--with-cxsparse-includedir option is ignored
From:
"c." [hidden email]
Date:
02/08/2017 03:58 AM
To:
Maintainers GNU Octave [hidden email]
List-Post:
[hidden email]
Content-Transfer-Encoding:
quoted-printable
Precedence:
list
MIME-Version:
1.0 (Mac OS X Mail 7.3 \(1878.6\))
Message-ID:
[hidden email]
Content-Type:
text/plain; charset=us-ascii
Message:
4

Hi,

I am trying to build Octave 4.2 on a machine with Scientific Linux release 6.6 (Carbon).
This machine uses an environmental modules system therefore many libraries, including SuiteSparse 
are installed in non-standard locations.

I am configuring with 

  ../configure <...> \
               --with-colamd-includedir=$mkSuitesparseInc \
               --with-colamd-libdir=$mkSuitesparseLib \
               --with-amd-libdir=$mkSuitesparseLib \
               --with-amd-includedir=$mkSuitesparseInc \
               --with-camd-libdir=$mkSuitesparseLib \
               --with-camd-includedir=$mkSuitesparseInc \
               --with-cholmod-libdir=$mkSuitesparseLib \
               --with-cholmod-includedir=$mkSuitesparseInc \
               --with-ccolamd-includedir=$mkSuitesparseInc \
               --with-ccolamd-libdir=$mkSuitesparseLib  \
               --with-cxsparse-libdir=$mkSuitesparseLib \
               --with-cxsparse-includedir=$mkSuitesparseInc \
               --with-umfpack-includedir=$mkSuitesparseInc \
               --with-umfpack-libdir=$mkSuitesparseLib 
              
The configure phase fails with the following message:

  checking for cs_di_sqr in -lcxsparse... yes
  checking whether CXSparse is version 2.2 or later... no
  configure: error: CXSparse library is too old (< version 2.2).  Upgrade CXSparse (SuiteSparse) or configure Octave with --disable-cxsparse"

The error message is not very useful because the problem is not with the version of CXSparse avaialble (the available version is > 3.0), checking config.log I see:

  configure:43472: checking whether CXSparse is version 2.2 or later
  configure:43523: g++ -std=gnu++11 -E  -fPIC  conftest.cpp
  conftest.cpp:96:24: fatal error: cs.h: No such file or directory

So it seems the directory passed to --with-cxsparse-includedir is not being added to the compilation flags (while it is added when testing for, e.g., cholmod), indeed adding "CPPFLAGS=-I$mkSuitesparseInc" is a workaround for this problem.

Is this a configuration bug? Does anyone know if it affects the development branch? Should I submit it to the tracker?

This is a bug.  Can you report it on the tracker?

The problem is that the m4 macro OCTAVE_CHECK_LIB sets library specific flags, in this case CXSPARSE_CPPFLAGS.  However, the next test in configure.ac which checks version, OCTAVE_CHECK_CXSPARSE_VERSION_OK, doesn't use these flags.

--Rik
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: CXSPARSE includes

John W. Eaton
Administrator
On 02/08/2017 06:23 PM, Rik wrote:

> On 02/08/2017 09:00 AM, [hidden email] wrote:
>> ubject:
>> --with-cxsparse-includedir option is ignored
>> From:
>> "c." <[hidden email]>
>> Date:
>> 02/08/2017 03:58 AM
>>
>> To:
>> Maintainers GNU Octave <[hidden email]>
>>
>> List-Post:
>> <mailto:[hidden email]>
>> Content-Transfer-Encoding:
>> quoted-printable
>> Precedence:
>> list
>> MIME-Version:
>> 1.0 (Mac OS X Mail 7.3 \(1878.6\))
>> Message-ID:
>> <[hidden email]>
>> Content-Type:
>> text/plain; charset=us-ascii
>> Message:
>> 4
>>
>>
>> Hi,
>>
>> I am trying to build Octave 4.2 on a machine with Scientific Linux release 6.6 (Carbon).
>> This machine uses an environmental modules system therefore many libraries, including SuiteSparse
>> are installed in non-standard locations.
>>
>> I am configuring with
>>
>>   ../configure <...> \
>>                --with-colamd-includedir=$mkSuitesparseInc \
>>                --with-colamd-libdir=$mkSuitesparseLib \
>>                --with-amd-libdir=$mkSuitesparseLib \
>>                --with-amd-includedir=$mkSuitesparseInc \
>>                --with-camd-libdir=$mkSuitesparseLib \
>>                --with-camd-includedir=$mkSuitesparseInc \
>>                --with-cholmod-libdir=$mkSuitesparseLib \
>>                --with-cholmod-includedir=$mkSuitesparseInc \
>>                --with-ccolamd-includedir=$mkSuitesparseInc \
>>                --with-ccolamd-libdir=$mkSuitesparseLib  \
>>                --with-cxsparse-libdir=$mkSuitesparseLib \
>>                --with-cxsparse-includedir=$mkSuitesparseInc \
>>                --with-umfpack-includedir=$mkSuitesparseInc \
>>                --with-umfpack-libdir=$mkSuitesparseLib
>>
>> The configure phase fails with the following message:
>>
>>   checking for cs_di_sqr in -lcxsparse... yes
>>   checking whether CXSparse is version 2.2 or later... no
>>   configure: error: CXSparse library is too old (< version 2.2).  Upgrade CXSparse (SuiteSparse) or configure Octave with --disable-cxsparse"
>>
>> The error message is not very useful because the problem is not with the version of CXSparse avaialble (the available version is > 3.0), checking config.log I see:
>>
>>   configure:43472: checking whether CXSparse is version 2.2 or later
>>   configure:43523: g++ -std=gnu++11 -E  -fPIC  conftest.cpp
>>   conftest.cpp:96:24: fatal error: cs.h: No such file or directory
>>
>> So it seems the directory passed to --with-cxsparse-includedir is not being added to the compilation flags (while it is added when testing for, e.g., cholmod), indeed adding "CPPFLAGS=-I$mkSuitesparseInc" is a workaround for this problem.
>>
>> Is this a configuration bug? Does anyone know if it affects the development branch? Should I submit it to the tracker?
>
> This is a bug.  Can you report it on the tracker?
>
> The problem is that the m4 macro OCTAVE_CHECK_LIB sets library specific
> flags, in this case CXSPARSE_CPPFLAGS.  However, the next test in
> configure.ac which checks version, OCTAVE_CHECK_CXSPARSE_VERSION_OK,
> doesn't use these flags.
Does the attached patch fix the problem?

jwe




diffs.txt (742 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: CXSPARSE includes

Rik-4
On 02/08/2017 04:30 PM, John W. Eaton wrote:
>
> Does the attached patch fix the problem?
>

Lots of e-mails crossing paths.  Mike's fix should be backported.  That is
the correct thing to do since the test in acinclude.m4 only makes use of
the preprocessor.  There is no need to save and restore the LIBS variable.

--Rik

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: CXSPARSE includes

Rik-4
In reply to this post by John W. Eaton
I backported Mike's fix to stable.

Separately, there were two cases in acinclude.m4 where we were saving
CXXFLAGS, but then only using the pre-processor to perform tests with
AC_PREPROC_IFELSE.  I pushed a cset to stop the unnecessary save&restore
here http://hg.savannah.gnu.org/hgweb/octave/rev/e9d7932373ad.

Finally, following Carlo's investigations I looked in config.log and found
that the test for the Qt SetPlaceHolderText function was failing with

conftest.cpp:123:32: fatal error: Qt/qglobal.h: No such file or directory

but I do have qglobal.h installed at

/usr/include/qt4/Qt/qglobal.h
/usr/include/qt4/QtCore/qglobal.h
/usr/include/x86_64-linux-gnu/qt5/QtCore/qglobal.h

Since Octave now defaults to Qt5, it is not finding the last instance.

The m4 code in acinclude.m4 is:

dnl
dnl Check whether QScintilla SetPlaceholderText function exists.
dnl FIXME: This test uses a version number.  It potentially could
dnl        be re-written to actually call the function, but is it worth it?
dnl
AC_DEFUN([OCTAVE_CHECK_FUNC_SETPLACEHOLDERTEXT], [
  AC_CACHE_CHECK([whether Qt has SetPlaceholderText function],
    [octave_cv_func_setplaceholdertext],
    [AC_LANG_PUSH(C++)
    ac_octave_save_CPPFLAGS="$CPPFLAGS"
    CPPFLAGS="$QT_CPPFLAGS $CXXPICFLAG $CPPFLAGS"
    AC_PREPROC_IFELSE([AC_LANG_PROGRAM([[
        #include <Qt/qglobal.h>
        ]], [[
        #if QT_VERSION < 0x040700
        #error No SetPlacholderText function available.
        #endif
        ]])],
      octave_cv_func_setplaceholdertext=yes,
      octave_cv_func_setplaceholdertext=no)
    CPPFLAGS="$ac_octave_save_CPPFLAGS"
    AC_LANG_POP(C++)
  ])
  if test $octave_cv_func_setplaceholdertext = yes; then
    AC_DEFINE(HAVE_SETPLACEHOLDERTEXT, 1,
      [Define to 1 if you have the Qt SetPlaceholderText function.])
  fi
])

Is it enough to change

#include <Qt/qglobal.h>

to

#include <qglobal.h>

It seemed to work for me, but I haven't gone and tested back with Qt4.

--Rik

Loading...