# Ruby\_init\_loadpath() vs Win32

**URL:** <https://www.ruby-forum.com/t/ruby-init-loadpath-vs-win32/195024>\
**Category:** Ruby\
**Created:** [September 15, 2010, 2:30pm UTC](https://www.ruby-forum.com/t/ruby-init-loadpath-vs-win32/195024 "2010-09-15T14:30:23Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Phlip](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/ed8c4c/32.png) [@Phlip](https://www.ruby-forum.com/u/Phlip)\
**Post date:** [September 15, 2010, 2:30pm UTC](https://www.ruby-forum.com/t/ruby-init-loadpath-vs-win32/195024/1 "2010-09-15T14:30:23Z")

</div>

If I set RUBYLIB to “C:\phlip\tools\ruby-1.9.1-p0” before running an  
embedded project - linked via Visual Studio to freshly-built LIBs in  
that build tree - I get $: load paths with site\_ruby off in evil-land:

[“C:\phlip\tools\ruby-1.9.1-p0\”,  
“C:/WINDOWS/system32/lib/ruby/site\_ruby/1.9.1”,  
“C:/WINDOWS/system32/lib/ruby/site\_ruby/1.9.1/i386-msvcr80”,  
“C:/WINDOWS/system32/lib/ruby/site\_ruby”… ]

site\_ruby is neither there nor in the build tree. Then, naturally,  
require ‘rubygems’ fails, and so on.

Please go easy on me, because I only have 10 years experience with  
Ruby and 20 with C++…

---

<div class="post-metadata">

**Author:** ![Phlip](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/ed8c4c/32.png) [@Phlip](https://www.ruby-forum.com/u/Phlip)\
**Post date:** [September 15, 2010, 5:35pm UTC](https://www.ruby-forum.com/t/ruby-init-loadpath-vs-win32/195024/2 "2010-09-15T17:35:23Z")

</div>

On Sep 15, 9:28 am, Phlip [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> require ‘rubygems’ fails, and so on.
> 
> Please go easy on me, because I only have 10 years experience with  
> Ruby and 20 with C++…

Are you linking to a shared library of ruby or statically linked?

Is VARIABLE\_LIBPATH defined?

If not, then it grabs the path of where the shared library is located.

Perhaps that could lead to something?

(guessing after quick looking at the C code)
