My system is FC3 with yum update done. Few if any other updates have been done to the system as I have installed it just yesterday. Even so, in the past I have tried it with many updates installed via various repositories.

I've gone to www.kde-look.org and www.kde-apps.org and downloaded a few of the goodies from there. Alas, most want you to compile their code instead of doing the work themselves. Hehe, I remember back to when Steve Jobs was telling his guys that if they can shave 5 seconds off some task and that was multiplied by thousands or even millions of users they'd be saving alot of time.

My question is, what are some of the factors that are keeping me from using these programs? What am I missing? Why are there so many programs that fail to compile while so many are there that can compile?

I have successfully compiled programs such as superkaramba, smb4k, amarok, among a few others. I did this today. So, I know I have the libraries, etc., installed as well as the compiler and the necessary KDE extras to enable me to compile such programs.

But I am encountering a large number and I do mean a large number of programs that I download that will not compile. It seems that nearly 100% of the time the ./configure appears to work properly. When I go to make is when they fail often times after long churning and dumping out all sorts of unuseful information that a user would never understand nor care to understand.

Well, I sort of don't understand the state of mind with the current crop of authors. It seems we have a group who are trying to create something without actually knowing and doing the hard work to make it work right the first time.

I had one guy state that all ./configure, make, make install are standard across all distros. This is sort of hard to swallow. Distros, often times, are dramatically different. This ./configure, make, make install are looking like, at least to me, as dead technologies becoming unworkable by the average user. I am dismayed to the point that I feel I need to try to understand what is going on so I can fix some of the amateurishness I find in these files. I wish we had a momma linux who could/would drop these guys drawers and publicly spank them, heh, so they get the picture that they are acting badly and not in the best interests of the end users.

Anyway, I am starting to question whether these guys have the skill sets to create these programs and whether that is helping or hurting the linux community. Nothing like a bunch of amateurs trying to impress everyone and doing just the opposite, including those evaluating the software.

I like linux yet I'm becoming very disillusioned by this junk that's being put out. Typically there's no documentation about how it should be installed or about missing and required files/headers/etc. The make file contents are excessively long with nearly no intrinsic value that the average user of linux can work out.

First of all is this a serious question or a rant?

If it is a question, then the answer is:

There are binary downloads available for almost everything out there. Try a different distro like Debian which has over 10,000 pre-compiled binary packages available for instant use in their repositories. Finding a software is merely searching their repository. No need to go frantically googling around for dependency programs either.

Installing a package in a system like Debian automatically takes care of dependencies. No more dependency hell. Compiling will be limited to a very very few apps out there that are not available as binary.

Try another distro. Seriously. Fedora is a pain when you want to install software and keep them up-to-date.

When you run make, you get huge loads of rubbish which is totally irrelevant until something goes wrong. Then you have to go through the output to locate what went wrong and what was missing. There are error messages imbedded in there and the first few will probably be the ones that will clue you in to what you need.

There is another question implicit to your confusion, which is "Why do you have to compile them in the first place?"

Part of the reason is all that stuff that spews onto the terminal when you run make. Part is due to the fact that linux distros vary wildly and getting users to compile their own software helps make sure it will run well in the system it is compiled in. It is also easier to get the user to edit the top level makefile themselves than to write the software that autodetects all the myriad possibilities so to automate the installation.

However, usually there will be rpm releases for anything designed for normal users (as opposed to programmers or "hackers" - in the sense meant by MIT AI labs rather than the oxford dictionary sense.) Software released as CVS or Source only are intended for programmers and are normally works in progress. Once a standard is attained, an rpm release will be forthcoming.

Sometimes this is programmer lazyness... remember: these guys aren't getting paid! Putting together an rpm release for a specific system is not actually all that hard - if you contacted the author and offered to pay them, I'm sure they would be only too happy to oblige!

The things you can get via YUM (for eg) have all been vetted, so they will install without a hitch. Not all distros support yum. Some are just too different. However, these distros probably have gcc with the standard libraries... so you can still compile the source!

You'll notice that M Player is available as an rpm for fedora core - but you are recommended to use the source-code installation ANYWAY! This is because you can tweak the source to your personal specifications instead of relying on vanilla defaults for some imagined generic system which is probably not compatable with your system anyway.

