Segmentation fault while compiling ruby 1.9.3p392 with OpenSSL 1.0.1e installed

Ruby
1

I’m trying to have my Rails website running on my fresh installation of
Mountain Lion Server. Not using RVM, because I don’t need many rails or
ruby installations. Configuring ruby and rails to run smoothly is a pain
in the ass.

Compiled the newest version of OpenSSL with these commands:

sudo ./configure --prefix=/usr/local/ darwin64-x86_64-cc
sudo make
sudo make install

Now when I type I get this:

grid:ruby-1.9.3-p392 Clu$ openssl version
OpenSSL 1.0.1e 11 Feb 2013

When I try to configure Ruby from source, I get to Segmentation Fault:

compiling md5init.c
compiling md5ossl.c
linking shared-object digest/md5.bundle
installing default md5 libraries
compiling rmd160init.c
compiling rmd160ossl.c
linking shared-object digest/rmd160.bundle
installing default rmd160 libraries
compiling sha1init.c
compiling sha1ossl.c
linking shared-object digest/sha1.bundle
collect2: ld terminated with signal 11 [Segmentation fault: 11]
make[2]: *** [../../../.ext/x86_64-darwin12.2.1/digest/sha1.bundle]

Error 1
make[1]: *** [ext/digest/sha1/all] Error 2
make: *** [build-ext] Error 2

2

Hi,
signal 11 suggests a hardware error and is not related to software. I
would
check ram first.
09-03-2013 17:35, “Piotr P.” [email protected] napisa(a):

3

I don’t think it’s a hardware failure, checked and everything is all
right.

4

SIG11 is not usually a hardware error, though it can be related to
memory issues. A SIG11 can be thrown when something tries to read or
write to a memory area it doesn’t have permissions on OR when it does
and the area is corrupt. (Usually caused when memory cells have gone bad
on individual sticks). Also happens when the addresses on the stack have
become corrupt, again usually due to bad cells on the/a memory stick.
The main issue though is that the pointer to a memory location is
invalid.

Run up against this so many times over the last 15+ years of computing,
its not funny. In some cases, swapping out memory sticks has solved
the issue.

That being said, the most common issue that raises SIG11s are bugs in
programs. (Bad pointer math, etc) There is no real way, short of testing
your individual memory sticks in a hardware based memory tester (not
something like mem86+ or Microscope), to determine if its specifically
your memory or a bug in the software. There are subsystems that can
throw this, hardware based, like overclocking memory and/or CPUs.

However, the vast majority of SIG11s thrown are due to bugs in programs,
not hardware. Just don’t totally discount hardware, is the point.

Hi,
signal 11 suggests a hardware error and is not related to software. I
would check ram first.

–
D. Deryl D.

“The bug which you would fright me with I seek” - William Shakespeare

  • The Winter’s Tale, Act III, Scene II - A court of Justice.
5

On Sat, Mar 9, 2013 at 6:35 PM, Miroslaw N. [email protected]
wrote:

signal 11 suggests a hardware error and is not related to software. I would
check ram first.

Signal 11 is SIGSEGV (segmentation fault). That has nothing to do
with hardware - unless you want to suggest that the MMU is involved in
the process. This typically happens when dereferencing null pointers.

Piotr, I’d start with simpler options - typically you do not need the
sudo’s for configuring and compiling. Also I’d omit the architecture
unless you are cross compiling.

./configure --prefix=/usr/local/
make
sudo make install

Kind regards

robert