CGALConfig.cmake contains incorrect boost libraries path

[Martin Uhrin]

The CGAL CMake config file (/usr/lib/CGAL/CGALConfig.cmake) contains the pre-saucy boost library paths. Specifically line 53:

set(CGAL_3RD_PARTY_LIBRARIES "/usr/lib/libboost_thread.so;/usr/lib/libboost_system.so;/usr/lib/x86_64-linux-gnu/libpthread.so" )

On 64-bit systems, the boost libraries now reside in /usr/lib/x86_64-linux-gnu

so the line should read:

set(CGAL_3RD_PARTY_LIBRARIES "/usr/lib/x86_64-linux-gnu/libboost_thread.so;/usr/lib/x86_64-linux-gnu/libboost_system.so;/usr/lib/x86_64-linux-gnu/libpthread.so" )

There may be other problems with the cmake config files but regenerating them all from CMake on a 13.10 system should fix all the issues.

Tested on: Ubuntu 13.10

Expected: When using FindCGAL in a project it should build correctly.

What happens: The compiler complains that it can't find /usr/lib/libboost_thread.so at link time.

[Giampiero Salvi (giampisalvi)]

I had the same problem trying to build dionysus
http://www.mrzv.org/software/dionysus/python/overview.html
on Ubuntu 13.04, cmake version 2.8.11.2.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[José Ignacio Carmona Villegas (zalioth)]

Is there any quick fix for this bug? I'm working on a project that uses CGAL and can't compile. How can I rebuild the package myself changing the path to the correct one (64b)?

[Martin Uhrin (martin-uhrin)]

The quickets way is to make the change to line 53 in /usr/lib/CGAL/CGALConfig.cmake that I've suggested in the original post.

[José Ignacio Carmona Villegas (zalioth)]

I've done that already, but it still does not work. I am confused, since it still keeps giving me the exact same message.
By the way, thank you so very much for taking the time to help me.

[Martin Uhrin (martin-uhrin)]

No worries. So try two things:

1) Check that the boost libraries are in the same place that they are on my system (should be as you're on 64-bit), type:

locate libboost_thread.so

This should come up with /usr/lib/x86_64-linux-gnu/libboost_thread.so (and possibly other results). Check libboost_system.so libpthread.so similarly, I suspect they'll all be in the same place as mine.

2) (more likely to work) Delete CMakeCache.txt in your project build directory and regenerate (i.e. cmake [whatever]). The old entry (CGAL_3RD_PARTY_LIBRARIES) is likely to be saved in your cache from before you made the changes I suggested.

-Martin

[José Ignacio Carmona Villegas (zalioth)]

2) Already thought of that. I purged all cmake generated files from the project and regenerated them after changing the aforementioned entry.

1) I've been searching for the .so files corresponding to the libboost and are the following:

~$ apt-file search /usr/lib/libboost_thread.so
libboost-thread1.49-dev: /usr/lib/libboost_thread.so
libboost-thread1.49.0: /usr/lib/libboost_thread.so.1.49.0
libboost-thread1.54-dev: /usr/lib/libboost_thread.so
libboost-thread1.54.0: /usr/lib/libboost_thread.so.1.54.0
libboost1.49-dbg: /usr/lib/debug/usr/lib/libboost_thread.so.1.49.0

~$ apt-file search /usr/lib/x86_64-linux-gnu/libboost_thread.so
libboost-thread1.53-dev: /usr/lib/x86_64-linux-gnu/libboost_thread.so
libboost-thread1.53.0: /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.53.0

Apparently I have two versions of them in /usr/lib, and one version in /usr/lib/x86_64-linux-gnu

I could try purging them all and installing only one of them, Do you think that would work?

[Martin Uhrin (martin-uhrin)]

Interesting. It might be worth checking exactly what CGAL is linking to:

ldd /usr/lib/libCGAL.so

and using the correct ones from here in the config file. Could you
paste a copy of the error message you're getting?