One way things become uncompatable is from updates... it is not uncommon for an rpm install to fail because a key dependancy is more advanced than the rpm expects. This is not bad programming as such, just that programmers cannot anticipate all the advances in the industry. After a bit, usually to a schedule, a new rpm is fourthcoming... alternatively the software will not be supported.

As stated, this is not for the standard user. You read it like you do a technical manual - skim for the rror messages and try to get a general feel for what it's telling you. Then you go to the support site for the software and see if anyone else has had the problems before. Usually they have. I normally find that I've missed something in the installation proceedure, like edit a particular makefile, which is indicated in the instructions. Sometimes, I'm just missing a library. YOU should be looking for rpm distributions of the same or similar software - try www.rpmfind.org - or simlar.

A bit like Microsoft really
Perhaps you should have a look at how the open source system is supposed to work?

Remember, if you can only get a source release, then it is most likely a work in progress. You are supposed to try it out and provide feedback.

This is what is meant by "platform independant".
And the guy is mistaken anyway.

Not all makefiles use the "configure, make, make install" pattern of commands. They can call it anything. For a good example, look at the Nethack and Falcon's Eye installs. (Though rpm is available.)

If you have been following the pattern without checking the documentation that comes in the tarball, then you have only yourself to blame. Most likely you need to edit the top makefile and maybe another one in a subdirectory.

Well it sounds like you may be looking in the wrong places for your software. Me - I have had most trouble with yum installs and updates... I will use rpm as a first option but will compile from source if I really want the thing working best out of three. I have seldom had trouble with compiling. I prefer this method as it tells me exactly what is happening and provides maximum flexability.

A good example is a kernel upgrade...
make xconfig
make modules
make modules intall
make install

etc... is roughly the process folk follow.
Though I can upgrade the kernel from rpm or yum, it will only install the new kernel for my existing settings... if I want to take advantage of the newer features of the kernel (for a later HW install for eg), I'm stuffed.

It is tempting to suggest that when you can program, then you should critisise the programmers... not really right: as a user of these programs you have a right to be pissed. OTOH: how often does windows crash for you? Most win shareware requires you to copy the files to a directory and then, perhaps it won't work and won't tell you why not. AND MS keep putting out windows versions that keep breaking because they've not quite ironed the bugs out yet but here it is.

What I'd like to see from you is a specific example... of those many many programs that you have failed to install... pick one (or five) and explain what you did and what happened. tell us the error messages. Most of the time, it is the user who has stuffed up!

Simon

Harishankar, I don't agree with you when you say Fedora is a pain when you want to install software. Fedora has the same tools that are available in Debian based distros for managing its packages and if used right, then package management is fairly easy.

Jimbo99 when you say packages fail to compile, there is always a reason why a package does not compile and usually configure or make scripts point you in the right direction, so that you can fix the problem and install the software. Usually its because you did not install development packages or there are some other unmet dependencies that you could install using apt or yum. To me, your post just seems like a rant, but I am not quite sure that you actually understand Linux/unix package management.

When I used Fedora I could never get yum or up2date to work properly. I always used to get problems. Maybe, as you say, I didn't use it properly.

But once I went to Debian, I cannot go back to Fedora. No way.

None of you answered my question, sorry. Can you tell me of some of the common things that contribute to a non-compile when my system obviously is setup to be able to successfully compile? I'm not so new that I don't understand that pre-requisite packages need to be installed at times and that the error messages sometimes have something useful to say. I totally disagree with the idea this these ./configure, make, make install files are for a select few. In fact, this has never been demonstrated in the linux community--just the opposite--linux folks have continually required the average user to use those files.

My point of my post is that the information spewed forth from the compile is not useful. If I were a programmer yeah. But I'm not a programmer these days.

I have read the error messages and find them to have mostly no value, and when I inquire about what they are or what they mean, the authors of the programs, those that posted them on KDE-APPS and KDE-LOOK do not respond. In fact, they almost never respond to anyone.

More indication that these guys are amateurs.

Sorry, it was a question tied to a rant fed by a large number of aggravating failures to compile from self-professed programmers who won't assist in problem resolution, writing clear documents, addressing possible bugs, and giving advice when a compile of THEIR program fails.

