This is because configure assumes that you have compiled ruby with a shared library as opposed to a static one.
RUBY_LIBS="-L`$RUBY $TOP_DIR/config/config_ruby.rb lib` -lruby"
However, in my case, the library is *static*. That means RUBY_LIBS should be:
It would be most convenient to be able to pass this in as a variable to configure, either as something like:
or an ac_ variable.
[ellson] I'm not saying that your suggestion isn't the right fix, but I'd like to understand the issue a bit better.
Why doesn't -lruby pick up libruby.a ? Is it because both libruby.a and libruby.so are installed on the system and the linker is preferring the .so ? Or have you renamed libruby.a to libruby_static.a to avoid this issue?
Normally .a are built without -fPIC. Why would this work when linked into a dynamically loadable ruby extension?
[Quanah] I don't have a libruby.so, it is only built static. Ruby *itself* builds the static library as libruby-static.a, this was not renaming done on my end.
> Normally .a are built without -fPIC. Why would this work when linked > into a dynamically loadable ruby extension?
I think only 64 bit linux really cares about that (I did have to build ruby shared on 64-bit linux because of this exact issue). On 32-bit linux and Solaris, using the static version of the library works just fine.