Boost is completely broken in many linux distros...

[ghost]

...such as CentOS. For those of us with a c10t version that works perfectly and for whom upgrading is a huge pain in the ass, do you think you could keep an up to date palette (-W) file in the toolchain site, please?

[Psithief]

/agree

I actually have no idea what any of that means but I am in favour of anything that makes it easier to run this on CentOS.

[ghost]

c10t can create a palette file which you can then use for loading the colors for missing blocks ina previous version. I can't find anyone running a recent version who can send me an up to date palette so my maps stop rendering half the blocks as black dots, and I don't have enough time to custom-write the palette myself.

[erisdev]

@Protected you should file a bug report with your Linux distribution if they're shipping broken packages. Inexcusable, especially for popular packages like boost.

[ghost]

I don't know any of the particulars about when the bug happens, I've only ever seen it in c10t. CentOS is a stable conservative distro so it takes them forever to upgrade. It has an older version of boost; I'm pretty sure the latest version would work if I could compile it at all.

[erisdev]

Ugh, conservative distributions. I'd hate to see what version of Ruby they're shipping when everybody else is still on 1.8.7 (the current stable version is 1.9.3 and has been 1.9.x for a long time now).

I wonder what c10t depends on that requires a newer version of boost, and if it could be made to work with an older version without a loss of function and without too much work… If you manage to get c10t working with an older boost, consider submitting a pull request.

[ghost]

If I remember correctly it was some issue with locale names that was fixed in boost 2 versions ago.

[ghost]

Oops.

[Tmkrth]

Hello. Shall I send you a palette file? I could create one on a today compiled c10t.

[ghost]

Hello. Actually, someone already did and the old version seems to complain about the names (I thought it read the materials in order but maybe I was wrong). Thanks anyway. Later I'll try to replace all the names with numbers.

[udoprog]

I've completely giving up using the boost dev packages on most platforms, luckily it's quite easy setting up an environment yourself.

How to work with boost is documented in http://www.boost.org/doc/libs/1_48_0/more/getting_started/unix-variants.html#invoke-b2

There are also doc pages for windows if I remember correctly.

[dayne]

latest version of c10t works fine on CentOS 6without any custom Boost work.

If you are on CentOS 5 you could look at using EPEL to get boost1.41 which is what I'm rolling with by default from CentOS 6 and RHEL 6.

http://fedoraproject.org/wiki/EPEL

http://download.fedoraproject.org/pub/epel/5/i386/epel-release-5-4.noarch.rpm

Adding EPEL to your machine should be fairly safe unless you've already enabled other 3rd party repositories, in which case tread with care as EPEL might clomp all over them (they don't expect to share with other repos).

[Psithief]

This is what I get when I run find / -iname *boost* after installing boost141 from epel.

./usr/include/c++/4.1.1/tr1/boost_shared_ptr.h
./usr/include/c++/4.1.1/bits/boost_concept_check.h
./usr/share/doc/boost141-system-1.41.0
./usr/share/doc/boost141-date-time-1.41.0
./usr/share/doc/boost141-filesystem-1.41.0
./usr/share/doc/boost141-serialization-1.41.0
./usr/share/doc/boost141-regex-1.41.0
./usr/share/doc/boost141-program-options-1.41.0
./usr/share/doc/boost141-iostreams-1.41.0
./usr/share/doc/boost141-wave-1.41.0
./usr/share/doc/boost141-graph-1.41.0
./usr/share/doc/boost141-python-1.41.0
./usr/share/doc/boost141-test-1.41.0
./usr/share/doc/boost141-thread-1.41.0
./usr/share/doc/boost141-signals-1.41.0
./usr/share/cmake/Modules/FindBoost.cmake
./usr/lib64/libboost_filesystem-mt.so.5
./usr/lib64/libboost_graph-mt.so.5
./usr/lib64/libboost_date_time-mt.so.5
./usr/lib64/libboost_regex-mt.so.5
./usr/lib64/libboost_wserialization-mt.so.5
./usr/lib64/libboost_date_time.so.5
./usr/lib64/libboost_system.so.5
./usr/lib64/libboost_unit_test_framework-mt.so.5
./usr/lib64/libboost_iostreams-mt.so.5
./usr/lib64/libboost_prg_exec_monitor.so.5
./usr/lib64/libboost_system-mt.so.5
./usr/lib64/libboost_signals-mt.so.5
./usr/lib64/libboost_prg_exec_monitor-mt.so.5
./usr/lib64/libboost_iostreams.so.5
./usr/lib64/libboost_python.so.5
./usr/lib64/libboost_regex.so.5
./usr/lib64/libboost_signals.so.5
./usr/lib64/libboost_unit_test_framework.so.5
./usr/lib64/libboost_graph.so.5
./usr/lib64/libboost_thread-mt.so.5
./usr/lib64/libboost_serialization.so.5
./usr/lib64/libboost_wave-mt.so.5
./usr/lib64/libboost_program_options.so.5
./usr/lib64/libboost_wserialization.so.5
./usr/lib64/libboost_python-mt.so.5
./usr/lib64/libboost_filesystem.so.5
./usr/lib64/libboost_program_options-mt.so.5
./usr/lib64/libboost_serialization-mt.so.5

The stuff in the wiki did not work, but I don't know what it expects.

SET(BOOST_ADDITIONAL_VERSIONS "1.41" "1.41.0")
SET(BOOST_ROOT "/usr/include/boost141")
SET(BOOST_LIBRARYDIR "/usr/lib64/boost141")

How do I rearrange these to make it work?

[dayne]

You are probably missing the development libraries: boost-devel (or boost141-devel in your case).

On my RHEL 6 box I have the following:

rpm -qa | grep boost
boost-thread-1.41.0-11.el6_1.2.x86_64
boost-program-options-1.41.0-11.el6_1.2.x86_64
boost-system-1.41.0-11.el6_1.2.x86_64
boost-python-1.41.0-11.el6_1.2.x86_64 
boost-devel-1.41.0-11.el6_1.2.x86_64
boost-test-1.41.0-11.el6_1.2.x86_64
boost-date-time-1.41.0-11.el6_1.2.x86_64
boost-wave-1.41.0-11.el6_1.2.x86_64
boost-serialization-1.41.0-11.el6_1.2.x86_64
boost-1.41.0-11.el6_1.2.x86_64
boost-filesystem-1.41.0-11.el6_1.2.x86_64
boost-signals-1.41.0-11.el6_1.2.x86_64
boost-regex-1.41.0-11.el6_1.2.x86_64
boost-iostreams-1.41.0-11.el6_1.2.x86_64
boost-graph-1.41.0-11.el6_1.2.x86_64

[Psithief]

That totally fixed it. Thanks.

[udoprog]

Reopen if you wanna discuss more : ).