[MacPorts] #35172: boost @ 1.50 - Error Building boost

[MacPorts]

#35172: boost @ 1.50 - Error Building boost
-----------------------------------+----------------------------------------
 Reporter:  notinmyhead@…          |       Owner:  adfernandes@…           
     Type:  defect                 |      Status:  new                     
 Priority:  Normal                 |   Milestone:                          
Component:  ports                  |     Version:  2.1.1                   
 Keywords:                         |        Port:  boost                   
-----------------------------------+----------------------------------------

Comment(by adfernandes@…):

 Heh. I've hit this problem (mixing ABIs) before, a few years ago. I think
 that the people-who-do-things-like-ABIs got it all straightened out now,
 but back in the day, you are correct, it was a nightmare.

 My understanding is that as long as you link libgcc into your final shared
 object, and the shared object is all compiled by '''one''' complier,
 mixing objects across compilers is not ''supposed'' to be an issue
 anymore.

 Note heavy use of the word "should". :-)

 Hmm... think I can change the `depends_lib` to `depends_build` if I use
 `-static-libgcc  -static-libstdc++` when building.

 Then any "subtle runtime effects" are because the auto-figure-it-out-logic
 in the headers does not match the options used to compile the libraries.

 However... my view is that if headers don't match compiled libraries,
 that's a bug in the library. Any compile-time option that changes the
 semantics of compiled code should he hard-coded into the headers, and not
 guessed. You simply can't assume, given a shared object, that future
 compiles will use the same compiler.

 The portgroup is a nice idea, but too many software packages require boost
 as a dependency. Having to maintain many different boosts... ouch. I don't
 even want to think about it.

 Let me update the patch for the static-libgcc build. Okay. Scratch that.
 Boost specifically forbids static linking of the gcc runtime with dynamic
 objects, using their typical smart-ass commenting style "such a
 combination is too dangerous to be of use". So depends_lib and not
 depends_build it is.

 The above patch is all there is.

 Please feel free to chime in, everyone!

-- 
Ticket URL: <https://trac.macports.org/ticket/35172#comment:7>
MacPorts <http://www.macports.org/>
Ports system for Mac OS