On 16 January 2014 15:33, José Ignacio Carmona Villegas
<email address hidden> wrote:
> 2) Already thought of that. I purged all cmake generated files from the project and regenerated them after changing the aforementioned entry.
>
> 1) I've been searching for the .so files corresponding to the libboost
> and are the following:
>
> ~$ apt-file search /usr/lib/libboost_thread.so
> libboost-thread1.49-dev: /usr/lib/libboost_thread.so
> libboost-thread1.49.0: /usr/lib/libboost_thread.so.1.49.0
> libboost-thread1.54-dev: /usr/lib/libboost_thread.so
> libboost-thread1.54.0: /usr/lib/libboost_thread.so.1.54.0
> libboost1.49-dbg: /usr/lib/debug/usr/lib/libboost_thread.so.1.49.0
>
> ~$ apt-file search /usr/lib/x86_64-linux-gnu/libboost_thread.so
> libboost-thread1.53-dev: /usr/lib/x86_64-linux-gnu/libboost_thread.so
> libboost-thread1.53.0: /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.53.0
>
>
> Apparently I have two versions of them in /usr/lib, and one version in /usr/lib/x86_64-linux-gnu
>
> I could try purging them all and installing only one of them, Do you
> think that would work?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1242111
>
> Title:
> CGALConfig.cmake contains incorrect boost libraries path
>
> Status in “cgal” package in Ubuntu:
> Confirmed
>
> Bug description:
> The CGAL CMake config file (/usr/lib/CGAL/CGALConfig.cmake) contains
> the pre-saucy boost library paths. Specifically line 53:
>
> set(CGAL_3RD_PARTY_LIBRARIES
> "/usr/lib/libboost_thread.so;/usr/lib/libboost_system.so;/usr/lib/x86_64
> -linux-gnu/libpthread.so" )
>
> On 64-bit systems, the boost libraries now reside in /usr/lib/x86_64
> -linux-gnu
>
> so the line should read:
>
> set(CGAL_3RD_PARTY_LIBRARIES "/usr/lib/x86_64-linux-
> gnu/libboost_thread.so;/usr/lib/x86_64-linux-
> gnu/libboost_system.so;/usr/lib/x86_64-linux-gnu/libpthread.so" )
>
> There may be other problems with the cmake config files but
> regenerating them all from CMake on a 13.10 system should fix all the
> issues.
>
> Tested on: Ubuntu 13.10
>
> Expected: When using FindCGAL in a project it should build correctly.
>
> What happens: The compiler complains that it can't find
> /usr/lib/libboost_thread.so at link time.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/cgal/+bug/1242111/+subscriptions

--
Are you worried by the NHS reforms being put through by the coalition
government at the moment? Check out whosupportsnhsreforms.org.uk for
a snapshot of the debate.

[José Ignacio Carmona Villegas (zalioth)]

This is the compile error I get:

make[2]: *** No rule to make target `/usr/lib/libboost_thread.so', needed by `stippling'. Stop.
make[1]: *** [CMakeFiles/stippling.dir/all] Error 2
make: *** [all] Error 2

I have changed the file /usr/lib/CGAL/CGALConfig.cmake as follows:

#set(CGAL_3RD_PARTY_LIBRARIES "/usr/lib/libboost_thread.so;/usr/lib/libboost_system.so;/usr/lib/x86_64-linux-gnu/libpthread.so" )
set(CGAL_3RD_PARTY_LIBRARIES "/usr/lib/x86_64-linux-gnu/libboost_thread.so;/usr/lib/x86_64-linux-gnu/libboost_system.so;/usr/lib/x86_64-linux-gnu/libpthread.so" )

This is the result of the call to "ldd /usr/lib/libCGAL.so":

~$ ldd /usr/lib/libCGAL.so
 linux-vdso.so.1 => (0x00007ffff21fe000)
 libboost_thread.so.1.53.0 => /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.53.0 (0x00007f451fb35000)
 libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f451f918000)
 libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f451f613000)
 libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f451f30f000)
 libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f451f0f9000)
 libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f451ed30000)
 libboost_system.so.1.53.0 => /usr/lib/x86_64-linux-gnu/libboost_system.so.1.53.0 (0x00007f451eb2c000)
 librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f451e924000)
 /lib64/ld-linux-x86-64.so.2 (0x00007f451ff94000)

It seems it's calling to the 1.53.0 version, so it shouldn't be a problem due to interference among two versions...

[José Ignacio Carmona Villegas (zalioth)]

It's working now. I specified the right file as you indicated and everything worked smooth.

Thank you so very much for helping me finding the cause of this problem.

[Martin Uhrin (martin-uhrin)]

Excellent. Glad we could get it sorted. Hopefully at some point the config file will be regenerated in a future version of the package.