Welcome to the world of "compile from source"!
It seems to me you have some fundamentally flawed concepts of how the whole thing works, so let's start from the beginning.
Broadly, there are 3 methods of software delivery (I will deal with Slackware specifically, but you could adapt to any other distro easily):
a) Slackware packages
b) Binary packages
Slackware packages are installed with installpkg and usually have the extension .tgz. You knew this already, so I won't bore you with the details. Suffice to say that Slackware packages contain the program binaries and just plonk all the associated stuff into your system, and then log it (ls /var/log/packages/) so you can later remove it with removepkg or, if you were so inclined, by hand =) Anything of the Slack cds will be a Slackware package.
"Aren't binary packages the same as Slackware packages?" I hear you cry! Well, yes, and no. Slackware packages can contain binaries, and so are a type of binary package, but binary packages are most definitly *not* Slackware packages. Binary packages don't use pkgtool at all and don't keep track of where they're putting things (no /var/log/packages/ entry for them). The Java runtime environment and the nVidia installer are both good examples of a binary package. Anything that contains an architecture (i386, i486, amd64, x86_86, mipsel) in it's filename should be a binary package for that architecture (this sounds like another topic, so I will leave it for now!).
Finally we come to the compile from source situation. The general rule with compile from source is:
1) Unpack the archive (tar xfz foo.tar.gz )
2) cd foo
5) su -c 'make install'
You can read the Makefile if you want to know what make, make clean, make install will actually do. In your case, you've been building the programs but failing to install it. I would advise reading up on checkinstall and replacing step 5 with:
5) su -c 'checkinstall'
Then instead of having this program installed straight into your system without tracking where it's putting everything, it will make a basic Slackware package and install that. So you get your /var/log/packages/ fix and things are all hunky dory!
This works for pretty much everything unless the readme / install files say differently. It's worth noting that a lot of the time people use "generic" readme / install files that don't always directly reflect the useage of their own files.
You can check what "make" options by reading the Makefile, maybe you'll understand, maybe you won't - have a squint at a few and do some reading if you're interested. With ./configure you can pass --help as an argument and it'll show you all the other options that are relevant to that configure script.
So, now you know about some stuff, let's deal with specifics.
So far I've downloaded and installed gtkpod. It needs libgpod.so.0 ...
Good, you've found and dealt with the dependency. I don't want to confuse the issue, but if you are building from source - you usually need to build the dependencies first and the program after, since one sits on the other. This leads me to believe you have downloaded a binary / Slackware package of gtkpod (maybe from linuxpackages.org?).
Let's assume that you can just install libgpod and gtkpod will work ... if gtkpod doesn't work, then you'll have to reinstall it later, but that's a real-life situation and this is just theory work =)
So you run `./configure && make && su -c 'make install'` in the libgpod directory, and it should configure, make and install itself. Voila!
In reality I would advise running something like:
~$ ./configure --prefix=/usr
~$ su -c checkinstall
Once it's installed, there is very little reason to keep the directory. Some programs (read: software) have "make uninstall" as a part of their Makefiles, so you could archive up the preconfigured directory and if you needed to get rid of a program later, untar it and run make uninstall. I prefer the checkinstall option, personally.
where should I put the file I'm installing to do it properly?
Just so we're abundantly clear: make install will do this for you, lib or program, or anything else you can think of. No need to manually be moving stuff around =)
Alright, so that's not true for 100% of the cases, but, in those cases you'll probably only have 1 binary file to move ... in which case, you can still use checkinstall to log it - go read up on it =)
I hope that's cleared up a few issues and helped you out!
- Piete "Argh! Not Another Essay!" Sartain.