Why is my Rails on CentOS install looking for libc.dylib?

Question

I'm moving a Rails app (written by somebody else) from running on an OSX server to a CentOS server and during my setup process I am trying to create the database using the command...

/usr/bin/bundle exec /usr/bin/rake db:create RAILS_ENV=production POSTGRES_DIR=/usr

This call fails with the error:

libc.dylib: cannot open shared object file: No such file or directory

Which makes no sense to me at all, dylib files are an OSX thing and so I don't know why the Rails db:create operation would be looking for libc.dylib? Shouldn't it just load up the standard Linux libc.so?

What is db:create actually executing that has this dependency?

Could it be that you've transferred a compiled piece of code from your OSX server to your Centos server? — S M, Jan 29 '13 at 23:25
I cloned the source git repository, but I installed rails entirely through yum. I should check the source repo to see if there were any compiled binaries in there. — Fraser Graham, Jan 29 '13 at 23:33
Just verified the repo I cloned has no binary executables in it. So I am very confused now. — Fraser Graham, Jan 29 '13 at 23:52
Does `grep -R 'libc\.dylib' .` (run in your working directory) turn anything up? — S M, Jan 29 '13 at 23:55
ah, interesting. It does: ./vendor/bundle/ruby/1.8/gems/posix_spawn-0.1.1/lib/pty.rb: dlload "libc.dylib" # Note: Darwin-only — Fraser Graham, Jan 30 '13 at 00:06

score 0 · Accepted Answer · answered Jan 30 '13 at 18:00

My repository had a cache of .gem files generated by the bundler when running on OSX and submitted to source control. One of those gems was an OSX binary, the db:create call runs through the all the initializer code to execute the calls to the ORM and so even though those modules were not being used during the db:create functions they were attempting to load.

Why is my Rails on CentOS install looking for libc.dylib?

1 Answers1