My Secret Life as a Spaghetti Coder
home | about | contact | privacy statement
If you follow me on twitter, you already know I ran into some trouble compiling Ruby and OpenSSL the other day. Calling it "Some Trouble" might be a bit of an understatement. The next morning, I likened it to this title bout:

Mac vs. Cthulhu

Not only was Ruby and OpenSSL giving me trouble, in my quest to get it working, I totally messed up everything that depended on OpenSSL.

Email with TLS? Gone. SSH? Yep, gone as well.

Tech support's first recommendation was to requisition a new server.

How often is 'get a new server' the 1st tech support troubleshooting tactic? Surely they should ask if it was plugged in before we got there

Of course I wasn't going to accept that for an answer -- I'm the guy who, when someone tells me something is impossible, I cannot help but find a way to do it.

It turned out that all I had done was mess up the configuration of where dynamically linked code looks for the shared libraries it's supposed to use.

You can avoid that:
  • Don't mess with the LD_LIBRARY_PATH environment variable in a way that makes it persist longer or outside the scope of your compilation. For example, export LD_LIBRARY_PATH=/path/to/non_standard_lib would be a bad line all on it's own. It would be worse to stick it in your .bash_profile. Just run it on the same line where you do you configuring or compilation, and don't let it persist outside of that.
  • If there is a setting like the crle command on Solaris, make sure you read the man pages. For example, there's no way to simply add a library path -- you need to include the default ones yourself (if you still wish to use the default paths). So make sure you write them down correctly. In the end, I didn't write them down correctly, so all that was needed to get the system back to working the way it was, was to delete the ld.config file (which sets the system back to default).
What other ways can you mess it up? (Let me know in the comments!)

Anyway, along this journey I got to use ldd, the command line tool I've always wanted on Mac when I had problems with gems being unable to compile their native extensions. For the Mac, you can use otool.

Basically, they tell you which libraries a compiled piece of code is dependent on, and where it is looking for those libraries on disk. In the case of ldd you can use the -r option ldd -r /path/to/binary which will let you know what symbols can't be found, which was helpful in diagnosing some of my issue.

I just wanted to let you know about these useful tools in case you were unaware. Being able to check the dependencies got me out of a tight spot, so maybe it will help you in the future as well.

Hey! Why don't you make your life easier and subscribe to the full post or short blurb RSS feed? I'm so confident you'll love my smelly pasta plate wisdom that I'm offering a no-strings-attached, lifetime money back guarantee!


Comments
Leave a comment

There are no comments for this entry yet.

Leave a comment

Leave this field empty
Your Name
Email (not displayed, more info?)
Website

Comment:

Subcribe to this comment thread
Remember my details
Google
Web CodeOdor.com

Me
Picture of me

Topics
.NET (19)
AI/Machine Learning (14)
Answers To 100 Interview Questions (10)
Bioinformatics (2)
Business (1)
C and Cplusplus (6)
cfrails (22)
ColdFusion (78)
Customer Relations (15)
Databases (3)
DRY (18)
DSLs (11)
Future Tech (5)
Games (5)
Groovy/Grails (8)
Hardware (1)
IDEs (9)
Java (38)
JavaScript (4)
Linux (2)
Lisp (1)
Mac OS (4)
Management (15)
MediaServerX (1)
Miscellany (76)
OOAD (37)
Productivity (11)
Programming (168)
Programming Quotables (9)
Rails (31)
Ruby (67)
Save Your Job (58)
scriptaGulous (4)
Software Development Process (23)
TDD (41)
TDDing xorblog (6)
Tools (5)
Web Development (8)
Windows (1)
With (1)
YAGNI (10)

Resources
Agile Manifesto & Principles
Principles Of OOD
ColdFusion
CFUnit
Ruby
Ruby on Rails
JUnit



RSS 2.0: Full Post | Short Blurb
Subscribe by email:

Delivered by FeedBurner