This thread is to discuss the article titled: Compiling Programs from Source

A most helpful article, however I would really like to see an article on how to compile on any RH version, since they seem to make it their mission to create a distro where compiling anything is impossible.

The trick to compiling on ANY distro is to have the development packages installed, this would be things like GCC, make, binutils... The reason RH and some of the other RPM based distros tend to leave these out is because they provide RPMs and would expect you to use those RPM's provided. It's just a different way of thought. They still do provide the GCC et al tools, you just have to install them yourself, or rather, knowingly install them.

That's where the trick comes in

Cool

Just two brief remarks:

shouldn't that be tar -zxf linuxquestions.tar.gz, i.e. the minus before the options is missing? Or isn't it necessary here?

And secondly, after a long time of experiments I found out, that some programs expect to be placed in special places in the directory tree. Then one has to specify e.g.

to get the executable (?) placed correctly (in this case in /opt/kde3). See also this thread ./configure - make - make install can't work ?!?.

P.S.: Why don't I get those nice lines before and after "code"?

Hehe, now it works. Nice.

Use the [ code ] brackets without the space

And no the - isn't necessary.

Cool

I copied from the original article via CTRL-C / CRTL-V ...
Aha.

I found your article informative. But, I don't understand how to remove a program, how to uninstall it when it is no longer wanted.

That's the tricky part as with source there is no "set" way. You can look into a program called checkinstall:
http://checkinstall.izto.org

This is probably considered as close as it gets to "make uninstall". Which brings me to my next point:
make uninstall
This is sometimes an option that the programmers will put into the Makefile. If they do, lucky you, all you have to do is type that when you are ready to remove the program and you are done.

The main reason for sources not having a universal way of being removed is that during the make install process they are simply copied over to the necessary locations. If the developer didn't write a make uninstall to rm everything from those locations, there is no way for your system to track them (without something like checkinstall).

Other options are available for things like this, check the LFS forum on this board for more info.



Cool

I hope I don't say anything so harshly that it offends, it's not meant to.
I ASSume that this is geared toward people who have never installed from source, so I'm critiquing it as such.

I disagree with the ordering.
The first thing you want to do is read the README (or equivalent) file and learn what special needs this program has (libs, make arguments, env vars, maybe it doesn't use autoconf, etc.). I guess this would be the second thing, after untaring the package.
The next thing you want to do is follow the instructions in the README on how to build the package. While autoconf is quite popular, it's not the only way to build and distribute a source package.
In the HOW-TO, the note about the README and INSTALL files seems a little lost. Basically, I think that needs to be more obvious and expanded upon.

After reading the README, ./configure --help should be, in my opinion, run. Again, this is mentioned in the HOW-TO, but most READMEs don't actually say much about all the possible options, and the best way to see what you have available to you is via configure (if that's even available).
The user should learn as much as possible about the package they are installing before they jump in and start dealing with error messages because, "bash: ./configure: No such file or directory".

Non-uid0 users can't usually write to /usr/local/src, so maybe you should recommend a "sandbox/src" directory under their home dir for downloading and building packages. Or, one would have to change permissions on /usr/local/src. I have both a ~/sandbox and a /opt/src directory available to normal users. /opt/src is for global packages, and ~/sanbox is my personal playground. Non root can write to /opt/src, of course.

Maybe mention that ./configure --with-blah can enable option blah that wouldn't otherwise be enabled.

You might also consider recommending checking MD5 sums if they exist. This will help to bypass any problems with long downloads, noisy lines, cracked hosts, etc.

Just a few of my comments, I'm sure I could come up with more. . . I like it so far, but it does need work--it's always great to have a start.

1 members found this post helpful.

be carefull with "make uninstall"

If it is improperly made it can delete a lot of files you need.
There is on such program I have seen.
I believe it was an issue with one of the sources used in LFS 3.?

=====
Great article. Left me with a few questions though:

I have been untar-ing my source files in random directories inside my Documents folder and compiling from there, rather than using /usr/local/src. Apart from being a little messy, is there any harm in doing that?

Once the (./configure, make, make install) process is complete and the app is working correctly, can you safely delete the source files?

Is there any need to close all open apps before installing?

Is there any need to re-boot after installing?

Must you install as root or can you install as anyone?

Just a guess, but are you coming from a windoze background

It's a good habit to get into to untar your files in a central location, just for ease of locating them and keeping the system tidy, but with my experience I've not had a problem untarring files anywhere I can and using it from that location to do the rest of the work to get it installed. Just choice.

Yes, removing the source to save space is a great way to gain back a few hundred MB sometimes. However should you need to uninstall the program, it's usually a good idea to at least keep the tarball handy.

No, you don't normally need to close all open applications You might consider doing that on MAJOR upgrades of important system files, but as a rule, no. If you are upgrading an open package and you can shut it down, it's probably a good idea to.

Re-booting is a thing of the past my friend. I install applications constantly on my server, yet I have an uptime of over 50 days (and that's really low). No, there is usually no need, the only exception might be the kernel and there are those who have said they don't even need to when they do that.

You don't have to be root, however you will need root privileges. Search the board and read up on 'sudo'. It's using a user, given certain permissions, to do things that root would normally do.

HTH

Cool

ok i'll "bite"...

1) no it's ok, but very messy. there are real benefits from using a standard location though.

2) you can, yes, but you would be advised to leave it there if you wished to uninstall it. jsut go back to that directory and run "make uninstall" and the application will be removed normally. (this is a per program basis though and not controlled in any way). to reduce spoace you can run "make clean" to delete the temporary compiled data in that directory if you wish.

3) nope

4) nope, unless it's a really core piece of software like glibc (which you really don't want to go near)

5) installing as you will mean you can only install it in places you have access to. on a very large nertworked system people may install their own software to /home/user/bin or a similar location they create themselves. this alternative location would be specified at ./configure time. e.g. ./configure --prerfix=/home/user/bin. it's best to configure and make as non root for mild security benefits, but actually installing them in /usr/bin or such like will require full rioghts to those locations, which *only* root should ever have.

>>Just a guess, but are you coming from a windoze background

hehe, it's obvious isn't it? I'm about 1 month into Mandrake after 10 years of Microsoft. :-/

I'm happy to forget rebooting - it takes a very long time! I still find myself logging in/out to swap between root and user very regularly, I'll look into this "sudo" thing to save time there.

As long as you remember how important the root user autally is and how you shouldn't be messin' with him when you don't need to.