On Sep 23, 2005, at 4:41 AM, Jonathan Worthington wrote:
"Ross McFarland" <[EMAIL PROTECTED]> wrote:
there's also a really hacky win32 thing tacked on the end that
removes the lib from the front, but it would only work for cases
without a path. i can do the same, but that's pretty broken as is
and it would seem you'd need to do the opposite if the lib was
specified in win32 speak and you're running on unix-y system.
Taking the "lib" off the start on Win32 always felt a little hacky
to me...it's certainly not a hard and fast rule but does apply in
some cases. I guess it's a last-ditch effort - that whole chunk of
code feels very "let's try everything we can possibly think of". I
think it's worth remembering that NCI = *Native* Calling Interface,
so by using it you are inherently doing something platform specific
anyway. We can only hide away platform differences so far...the
question is how far should we go.
yeah and no, it's native as in C not really platform. something like
libm would be a good, though trivial, example. it's likely on every
system you come across and if you want to get at something in it you
should be able to. there's nothing platform specific about libm other
than the file name. if we allow to code to say either
loadlib libm
or
loadlib m
then bindings for it would work on any platform that had lib m. i'm
all for not trying every perm, in fact there's several of them that
aren't handled in the current code as it stands. i think the real
solution is to define what loadlib expects more thoroughly so that a
reasonable and completely set of things can be attempted.
-rm
