## LuxRays: build break change in Boost 1.48

Discussion and help for Compilation problems and platform portability.

Moderator: coordinators

### LuxRays: build break change in Boost 1.48

I most recently tried to build LuxRays from source on OSX 10.7.3, with:
- Cmake 2.8.7
- Xcode 4.3.1
- Boost 1.48

In Boost 1.48, there's a change in
Code: Select all
boost::interprocess::detail
where 'detail' namespace has been moved to 'ipcdetail'. This causes:
Code: Select all
luxrays/include/luxrays/utils/core/atomic.h
to fail with:
Code: Select all
/LuxRender/luxrays/include/luxrays/utils/core/atomic.h:47:35: error: no member named 'detail' in namespace 'boost::interprocess'

The Boost change is mentioned here:
[url]http://boost.2283326.n4.nabble.com/1-48-0-beta-1-interprocess-detail-namespace-td3947314.html
[/url]

FIX: I manually modified atomic.h in several places to make it build:
Code: Select all
while (boost::interprocess::detail::atomic_cas32(((boost::uint32_t *)val), newVal.i, oldVal.i) != oldVal.i);

to
Code: Select all
while (boost::interprocess::ipcdetail::atomic_cas32(((boost::uint32_t *)val), newVal.i, oldVal.i) != oldVal.i);

Question:
Is there anything I can do to avoid making changes to atomic.h?
What is the blessed version of Boost?
vinkemp

Posts: 3
Joined: Sat Mar 10, 2012 12:41 am

### Re: LuxRays: build break change in Boost 1.48

vinkemp wrote:In Boost 1.48, there's a change ... where 'detail' namespace has been moved to 'ipcdetail'.

Are you using the current source? I think Dade already fixed that.

vinkemp wrote:What is the blessed version of Boost?

1.47
Linux builds packager

SATtva

Posts: 5487
Joined: Tue Apr 07, 2009 12:19 pm
Location: from Siberia with love

### Re: LuxRays: build break change in Boost 1.48

SATtva wrote:
vinkemp wrote:In Boost 1.48, there's a change ... where 'detail' namespace has been moved to 'ipcdetail'.

Are you using the current source? I think Dade already fixed that.

Ah, nice. My version was a week old. I can verify that the fix is good for compiling with Boost 1.48.

However, and unrelated to this, I'm seeing a lot of warnings like these:
Code: Select all
ld: warning: direct access in __ZN7luxrays7DataSetC2EPKNS_7ContextE to global weak symbol __ZTVN5boost10lock_errorE means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.ld: warning: direct access in __GLOBAL__I_a to global weak symbol __ZTVN5boost21thread_resource_errorE means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.ld: warning: direct access in __ZN7luxrays30NativeThreadIntersectionDeviceD2Ev to global weak symbol __ZTVN5boost10lock_errorE means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.ld: warning: direct access in __ZN7luxrays36VirtualM2OHardwareIntersectionDeviceC2EmPNS_26HardwareIntersectionDeviceE to global weak symbol __ZTVN5boost21thread_resource_errorE means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.ld: warning: direct access in __ZN7luxrays36VirtualM2OHardwareIntersectionDevice19RemoveVirtualDeviceEPNS_18IntersectionDeviceE to global weak symbol __ZTVN5boost10lock_errorE means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.ld: warning: direct access in __ZN7luxrays36VirtualM2OHardwareIntersectionDevice16GetVirtualDeviceEm to global weak symbol __ZTVN5boost10lock_errorE means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.ld: warning: direct access in __ZN7luxrays36VirtualM2OHardwareIntersectionDevice16AddVirtualDeviceEv to global weak symbol __ZTVN5boost10lock_errorE means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.ld: warning: direct access in __ZN7luxrays36VirtualM2OHardwareIntersectionDevice22VirtualM2ODevHInstance10SetDataSetEPKNS_7DataSetE to global weak symbol __ZTVN5boost10lock_errorE means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.ld: warning: direct access in __ZN7luxrays36VirtualM2OHardwareIntersectionDevice22VirtualM2ODevHInstance5StartEv to global weak symbol __ZTVN5boost10lock_errorE means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.ld: warning: direct access in __ZN7luxrays36VirtualM2OHardwareIntersectionDevice22VirtualM2ODevHInstance4StopEv to global weak symbol __ZTVN5boost10lock_errorE means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.ld: warning: direct access in __ZN7luxrays36VirtualM2MHardwareIntersectionDeviceC2EmRKSt6vectorIPNS_26HardwareIntersectionDeviceESaIS3_EE to global weak symbol __ZTVN5boost21thread_resource_errorE means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.ld: warning: direct access in __ZN7luxrays36VirtualM2MHardwareIntersectionDevice19RemoveVirtualDeviceEPNS_18IntersectionDeviceE to global weak symbol __ZTVN5boost10lock_errorE means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.ld: warning: direct access in __ZN7luxrays36VirtualM2MHardwareIntersectionDevice16AddVirtualDeviceEv to global weak symbol __ZTVN5boost10lock_errorE means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.ld: warning: direct access in __ZN7luxrays36VirtualM2MHardwareIntersectionDevice22VirtualM2MDevHInstance10SetDataSetEPKNS_7DataSetE to global weak symbol __ZTVN5boost10lock_errorE means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.ld: warning: direct access in __ZN7luxrays36VirtualM2MHardwareIntersectionDevice22VirtualM2MDevHInstance5StartEv to global weak symbol __ZTVN5boost10lock_errorE means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.ld: warning: direct access in __ZN7luxrays36VirtualM2MHardwareIntersectionDevice22VirtualM2MDevHInstance4StopEv to global weak symbol __ZTVN5boost10lock_errorE means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.

Should I be concerned? Sorry for being a n00b here but I'm trying to get into the code.
vinkemp

Posts: 3
Joined: Sat Mar 10, 2012 12:41 am

### Re: LuxRays: build break change in Boost 1.48

vinkemp wrote:

Should I be concerned? Sorry for being a n00b here but I'm trying to get into the code.

Since we control visibility for luxrays/lux to avoid global symbol conflicts you must compile boost with cxxflags='-fvisibility=hidden -fvisibility-inlines-hidden' and the warnings go away.

Jens

jensverwiebe

Posts: 2124
Joined: Wed Apr 02, 2008 4:34 pm

### Re: LuxRays: build break change in Boost 1.48

i may be being an idiot here, but I've deleted all of the dev stuff I had and have re-downloaded it. As in, completely cleared out the folder that I had all the sources, dependencies, etc. in. However, I have noticed that when I used get-deps.bat, it downloaded Boost 1.43.

I know this is about OSX, and I have Windows XP, but is this intended?
Pilchard123

Posts: 406
Joined: Sun Oct 30, 2011 8:05 am

### Re: LuxRays: build break change in Boost 1.48

I think we need Lord Crc to update Windows compilation scripts to use boost-1.47.
Linux builds packager

SATtva

Posts: 5487
Joined: Tue Apr 07, 2009 12:19 pm
Location: from Siberia with love

### Re: LuxRays: build break change in Boost 1.48

Well, we're kinda in the middle of a transition here. We've put out some weeklies with 1.47, but it's not final that we're staying with 1.47, though it is looking good so far.
May contain traces of nuts.

Lord Crc

Posts: 4447
Joined: Sat Nov 17, 2007 2:10 pm