SGI: Development

I actualy wrote a tool that did exactly that a while ago.

Cool thing was: it caught anything you did (copy, chown, mv, ...) and secretly put the stuff in /usr/nekoware_dev instead of /usr/nekoware without make (or any other tool) knowing about it :)

Oh I LOVE rld override :)

Problem is that I lost most of it and would need to rewrite a shitload again :S

I knew it! ...The idea sounded me too familiar! ...So, the script was "AutoPackager", or "Pre Requisites Generator"? ...Because I've saved both on CDROM for any future eventual need!

Heh, I wasn't even aware that's what cairo/glitz did! You're probably right - something in there isn't properly detecting/utilizing OpenGL on IRIX.

Anyway, after a little search I found this which is interesting; seems that glitz is suffering from "maintainer bandwidth problems":

http://weblogs.mozillazine.org/tor/arch ... cairo.html

The version I 'shipped' didn't have the override code with it. But that's what I was working on, yeah.
I'll see if I can dig it up again.

Cool Whiter. I'll give it a spin if you can ressurect it (although I was more talking about just building a data base as opposed to actually relocating files).

Regarding cairo/glitz....definately Linux targeted. Who knows if it makes good use of things on IRIX. I've down loaded it and will look at the code.

squeen: yeah I know, but it's the same principle. You want to capture all the stuff the system is doing when running the install, and then do something with that info.

*searches deep into old backups*

In /beta : For those folks interest in playing with the GNU Flash player + a repackage to eliminate glib erros in dia.


neko_gtkglext-1.2.0
neko_gnash-cvs20060823
neko_dia-0.95


The plugin for gnash is in /usr/nekoware/lib/libgnashplugin.so. Link it to your $HOME/.mozilla/plugins directory to get it recognized. The caveats are that SDL_mixer sounds is broken, its GTK2 based so neko_firefox doesn't like it, and neko_mozilla won't execute it. So basically as a plugin it is useless until some brave soul fixes it. The command line player (/usr/nekoware/bin/gnash) works. Probably should stay in beta limbo until the issues are resolved. A build of Gstreamer would probably fix the sound.

EDIT : I plugged dia-0.95. I've got more packaging (lib) errors.

Cool!
Anyway, and for the record, it seems that at least one of the two above mentioned packages is a son of you (AutoPackager), since it holds your name on the Guidelines Document!

they both are ;) (if you mean the prereq generator that shipped with autopkg)
I use them a lot.

anyway, I found my code and just created a little thingy that captures mkdir:


It's fun :)

Now.... Squeen... if you feel like helping out with developing this further, that would be great. I'm not such a brilliant c coder :)

Didn't know you could force everthing through a single dynamic lib? I have spoofed lib functions before by forcing my (similarly named) lib to appear in a directory earlier on the RLD_ ROOT doing something and then using dlopen to get and execute the proper function. What about statically link apps?---where and what function calls are you catching?--the shell? Yeah, I'd like to play with it....

Isn't there a restriction on rld'ing root?

Well, this is about wrapping something around the make install process, and I think we can be sure that that is all dynamicaly linked code. (We obviously don't have to worry about the way the files it is actualy installing are linked.)

Moving your custom library in a folder that appears earlier on in the standard RLD_ROOT sounds a bit like a non-nice way of doing it. :)
_RLD_LIST was specificaly designed for adding custom libraries that are not in the library paths to the list.

I know about no restrictions. I've succesfuly overridden loads of syscalls. The biggest problem I'm facing is "How the hell do those va_arg things work in irix?"

My wrapper function needs to be something like

int theSysCall(const char *path, mode_t mode, ...)
{
* do override stuff here *

* call the original method here with all the args, but we don't know how many we got or what type they are *
}

:S

I don't know if you can make a general wrapper function since dlopen needs a specific prototype and library in order to find the spoffed function. All you can do is target a certain number of syscalls and make a specifc wrapper for each...I think. There is a general problem IIRC with passing varags to another varg function (e.g. printf), which might be lurking out there. Hmm....things like mkdir() are C functions, but how is cp implimented...by read() and write() in the shell? Maybe we look just at gmake and see if it uses the system() command to send it's instructions down the pipe. In which case we just intercept system() and parse the commands for one's we care about---hell for that matter we've got the source to gmake, why not just patch it in neko_gmake to make a database copy of all commands executed as root or when a specific environment varaiable is set? Yeah, why come in through the back-door when the front-door was left open?

Am I re-inventing your wheel? Have you got this all working already?

On line #1987 of job.c in (g)make-3.81 is a function called exec_command might be fun to just put a print statement in there that echoed the command string.

hmm... partialy :)

I did get underway with implementing a wrapper for all possible syscalls and outputting useful information to a log. However I did NOT yet look at gmake to see what command it actualy uses. Also I think that's not gonna cover everything, because I also want to catch it if a program adds a line to this and that system config file. read() and write() are very important ones to catch then, because gmake will probably just do system('somecustomshellscriptthatdoesalot.sh') in that case.

The list of syscalls I looked up that need a wrapper is as follows:
A long list, but some are more important than others. :)

I had done a load of those already (ones with static number of args) but lost that code. However I do know how to do it again. It's not that hard.

The varargs are a BIG problem though. As the very fine FAQ points out:
And then the question is.... what to do with the wrappers :)
I wanted it to do all actual writing in a separate diverted location, so packaging it all up is very easy then. But possibly just recording all changes in a log, and then writing a tool that reads the log and generates an idb would be nicer. Loads of options :)

ok... static things are indeed a problem :)

'ln' is staticaly linked so overriding symlink(char *, char *) doesn't have any effect.

Any ideas ? :)