You see, producing something, anything, that you put into the public eye must be documented and fully address the possibilities of failure and solutions to those. Clearly these guys failed to address any of their problems with testing. It is almost like they just installed it on their machine (of which they tailored to get their program to compile on their machine) and did nothing else, not even list dependencies and the versions of those dependent files and/or where the location of those dependent files should be located on the computers.

As for the pre-compiled binaries. This is a non-starter for you guys as infrequently are there binaries for distros. When there are they are limited in the number of distros for which they provide the binaries, or they are much older versions with their own set of bugs and issues.

I know about apt-get, yum, synaptic, repositories, etc. I have 4 different distros here where I work and trying to get binaries for them just doesn't work as most of the time they are non-existant. I know about the rpm repositories and sourceforge as well as the author's web sites.

But you have to think in terms of the sheer number of distros. If you think about that then think about some recent journalist commentaries where they promote linux's success but won't commit to linux themselves as there are far too many distros and too much variety even within the distros releases themselves.

The whole idea is that this is a public OS now. It isn't private made by a few for a few where a few outsiders tresspass on their range. This clearly is a group of individuals who are quite amateurish in their skill, all trying to pass off their code as quality--because, if the code isn't quality don't freeking put it out into the public until it is.

I made the point that I was able to compile and I was have seen some good ./configure scripts. In fact, the amaroK configure script is quite impressive. If you don't believe me, take a look at it. Everyone should be writing scripts that actually look for and evaluate their specific package's requirements like amaroK does. The problem I have noticed with alot of these programs is that they actually are not writing a good configure script as they are relying on the generic scripts to handle their needs (generic in the sense that they are letting whatever package they are using to create the configure make alot of the decisions or they are just copying other configure scripts and not doing enough research to identify specific needs of their own program).

The fact that there's such a huge following for sourceforge.net should demonstrate to all of you that the concept of binary packages is a non-starter for any argument. If these guys were truly professional they'd have distributed their programs in the above described fashion from the start.

Frankly, the whole configure, make, make install sould be foreign to everyone's consciousness. But can we honestly ask a single programmer who writes his new bit of code to create packages for every distro and even the wide range of variation found in various releases of that same distro? Hence, the need for something else and forcing the end-users to seek out a wide variety of rpm (or other package type) repositories is also bad.

Next you'll be saying that linux isn't for the average folk or that linux users MUST pay someone to maintain their systems. Just the opposite. It takes the average folk to make an OS a success. These amateurish programmers are hurting linux more than their tidbits of cute code are helping.

As far as I can tell the rpm repositories are also non-starters as they often have such old versions and the authors of these program rarely if ever place their compiled versions in those repositories.

This means that individuals who are evaluating linux are finding that linux sucks when it comes to applications with the idea of "trying to not be like windows" (when it comes to distribution of packages) hence not creating a universal application installer that is independent of distros can't catch on.

Frankly, it is an injustice to ask any linux user to go looking for repositories for RPMs that are distributed yet create huge deficits when it comes to dependencies. Those repositories are not helping in the dependencies problem which in case you guys don't remember is about 1000 times worse than any dependency issues found in windows at the time when it was the worst.

Debian is way too messy for the average user. It requires significantly more technical knowledge to get debian installed and running than it does to get FC3. I have not had problems with yum. In fact, it is pretty simple. Install your distro, and in a shell type:

yum update

Then just wait while the packages are downloaded and installed.

The issues aren't necessarily with that series of steps with yum, it's with determining which files are important to your workstation and the travesty is in the possibility that if you leave something out you could suffer serious problems sometime down the road. The end result is a computer full of a bloated distro like FC3.

??? who ever gave you this idea? Nobody is asking you to use it, if you don't like it, then don't use it. While it is open to anyone who wants to try it, until recently there was not many large efforts to make linux more accessible to the less technically inclined. And really, why would there be? Now, you have already stated you are not a programmer and do not understand the error messages from the devel tools, but you know amateur code or quality code? Bottom line, this is open source, you have the option to use it or not, and while you use it you can also modify it any way you like. Actually, I take that back, you are encouraged to modify it any way you like.





