I am trying to install biogrinder on my macOS Monterey, which needs some perl modules.
All necessary modules are installed except Math::Random::MT
When trying to install this module using the following command:
sudo cpan install Math::Random::MT
I get the following error
Loading internal null logger. Install Log::Log4perl for logging messages
CPAN: Storable loaded ok (v2.62)
Reading '/Users/imac/.cpan/Metadata'
Database was generated on Mon, 17 Oct 2022 13:29:01 GMT
Running install for module 'Math::Random::MT'
CPAN: Digest::SHA loaded ok (v5.96)
CPAN: Compress::Zlib loaded ok (v2.074)
Checksum for /Users/imac/.cpan/sources/authors/id/F/FA/FANGLY/Math-Random-MT-1.17.tar.gz ok
CPAN: YAML loaded ok (v1.30)
CPAN: CPAN::Meta::Requirements loaded ok (v2.140)
CPAN: Parse::CPAN::Meta loaded ok (v2.150010)
CPAN: CPAN::Meta loaded ok (v2.150010)
CPAN: Module::CoreList loaded ok (v5.20180414_26)
Configuring F/FA/FANGLY/Math-Random-MT-1.17.tar.gz with Makefile.PL
Checking if your kit is complete...
Looks good
Generating a Unix-style Makefile
Writing Makefile for Math::Random::MT
Writing MYMETA.yml and MYMETA.json
FANGLY/Math-Random-MT-1.17.tar.gz
/Users/imac/opt/anaconda3/bin/perl Makefile.PL -- OK
Running make for F/FA/FANGLY/Math-Random-MT-1.17.tar.gz
cp MT.pm blib/lib/Math/Random/MT.pm
Running Mkbootstrap for MT ()
chmod 644 "MT.bs"
"/Users/imac/opt/anaconda3/bin/perl" -MExtUtils::Command::MM -e 'cp_nonempty' -- MT.bs blib/arch/auto/Math/Random/MT/MT.bs 644
"/Users/imac/opt/anaconda3/bin/perl" "/Users/imac/opt/anaconda3/lib/5.26.2/ExtUtils/xsubpp" -typemap '/Users/imac/opt/anaconda3/lib/5.26.2/ExtUtils/typemap' -typemap '/Users/imac/.cpan/build/Math-Random-MT-1.17-48/typemap' MT.xs > MT.xsc
mv MT.xsc MT.c
x86_64-apple-darwin13.4.0-clang -c -fno-common -DPERL_DARWIN -no-cpp-precomp -mmacosx-version-min=10.9 -fno-strict-aliasing -pipe -fstack-protector-strong -DPERL_USE_SAFE_PUTENV -O3 -DVERSION=\"1.17\" -DXS_VERSION=\"1.17\" -fPIC --sysroot=/Applications/Xcode_12.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk "-I/Users/imac/opt/anaconda3/lib/5.26.2/darwin-thread-multi-2level/CORE" MT.c
In file included from MT.xs:2:
/Users/imac/opt/anaconda3/lib/5.26.2/darwin-thread-multi-2level/CORE/perl.h:694:10: fatal error: 'sys/types.h' file not found
#include <sys/types.h>
^~~~~~~~~~~~~
1 error generated.
make: *** [MT.o] Error 1
FANGLY/Math-Random-MT-1.17.tar.gz
/usr/bin/make -- NOT OK
My perl version is:
perl --version
This is perl 5, version 26, subversion 2 (v5.26.2) built for darwin-thread-multi-2level
Copyright 1987-2018, Larry Wall
Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 5 source kit.
Complete documentation for Perl, including FAQ lists, should be found on
this system using "man perl" or "perldoc perl". If you have access to the
Internet, point your browser at http://www.perl.org/, the Perl Home Page.
What doesn't look Okay, is that I don't have /usr/include folder on my machine, instead the types.h file is located in /Library/Developer/CommandLineTools/SDKs/MacOSX12.3.sdk/usr/include/sys/types.h
PS: I already installed Bio:SeqIO module using the exact same command and it worked.
Any idea on how to get over this issue ?
Many thanks
I want to install perl Gtk2, and for this I need first to have Glib installed. I tried sudo cpanm Glib, but I get an error when compiling (I also tried downloading the .tar.gz source etc., with the same effect). I also tried with an older version of Glib. I’m on OS X 10.11 (El Capitan). Here’s the error :
error: '_GStaticAssertCompileTimeAssertion_0' declared as an array with a negative size
I don’t know how to fix it… Thanks a lot if anyone can do something for me !
(BTW, brew install glib works fine, but it seems the app that I’m trying to build and run — auto-multiple-choice, for instance — is looking for a Gtk2.pm somewhere. So, the ‘glib’ installed by Homebrew is of no help.)
Benjamin
p.-s. : below is the complete log, if it helps :
cpanm (App::cpanminus) 1.7042 on perl 5.018002 built for darwin-thread-multi-2level
Work directory is /Users/benjamin/.cpanm/work/1474765262.7331
You have make /usr/bin/make
You have LWP 6.05
You have /usr/bin/tar: bsdtar 2.8.3 - libarchive 2.8.3
You have /usr/bin/unzip
Searching Glib () on cpanmetadb ...
--> Working on Glib
Fetching http://www.cpan.org/authors/id/X/XA/XAOC/Glib-1.322.tar.gz
-> OK
Unpacking Glib-1.322.tar.gz
Entering Glib-1.322
Checking configure dependencies from META.json
Checking if you have ExtUtils::MakeMaker 6.58 ... Yes (6.66)
Checking if you have ExtUtils::PkgConfig 1.000 ... Yes (1.15)
Checking if you have ExtUtils::Depends 0.300 ... Yes (0.306)
Configuring Glib-1.322
Running Makefile.PL
Including generated API documentation...
Checking if your kit is complete...
Looks good
Writing Makefile for Glib
Writing MYMETA.yml and MYMETA.json
-> OK
Checking dependencies from MYMETA.json ...
Checking if you have ExtUtils::Depends 0.300 ... Yes (0.306)
Checking if you have ExtUtils::PkgConfig 1.000 ... Yes (1.15)
Checking if you have ExtUtils::MakeMaker 0 ... Yes (6.66)
Building and testing Glib-1.322
cp lib/Glib/CodeGen.pm blib/lib/Glib/CodeGen.pm
cp /Users/benjamin/.cpanm/work/1474765262.7331/Glib-1.322/typemap blib/arch/Glib/Install/typemap
cp lib/Glib/ParseXSDoc.pm blib/lib/Glib/ParseXSDoc.pm
cp doctypes blib/arch/Glib/Install/doctypes
cp devel.pod blib/lib/Glib/devel.pod
cp gperl_marshal.h blib/arch/Glib/Install/gperl_marshal.h
cp lib/Glib/MakeHelper.pm blib/lib/Glib/MakeHelper.pm
cp gperl.h blib/arch/Glib/Install/gperl.h
cp lib/Glib.pm blib/lib/Glib.pm
cp lib/Glib/Object/Subclass.pm blib/lib/Glib/Object/Subclass.pm
cp build/IFiles.pm blib/arch/Glib/Install/Files.pm
cp lib/Glib/GenPod.pm blib/lib/Glib/GenPod.pm
[ XS Glib.xs ]
[ CC Glib.c ]
In file included from Glib.xs:22:
In file included from ./gperl.h:37:
In file included from /usr/local/Cellar/glib/2.48.2/include/glib-2.0/glib-object.h:23:
In file included from /usr/local/Cellar/glib/2.48.2/include/glib-2.0/gobject/gbinding.h:28:
In file included from /usr/local/Cellar/glib/2.48.2/include/glib-2.0/glib.h:30:
In file included from /usr/local/Cellar/glib/2.48.2/include/glib-2.0/glib/galloca.h:32:
/usr/local/Cellar/glib/2.48.2/include/glib-2.0/glib/gtypes.h:422:3: error: '_GStaticAssertCompileTimeAssertion_0' declared as an array with a negative size
G_STATIC_ASSERT(sizeof (unsigned long long) == sizeof (guint64));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/local/Cellar/glib/2.48.2/include/glib-2.0/glib/gmacros.h:232:103: note: expanded from macro 'G_STATIC_ASSERT'
#define G_STATIC_ASSERT(expr) typedef char G_PASTE (_GStaticAssertCompileTimeAssertion_, __COUNTER__)[(expr) ? 1 : -1] G_GNUC_UNUSED
^~~~~~~~~~~~~~~
1 error generated.
make: *** [Glib.o] Error 1
-> FAIL Installing Glib failed. See
/Users/benjamin/.cpanm/work/1474765262.7331/build.log for details. Retry with --force to force install it.
This was posted to a GitHub issue.
I tracked down the problem by running:
cpanm --verbose --build-args=NOECHO=' ' Glib
so that I could see the specific compilation command that failed:
cc -c -I. -I/usr/local/Cellar/glib/2.50.0/include/glib-2.0 -I/usr/local/Cellar/glib/2.50.0/lib/glib-2.0/include -I/usr/local/opt/gettext/include -I/usr/local/Cellar/pcre/8.39/include -D_REENTRANT -arch x86_64 -arch i386 -g -pipe -fno-common -DPERL_DARWIN -fno-strict-aliasing -fstack-protector -Os -DVERSION=\"1.323\" -DXS_VERSION=\"1.323\" -o Glib.o "-I/System/Library/Perl/5.18/darwin-thread-multi-2level/CORE" Glib.c
Since the problem was something to do with mismatching sizeof's, I figured that the problem was that the architecture that Perl was building with does not the architecture that Homebrew's libglib-2.0 was built against.
The fix is to specify that you only want to build for x86_64 by setting the ARCHFLAGS environment variable:
ARCHFLAGS="-arch x86_64" cpanm --verbose Glib
This is all using the system Perl. If you want the install to work in the long run across system upgrades, you will want to install your own user Perl using either perlbrew or plenv.
I ran into the same issue.
Installing gtk+ as a prerequisite fixed it.
I am attempting to install the Perl package Math::GMP on OS X El Capitan.
I had one computer where this worked without issue - but a second computer is running into the following problem:
The Perl module Math::GMP requires the C library for GMP, so I have done a brew install gmp
This installed GMP including the following file:
/usr/local/include/gmp.h
But the package install still fails claiming I don't have gmp installed:
$ sudo perl -MCPAN -e shell
cpan[1]> install Math::GMP
Reading '/Users/chaosadmin/.cpan/Metadata'
Database was generated on Sat, 14 Nov 2015 09:17:02 GMT
Running install for module 'Math::GMP'
Checksum for /Users/me/.cpan/sources/authors/id/S/SH/SHLOMIF/Math-GMP-2.11.tar.gz ok
Scanning cache /Users/me/.cpan/build for sizes
............................................................................DONE
'YAML' not installed, will not store persistent state
Configuring S/SH/SHLOMIF/Math-GMP-2.11.tar.gz with Makefile.PL
Can't link/include C library 'gmp.h', 'gmp', aborting.
No 'Makefile' created SHLOMIF/Math-GMP-2.11.tar.gz
/usr/bin/perl Makefile.PL -- NOT OK
Failed during this command:
SHLOMIF/Math-GMP-2.11.tar.gz : writemakefile NO -- No 'Makefile' created
The obvious line is:
Can't link/include C library 'gmp.h', 'gmp', aborting.
But I definitely have "gmp.h" installed in /usr/local/include/gmp.h
I'm unsure why it's failing to install on this OS X El Capitan machine (it worked fine on my other one).
In the CPAN shell I used:
look Math::GMP
And updated the Makefile.PL to debug:
check_lib_or_exit(
header => 'gmp.h',
lib => 'gmp',
debug => 'true'
);
Which displayed the following error when running perl Makefile.PL
# /usr/bin/cc -arch i386 -arch x86_64 -g -pipe -fno-common -DPERL_DARWIN -fno-strict-aliasing -fstack-protector -arch i386 -arch x86_64 -fstack-protector assertlibD4RJzZEa.c -o assertlibwGFzIVsM
assertlibD4RJzZEa.c:1:10: fatal error: 'gmp.h' file not found
include
On Centos :
Just install this : yum install gmp* -y
Good Luck :)
Building GCC (latest revision) on OS X 10.11.1 here, using the command line:
../gccx/configure --with-gmp="/opt/local" --with-mpfr="/opt/local" \
--with-mpc="/opt/local" --with-libiconv-prefix="/opt/local" --with-pkgversion="GCCX" \
--program-transform-name='s/^gcc$/gccx/; s/^g++$/g++x/' --enable-languages=c
Followed build instructions exactly, and getting this error:
g++ -std=gnu++98 -g -DIN_GCC -fno-strict-aliasing
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -Wl,-no_pie -o build/genmatch \
build/genmatch.o ../build-x86_64-apple-darwin15.0.0/libcpp/libcpp.a build/errors.o build/vec.o build/hash-table.o ../build-x86_64-apple-darwin15.0.0/libiberty/libiberty.a Undefined symbols for architecture x86_64: "_iconv", referenced from:
convert_using_iconv(void*, unsigned char const*, unsigned long, _cpp_strbuf*) in libcpp.a(charset.o)
(maybe you meant: __Z14cpp_init_iconvP10cpp_reader, __cpp_destroy_iconv ) "_iconv_close", referenced from:
__cpp_destroy_iconv in libcpp.a(charset.o)
__cpp_convert_input in libcpp.a(charset.o) "_iconv_open", referenced from:
init_iconv_desc(cpp_reader*, char const*, char const*) in libcpp.a(charset.o) ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[3]: *** [build/genmatch] Error 1 make[2]: *** [all-stage1-gcc] Error 2 make[1]: *** [stage1-bubble] Error 2 make:
*** [all] Error 2
(A complete log is available at https://gist.github.com/3cb5d044533e657f4add.)
After investigating gcc/Makefile, it seems that the BUILD_CPPLIB variable does not include $(LIBICONV), since it is in a stage1 bootstrap at the time of the error. The relevant section is preceded by
# For stage1 and when cross-compiling use the build libcpp which is
# built with NLS disabled. For stage2+ use the host library and
# its dependencies.
Yet clearly the stage1 build of build/genmatch is referencing libcpp, which uses symbols from libiconv. So something is amiss here.
How can I fix it?
General discussion
Building GCC on Mac OS X is an occasionally fraught process. I've had various issues with various versions of GCC and various versions of Mac OS X over the years. You can see an earlier explanation of what I did in Install GCC on Mac OS X — that was for building GCC 4.8.x on Mavericks 10.9.x (or possibly Mountain Lion 10.8.x); it also reports success building GCC 4.9.0 on Mavericks 10.9.x, but failure to do so on Yosemite 10.10.x.
This is an updated recipe for building GCC 5.2.0 on Mac OS X 10.11.1 El Capitan.
It starts off using XCode 7.1.1 — I don't know which other versions of XCode are OK.
Note that El Capitan has a feature SIP (System Integrity Protection) that was not in Yosemite and earlier versions. This means you cannot create arbitrary directories under /usr any more. I used to install in /usr/gcc/vX.Y.Z; that is no longer permitted in El Capitan. One major change, therefore, is that I now install in /opt/gcc/v.X.Y.Z.
I've found that having DYLD_LIBRARY_PATH set is problematic — especially on El Capitan. In a major break from the past, I'm now not setting that at all. Note that the scripts unset it. Note too that the script explicitly sets the phase 1 compilers CC and CXX to /usr/bin/clang and /usr/bin/clang++ respectively (the XCode compilers). The current versions of GCC require a capable C++ compiler instead of (or as well as) a C compiler.
I have occasionally had problems with libiconv, but at the moment I've evaded them by not having my own version installed. Similarly, I've occasionally had problems with some awk scripts in the GCC source. I had to hack it/them to get it to work OK. However, with release copy of GCC 5.2.0 source, I seem to be able to build directly out of the box.
If you've only got a single disk partition, this next point isn't crucial. If you have multiple disks, either make sure the target directory does not exist or ensure that its name is exactly what you want. On the machines at work (not Macs but Linux machines, etc), I still use /usr/gcc/vX.Y.Z as the 'official' install location, but the software ends up in some arbitrary file system where there's enough space, such as /work4/gcc, and eventually there is a symlink such that /usr/gcc/vX.Y.Z gets to /work4/gcc/vX.Y.Z. However, it is crucial that /work4/gcc/vX.Y.Z does not exist while GCC is being compiled because it will resolve the name via realpath() or its equivalent and embed /work4/gcc/vX.Y.Z into the binaries, rather than the neutral name /usr/gcc/vX.Y.Z. This limits the portability of the installation; any other machine that it is moved to has to have a directory /work4/gcc/vX.Y.Z, even though you asked to install it in /usr/gcc/vX.Y.Z.
Compiling GCC 5.2.0 on Mac OS X 10.11.1 with XCode 7.1.1
I had to work with down-versions of both GMP (5.1.3 instead of 6.0.0a) and ISL (0.14 instead of 0.15). The builds for the later versions both caused me trouble.
Note that I put the library code for GMP, MPC, MPFR, ISL and Cloog (see the GCC pre-requisites) in the GCC source directory so that GCC builds its own versions of these libraries. I've found that its the simplest way to ensure that GCC locates these libraries correctly.
Target directory: /opt/gcc/v5.2.0
Build time was about 2h 15m on a 17" MacBook Pro (early 2011) running Intel Core i7 at 2.3 GHz, with 16 GiB 1333 MHz DDR3 main memory, and a 750 GB 5400 rpm hard disk drive. The source occupies about 850 MiB; the build tree ends up at about 4.6 GiB — you need plenty of disk space. The installed code ends up at about 420 MiB.
Script used — extract-gcc-5.2.0.sh
#!/bin/bash
unset DYLD_LIBRARY_PATH
TAR=tar
VER_NUM=5.2.0
GCC_VER=gcc-${VER_NUM}
TGT_BASE=/opt/gcc
TGT_DIR=${TGT_BASE}/v${VER_NUM}
CC=/usr/bin/clang
CXX=/usr/bin/clang++
extract() {
echo "Extract $1"
$TAR -xf $1
}
if [ ! -d "$GCC_VER" ]
then extract ${GCC_VER}.tar.bz2 || exit 1
fi
(
cd ${GCC_VER} || exit
nbncl <<EOF |
cloog 0.18.1 tar.gz
gmp 5.1.3 tar.xz
# gmp 6.0.0 tar.lz
isl 0.14 tar.bz2
# isl 0.15 tar.bz2
mpc 1.0.3 tar.gz
mpfr 3.1.3 tar.xz
EOF
while read file vrsn extn
do
tarfile="../$file-$vrsn.$extn"
if [ ! -f "$tarfile" ]
then echo "Cannot find $tarfile" >&2; exit 1;
fi
if [ ! -d "$file-$vrsn" ]
then
(
set -x
extract "$tarfile" &&
ln -s "$file-$vrsn" "$file"
) || exit 1
fi
done
)
if [ $? = 0 ]
then
mkdir ${GCC_VER}-obj
cd ${GCC_VER}-obj
../${GCC_VER}/configure --prefix="${TGT_DIR}" \
CC="${CC}" \
CXX="${CXX}"
make -j8 bootstrap
fi
Script nbncl — non-blank, non-comment lines
#!/usr/bin/env perl
#
# Non-blank, non-comment lines only
use warnings;
use strict;
while (<>)
{
chomp;
s/\s+$//;
s/\s*#.*$//;
print "$_\n" unless /^$/;
}
First, see Jonathan Leffler's very complete answer. I have a few more suggestions here.
The gcc configuration and build process needs to find your system's native header files and C run-time libraries. Newer, clang-based versions of Xcode hide these pretty deeply, and older versions of gcc don't seem to know how to find them. To get gcc 4.6 to build at all, I had to create these symlinks:
ln -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include /usr
ln -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/dylib1.10.5.o /usr/local/lib
ln -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/crt1.10.5.o /usr/local/lib
ln -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/bundle1.o /usr/local/lib
Your mileage will likely vary slightly: note that those pathnames underneath /Applications/Xcode.app/Contents have various version numbers baked in to them, which are likely to be different on your system.
(If, as Jonathan describes, the newest versions of MacOS don't allow you to put anything in /usr, you might have to create the /usr/include symlink in /usr/local/include, instead, and I suspect that would work, too.)
Also, this is mentioned elsewhere, but it's an unusual requirement, and easy to overlook: do not try to build gcc within its own source tree. Always create a build directory which is a parallel sibling, not a child underneath, of the directory into which you've extracted the gcc sources. That is, do not do this:
tar xzf gcc-x.y.z.tar.bz2
cd gcc-x.y.z # WRONG
mkdir build
cd build
../configure # WRONG
make
Instead, do this:
tar xzf gcc-x.y.z.tar.bz2
mkdir build
cd build
../gcc-x.y.z/configure
make
This is counterintuitive, I know, and it's not the way a lot of other packages work, but it definitely does work for gcc, and it's the recommended way to do it.
Another point: if you discover that your build is failing because you configured it improperly, such that you have to rerun configure with different options, it's safer to delete your entire build directory and start from scratch. The configure and build system sometimes, but it seems not 100% reliably, detects what might need rebuilding in that case. (Deleting and starting over is frustrating, I agree, but again, it can really save time in the long run.)
Finally, if you're trying to build a cross-compiler, see some additional suggestions and commentary at install gcc 4.6.1 on OS X 10.11 .
For what it's worth, MacPorts has ports for all recent versions that should be sufficiently easy for everyone (who knows how to code!) to read who doesn't want to install MacPorts but prefers to install the various dependencies mentioned here some other way.
A slightly tweaked personal version of the port for gcc 6.3.0:
https://github.com/RJVB/macstrop/blob/master/lang/gcc6/Portfile
The reason I mention that one (and post this answer) is that this tweaked version shows how to get G++ to use libc++ instead of libstdc++. That's a prerogative for being able to use G++ as a real replacement for clang++ that can be used without worrying about C++ runtime incompatibilities. This patch has allowed me to use g++ to build KDE (KF5) code and run it against Qt5 and the KF5 frameworks built with various clang compiler versions. (The patch files are in .../gcc6/files .)
Some explanation that might help interpreting the Tcl code of the linked file:
Ignore anything that's specific to $subport == "libgcc".
As you can see, you need gmp, mpc, mpfr and isl (the other dependencies should be of no interest if you're installing on your own).
The configure.args expressions construct the argument list to the configure script, configure.env and build.env add environmental variables for the configure and build (make) commands. Many of the configure options here are to ensure that the build uses dependencies from MacPorts but they'd probably be required too if you want or have to use a location not controlled by SIP and that isn't included in standard PATH definitions (the compiler still ought to work when invoked through a process that resets the path).
The configure and build are done in a build directory that sits next to the source directory, which makes it very easy to start over or just clean up without throwing away the sources.
After the configure step the build is done with "make bootstrap-lean" - which still creates about 1.7Gb of data in that build directory.
I've been trying to install Ruby 2 on my machine running OSX 10.7 via rvm, but run into compilation issues no matter what I try.
So far, I've tried using the OSX GCC Installer, have reinstalled Xcode twice (tried the DMG first, then the App store), and have reinstalled the command line tools.
Compilation fails for both gcc and clang.
Here is what it is failing on (from ~/.rvm/src/ruby-2.0.0-p247/config.log):
configure:3776: checking whether the C compiler works
configure:3798: /usr/bin/clang --I/usr/local/opt/freetype/include -L/usr/local/opt/freetype/lib conftest.c >&5
clang: error: unsupported option '--I/usr/local/opt/freetype/include'
This causes ./configure to output checking whether the C compiler works... no.
As far as I can see, the correct syntax for the option should be -I, rather than --I - how can I get configure to use the correct option?
EDIT: Compiling from source without using rvm results in the same issue.
It turns out that my CPPFLAGS environment variable was the culprit.
Running CPPFLAGS='-I/usr/local/opt/freetype/include' rvm install ruby-2.0.0-p247 did the trick.