From: matz@... (Yukihiro Matsumoto)
Date: 2000-05-08T12:57:11+09:00
Subject: [ruby-talk:02627] Re: Requiring more flexible require

Hi,

In message "[ruby-talk:02623] Re: Requiring more flexible require"
    on 00/05/08, Aleksi Niemel� <aleksi.niemela@cinnober.com> writes:
|
|I lost my 24h internet connection permanently, so sorry for the delay :).

Is it you?  mrilu <mrilu@ale.cx>? 

|Normally there's no need to access foo_wrap shared object. But now I got
|another idea and the question remains, could there be a use for wrapped
|libraries?

On Linux and many flavors of UNIXes, dynamic loadable objects works
similarly to shared libraries.  But it's not portable.  For example,
for OS/2 port of Ruby, dynamic loadables are not in shared library
format.

|Can you imagine program barrel.c using some routines from foo_wrap.c
|directly? Or how about embedded Ruby programs? Could they possess some need
|to 'ld -lfoo_wrap'?

In that case, foo_wrap.o should be linked statically into an embedding
program.  Although static linking facility for Ruby extension is far
from perfect.

|I see the original idea to name extensions to name_for_extension.so. Since
|they still are normal libraries (just used normally for Ruby) I think they
|should be named
|
|1) like the standard, that is libname_for_the_extension.so, or to
|2) make notable difference
|
|The first one is probably harder to tackle with, considering the wide range
|of platforms. The second point might already be done. libfoo.so's wrapper is
|foo.so, thus being clear. We might get some clarity by making bigger
|difference like naming the foo.so to Foo.rso (denoting Ruby shared Object)
|or something.

Dynamic loading facility provided by the OS may require the fixed
extension for dynamic loadables (for example `.dll').

|However, I still think the main point is to allow specific initialization
|routine instead of naming of the lib. I wasted some of my precious free time
|by creating the following patch :). Feel free to discuss about it, and I
|personally don't mind it to get into development version, as it's (most
|probably) not breaking any existing code.
|
|This allows to write 
|
|  require 'Foo' 'weird_initialization_function'
|
|loading Foo.so from path and calling it's
|Init_weird_initialization_function.
|
|First, I would like to ask what is ALLOCA_N (and alloca family) and how it
|differs from the other macros?

They take space from stack, so that the allocated space does not have
to (and must not) be freed.

|Secondly, I would like to note that this is patch for require 'lib'
|'init_name' not for finding libraries with appended 'lib' as it's not yet
|"accepted" feature.

I don't think I'm going to merge your `lib' prefix and arbitrary
`init_name' features.  The former is no chance to be incorporated.
The latter requires more discussion.

|Then, I see this patch incorporated few waiting-to-be-handled-bugfixes. I
|skimmed through the code few hours trying to find these kind of problems
|elsewhere in the code too, but with no luck. For these I'm not sure even now
|if these are real problems or fixes. I present these first for easier
|discussion.

Do you mean [ruby-talk:02624]?

							matz.