Ticket #82 (closed enhancement: fixed)

Opened 2 years ago

Last modified 1 year ago

scons-addon boost library test

Reported by: jsd Assigned to: unassigned
Priority: blocker Milestone: 2.0 Beta
Component: Build Version: 2.0
Keywords: Cc:
Completion:

Description

on fc5 using boost/boost-devel rpms scons-adon does not find boost libraries. this is because the rpms by the fedora project strip toolchain information from the boost library names, e.g.

searched: boost_filesystem-gcc-mt

available: libboost_filesystem.[a|so.1.33.1|.2]

there's some work underway to provide the correct rpm specs to the fedora (or any other rpm-based) project; see http://archives.free.net.ph/thread/20060908.202855.1f49e09a.en.html#20060908.202855.1f49e09a

as a workaround i would propose to add code to Tools/scons-addons/src/SConsAddons/Options/Boost.py

to the effect that after the initial library test fails the simpler, stripped name version used by the fedora project is tested for.

Attachments

scons-addons-boost-py.diff (4.1 kB) - added by jsd on 10/06/06 13:36:42.
scons-addons-boost-py.2.diff (4.3 kB) - added by jsd on 12/15/06 06:44:36.
update wrt. current SConstruct

Change History

10/06/06 13:36:42 changed by jsd

  • attachment scons-addons-boost-py.diff added.

10/06/06 13:38:10 changed by jsd

added scons-addons-boost-py.diff which shows a workaround implementation

10/06/06 14:00:11 changed by allenb

There is one additional complexity here. The last time I checked the version of boost installed by redhat is not the multi-thread safe version. So I am not entirely sure if it would be safe for OpenSG to use the version that is found.

We have been handling it by using a custom rpm that adds the multi-thread version to the system.

I know other people use boost with OpenSG projects, how do you deal with this?

10/07/06 14:28:25 changed by anonymous

  • priority changed from major to blocker.

Do we need boost mt-safety? We do handle the safety of all out own operations separately, so unless somebodu uses boost mt-unsafely I'm not sure how much of a problem that is.

However, not being able to compile without installing non-standard RPMs is a serious problem that needs to be solved. The patch seems to help, but I would make the workaround the default. If OpenSG does not compile out of the box without esoteric scons options on one of the core distributions we're screwed.

(follow-up: ↓ 5 ) 10/07/06 16:34:28 changed by cneumann

Here on Debian the boost libraries are named as follows:

  • libboost_filesystem-gcc-1_33_1.so → libboost_filesystem-gcc-1_33_1.so.1.33.1
  • libboost_filesystem-gcc-1_33_1.so.1.33.1

(in reply to: ↑ 4 ; follow-up: ↓ 6 ) 10/07/06 17:25:18 changed by allenb

Replying to cneumann:

Here on Debian the boost libraries are named as follows:

* libboost_filesystem-gcc-1_33_1.so → libboost_filesystem-gcc-1_33_1.so.1.33.1

* libboost_filesystem-gcc-1_33_1.so.1.33.1

Are these the multi-thread or single-thread versions? It looks like they share the same problem as redhat in that you can't tell which version the distribution included.

(in reply to: ↑ 5 ) 10/08/06 04:20:37 changed by cneumann

Replying to allenb:

Replying to cneumann:

Here on Debian the boost libraries are named as follows:

* libboost_filesystem-gcc-1_33_1.so → libboost_filesystem-gcc-1_33_1.so.1.33.1

* libboost_filesystem-gcc-1_33_1.so.1.33.1

Are these the multi-thread or single-thread versions? It looks like they share the same problem as redhat in that you can't tell which version the distribution included.

These are the single thread versions. The complete picture is like this:

  • libboost_filesystem-gcc-1_33_1.so → libboost_filesystem-gcc-1_33_1.so.1.33.1
  • libboost_filesystem-gcc-1_33_1.so.1.33.1
  • libboost_filesystem-gcc-mt-1_33_1.so → libboost_filesystem-gcc-mt-1_33_1.so.1.33.1
  • libboost_filesystem-gcc-mt-1_33_1.so.1.33.1
  • libboost_filesystem.so → libboost_filesystem-gcc-mt-1_33_1.so

12/15/06 06:44:36 changed by jsd

  • attachment scons-addons-boost-py.2.diff added.

update wrt. current SConstruct

12/15/06 06:46:54 changed by jsd

  • estimated_completion changed.

i have added a second diff that prefers simple libnames over the version request from SConstruct.

01/05/07 17:11:54 changed by allenb

  • status changed from new to closed.
  • resolution set to fixed.

This is now fixed in r473. The boost options code will now fallback to less explicit library file names.