Anyone else have this problem with open source software?

Post Reply New Topic

I download open source software a lot, and sometimes it comes as source code, not as an executable. So I go into the directory that contains the makefile for the program and type "make", just like the README says. When I do this, gcc invariably issues compiler errors after attempting to build the software from source. And they don't seem to be "Works on Linux but not on Mac" type of errors. They're usually more along the lines of "Function con() in src.c is undeclared.", which would produce a compiler error no matter what system you try to compile it on. I don't get it. I wish I was more skilled at computers.

I am not really a C programmer but what I think is happening is
related to dependencies... There are probably older libraries that
are missing newer functions and somehow those were overlooked
before compiling. I don't know for sure if that is the problem but
occasionally even automatic dependency checking might miss
this, especially if the code normally shares libraries with other
software that is not very often used on your specific OS.

OSS doesn't mean universal to all OS and systems. I write OSS
for unique systems, but it is well commented so that programmers
can rewrite it for whatever they want to run it on. OSS just means
you can see code. If you want it to work, look for source for your
specific OS type, for example many Linux can use Debian packages
easily.

I've had that trouble too. I usually just go through Synaptic on Ubuntu and get it to install it, that way I don't have to worry about compiling. I know a bit about the OS, but not enough to do that.

You can also try checking source forge and other sites, they ought to have executable versions stuck in there somewhere.

I found an interesting piece of code in ogg_to_pcm.c, the C file that the error was in:

Maybe different operating systems use different C libraries? I looked in my /usr/include and I actually found a file called malloc.h, but it was in /usr/include/malloc, not /usr/include.

In any case, I changed it so it includes malloc/malloc.h, and I still got the same compiler errors, so I don't think it made a difference. I just found it curious.

Sometimes there is also a configure script, so you need ./configure before make.
Sometimes the configure and make need to be run as root / superuser because they write outside the home directory.
Sometimes (most likely one) there is an unfulfilled dependency, i.e. another package containing the header and functions that aren't declared.

Mostly I put it down to sloppy file management and undefined standards. Downloading through the package manager is preferable whenever possible. The relevant forums for the operating system are very good. I find that Googling for either Linux or the OS name and the exact error string often gives a solution.

This is very true. You may find a README file along with the code, which should help.


The sequence is often:
As a normal user:

Then, and only then, as superuser:



Dependency problems don't give compiler errors.


Much of the Linux source code tries to be compilable and runnable on a wide range of hardware and OSes. Sometimes it doesn't quite get it right.

When I write code, I try to use as few libraries and outside code as possible. This is because I know how frustrating dependency hell can be. I do have to admit that most of the software that I write do not form very big packages. When I do need to use code from another project, I try to bundle that project along with the code I have written (giving the author full credit of course).

I remember compiling stuff on Mac OS sucked a lot. Macports is generally good for automating the process, if it has the package you're looking for. There's also gentoo prefix which might work, now... I only tried it just after 10.6 came out and it didn't work too well, but neither did anything else at the time.