compiling current master gives error: undefined reference to `read_wisdom' about presto HOT 19 OPEN

Hi Scott, I'm having the same issue. I'm running CentOS 7. I'm building within a Docker container, so I can offer the exact environment required to reproduce this issue. My docker file is on Github:

https://raw.githubusercontent.com/scienceguyrob/Docker/master/Images/tvg/CentOS/Dockerfile (commit 58a0dcf). Not sure if this helps!

from presto.

I had this problem as well under Ubuntu 16.04 LTS (gcc 5.4.0)

Fixed by changing gcc flag ordering in the Makefile:

CFLAGS = -I$(PRESTO)/include $(GLIBINC) $(CFITSIOINC) $(PGPLOTINC) $(FFTINC) \
	-g -Wall -W -fPIC -O3 -ffast-math -DUSEFFTW -DUSEMMAP -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64

from presto.

Huh. I've never been able to replicate this bug. And I use Ubuntu 14.04, 16.04 and now 18.04.
@siemion Any idea why that change in the CFLAGS ordering makes a difference?

from presto.

No idea... =)

Here's the full compiler info:

gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 5.4.0-6ubuntu1~16.04.9' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.9) 

from presto.

Hi @scottransom,

I've tried installing Presto in a Redhat 6.10 OS machine, in a CentOS 7 machine, and a Ubuntu 18.04 machine and they all give me this bug.

I tried fixing it by following @siemion suggestion of editing the gcc flag ordering in the Makefile, but I still get the error.

Since you've never been able to replicate this bug, what were your configurations/ did you try to compile presto on a new machine that is fresh out of the box? If so, what dependencies did you install that are not listed on the INSTALL file.

Thanks

from presto.

Here is my compiler info on my Ubuntu 18.04 machine:

gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 7.4.0-1ubuntu1~18.04.1' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-7 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 7.4.0 (Ubuntu 7.4.0-1ubuntu1~18.04.1)

from presto.

Ugh. This is so strange. I regularly compile PRESTO on RHEL7, RHEL6, and all the recent Ubuntu releases (I'm using 18.10 on my laptop now, and will probably try 19.04 this weekend). And yes, I compile PRESTO in out-of-the box configurations of those quite regularly.

Are you compiling your own FFTW? Or are you using a package for it?

And what if you remove search_bin from the BINARIES target? Does everything else compile?

from presto.

Did you by any chance get rid of the -DUSEFFTW flag in CFLAGS? That would cause this as well, I think.

from presto.

Yeah, it's a strange one. On the Ubuntu machine, I'm using the libfftw3-dev package that was suggested. On the others, I was compiling my own FFTW.

I haven't tried removing the search_bin from the BINARIES. By this, do you mean removing search_bin.c, search_bin_cmd.c, search_bin_cmd.o, and search_bin.o from the $PRESTO/src directory?

I just tried now with removing the -DUSEFFTW flag in CFLAGS and it still didn't work.

from presto.

If you look in $PRESTO/src/Makefile, search_bin is listed in the BINARIES variable. Just remove the word from there and search_bin won't be compiled by default. I want to see if everything else compiles and runs fine. (i.e. is this a problem just with search_bin, or with other parts of PRESTO that use FFTW).

As for -DUSEFFTW, I was wondering if that was not being set somehow. If that is not set, I can completely see how this error would happen. In other words, you should definitely have that as part of CFLAGS.

from presto.

Follow up:
I removed search_bin from the BINARIES variable, and proceeded to compile it and I got this new error now:

accel_utils.o: In function init_subharminfo': accel_utils.c:(.text+0xa95): undefined reference to fftwcall'
accel_utils.o: In function subharm_fderivs_vol': accel_utils.c:(.text+0x6361): undefined reference to fftwcall'
collect2: error: ld returned 1 exit status
Makefile:206: recipe for target 'accelsearch' failed
make: *** [accelsearch] Error 1

Should I remove accelsearch from the BINARIES?

from presto.

Ok, that is useful. This definitely means that, for some reason, USEFFTW is not being set properly.

Can you please post what one of the gcc lines looks like when you run "make" in $PRESTO/src?

And no, you definitely want to keep accelsearch in BINARIES

from presto.

This is one of the gcc lines when running "make" in $PRESTO/src:

gcc -I/home/oleasjuan/software/presto/include -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I -g -Wall -W -fPIC -O3 -ffast-math -DUSEFFTW -DUSEMMAP -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -Wno-unused-result -Wno-unused-but-set-variable -Wno-unused-but-set-parameter -fopenmp -o /home/oleasjuan/software/presto/bin/makedata com.o randlib.o makedata.o -lcfitsio -lpthread -L/home/oleasjuan/software/presto/lib -lpresto -lfftw3f -lm

from presto.

That last "empty" -I might be the problem. It seems like the FFTW include location isn't being found. What do you get if you run
pkg-config --cflags fftw3f
on the command line? (Note that that is in the Makefile to find the FFTW include files).

If that doesn't give you an include path, you might need to set FFTINC explicitly to the include directory where fftw3.h lives.

from presto.

Hi, so I ran the command pkg-config --cflags fftw3f and I got this -I/usr/local/include

Would I still need to set FFTINC explicitly o include the directory where ffw3.h lives? Is so, would I set this on my .bashrc file?

from presto.

Follow up,
I uninstalled and manually reinstalled FFTW3, Tempo, cfitsio, and pgplot, and edited my .bashrc file to this:

export PATH="/home/oleasjuan/anaconda3/bin:/home/oleasjuan/software/presto/bin:$
PATH"
export PYTHONPATH="/home/oleasjuan/anaconda3/bin:/home/oleasjuan/software/presto
/lib/python"
export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/home/oleasjuan/software/presto/lib"
export PRESTO="/home/oleasjuan/software/presto"
export PGPLOT_DIR="/usr/local/pgplot"
export PGPLOT_DEV="/XServe"
export TEMPO="/home/oleasjuan/software/tempo"
export CFITSIO_DIR="/home/oleasjuan/software/cfitsio-3.47"
export FFTW3F_DIR="/home/oleasjuan/software/fftw-3.3.8"

export PKG_CONFIG_PATH="$PKG_CONFIG_PATH:/usr/local/include:/home/oleasjuan/soft
ware/fftw-3.3.8:/usr/share/glib-2.0:/home/oleasjuan/software/cfitsio-3.47:/home/
oleasjuan/software/presto/include"

This seems to not give issues with FFTW. However, I get this new error when trying to compile it:

/usr/bin/ld: warning: libcurl.so.4, needed by /home/oleasjuan/software/cfitsio-3.47/lib/libcfitsio.so, not found (try using -rpath or -rpath-link)
/home/oleasjuan/software/cfitsio-3.47/lib/libcfitsio.so: undefined reference to `curl_easy_setopt'
/home/oleasjuan/software/cfitsio-3.47/lib/libcfitsio.so: undefined reference to `curl_global_cleanup'
/home/oleasjuan/software/cfitsio-3.47/lib/libcfitsio.so: undefined reference to `curl_easy_init'
/home/oleasjuan/software/cfitsio-3.47/lib/libcfitsio.so: undefined reference to `curl_easy_perform'
/home/oleasjuan/software/cfitsio-3.47/lib/libcfitsio.so: undefined reference to `curl_easy_cleanup'
/home/oleasjuan/software/cfitsio-3.47/lib/libcfitsio.so: undefined reference to `curl_global_init'
collect2: error: ld returned 1 exit status
Makefile:234: recipe for target 'prepdata' failed
make: *** [prepdata] Error 1

from presto.

Given what you got with the pkg-config command, I think that that "empty" -I should have been -I/usr/local/include. You could try manually setting that in the makefile for FFTINC.

The libcurl issue isn't a PRESTO problem, though, but is related to the installation of CFITSIO. You could try a "locate libcurl.so.4" to see if that exists on your system. But curl is definitely a package in all of the Linuxes.

from presto.

Hi Scott,

I'm on Ubuntu 20.04 and I got the same issue as described above - changing the gcc flag ordering as per Andrew's suggestion also fixed it for me.

Thanks,

from presto.

@vtonder Thanks for that. I've changed the ordering in the official PRESTO even though I have no idea why that works. Seems really bizarre to me....

from presto.