bugGNU APL - Bugs: bug #65367, GNU APL 'configure' does not...

 
 

bug #65367: GNU APL 'configure' does not detect the FFTW on macos.

Submitter:  None
Submitted:  Mon 26 Feb 2024 01:34:29 AM UTC
   
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open
* Mandatory Fields

Add a New Comment Rich Markup
   

Mon 26 Feb 2024 01:34:29 AM UTC, original submission:  

GNU APL 'configure' does not detect the installed FFTW library on macos.

I'm building GNU APL on an old Intel macbook.

    $ uname -a
    Darwin mbp13 19.6.0 Darwin Kernel Version 19.6.0: Tue Jun 21 21:18:39 PDT 2022; root:xnu-6153.141.66~1/RELEASE_X86_64 x86_64

    $ g++ --version
    Configured with: --prefix=/Users/z/Apps/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/c++/4.2.1
    Apple clang version 12.0.0 (clang-1200.0.32.29)
    Target: x86_64-apple-darwin19.6.0
    Thread model: posix
    InstalledDir: /Users/z/Apps/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

    $ svn info
    Path: .
    Working Copy Root Path: /Volumes/Archive/Language/APL/gnu-apl/SVN/trunk
    URL: http://svn.savannah.gnu.org/svn/apl/trunk
    Relative URL: ^/trunk
    Repository Root: http://svn.savannah.gnu.org/svn/apl
    Repository UUID: bd74f7bd-1a55-4bac-9fab-68015b139e80
    Revision: 1755
    Node Kind: directory
    Schedule: normal
    Last Changed Author: j_sauermann
    Last Changed Rev: 1755
    Last Changed Date: 2024-02-20 05:41:46 -0600 (Tue, 20 Feb 2024)

(Using SVN 1755 because there's a compile error in 1756).

FFTW is installed in /usr/local

    $ ls -l /usr/local/include/fft*
    -rw-r--r--@ 1 root  wheel   2447 Feb  3 21:04 /usr/local/include/fftw3.f
    -rw-r--r--  1 root  wheel  55032 Feb  3 21:04 /usr/local/include/fftw3.f03
    -rw-r--r--@ 1 root  wheel  31986 Feb  3 21:04 /usr/local/include/fftw3.h
    -rw-r--r--@ 1 root  wheel  27203 Feb  3 21:04 /usr/local/include/fftw3l.f03
    -rw-r--r--@ 1 root  wheel  25902 Feb  3 21:04 /usr/local/include/fftw3q.f03

    $ ls -l /usr/local/lib/libfft*
    -rwxr-xr-x  1 root  wheel  1053488 Feb  3 21:04 /usr/local/lib/libfftw3.3.dylib
    -rw-r--r--  1 root  wheel  1540408 Feb  3 21:04 /usr/local/lib/libfftw3.a
    lrwxr-xr-x  1 root  wheel       16 Feb  3 21:04 /usr/local/lib/libfftw3.dylib -> libfftw3.3.dylib
    -rwxr-xr-x  1 root  wheel      936 Feb  3 21:04 /usr/local/lib/libfftw3.la


Run configure

    ./configure
        ...
    checking for fftw3.h... (cached) yes
    checking for fftw_plan_dft in -lfftw3... (cached)
       └──── will affect ⎕FFT
       └──── will affect: ⎕FFT
      ...
        apl_FFT:                     (affects: ⎕FFT)

Note, the space after 'apl_FFT' is blank, not 'yes' or 'no'.

In config.log

    configure:18731: g++ -c -g -O2 -I /Volumes/Archive/Language/APL/gnu-apl/SVN/trunk  conftest.cpp >&5  
    configure:18731: $? = 0
    configure:18731: result: yes
   
    configure:20882: checking for fftw3.h            
    configure:20882: result: yes
    configure:20892: checking for fftw_plan_dft in -lfftw3
    configure:20924: result:

Again, the result is blank, not 'yes' or 'no.

What is set in config.h

    $ grep -i fft config.h
    /* Define to 1 if you have the <fftw3.h> header file. */
    #define HAVE_FFTW3_H 1
    /* Define to 1 if you have the `fftw3' library (-lfftw3). */
    /* #undef HAVE_LIBFFTW3 */
    /* FFT available */
    #define apl_FFT 0

It detects the header file, but doesn't link with the library file, or doesn't correctly parse the compiler messages.

No FFT library linked to the 'apl' command:
('ldd' is my alias for 'otool -L')

    $ ldd src/apl
    src/apl:
    /opt/local/lib/libsqlite3.0.dylib (compatibility version 9.0.0, current version 9.6.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1)
    /opt/local/lib/libncurses.6.dylib (compatibility version 6.0.0, current version 6.0.0)
    /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 902.1.0)


Questions:

Can we get 'configure' to leave the test programs around so we can see what it's trying to find?

How do we find out what it's looking for (error message format, output format, whatever)?

Does 'm4/check_FFT.m4' need to be revised like 'm4/check_SQLITE.m4' was?


This situation also happens for PCRE2. The headers and libraries are in /usr/local, but 'configure' doesn't detect the library.

Anonymous

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

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 logged-in users can vote.

 

No changes have been made to this item

Back to the top

Powered by Savane 3.13-bb6a.
Corresponding source code