is the problem the gnu autotools ( configure and friends) or the end users? I'm going to argue the latter on that one. Go through these forums and look at the threads, after awhile you start to notice that most of the people who bitch about the tools have never even attempted to learn about them. I do agree, some configure scripts are better than others, but if you know what you are doing the all of the problems from your rant are just minor things that do not pose a problem.

Quote:

Next you'll be saying that linux isn't for the average folk or that linux users MUST pay someone to maintain their systems. Just the opposite. It takes the average folk to make an OS a success. These amateurish programmers are hurting linux more than their tidbits of cute code are helping. As far as I can tell the rpm repositories are also non-starters as they often have such old versions and the authors of these program rarely if ever place their compiled versions in those repositories. This means that individuals who are evaluating linux are finding that linux sucks when it comes to applications with the idea of "trying to not be like windows" (when it comes to distribution of packages) hence not creating a universal application installer that is independent of distros can't catch on. Frankly, it is an injustice to ask any linux user to go looking for repositories for RPMs that are distributed yet create huge deficits when it comes to dependencies. Those repositories are not helping in the dependencies problem which in case you guys don't remember is about 1000 times worse than any dependency issues found in windows at the time when it was the worst.

I realize I'm probably just pissing into the wind here, but what you are stating that you want is contrary to the whole point of open source in general. Have you ever even looked at the GPL? If you want an operating system that holds your hand and does everything for you, I'd say you are in the wrong place. While there are options for you in this regard, everything comes at a price ( I am not referring to $$$). Anyway, my whole point is in the *nix world, if you refuse to put out the effort to learn ( this even implies from distro to distro), don't expect to gain anything in return. And try not to forget linux was created by programmers for programmers ( hence the "open source"). It's getting better in terms of being more user friendly, but It's definitely not there yet ( who knows if it will ever be?). Also don't forget no-one is getting paid for their contributions, who is going to spend THEIR time they could be with family or friends to make it more accessible to those who will not spend some time learning the way things work?

You are mistaken in all respects... we have answered your questions. I have replied specifically to each question you have asked. Please read more carefully.

Linux community does not expect anyone to use the source compile routinely. I don't understand why you insist on the opposite of explicit policy (see for eg. the fedora forum rules and the GPL) I would like you to provide a list of ten software items not in development which are only available as source code. You do that and I'll show you the rpm distribution or give you the yum instruction to install. If you do not do this, we will all have to assume you are just stirring.

my sentiments have been echoed by others who have posted in this forum. We gave you pointers as to what could be going wrong. If you don't understand ./configure and make errors, post them and people who do understand them will help you out. Your post make a mockery out of the Linux and opensource community as whole and the people on this site who offer their help, time and code for free. If you don't understand something, its better to make an effort to learn it than to go on unnecessary rants.

The thread was started by a guy with a fair few posts under his belt - he knows the rules and his way around: he's been around the block at least once.

So I figured I'd have a look at some of his other posts, just to see if he has a habit of this kind of ill informed ranting. And most of what he writes seems considered and sometimes helpful. Moer recent posts have started to show the kind of blanket value judgements as above but only a little.

So (again) I got to wondering how he got to this point... and had a look at the sites indicated in the original posts... you know: kde-looks and kde-apps.

After messing around in there - I find myself glad I didn't happen on them earlier or I would have been similarily frustrated. Here are hundreds of neeto sounding things with links to download source tarballs and little or nothing to illuminate this process.

After a bit, and since I know that other forms must exist, I discovered that the secret is to go to the developers web site and follow those links... these will take you to an rpm repository... but even then, the novice finds him/herself in the dark... the whole style of the page changes from "click here" to "hunt it down".

In some of the top developer sites (those with the highest ratings) though, I found something that would benifit all those who hate source or rpm installs... apparently it is possible to install all the top apps et al with yum install <package> ... no more dependancy troubles, no more makefiles. But you've got to have configured yum to look in the right place - the sites tell you how to do that too.

However, this isnot exactly easy to find if you are new to how things are done... especially not if you prefer to be spoonfed by Bill Gate$.

