Dynamic libararies are the most popular -- much smaller, but it does mean
     that it is up to the user to ensure that these libraries are installed.
     'ldd' goes a long way to checking and ensuring that is the case. But at
     compilation time, the user is often told what libraries (if any) are
     needed.

     The querent then reported back that all was right with the world and that
     he found what he was after. I suppose we call all learn a lesson here in
     that being precise is important when asking questions, otherwise your
     question may never get the correct answer! -- Thomas Adam

   (?) Anyway, another helpful soul came up with the answer on usenet: 
make prefix=/tmp/foo install.

   That is exactly what I'm looking for. With this I can drop everything in an
   empty dir, gzip it, move it to another machine and unpack it & run it. Never
   thought  it  would  be  this  simple,  I  tried  this  with  configure
   --prefix=/tmp/foo, but that's where /tmp/foo gets into the compiled files. 
            ____________________________________________________

(?) Dedicated Linux application

   From Jon Aldrich 

         Answered By: Thomas Adam, Kapil Hari Paranjape, Jay R. Ashworth 

   I am in the process of developing a linux app (for gaming). I want the final
   product to reside on a linux box that, after booting, automatically runs the
   application. What is the preferred method for doing this? 

   1) An 'auto login' for a special user on one of the system consoles, who's
   user profile starts the application. 

     (!) [Thomas] You could add something like this to the user's ~/.bashrc

[ "$(tac ~/.xsession | sed -n '2p')" = "the_name_of_my_game" ] && {
   startx &
}

     (!) [Thomas] which says that if the penultimate line starts with your game
     program name then launch X, otherwise don't bother. Why the penultimate
     line? Because the last line in ~/.xsession should ALWAYS an "exec call" to
     your window manager. Of course, should you add anything to that file, the
     number passed to sed will have to be changed.

   (?) 2) Start the app with an inittab entry. 

     (!) [Thomas] No. Doing this is deprecated and will cause all kinds of
     weird errors. What happens say, if X crashes? Each time X tries to start
     (based on the run-level X starts in) the game will also try to load, and
     so you get a feedback loop. In the case of [119]Debian, X is started
     throughout runlevels 2-5.

   (?) 3) Something else? 

   The app will produce graphics output and get user input, so it can't run as
   just a backgroud type daemon. It will run on a secure, dedicated network 

   Is there an info source or HOWTO for this sort of "bringing to market,
   implementation" kind of topic? 

     (!)  [Thomas]  I would just have it launched from within the user's
     ~/.xsession file (see above).

     (!) [Kapil] One of the lesser known methods. An "@reboot" entry in the
     crontab. This will start a program just after "crond" is started.

     (!) [Thomas] Not unless you have read: 'man 5 crontab', it isn't!!

   (?) One other small question. Is it possible to display a flash screen of
   some  sort  during the boot sequence and pipe the boot data to the bit
   bucket? Sort of a "boot -quiet" option. 

     (!) [Kapil] I think there is a "bootsplash" patch to the kernel that does
     this.

     (!)  [Thomas]  I think Jon was referring specifically to his game's
     flashscreen.

     (!) [Jay] You'll get lots of opinions, I suspect, but mine is 'put it in
     inittab'. That and (optionally) an sshd should be about it: you should
     know everything that's running in a ps, in this kind of environment.

     Make sure the bios boots the HD (/flash image) and nothing else, and is
     passworded. Yes, even if there isn't a hardware keyboard.
            ____________________________________________________

(?) Diagnosing a Linux crash

   From Tom Brown 

                           Answered By: Thomas Adam, Karl-Heinz Herrmann 

   OK guys, here's a n00b question for you that probably crosses over into Sys
   Admin territory. 

   What steps should someone follow after Linux crashes to figure out what went
   wrong?