Front page | perl.perl6.internals |
Postings from September 2005
On Sep 23, 2005, at 4:41 AM, Jonathan Worthington wrote:
> "Ross McFarland" <rwmcfa1@neces.com> 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
Thread Previous