Compiling from source...

[forkbomb]

Originally Posted by timmywear

Everything will know where to go? (/usr/local... right?)

Depends on the makefile, I guess.

If I don't get a launcher how will I launch the program aside from the terminal?

Depends on your DE or whatever menu system you use. It may "just work" (tm).

*After the program is installed, can I delete the source (tarball)?

Sure.

So if I build the rpm myself, the package manager would update it whenever a new version comes out?

Don't think so, but I'm no rpm-building expert. You'd have to note when any updates were released, download the source, and build an updated rpm, then run rpm -Uvh.

I don't plan to compile a kernel just yet.

Actually in a sense I'm inclined now that I think about it that zodiac is right. The average end user can't gain much from it anyway*, unless you're 1) obsessed with optimization or 2) need to compile in support for some exotic hardware.

(* excepting in some situations maybe kernel preemption and microcode application.)

[scottro]

Well, if for example, you built a fluxbox rpm on CentOS and only used the base repos, no, it wouldn't be updated, because fluxbox isn't in their base repo. Now, say you also had the rpmforge repo, which includes fluxbox. However, it has 1.0 and you've built 1.1. When fluxbox gets to 1.2, and it gets into rpmforge, then yes, it should be updated.

However, if you're building an rpm of a package that's already in the repos, then yes, it should be updated when the system looks for updates.

Hrrm, hopefully, that was clear.

[Hlingler]

Originally Posted by timmywear

*So besides not having the menu launchers theres nothing else to do? Everything will know where to go? (/usr/local... right?) If I don't get a launcher how will I launch the program aside from the terminal?

Usually, nothing else "special" should be required. Everything will "just know where to go" based on FSH. You can always create a custom menu launcher fairly easily and quickly.

Originally Posted by timmywear

*After the program is installed, can I delete the source (tarball)?

Yes, if you wish.

Originally Posted by timmywear

*So if I build the rpm myself, the package manager would update it whenever a new version comes out?

Mm... say rather: replace. You would of course get the newer version from the repo(s) to replace your custom build.

V

[JohnnyLinux]

OK. Thanks tjvanwyk. I will get on practicing compiling tarballs

Any tips or links you recommend I check out?
On compiling.

I do want to know what these things do more in depth... ( I keep reading general descriptions, is there more as to what they are doing behind the scenes?)

./configure
make
make install

BTW. I really appreciate all the help.


edit: I was replying the same time you guys were. Thanks Hlingler and scottro too

[Hlingler]

Usually:
./configure --help

will give all available options. Explanations of options may be more difficult. Consult included README file if available for details.

V

P.S. Configure leaves a long and arcane log file in the source folder (../configure.log) listing it's actions and output.

[forkbomb]

Eh, as for tips... it's one of those things that is really rough at first.

I'd start with (at least)

yum groupinstall "Development Tools"

and depending on how much hard drive space you have

yum groupinstall "Development Libraries"

The former should give you what you need to run most compile jobs (compilers, make, etc). The latter will install most *-devel packages in the repositories. Suffice it to say it can be a lot.

[JohnnyLinux]

Thanks.

Hard Drive Space is plenty...

Thank you!
I will get to learning.

[JohnnyLinux]

Two more questions:

*folder for preferences gets created in /home by default as well?
*To uninstall?

edit: work as root? su

[Hlingler]

If you erase the source code folder, any possible 'make uninstall' command will be lost (if it was ever available at all), in which case you're on your own (or have to repeat the whole creation process just to see if 'make uninstall' is possible).

"Standard" procedure is to run configure and make as normal user (avoid possible damage if things go wrong), 'make install' as root (required to write to system folders).

V

[JohnnyLinux]

So make uninstall is also in the tarball? Handy. Thanks.

[Hlingler]

Mm... 'make uninstall' script is occasionally in the source code. Never any guarantee that the author actually bothered... .

V

[JohnnyLinux]

What about the differences between 32 and 64 bit?

I'm running 64 bit. Would it compile everything into 64 bit?

Thanks. Sorry for all the questions

[forkbomb]

Originally Posted by timmywear

What about the differences between 32 and 64 bit?

I'm running 64 bit. Would it compile everything into 64 bit?

Thanks. Sorry for all the questions

Yes, typically code will be compiled to your architecture.

Cross-compiling (compiling for a different architecture) is possible (I've never done it, though).

[stevea]

Originally Posted by leigh123linux

I have seen plenty of users here who have broken everything by compiling python with the --prefix=/usr ./configure option .
Personally I wouldn't recommend compiling unless it doesn't exist in the repo's because of the risk of overwriting system files.

Good point .. but there are some good reasons to build from source.

Leigh suggests the primary reason - the package you want doesn't appear in the repos. Or you need/want to install a later version, You need to apply a patch. You want to customize the kernel or an app.

Perhaps most important is the educational experience. Whether you are rebuilding an existing package from source, installing some unsupported package or rolling your own kernel - it's likely to provide a lot of good insight into how things work.

[JohnnyLinux]

Originally Posted by stevea

Perhaps most important is the educational experience. Whether you are rebuilding an existing package from source, installing some unsupported package or rolling your own kernel - it's likely to provide a lot of good insight into how things work.

Exactly what I'm after
Thanks stevea
All of you guys have been very helpful.