I've recently decided to look at an old Rails app running Ruby 1.9.2 and decided to try to install 1.9.2 on my macOS 10.13 machine.
I'm aware that gcc no longer ships with macOS so I remembered the old trick of using Homebrew Core's apple-gcc42 recipe, sadly the maximum version this works with is 10.9 (Mavericks). I tried my luck anyway and even followd rbenv's gcc compatibility notes:
(Note that Ruby < 2.0 does not have the with-readline-dir flag; use with-opt-dir instead.)
I tried the following command (note that I have rbenv's ruby-build plugin installed and up-to-date):
RUBY_CONFIGURE_OPTS="--with-opt-dir=/usr/local/opt/" CC=/usr/local/bin/gcc-4.2 rbenv install 1.9.2-p180
ruby-build: use libyaml from homebrew
Downloading ruby-1.9.2-p180.tar.bz2...
-> https://cache.ruby-lang.org/pub/ruby/1.9/ruby-1.9.2-p180.tar.bz2
Installing ruby-1.9.2-p180...
WARNING: ruby-1.9.2-p180 is past its end of life and is now unsupported.
It no longer receives bug fixes or critical security updates.
ruby-build: use readline from homebrew
BUILD FAILED (OS X 10.13.3 using ruby-build 20180329)
Inspect or clean up the working tree at /var/folders/0t/hft4_1h13wqd91mwcw2j94h80000gn/T/ruby-build.20180407090310.93949
Results logged to /var/folders/0t/hft4_1h13wqd91mwcw2j94h80000gn/T/ruby-build.20180407090310.93949.log
Last 10 log lines:
/var/folders/0t/hft4_1h13wqd91mwcw2j94h80000gn/T/ruby-build.20180407090310.93949 /usr/local/bin
/var/folders/0t/hft4_1h13wqd91mwcw2j94h80000gn/T/ruby-build.20180407090310.93949/ruby-1.9.2-p180 /var/folders/0t/hft4_1h13wqd91mwcw2j94h80000gn/T/ruby-build.20180407090310.93949 /usr/local/bin
configure: WARNING: unrecognized options: --with-openssl-dir, --with-libyaml-dir, --with-readline-dir
checking build system type... i386-apple-darwin17.4.0
checking host system type... i386-apple-darwin17.4.0
checking target system type... i386-apple-darwin17.4.0
checking whether the C compiler works... no
configure: error: in `/var/folders/0t/hft4_1h13wqd91mwcw2j94h80000gn/T/ruby-build.20180407090310.93949/ruby-1.9.2-p180':
configure: error: C compiler cannot create executables
See `config.log' for more details
The error on the config.log is the same as the one output above:
configure:3446: error: C compiler cannot create executables
I tried to compile a basic file with C code and gcc-4.2 failed to do so (unlike /usr/local/bin/gcc) which I tells me gcc-4.2 simply doesn't work on macOS 10.13 right now. Perhaps the only way forward would be to find a way to compile old Rubies with modern gcc versions, but I'm guessing that might involve making a lot of manual changes to the configure files to make them compatible.
I'm just curious if anyone's succeeded in this endeavor or if this is a lost cause.
It's probably possible with rvm have a look at https://github.com/rvm/rvm/issues/3099 and also https://github.com/rvm/rvm/issues/3876
You should be able to install ruby-1.9.3
But if that doesn't work, you might consider spinning up a docker ubuntu container and install it that way? https://github.com/rvm/ubuntu_rvm
Related
So I'm trying to build bitcoind on big sur in my m1 mac through following the documentation for building bitcoind for OS X: https://github.com/bitcoin/bitcoin/blob/master/doc/build-osx.md and I've had the same error every time I try and build. Here are the steps I take:
brew install autoconf automake berkeley-db4 libtool boost miniupnpc openssl pkg-config protobuf qt5
git clone https://github.com/bitcoin/bitcoin.git
cd bitcoin
./autogen.sh
./configure --with-gui=no
After the configuration I get the following message:
checking for boostlib >= 1.58.0 (105800)... configure: We could not detect the boost libraries (version 1.58.0 or higher). If you have a staged boost library (still not installed) please specify $BOOST_ROOT in your environment and do not give a PATH to --with-boost option. If you are sure you have boost installed, then check your version number looking in <boost/version.hpp>. See http://randspringer.de/boost for more documentation.
I don't get why it's not detecting the library...
Can anyone help me out?
I had the same problem and I solved it this way:
cd depends/
make
# After completing this step, you will see one new folder (arm-apple-darwin20.4.0) in /bitcoin/depends. The version number may change
# Go back to bitcoin folder
cd ..
# Set up the compilation tool
./configure --with-gui=no --prefix=$PWD/depends/arm-apple-darwin20.4.0
# change the version ...darwin20.x.x with what you have in depends directory
# Start to compile bitcoin
make HOST=arm-apple-darwin20
make check
You can see the bitcoind binary in the src directory. Enjoy :)
source:
https://gist.github.com/awesome-doge/9bfbd1d3fd9b725c4df224433fa3596e
This started as a question about a specific gem installation issue but I went through so many iterations of issues trying to get this application working on Windows 10 that I decided to alter the question and write a sort of guide. Hopefully this will be of use to anyone else (or myself) experiencing these issues in the future.
I am running a Windows 10 64 bit machine. I have tried RubyInstaller and setting up Windows SubSystem for Linux (WSL) and have been met with various installation issues, gem dependency issues and just straight out vague as anything who-knows-what issues.
How do I get Ruby on Rails and subsequently, Locomotive CMS running on Windows 10?
Note: I initially followed this tutorial to install Ruby with RubyInstaller. This apparently worked fine (although there were a fair few hiccups along the way), but I eventually ended up with the following error when attempting to gem install locomotivecms_wagon, which I was unable to solve:
ERROR: Error installing locomotivecms_wagon:
ERROR: Failed to build gem native extension.
current directory: C:/Dev/Dependencies/rubyinstaller-2.5.8-1-x64/lib/ruby/gems/2.5.0/gems/nokogumbo-1.5.0/ext/nokogumboc
C:/Dev/Dependencies/rubyinstaller-2.5.8-1-x64/bin/ruby.exe -I C:/Dev/Dependencies/rubyinstaller-2.5.8-1-x64/lib/ruby/site_ruby/2.5.0 -r ./siteconf20200827-12272-1va06mr.rb extconf.rb
checking for xmlNewDoc() in -lxml2... yes
checking for nokogiri.h in C:/Dev/Dependencies/rubyinstaller-2.5.8-1-x64/lib/ruby/gems/2.5.0/gems/nokogiri-1.10.10/ext/nokogiri... yes
checking for nokogiri.h in C:/Dev/Dependencies/rubyinstaller-2.5.8-1-x64/lib/ruby/gems/2.5.0/gems/nokogiri-1.10.10/ext/nokogiri... yes
checking for gumbo_parse() in -lgumbo... no
checking for GumboErrorType with error.h... not found
checking for GumboInsertionMode with insertion_mode.h... not found
checking for GumboParser with parser.h... not found
checking for GumboStringBuffer with string_buffer.h... not found
checking for GumboTokenType with token_type.h... not found
creating Makefile
current directory: C:/Dev/Dependencies/rubyinstaller-2.5.8-1-x64/lib/ruby/gems/2.5.0/gems/nokogumbo-1.5.0/ext/nokogumboc
make "DESTDIR=" clean
current directory: C:/Dev/Dependencies/rubyinstaller-2.5.8-1-x64/lib/ruby/gems/2.5.0/gems/nokogumbo-1.5.0/ext/nokogumboc
make "DESTDIR="
generating nokogumboc-x64-mingw32.def
compiling attribute.c
compiling char_ref.c
compiling error.c
compiling nokogumbo.c
In file included from nokogumbo.c:31:
C:/Dev/Dependencies/rubyinstaller-2.5.8-1-x64/lib/ruby/gems/2.5.0/gems/nokogiri-1.10.10/ext/nokogiri/nokogiri.h:13: warning: "_GNU_SOURCE" redefined
13 | #define _GNU_SOURCE
|
In file included from C:/Dev/Dependencies/rubyinstaller-2.5.8-1-x64/include/ruby-2.5.0/ruby/ruby.h:24,
from C:/Dev/Dependencies/rubyinstaller-2.5.8-1-x64/include/ruby-2.5.0/ruby.h:33,
from nokogumbo.c:21:
C:/Dev/Dependencies/rubyinstaller-2.5.8-1-x64/include/ruby-2.5.0/x64-mingw32/ruby/config.h:18: note: this is the location of the previous definition
18 | #define _GNU_SOURCE 1
|
compiling parser.c
compiling string_buffer.c
compiling string_piece.c
compiling tag.c
compiling tokenizer.c
compiling utf8.c
compiling util.c
compiling vector.c
linking shared-object nokogumboc.so
C:/Dev/Dependencies/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: nokogumbo.o:nokogumbo.c:(.text+0x49b): undefined reference to 'Nokogiri_wrap_xml_document'
collect2.exe: error: ld returned 1 exit status
make: *** [Makefile:259: nokogumboc.so] Error 1
make failed, exit code 2
Gem files will remain installed in C:/Dev/Dependencies/rubyinstaller-2.5.8-1-x64/lib/ruby/gems/2.5.0/gems/nokogumbo-1.5.0 for inspection.
Results logged to C:/Dev/Dependencies/rubyinstaller-2.5.8-1-x64/lib/ruby/gems/2.5.0/extensions/x64-mingw32/2.5.0/nokogumbo-1.5.0/gem_make.out
Temporarily enhancing PATH for MSYS/MINGW...
Building native extensions. This could take a while...
After 3 installs, uninstalls and reinstalls I gave up on RubyInstaller. RubyInstaller worked great for me running Windows 7 - I doubt I ever would have managed to get a working Ruby environment without it. And it may have worked for some things on Windows 10. I got it set up ok, but I could not get the Locomotive CMS Wagon gem to install as per the issue in my question.
What worked for me was setting up WSL (Windows SubSystem for Linux) and installing Ruby on that. I followed the Go Rails tutorial in conjunction with these instructions.
I highly recommend updating the WSL Linux kernel (WSL 1 > WSL 2). I didn't do this the first time around and had various problems. This GitHub tutorial helps with identifying whether you have WSL 1 or 2 installed.
(I didn't worry about creating another user as described in the GitHub tutorial as I was prompted to do this on starting Ubuntu for the first time. As far as I can tell this is what is required to prevent the user vs root permissions problems. I haven't had any issues yet.)
When you get to installing Ruby, don't install 2.7.1. If you do, then when you get to installing locomotivecms_wagon, as of the time of writing, you will run into the following issue:
Bundler found conflicting requirements for the Ruby version:
In Gemfile:
Ruby
locomotivecms_steam was resolved to 1.5.0.rc0, which depends on
nokogiri (~> 1.8.2) was resolved to 1.8.5, which depends on
Ruby (>= 2.1.0)
locomotivecms_steam was resolved to 1.5.0.rc0, which depends on
nokogiri (~> 1.8.2) was resolved to 1.8.5, which depends on
Ruby (< 2.6, >= 2.2) x64-mingw32
From what I can gather, you can only run Locomotive CMS on Ruby < 2.6 or >= 2.1.0.
I used rbenv as opposed to rvm. That's another discussion.
After making my way through all that I was able to set up the following without too much trouble:
Install Node.js as per these instructions.
Install Yarn as per these instructions: npm install -g yarn
Install Image Magick as per these instructions: sudo apt-get install imagemagick
Install Locomotive CMS as per the Locomotive CMS docs: gem install locomotivecms_wagon
A few caveats:
I haven't yet set up Git on WSL. I am concerned about how it is going to handle changes made via Ubuntu vs changes made via Windows. And I will need to make some changes via Windows - doing everything through the terminal isn't realistic. Not sure how that is going to go. I might update this answer with further info when I find out.
All my files are contained within a Dropbox folder. Not sure whether the fact that I will be creating / editing them under Ubuntu will have any implications.
I've found a similar GitHub issue here: https://github.com/rubys/nokogumbo/issues/4.
They mentioned the following statement as a solution:
gem install nokogumbo -- --with-ldflags=-no-undefined
Run this command and then re-run bundle install.
The last days I struggled with libraries (GLib2.52.2 & GTK3.22.15), while I tried to compile them on Ubuntu 16.04 LTS (fresh installation).
The GLib2.52.2 just compiled without errors after installing the needed dependencies.
My problem is following:
when I want to start compilation of GTK3.22.15
$ ./configure --prefix=/usr --with-pcre=system && make -j 6
I get this error message:
configure: error: Package requirements (glib-2.0 >= 2.49.4 atk >= 2.15.1 pango >= 1.37.3 cairo >= 1.14.0 cairo-gobject >= 1.14.0 gdk-pixbuf-2.0 >= 2.30.0) were not met:
Requested 'glib-2.0 >= 2.49.4' but version of GLib is 2.48.2
Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.
Alternatively, you may set the environment variables BASE_DEPENDENCIES_CFLAGS
and BASE_DEPENDENCIES_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
SOLVED EDIT
I got a suggestion from AskUbuntu to compile everything in /usr/local to prevent conflicts, in some cases with official repository updates.
$ ./configure --prefix=/usr/local --with-pcre=system && make -j 6
Did solve my problem under these conditions. I didn't touch anything more, referring to the other so said "not matching" dependencies, to compile GTK3 (3.22.15) after recompiling GLib2.0 (2.52.2) in /usr/local.
Requested 'glib-2.0 >= 2.49.4' but version of GLib is 2.48.2
When compiling libraries for Gnome or Gtk, you frequently have to update other libraries too. If you download gtk3 from the ubuntu repositories (use the synaptic package manager to search for gtk3 or gtk+-3.0), you will see that you will not only download gtk3, but a pile of other libraries gtk3 needs. In case of using the repositories (recommended!) the system will take care of everything.
I'm not an Ubuntu user, but I am interested in the behind-the-scenes part, so I frequently compile libraries, and I have to do this manually. So, to install a new version of gtk3, I have to first compile and update glib. After doing so, I might also have to update Pango, ATK, and several other libraries first. If you like losing time with such stuff, go for it! Else consider using the repositories.
I installed the development version of Ruby 2 via rbenv on Mac OS X v10.8.3, and am using it to compile a gem I'm working on. I have a memory problem I want to debug. Unfortunately, whenever I run valgrind, gdb, or cgdb in the context of a rake spec, I get a whole bunch of errors like this one:
warning: Could not find object file "/private/var/folders/5f/h1s00nhn0rv4ckkpg4k_bwhr0000gn/T/ruby-build.20130331232604.54521/ruby-2.0.0-dev/main.o" - no debug information available for "main.c".
Obviously, that ruby-build directory no longer exists.
I get a series of likely-related errors from valgrind. Here are examples:
--2564-- /Users/jwoods/.rbenv/versions/2.0.0-dev/lib/libyaml-0.2.dylib:
--2564-- dSYM directory is missing; consider using --dsymutil=yes
If I try to use that --dsymutil=yes option, I get errors which are basically the same as those from gdb:
warning: (x86_64) /private/var/folders/5f/h1s00nhn0rv4ckkpg4k_bwhr0000gn/T/ruby-build.20130331232604.54521/ruby-2.0.0-dev/ext/openssl/ossl_bn.o unable to open object file
Per an answer to another question, I tried running info target inside gdb. Here is the output.
Is there some way I can instruct rbenv to put the debugging symbols somewhere that they won't get cleaned up?
I'm using GCC 4.7.1, which I installed via homebrew. My exact Ruby version string is ruby 2.1.0dev (2013-04-01 trunk 40029) [x86_64-darwin12.3.0], and my rbenv version is 0.4.0.
According to the documentation for ruby-build:
Both ruby-build and rbenv install accept the -k or --keep flag, which tells ruby-build to keep the downloaded source after installation. This can be useful if you need to use gdb and memprof with Ruby.
So try ruby-build install X -k, where X is the version number.
I was following an online tutorial to install some Python modules using homebrew and one step was to install gfortran with brew install gfortran. Later on, I tried using another third-party installation script to install some Python modules and after the fact I realized that part of what the script did was download and run http://r.research.att.com/tools/gcc-42-5666.3-darwin11.pkg. I don't know that much about gfortran, but looking at the brew formula for gfortran it appears that brew uses a different version from the att.com one. Will that lead to problems in the future? I did brew uninstall gfortran and brew install gfortran again, and so far it seems like things are the same (I tried recompiling the old code that I had compiled before), but I am not sure what all the att.com pkg did. (I have OS X 10.8.2 and XCode 4.2 if that matters).
It depends on where the other gfortran installer goes to. In general, no, it won't conflict. * Homebrew is designed to be compatible with third-party gfortran installs - it defines dependencies on a generic "fortran" compiler, and not on the specific gfortran Homebrew formula. Homebrew stays under /usr/local, sticking the main install in /usr/local/Cellar, and symlinking judiciously in to /usr/local/lib. Other installers that install to /usr/local will just prevent Homebrew from linking its own compiler in, but will work with other formulas that use a fortran compiler. (Assuming the gfortran build options are compatible.)
That particular gcc-42 installer you linked to installs to /usr, not to /usr/local.** And its binaries are suffixed with "-4.2"; that is, it installs cpp-4.2, g++-4.2, gfortran-4.2, and so on. So a) there's no direct conflict with the Homebrew gfortran, and b) it won't directly shadow the /usr/local/bin/gfortran installed by Homebrew.
Which compiler will get picked up by things you build with both these gfortrans installed will depend on how the build works, but most will be looking for plain gfortran and so will find the Homebrew one, unless you explicitly direct them to the AT&T-provided one. You don't specify how you're building things, but since you're using brew, I'm assuming it's via brew or command line tools, in which case I think they're all probably seeing the Homebrew gfortran and ignoring this one. Look at the verbose output from their build processes to find out for sure.
*Depending, of course on what you mean by "conflict".
**Side note: AFAIK there's no easy way to figure this out by looking at the package or an installation manager. I just did a find /usr before and after running that installer, and did a diff on the output:
$ diff usr_before_any_installs.txt usr_after_att_install.txt | grep '^[<>]'
> /usr/bin/c++-4.2
> /usr/bin/cpp-4.2
> /usr/bin/g++-4.2
> /usr/bin/gcc-4.2
> /usr/bin/gfortran-4.2
> /usr/bin/i686-apple-darwin11-cpp-4.2.1
> /usr/bin/i686-apple-darwin11-g++-4.2.1
> /usr/bin/i686-apple-darwin11-gcc-4.2.1
> /usr/bin/i686-apple-darwin11-gfortran-4.2.1
> /usr/include/gcc
> /usr/include/gcc/darwin
> /usr/include/gcc/darwin/4.2
...