|Anonymous | Login||2017-11-24 10:08 EST|
|Main | My View | View Issues | Change Log | Roadmap | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000606||graphviz||Build/Install||public||2006-09-02 22:44||2011-04-28 04:03|
|Summary||0000606: graphviz assumes shared library for ruby|
When going to build graphviz, it fails because it cannot find the ruby library.
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?
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.
|Tags||No tags attached.|
|2011-04-28 04:03||user1||New Issue|
|2011-04-28 04:03||user1||Assigned To||=> user695|
|MantisBT 1.2.5[^] Copyright © 2000 - 2011 MantisBT Group|