[ https://issues.apache.org/jira/browse/THRIFT-2219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13801459#comment-13801459 ]
Ben Nham edited comment on THRIFT-2219 at 10/22/13 4:26 AM: ------------------------------------------------------------ The issue is that in Mavericks, strlcpy is now defined as a macro if you install the SDK. This conflicts with the duplicate declaration of strlcpy as a function in strlcpy.h. The fix should be simple: don't re-declare the strlcpy prototype in strlcpy.h. Just remove that line, since <string.h> is guaranteed to have declared strlcpy declared already--this is tested for already in lib/rb/ext/extconf.rb via the call to have_func("strlcpy", "string.h"). As a temporary fix for folks using gems, you can try setting the #define'ing the _FORTIFY_SOURCE macro to 0 to make strlcpy a function rather than a macro: $ gem install --with-cppflags='-D_FORTIFY_SOURCE=0' or if you're using bundler, you can set the cflags for thrift locally via: $ bundle config build.thrift --with-cppflags='-D_FORTIFY_SOURCE=0' The workaround uses with-cppflags rather than with-cflags since since thrift's extconf.rb overwrites the $cflags global with its own stuff, but leaves $cppflags alone. Ruby's mkmf.rb passes both $cflags and $cppflags along to the compiler so this slightly hacky workaround seems to work. was (Author: nham): The issue is that in Mavericks, strlcpy is now defined as a macro if you install the SDK. This conflicts with your duplicate declaration of strlcpy as a function in strlcpy.h. The fix should be simple: don't re-declare the strlcpy prototype in strlcpy.h. Just remove that line, since <string.h> is guaranteed to have declared strlcpy declared already--you tested for this in lib/rb/ext/extconf.rb via the call to have_func("strlcpy", "string.h"). As a temporary fix for folks using gems, you can try setting the #define'ing the _FORTIFY_SOURCE macro to 0 to make strlcpy a function rather than a macro: $ gem install --with-cppflags='-D_FORTIFY_SOURCE=0' or if you're using bundler, you can set the cflags for thrift locally via: $ bundle config build.thrift --with-cppflags='-D_FORTIFY_SOURCE=0' The workaround uses with-cppflags rather than with-cflags since since thrift's extconf.rb overwrites the $cflags global with its own stuff, but leaves $cppflags alone. Ruby's mkmf.rb passes both $cflags and $cppflags along to the compiler so this slightly hacky workaround seems to work. > Thrift gem fails to build on OS X Mavericks with 1.9.3 rubies > ------------------------------------------------------------- > > Key: THRIFT-2219 > URL: https://issues.apache.org/jira/browse/THRIFT-2219 > Project: Thrift > Issue Type: Bug > Components: Ruby - Library > Affects Versions: 0.9.1 > Environment: OS X Mavericks (GM), ruby 1.9.3-p448 built with > rbenv/ruby-build > Reporter: Chris Anderson > Fix For: 0.9.2 > > > (Preface, this issue is for the unreleased OS X Mavericks, so understand if > it's not fixable now, just wanted to bring it up.) > I'm unable install the 0.9.1 thrift gem on my GM OS X Mavericks system with > ruby 1.9.3-p448. I get the error `extconf.rb:25: Use RbConfig instead of > obsolete and deprecated Config.` along with some strlcopy errors. > Strack trace is at (https://gist.github.com/chrismanderson/6834809) > Oddly, I CAN install the 0.9.1 gem with both 2.0.0-p247 and > ree-1.8.7-2011.12. I also tried 1.9.3-p194 and p429 and got the same error. -- This message was sent by Atlassian JIRA (v6.1#6144)