lol, I've been going to those two for years and they never have changed. It always has seemed ( to me at least) like distro wars on those sites, with devel's refusing to give source code, or providing *only* distro_x packages, etc....

Top 10 reasons a source compile may fail:
... most of the below have appeared in answers previous in this thread.

1. You lack something - usually a library ...
I know you think your distro is complete... but it isn't. It cannot possibly be since there are libraries coming out all the time. Even if you have only just done "yum update" that won't get everything.... only those things you already have. If you ain't got it, yum don't update it. You also will find you'll have to use yum install sometimes to get additional library packages. Most commonly missed are development packages.

2. You missed a configurations step
The first step in compilation is to edit the makefile. Usually this is deliberate, and there are a whole list of configuration options written in there for non programmers to use. Normally it is a matter of uncommenting a vital line referring to your system. This is usually, but not always, spelled out in a "readme" file.

3. You unzipped the tarball somewhere unexpected
This is like #2 - reading the instructions helps... if you must stick the tarball someplace other that what the programmer expected then you also must edit the makefile...

4. You don't have an app installed which is used or referenced by the one your trying to compile
mplayer is like this ... however, there is usually something in the readme about what you needed. Not always, sometimes the clue is on the page you got the tarball from and you didn't realise that it was referring to an actual program rather than jargon.

5. The program expects an older library than the one you have installed
this is a hazard with older software ... after a while, the library developers find the backwards compatability takes up too much unweildy code and any nobody in their right mind is still using it... are they? - If this crops up in newer progs, it is a programmer blue ... you can fix this by visiting the developers webpage - there will often be a patch or a newer version of the tarball. Faling that, winge to the developer.

6. A library you have has gone bad somehow
law of entropy, if not Murphy, indicates that data will become corrupted over time. Sometimes it's just a bad install. Unlikely but if you do a lot of automated installs this can happen. You have to remove the library and reinstall it.

7. You have a source code which is optomised for a particular distro ... so it will be iffy on others depending on how much you depart from the developers favorite thing.
I've seen this mostly from debian developers - they have this community thing and some will "support" the community by not really getting thing exactly right for others - this is politics. However: normally the readme file will tell you what distros have been tried with what results ... if your distro is not on the list, then you cannot expect it to work.

8. GCC is having a bad day and hates you
this is actually serious ... I have had others compile source on my machine and the only thing different is the person doing the typing. Actually I suspect there's something I missed which dosn't look obvious - like an extra space or a dash or capitalisation like that.

9. The software calls for Xorg86 and you use Xfree86
more likely to be the opposite way around for FC3 - and FC3 gets around this by providing all the Xfree directories with the right names and simlinks. You shouldn't see this one - if you get it, or something similar (a new kind of system has replaced an older one which is still in common useage) it is a sign you have accidentally deleted a vital link. Hah - I remember the trouble I got into doing rm * in my home directory... this leads to...

10. You have accedentally messed something up in your system so it is now subtley non standard
you see this where someone reinstalls the OS and everything works ... it was probably possibly to track the fault down but with a system the size and complexity of FC3, that could take a while. Regular backups can eliminate this.

Right - all these are personally experienced or witnessed in systems which were touted as "complete" and, even, "developer level". So you never know.

Again - ask specific questions for specific responces. Give examples!

Yeah, well this was my first time :/

Interestingly, I've been hunting for KDE configuration stuff for ages and have never googled these pages - must be some sorf of indigtm - indightment - indietmin - indication. (I could spell this yesterday...)

Much seems to depend on the early experiences - at my start I didn't even know about LQ and stumbled upon it by accedent while looking for this fabled "linux community". As a result I've come to appreciate the enforced self-sufficiency required.

I paid for a book and some of my earliest advise came from the mad dog hisself - which made me think the community must be quite good to be in. And there was no infuriating helpdesk type "assistance" like "have you switched the computer on?"

However, I scratch-built my own computer in 1986 and was programming that in machine code ('cause my dad wouldn't get me an apple II) so I was already well into nutting things out. People who are brought up on spoonfed "solutions" will have a dimmer view from those shakey starts. Lets face it, Linux is not really for the "average user" - the average user dosn't know where the "any" key is!

I think there's a point in there somewhere...