loadlib P1, "/lib/libc.so.6"
dlfunc P0, P1, "system", "it"
set I0, 1
set S5, "ls"
invoke
end
(Which in itself tickles and scares the bejesus out of me.) Is there a
good way of finding the standard C library on a Unix system other than
hard-wiring it in like this?
Also, is there any way yet of getting an unbuffered read (in parrot) so I
can getc() from the keyboard? I should ask, is there an *approved* way of
doing that now? I'm fairly familiar with C's I/O model so I could pull it
off with ioctl(), fcntl(), etc... and all of their friends, but alas
they're not around yet.
These questions are not necessarily related. Or unrelated. :)
> loadlib P1, "/lib/libc.so.6"
> dlfunc P0, P1, "system", "it"
> set I0, 1
> set S5, "ls"
> invoke
> end
>
> (Which in itself tickles and scares the bejesus out of me.) Is there a
> good way of finding the standard C library on a Unix system other than
> hard-wiring it in like this?
Not that I know of. You can get perl5's guess by looking at
$Config{libc}, but that value could be empty or wrong. If you want to be
either amused or amazed, you can look at the complex gyrations perl5's
Configure tries to go through to find the C library, but even that isn't
always right. Further, perl5's Configure only looks for the libc name if
it is necessary. Often, it is sufficient (for Configure's purpose) to let
the compiler find the C library. As one example, it's conceivable that
the compiler might use the C library in either /lib32/ for /lib64/,
depending on compiler flags and environment variables.
--
Andy Dougherty doug...@lafayette.edu
const char * s = 0;
if( $2->strlen != 0 ) {
s = string_to_cstring(interpreter, ($2));
}
p = Parrot_dlopen(s);
With this hack, the following code will work:
loadlib P1, ""
dlfunc P0, P1, "system", "it"
set I0, 1
set S5, "ls"
invoke
end
cya,
Jens Rieks
Index: core.ops
===================================================================
RCS file: /cvs/public/parrot/core.ops,v
retrieving revision 1.287
diff -r1.287 core.ops
4862c4862,4866
< const char * s = string_to_cstring(interpreter, ($2));
---
> const char * s = 0;
>
> if( $2->strlen != 0 ) {
> s = string_to_cstring(interpreter, ($2));
> }
cya,
Jens Rieks
A very cool hack, indeed. :)
It's gonna need a little work though. On Win32 Parrot_dlopen is a
passthrough to LoadLibrary() which, as far as I can tell, doesn't have the
same behavior for this case. *But* it seems as though if you can find
parrot's name (imcc.exe, parrot.exe, etc...) and pass *that* to loadlib it
should work fine. Maybe. More testing required.
On my linux box (which was the issue...) it seems fine though. Whee.
Thanks!
> Thanks!
No problem, thank you for your work!
cya,
Jens Rieks
> You can not pass a NULL pointer to loadlib at the moment, this small hacks
> "converts" an empty string to a NULL pointer to pass it to Parror_dlopen:
We could as well change string_to_cstring to return a NULL pointer for a
NULL String argument.
And for obtaining a NULL String you could use e.g. C<clears> or better a
new opcode:
B<null>(out STR) # set register to NULL
For consistency we could have this op for all register type.
null I0 # a little faster shortcut of "set I0, 0"
> Jens Rieks
leo
Works, and done! :)
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
That's an interesting trick, albeit a very platform-dependent one. I
can see adding in support for getting a handle on the current
executable (though this is one of the cases where things may behave
differently under the interpreter and as a compiled standalope app)
Given all this, I think that an alternate version of loadlib to open
the current application is in order. (I'd say it should be a library
routine, but since loadlib is already an op it seems in order)
Perhaps loadlib with only one argument should give a handle on the
current app, with callouts to a platform-specific loading routine.
(The dlopen trick won't work on OS X right now, as well as Win32,
since we fake out dlopen)
>You can not pass a NULL pointer to loadlib at the moment, this small hacks
>"converts" an empty string to a NULL pointer to pass it to Parror_dlopen:
I've put in an alternate hack, one that returns NULL from
string_to_cstring if passed in a NULL string pointer.
> > (Which in itself tickles and scares the bejesus out of me.) Is there a
> > good way of finding the standard C library on a Unix system other than
> > hard-wiring it in like this?
> Yes. Parrot is linked with the standard C library. You can get a handle for
> the own executable by passing a NULL pointer to dlopen. You can also use this
> handle to call libc functions.
Ahh, clever. That's likely to work for systems which use the dlopen()
dynamic loading interface. I don't know if it will also work on HP-UX,
AIX, and Mac, though there's likely some equivalent trick. (Similarly,
non-Unix systems such as Win32, VMS, and OS/2 will need some
platform-specific trick, though I realize the original query was limited
to Unix systems.)
--
Andy Dougherty doug...@lafayette.edu
As a brief aside, under win32 the dlopen trick could be emulated by
GetProcAddress, LoadLibrary and GetModuleHandle.
Hope this helps.
Matt Seddon.
_________________________________________________________________
Find a cheaper internet access deal - choose one to suit you.
http://www.msn.co.uk/internetaccess