[ruby-talk:02604] Requiring more flexible require

This discussion relates to Ruby on some unix flavors, most notably 
ELFfed Linux. Though, it might make some sense for other platforms too.

I thought to ask and provide an opportunity for someone to give me 
a glimpse of deep reasoning behind 'require'. Why it figures out the 
name of the initialization routine from given filename and why it 
looks strictly for the library file named as the given filename?

Consider the following test case. I have foo.c and shared library libfoo.so . 
Then I have bar.c and it's using routine foo defined at foo.c, and there's
another shared libbar.so .

Then I want to use these from Ruby so I make wrappers (with SWIG) for 
both libraries, and make new shared libs libfoo_wrap.so and libbar_wrap.so. 
I really like to have them named _wrap because I have already programs
which are using the libxxx.so versions. And I really like to have them 
prefixed 'lib' because on the C side the 'ld -lname' looks for libname.so. 
(I know I could cope with symlinks, but it feels clumsy for this one.)

So we have ('->' means processed: compiled, generated shared library):
foo.c     -> foo.o                  -> libfoo.so
bar.c     -> bar.o  with libfoo.so  -> libbar.so
progfoo.c -> with libfoo.so         -> progfoo
progbar.c -> with libbar.so         -> progbar

foo.c   -> foo_wrap.c -> foo_wrap.o -> libfoo_wrap.so
bar.c   -> bar_wrap.c -> bar_wrap.o with libfoo_wrap.so -> libbar_wrap.so

Now, few problems are raised:
1) require 'foo'
Does not work. There's no foo.so. Closest is libfoo.so but it's the 
C version, not the wrapped one.

2) require 'foo_wrap' 
Does not work. There's no foo_wrap.so file. Should be libfoo_wrap.so.

3) require 'libfoo_wrap'
Does not work. There's no Init_libfoo_wrap routine in libfoo_wrap.so.
There is, however, Init_Foo().

4) require 'Foo'
Does not work. Would call right initialization routine but unfortunately
there's no Foo.so. So this needs link Foo.so -> libfoo_wrap.so. This in
turn is a little bit confusing when we have foo.so around too.

So my propose would be to change syntax and semantics for require.

First, let's change it to search with require 'name_of_lib' for the file
libname_of_lib.so too. This might break some old stuff if the 
LD_LIBRARY_PATH is not traversed totally for foo.so before for 
libfoo.so.

Second, let's add optional string which specifies the name of the 
initialization function. The syntax could be
  require 'library' 'name_of_the_Init_library'     or
  require 'library'('name_of_the_Init_library')    or something similar.

The latter form would enable require 'foo' 'bar'('Bar') type of construct
(that is to require multiple libraries at once).

I did look for the code to see how it was currently implemented and it
didn't seem too hard to make these changes. I would have implemented 
these already but then it struck me: I don't know if there's some 
reasons for the current behaviour.

----

And while we're changing, should we force dln_load to return something
useful and raise exceptions to enable normal error handling for
missing, or not properly initialized libraries.

Could libraries be reloaded at runtime? Could this enable stable server 
architecture with 24x7 uptime, reloading served functionality when there's
a update. Clearly this needs 

  begin 
    require libs_array
  rescue
    die gracefully at loading error
  end

----

One more point. When I played with my test case I lost quite much time
trying to find reason why accessing Bar's variable and functions from Ruby 
worked but calling a function which in turn called Foo's function didn't
work. The reason was incorrect LD_LIBRARY_PATH and incorrect loading of
libfoo.so.

This makes me wonder whether we could check somehow at initialization 
that everything is set up correctly *and* if libbar depends on libfoo, 
libfoo is loaded properly too?

At this case everything worked until I hit the routine calling foo from
libfoo, so I got 

printouts from apparently working program
...
ruby: error in loading shared libraries: ./bar.so: undefined symbol: foo