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

Build fails with boost 1.71.0: server/plugins/CMakeFiles/DiskIO_UGens_supernova.dir/build.make:84: *** target pattern contains no '%'. Stop. #4576

Closed
dvzrv opened this issue Sep 13, 2019 · 9 comments
Labels

Comments

@dvzrv
Copy link
Member

@dvzrv dvzrv commented Sep 13, 2019

I'm currently trying to rebuild supercollider against boost 1.71.0, but it fails:

make -f server/plugins/CMakeFiles/DiskIO_UGens_supernova.dir/build.make server/plugins/CMakeFiles/DiskIO_UGens_supernova.dir/depend
make[2]: Entering directory '/build/supercollider/src/supercollider-3.10.3/build'
server/plugins/CMakeFiles/DiskIO_UGens_supernova.dir/build.make:84: *** target pattern contains no '%'.  Stop.
make[2]: Leaving directory '/build/supercollider/src/supercollider-3.10.3/build'
make[1]: *** [CMakeFiles/Makefile2:1380: server/plugins/CMakeFiles/DiskIO_UGens_supernova.dir/all] Error 2
make[1]: Leaving directory '/build/supercollider/src/supercollider-3.10.3/build'

Environment

  • SuperCollider version: current develop HEAD (9f6bc367ba) (but also 3.10.3)
  • Operating system: Arch Linux
  • Other details (Qt version, audio driver, etc.):
    boost 1.71.0
    desktop-file-utils 0.24-1
    fftw 3.3.8-1
    link 3.0.2-1
    jack 0.125.0-7
    qt5-svg 5.13.1-1
    qt5-webengine 5.13.1-2
    qt5-websockets 5.13.1-1
    qt5-tools 5.13.1-1
    yaml-cpp 0.6.2-1
    cmake 3.15.3-1
    emacs 26.3-1
    gedit 3.34.0-1
    xorg-server-xvfb 1.20.5-2

Steps to reproduce

  mkdir -p build && cd build
  cmake .. -DCMAKE_INSTALL_PREFIX=/usr \
           -DCMAKE_BUILD_TYPE=Release \
           -DLIBSCSYNTH=ON \
           -DFORTIFY=ON \
           -DSYSTEM_YAMLCPP=ON \
           -DSYSTEM_BOOST=ON \
           -DSC_VIM=OFF
  make VERBOSE=1

Expected vs. actual behavior

Supercollider should compile with boost 1.71.0.
vs.
It fails:
supercollider-devel-build.log
supercollider-3.10.3-build.log

@brianlheim

This comment has been minimized.

Copy link
Member

@brianlheim brianlheim commented Sep 14, 2019

Hey @dvzrv , a couple questions --

  1. does this happen with a totally clean build?
  2. any other targets that don't build? (i.e. with make -k)
  3. what are the contents of server/plugins/CMakeFiles/DiskIO_UGens_supernova.dir/build.make?

initial guess is that something wasn't quite right with #4185, and now the generated makefile is buggy with SYSTEM_BOOST

@dvzrv

This comment has been minimized.

Copy link
Member Author

@dvzrv dvzrv commented Sep 14, 2019

@brianlheim good point (about #4185). However, that's what I'm pulling in for 3.10.3 and what is used for develop HEAD and works with boost 1.69.0.

I'll provide you with the info asap, but to answer question 1 upfront: I'm building in a pristine container.

@dvzrv

This comment has been minimized.

Copy link
Member Author

@dvzrv dvzrv commented Sep 14, 2019

After rerun using make -k, I've also identified UIUgens, libscsynth and libsupernova and ran into #4490:
supercollider-3.10.3-build.log

To get back to the initial error, the accompanying line (83) in server/plugins/CMakeFiles/DiskIO_UGens_supernova.dir/build.make looks like:

server/plugins/UIUGens_supernova.so: Boost::thread

build.make.txt

@dvzrv

This comment has been minimized.

Copy link
Member Author

@dvzrv dvzrv commented Sep 14, 2019

When comparing this to server/plugins/CMakeFiles/DiskIO_UGens_supernova.dir/build.make generated with boost 1.69.0, the difference becomes clear:

server/plugins/UIUGens_supernova.so: /usr/lib/libboost_thread.so

build.make.txt

So, yeah, the assessment, that something in #4185 might not apply cleanly anymore, seems correct.

Potentially the return of find_package() with newer boost is different, so that the following doesn't work the same?

add_library(boost_thread_lib SHARED IMPORTED)                                                                                                                                         
set_property(TARGET boost_thread_lib PROPERTY IMPORTED_LOCATION ${Boost_THREAD_LIBRARY})

Will investigate

@dvzrv

This comment has been minimized.

Copy link
Member Author

@dvzrv dvzrv commented Sep 14, 2019

It seems, that boost 1.71.0 ships its own cmake file, which takes precedence over cmake's own.
https://gitlab.kitware.com/cmake/cmake/merge_requests/3763

Running cmake with -DBoost_NO_BOOST_CMAKE=ON (to ignore the cmake files that come with boost) and applying #4491 I can compile 3.10.3!

I guess this means a follow up pull request, once the vendored boost of supercollider gets changed.

felixonmars-bot pushed a commit to felixonmars/archlinux-community that referenced this issue Sep 14, 2019
Rebuilding against boost 1.71.0. Adding upstream patch for boost >= 1.70.0.
Adding all direct library dependencies. Adding -DBoost_NO_BOOST_CMAKE=ON, so boost own cmake file won't get used ( supercollider/supercollider#4576 ).

git-svn-id: file:///srv/repos/svn-community/svn@510576 9fca08f4-af9d-4005-b8df-a31f2cc04f65
@brianlheim

This comment has been minimized.

Copy link
Member

@brianlheim brianlheim commented Sep 14, 2019

Thanks for investigating @dvzrv !

It seems, that boost 1.71.0 ships its own cmake file, which takes precedence over cmake's own.

I see. But why should that cause problems here? Are the libraries it exports different somehow?

@dvzrv

This comment has been minimized.

Copy link
Member Author

@dvzrv dvzrv commented Sep 20, 2019

Are the libraries it exports different somehow?

The libraries (probably) not. However, the return values of find_package() are altered.
Once 1.71.0 is out of staging I can dive deeper into this and try to open a pull request for updating it for supercollider.

@brianlheim

This comment has been minimized.

Copy link
Member

@brianlheim brianlheim commented Oct 3, 2019

i am currently unable to build because of mutual incompatibilities among Xcode, cmake, and boost, so i will be submitting a PR that i believe ought to fix this within a few days. I also have notes on what needs to be done in case anyone is interested.

@brianlheim brianlheim mentioned this issue Oct 7, 2019
4 of 4 tasks complete
@brianlheim

This comment has been minimized.

Copy link
Member

@brianlheim brianlheim commented Dec 22, 2019

Closed in #4612

@brianlheim brianlheim closed this Dec 22, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.