linker error when running make about rebound HOT 8 CLOSED

Hm. I'm not sure what the right solution here is. This post suggests to use -pthread instead. All this seems rather compiler specific.

from rebound.

Hi Thomas. Thanks for reporting this. I can't reproduce this (I'm using Ubuntu 22.04.2). Googling a bit, it looks like most C compilers will include standard libraries by default in a "hosted environment" but not in a "freestanding" one. May I suggest you try updating WSL? Also, I'd be curious what you can when you run cc -v.

from rebound.

Hi hannorein. Thank you for the response. I've updated WSL and still get the same error. I will look into the hosted/freestanding environments and see if that works for me. cc -v for me shows this:

Using built-in specs.
COLLECT_GCC=cc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 9.4.0-1ubuntu120.04.2' --with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-9 --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 --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib=auto --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=/build/gcc-9-9QDOt0/gcc-9-9.4.0/debian/tmp-nvptx/usr,hsa --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 9.4.0 (Ubuntu 9.4.0-1ubuntu120.04.2)

from rebound.

Using -pthread rather than -lpthread also works for me. Thank you for the link and information.

from rebound.

Compiling examples/openmp works fine with my current setup without having to include the -pthread option. I think this is due to -fopenmp being implemented with pthreads. source . Seems like pthreads are defined and linked when compiled with the -fopenmp option on my system.

I wrote a few example C programs using pthreads and included the -fopenmp option, and indeed it worked fine without needing to pass the -pthread option.

I modified Makefile.defs to include the -pthread option only when not using openmp, and now all examples compile fine on my system. Adding the -pthread option here is a little more surgical than what I suggest before.

ifeq ($(OPENMP), 1)
    PREDEF+= -DOPENMP
ifeq ($(CC), icc)
    OPT+= -openmp
    LIB+= -openmp
else
    OPT+= -fopenmp
    LIB+= -fopenmp
endif
else
ifeq ($(OPENMPCLANG), 1)
    PREDEF+= -DOPENMP
    OPT+= -I$(brew --prefix libomp)/include -Xpreprocessor -fopenmp
    LIB+= -lomp
else
    ifneq ($(OS), Windows_NT) #this branch runs when trying to compile other examples (exception is examples/openmp)
        OPT+= -Wno-unknown-pragmas
        OPT+= -pthread #adding the -pthread option here defines pthread functions when openmp isn't used
    endif
endif
endif

from rebound.

I think the logic is even more complicated. Pthreads is only needed if either the SERVER or the OPENGL flag is set to 1. Given that I still can't reproduce this issue on my version of Windows/WSL (neither are there issues on the CI), I think we should just leave things the way they are. There might be some unpredictable consequences... for various OS/compiler combinations.

from rebound.

That's a good point about unpredictable consequences. I'll just use the -pthread option as a temporary fix on my setup. Thank you for your responses!

from rebound.

Sound good. Note that you can also just do something like (without editing any files):

OPT=-pthread make

The proper way to handle these things would be a configure script, but I hesitate adding this extra layer of abstraction. I'll close this now but hopefully it will come up if someone else has the same issue. In any case, thanks for reporting it.

from rebound.