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

Postby vinkemp » Sat Mar 10, 2012 1:00 am

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

Postby SATtva » Sat Mar 10, 2012 1:11 am

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
聞くのは一時の恥、聞かぬのは一生の恥
User avatar
SATtva
Developer
 
Posts: 5487
Joined: Tue Apr 07, 2009 12:19 pm
Location: from Siberia with love

Re: LuxRays: build break change in Boost 1.48

Postby vinkemp » Sat Mar 10, 2012 5:01 am

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

Postby jensverwiebe » Sat Mar 10, 2012 5:11 am

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
User avatar
jensverwiebe
Developer
 
Posts: 2124
Joined: Wed Apr 02, 2008 4:34 pm

Re: LuxRays: build break change in Boost 1.48

Postby Pilchard123 » Sun Mar 11, 2012 2:31 am

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

Postby SATtva » Sun Mar 11, 2012 2:39 am

I think we need Lord Crc to update Windows compilation scripts to use boost-1.47.
Linux builds packager
聞くのは一時の恥、聞かぬのは一生の恥
User avatar
SATtva
Developer
 
Posts: 5487
Joined: Tue Apr 07, 2009 12:19 pm
Location: from Siberia with love

Re: LuxRays: build break change in Boost 1.48

Postby Lord Crc » Sun Mar 11, 2012 8:52 am

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.
User avatar
Lord Crc
Developer
 
Posts: 4447
Joined: Sat Nov 17, 2007 2:10 pm


Return to Compilation & Portability

Who is online

Users browsing this forum: No registered users and 1 guest