[MacPorts] #33006: enhancement: gcc46 variant for R-framework

[MacPorts]

#33006: enhancement: gcc46 variant for R-framework
--------------------------------------+-------------------------------------
 Reporter:  adfernandes@…             |       Owner:  kjell.konis@…      
     Type:  enhancement               |      Status:  new                
 Priority:  Normal                    |   Milestone:                     
Component:  ports                     |     Version:  2.0.3              
 Keywords:  haspatch                  |        Port:  R-framework        
--------------------------------------+-------------------------------------

Comment(by adfernandes@…):

 I understand completely. I have been bitten by the "different pieces
 compiled by different compilers" bug before, and it was a nightmare to
 sort out.

 I believe that some of the old problems were caused by an ABI change in
 gcc back in the early 4-something days. That was horrible. Plus, now I
 believe that for shared objects as long as you link to the correct
 `libgcc_s` initialization library, you should never have a problem
 combining shared objects with an executable no matter the compiler
 version.

 Objective-C is a tricky beast, though. Here we're talking about compiling
 one object via apple's gcc then linking with the gcc runtime... I did a
 `DYLD_PRINT_LIBRARIES=1` for R and used the quartz plotting system as a
 test just now.  The first few entries are
 {{{
 dyld: loaded:
 /opt/local/Library/Frameworks/R.framework/Versions/2.14/Resources/library/grDevices/libs/x86_64/grDevices.so
 dyld: loaded:
 /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
 dyld: loaded:
 /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
 dyld: loaded:
 /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
 ...
 }}}
 Now all of these, including `R`'s `grDevices.so' link to the system
 `/usr/lib/libobjc.A.dylib`.

 I've checked ALL the libraries in ALL of the executable and shared objects
 in the `R` port, and NONE of them link to any of the `/opt/local/lib/gcc46
 /libobjc-gnu.*` files.

 So what I think is happening is that using Apple's objective-c compiler is
 always legal in this case because it always links to Apple's objective-c
 runtime, and not the GNU objective-c runtime by mistake. I '''do''' know,
 from hacking with gcc and clang on mac and linux, that the compiler is
 tightly coupled to the runtime; gcc-objc assumes the gnu-objc runtime,
 apple's compilers assume apple's runtime.

 It appears that, since `grDevices.so` automagically links the apple
 runtime, the apple objective-c gets used to resolve all objective-c link
 references.

 (And it appears that this graphics device is the only part of the R code
 base that uses any objective-c!)

 So... my conclusion is that this appears safe for `gcc46` and the current
 `R-framework` port since the correct libraries and compilers and runtimes
 always seem to link up together.

 Plus... I've been using `R`, `Rcpp`, `Rmpi`, and `rgl` a '''lot''' in the
 past couple of weeks, along with many of my own compiled objects (fortran
 with openmpi), and have never had a crash yet... :-)

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