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

linker error when running make #754

Closed
tbui468 opened this issue Mar 3, 2024 · 8 comments
Closed

linker error when running make #754

tbui468 opened this issue Mar 3, 2024 · 8 comments
Labels

Comments

@tbui468
Copy link

tbui468 commented Mar 3, 2024

Environment
Which version of REBOUND are you using and on what operating system?

  • REBOUND Version: 4.3.2
  • API interface: C
  • Operating System (including version): WSL2 - Ubuntu 20.04.6 LTS

Describe the bug
Linker error when running the default Makefile with following messages:
/usr/bin/ld: ./librebound.so: undefined reference to pthread_join' /usr/bin/ld: ./librebound.so: undefined reference to pthread_create'
/usr/bin/ld: ./librebound.so: undefined reference to `pthread_cancel'

The shared librebound.so compiles fine, but linking it causes those errors.

To Reproduce
Running make inside of /rebound/examples/simplest or any of the examples causes this error.
Running this line from the README.md also causes this problem.
git clone https://github.com/hannorein/rebound && cd rebound/examples/shearing_sheet && make && ./rebound

Additional context
Linking the pthread library in src/Makefile.defs when the OS is Linux solves this problem for me (see example below). Would love to submit a pull request and contribute to the project if possible!

ifeq ($(OS), Linux)
OPT+= -Wall -g
LIB+= -lm -lrt -lpthread
endif

@tbui468 tbui468 added the bug label Mar 3, 2024
@hannorein
Copy link
Owner

hannorein commented Mar 3, 2024

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.

@tbui468
Copy link
Author

tbui468 commented Mar 3, 2024

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-1ubuntu1
20.04.2)

@hannorein
Copy link
Owner

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

@tbui468
Copy link
Author

tbui468 commented Mar 3, 2024

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

@tbui468
Copy link
Author

tbui468 commented Mar 4, 2024

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

@hannorein
Copy link
Owner

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.

@tbui468
Copy link
Author

tbui468 commented Mar 6, 2024

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!

@hannorein
Copy link
Owner

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.

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

No branches or pull requests

2 participants