Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

compiling current master gives error: undefined reference to `read_wisdom' #68

Open
gijzelaerr opened this issue Jul 7, 2016 · 19 comments

Comments

@gijzelaerr
Copy link
Contributor

search_bin.o: In function `main':
/packaging/repos/presto/src/search_bin.c:206: undefined reference to `read_wisdom'
gcc -I/packaging/repos/presto/include -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include  -I  -DUSEFFTW -DUSEMMAP -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -g -Wall -W -fPIC -O3 -ffast-math -Wno-unused-result -Wno-unused-but-set-variable -Wno-unused-but-set-parameter -fopenmp -o /packaging/repos/presto/bin/prepsubband prepsubband.o prepsubband_cmd.o backend_common.o zerodm.o sigproc_fb.o psrfits.o -lcfitsio -lpthread -L/packaging/repos/presto/lib -lpresto -lfftw3f -lcfitsio -lm
collect2: error: ld returned 1 exit status
Makefile:296: recipe for target 'search_bin' failed

looks like read_wisdom is defined in include/ransomfft.h, but when I include that it fails even more. removing read_wisdom seems to solve the problem, not sure if that is the smartest thing to do.

@scienceguyrob
Copy link

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!

@siemion
Copy link

siemion commented May 7, 2018

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

@scottransom
Copy link
Owner

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?

@siemion
Copy link

siemion commented May 7, 2018

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) 

@oleas-juan
Copy link

oleas-juan commented Jun 28, 2019

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

@oleas-juan
Copy link

oleas-juan commented Jun 28, 2019

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)

@scottransom
Copy link
Owner

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?

@scottransom
Copy link
Owner

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

@oleas-juan
Copy link

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.

@scottransom
Copy link
Owner

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.

@oleas-juan
Copy link

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?

@scottransom
Copy link
Owner

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

@oleas-juan
Copy link

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

@scottransom
Copy link
Owner

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.

@oleas-juan
Copy link

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?

@oleas-juan
Copy link

oleas-juan commented Jun 28, 2019

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

@scottransom
Copy link
Owner

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.

@vtonder
Copy link

vtonder commented Apr 12, 2021

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,

@scottransom
Copy link
Owner

@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....

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants