Multiple Extensions Failing To Build For Mac

• Multiple Extensions Failing To Build For Macbook Pro
• Multiple Extensions Failing To Build For Machine

Variations of this question almost always describe a tedious one-at-a-time 'Get Info' process to check or uncheck 'hide extension', OR to use a hammer approach by using Finder -> Preferences -> Advanced -> Show all file extensions. I've found a way to deal with batches of files all at once, using Terminal.app with a single command line.

It's an odd error that I'm not able to replicate. So this is a bit of stabbing in the dark.

The tip from is spot on for installing jazzy with the stock ruby. I wonder if it's to do with the selected Xcode?

To check which of the versions is selected use: xcode-select -print-path # Example output: # /Applications/Xcode.app/Contents/Developer And double check with xcodebuild -version # Example output: # Xcode 7.3.1 # Build version 7D1014 I'm wondering if the latest Xcode needs to be selected for you to install jazzy. You can switch the selected Xcode with: (replacing Xcode2 with your other Xcode) sudo xcode-select -switch /Applications/Xcode2.app/Contents/Developer Then try installing jazzy again: gem install activesupport -v '.

Having the same issue: UliBoxBook: uli$ sudo gem install activesupport -v '. I see the same issue on Mojave 10.14.1, just as reported.

Multiple Extensions Failing To Build For Macbook Pro

This is a new machine, it has only ever had Xcode 10.1 installed. Make:. No rule to make target `/System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/include/ruby-2.3.0/universal-darwin18/ruby/config.h', needed by `autolink.o'. Looking in /System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/include/ruby-2.3.0/, I see that there is no universal-darwin18 directory, only universal-darwin17.

Does anyone know why it would be looking for for universal-darwin18 and unable to use universal-darwin17? I will also report this to the redcarpet maintainers, since this also happens when I run gem install redcarpet.

It's time for all Ruby developers to confront their worst fear. One of the scariest moments in the life of a Ruby developer is seeing that dreaded message appear as you try to install a new gem: Building native extensions. This could take a while. As the console output suddenly hangs, you feel a horrible, sinking sensation of fear in your stomach: something truly bad is about to happen! Then your worse nightmare comes true: in the console you get: ERROR: Failed to build gem native extension. Now you’re condemned to spending hours googling for obscure compiler flags, environment settings or Linux package info – and not doing Ruby development. For years I’ve been nervous installing gems that contained native extensions because I wasn’t familiar with the gem extension build process, and had no idea where to begin when something went wrong.

Today I’m going to confront my own worst fears – and yours – by taking a closer look at what “Building native extensions” actually means. After reviewing how the build process works, I’ll give you some advice that will hopefully point you in the right direction the next time you run into a problem. What are native extensions anyway?

Before we get to what might go wrong building native extensions, let’s take a look at what native extensions are and why Ruby developers need them. “Native extensions” are the glue that connects a Ruby gem with some other non-Ruby software component or library present on your machine.

Here’s a simple diagram that shows the relationship between a Ruby gem and some software it uses: The native extension is some C code that’s included inside the Ruby gem that calls the external component’s API, converting the parameters and return values between the format the external library needs and what the Ruby interpreter expects. Native extensions are one of the reasons for the success of the Ruby platform, since they allow Ruby gem authors to take advantage of non-Ruby libraries when appropriate in an organized, standard way. This means that Ruby gem authors can use Ruby to do what Ruby is best at, but switch to C or some other programming language or library when that makes sense. Here’s what the directory structure looks like for a Ruby gem that contains native extension code: What’s the process for building a native extension? The power of native extensions is also their biggest challenge. Since the extension code itself is written in C, it needs to be compiled into machine language for your specific platform and environment before you can use it. Rubygems provides a standard process for doing this; here’s what that looks like: This is what’s actually happening while you’re reading the message Building native extensions.

This could take a while. The first step, shown at the top, is to run a Ruby script called “extconf.rb.” This is included in the ext/GEMNAME folder by the Ruby gem author, and is responsible for generating the C Makefile used in the next step. Extconf.rb inspects your laptop or server to find out what platform you have, what type of C compiler you have, which libraries are present and where they are located. The Makefile that it generates will then contain just the right C compiler settings you need to compile the gem’s C extension code – the gem author needs to write extconf.rb properly to guarantee this is always the case. Once the Makefile is generated, Rubygems runs the make command in the ext/GEMNAME folder, causing your C compiler to be executed on each C code file present there, with all of the proper flags and settings. After all of the C code files are compiled, the Makefile also runs the C linker to build the new gem extension executable file. Finally, the last step is to install the new native executable file into the proper directory, using the make install command.

Now when the Ruby code in the gem calls a function implemented in the C extension code, the Ruby interpreter will be able to find the new native executable file. If you’re interested in the details, you can try using the —verbose option the next time you install a gem containing native extensions, for example. $ gem install sqlite3 -verbose Conquering your fear: what to do when there’s an error With so many different steps in the native extensions build process, there’s a good chance that something will go wrong. But what truly puts fear into our hearts is that whatever problems come up will have nothing to do with Ruby or anything about our Rails application, but instead will have to do with the obscure technical details of the external library we’re compiling against, or with the very low-level technical details or configuration of our computer. But don’t lose hope, there are a few fairly simple things you can do after getting an error compiling native extensions that will often solve or at least avoid the problem you’ve run into. Let’s start with the most obvious, and the most effective way to avoid native extension terror Always use Homebrew or your Linux platform’s package manager The most common problem you’ll run into while compiling native extension code is that either you’re missing the external library the code depends on entirely, or that it’s installed into the wrong place. For example, here’s what you’ll get if you try to install the “mysql2” gem but forgot that you’ve never installed MySQL itself onto your new Mac laptop.

$ gem install mysql2 Building native extensions. This could take a while.

Successfully installed mysql2-0.3.7 Of course, if you’re using Windows there’s no standard package manager and you have no choice but to install MySQL with a pre-built, binary install kit. This makes it less likely that the Rubygems native extensions compile process will find the package, and the compiler might depend on the PATH or other system settings to find the header and library files it needs. Using gems with native extensions on Windows is truly horrifying! Look for a missing or incorrect configuration flag If you have the package or server your gem depends on but the native extensions still don’t compile properly, then there might be some configuration settings that you need to provide in order for the C compiler to work.

Multiple Extensions Failing To Build For Machine

Usually these options indicate where some target package is located on your machine; they might also indicate your machine’s architecture (32 vs. 64 bit) or other things.

For example, if you want to use the “R” statistical programming language in your Ruby app, then you might try to install the rsruby gem like this. Gem install xyzgem - -with-some=/path/i/need/to/provide The first two dashes separate the Rubygems options from the C compiler options passed to the native extensions process. If there’s not a lot of documentation for the gem you’re trying to install, then googling for each one of the available options listed in the console output will often take you to a StackOverflow or other discussion containing the magic setting you need to add.

As a last resort you can dive in and just read the Ruby code inside extconf.rb to see what it’s looking for. Extconf.rb uses the to generate the C Makefile, but even if you’re not familiar with mkmf most of the code you’ll find in extconf.rb will be fairly easy to understand, listing which directories to search in, which C header or library files to look for, etc. Usually there will be some clue here leading you in the right direction. Note: if you’re using Bundler and don’t actually type in the gem install commands manually like this, you can specify these extension code settings using the bundler config command line like this. Bundle config build.rsruby -with-R-dir=/usr/local/Cellar/r/2.13.2/R.framework/Resources Now everytime you run bundler on this machine, it will include the proper options for building the native extensions for rsruby, every time rsruby is installed again. This will most likely happen if you run bundle upgrade and get a newer version of rsruby, for example.

FYI these config settings are saved in the “/.bundle/config” file. For more details see the. You’re not out of the woods yet remember to set environment variables! Ok – you finally got your native extensions to compile properly, and the gem installed.

Now you’re finally out of the woods and ready to get back to the Ruby development you were planning to do two hours ago, right? Before continuing, double check whether the server or package you just installed to work with your new gem also requires some environment variables to be set.

Ironically, these are often the same values, such as directory paths, that you needed to set using a gem install or bundle config option. For example, the gem install command above will get the rsruby gem built and installed. But the R interpreter won’t actually work until you set the “RHOME” environment variable properly.