SEARCH

Enter your search query in the box above ^, or use the forum search tool.

You are not logged in.

#1 2012-03-21 23:38:09

gensym
#! Junkie
Registered: 2011-10-17
Posts: 447

How-To Building Programs From Source

<Preamble>

Debian repositories are HUGE, but there is always that one particular application that you burn with never ending desire to use (be it a Window Manager (WMFS), Browser (Jumanji), or  else) but sadly isn't in the repos. Although there are more than one way of getting these applications (more repos!), the one we will cover here will be building these applications from source.

If you want to know how to compile a certain application reading the README file in the source code should be the first step for you. This how-to only focuses on certain know-hows on compiling applications and getting some familiarity with build utilities.


</Preamble>

<Some useful applications>

apt-file

I have a soft spot in my heart for yum, mostly because of its whatprovides option. For those unfamiliar with yum

yum whatprovides $resource

gives you the names of the packages which provide the resource $resource (this becomes extremely handy when you are searching for developement headers et al.).

Sadly the best Debian can do by default is 'dpkg -S $resource' which provides a similar feature, but if and only if the resource is installed in the system.

Here comes apt-file to the rescue (it isn't in the system by default, you have to install it from the repositories using your favorite package management tool).

apt-file update

fetches the contents of the repositories (you can run this with or without sudo, it is a matter of preference but I choose to run it with sudo, as it then stores those  contents in a system directory instead of my user directory)

and

apt-file search $resource

which tells the packages which provide the resource.

Most of the problems you will have while compiling applications will be due to missing dependencies. Reading the error message to see what is missing, using apt-file to find out which package provide that and installing it with apt-get or else generally works like a charm (unless the application you want to build depends on a specific version of that file, then things might get a little messy).

Basic tools

To compile things you will need some basic tools like a compiler, a make utility, certain auto configuration utilities and etc. Most of these are provided by the  cb-welcome script's development tools section, if you don't have those tools installed something like

sudo apt-get install g++ gcc make python perl git mercurial subversion patch diff autoconf

should be enough to get your feet wet.
More could be added to this list, but most of the time the packages you need are relevant to the programs you want to compile (i.e you will need libgtk-dev for gtk applications or libxft-dev for programs that support xft fonts)

</Some Useful Applications>

<Dramatis Personae>
This section is meant to be used as a basic glossary.
I feel myself more comfortable using certain tools if I know what they do.
This section aims to give you some familiarity with common conventions, commonly used tools and etc.

Compiler

A compiler is a utility which creates machine code (code that could be executed by the CPU) from the source code (i.e C code). The generated machine code can be executed at any times and it will always demonstrate the behavior, that is specified in the source file.

Make Utilities & Makefiles

Think  of a program as a piece of furniture. You can buy it pre-assembled (download from the repos) or in  a form which is ready-to-be-assembled (IKEA tongue).
The thing about buying a piece of furniture from IKEA is that although it isn’t terribly hard to assemble it yourself, things might go wrong and you might end up with no furniture at all.  To avoid that IKEA gives you an instruction manual alongside with the pieces.
The same applies to software, it isn’t too hard to compile the code just using the compiler, but things get messy and we might end up with no software at all. That’s why they include Makefiles, which automate the compilation process (they can actually automate anything).
(for more about Makefiles see the corresponding section)


configure

Back to my furniture analogy: Although having the instruction manual makes assembling the piece of furniture easier, there are still problems that I must solve like finding an appropriate place for it, or checking whether there are missing pieces.
A configure script is generally what corresponds to those little tasks one must do prior to building an application.
A configure script can i.e determine your OS (Linux uses different libraries from BSD), determine under which directory it should install the binaries (/usr/local/bin, /usr/bin, ~/bin? ) and modify the Makefile accordingly or maybe even generate one Makefile.

diffs and deltas

Assume you have two versions of a 10000 page book (a first edition copy, a second addition copy).
The naive way of storing these books would be having a copy of each (storing 20000 pages effectively). Memory is expensive and such a thing is intolerable, a much more efficient way of providing the same functionality will be storing just one copy of the book, and the differences between the one you store and the other book, as the differences between the two books won’t be monstrous, the number of pages you will need to store will be much less than 20000.
The same applies to source code, when you are trying the deal with multiple versions of a file it is generally smart to have a full copy of the code and differences between that specific version of the code and the others. The differences are called diffs or deltas (one way generating the diffs will be using the Unix “diff” utility. Turning one version of the code to another can be done by using the unix “patch” utility.)

Package Management

Assume you have successfully  compiled and installed an application. Although you can use the application now, managing it might be a pain the back side. (i.e If the developer hasn’t add an uninstall option to the Makefile, you will either have to delete all the application relevant files manually, or add the uninstall option to the Makefile yourself, similarly there is no one size fits all way of knowing which libraries does this application depends on other than browsing through the source code).
Here is where Package Management Systems come to the rescue. They provide a unified way of managing these applications and all the things that are related to them, encapsulating them in packages.
-> It is for the most of the time a good idea to build packages of the sources you compiled and install them through a PMS application (like dpkg).

</Dramatis Personae>

<How to build>

Now the exact commands you need to build the program are relevant to the program it self, so there is no one size fits all solution here. But generally something like

% cd source-folder
% ./configure #if there is a configure script
% make
% sudo make clean install

should do the trick.

Generally developers describe how to compile their code in the README or in their websites (be it github/google code or else). Before you try compiling the code you should read those, else Lionel Richie might show up at your door looking like this.

Please keep in mind that compiling packages as root is a very bad idea and you should always compile files in user mode.
(=> Always run make without sudo and as a regular user)

For the make install however you will need the sudo, if you wish to move the files to a system directory.

Keep in mind that the compilation might take too long if you are trying to compile a monstrous project (i.e KDE SC 4.7).

During the compilation you will see some text being printed on the console really really fast (you don't need to be alarmed about this), if you want to read the text keep in mind that Ctrl+S suspends the compilation process and Ctrl+Q resumes it.

(some user whose name I won't tell, thought it might be a good idea to add the following (see the actual post down below if you are interrested in the original commands he posted). that being said he by no means claims the ownership of these commands)
if you want to save the compilation messages to read them later on you can pipe them to a fille with

command > $file 2> &1 # saves both stdout and stderr of the command to $file

or

comand > $file  # saves the stdout of the command to $file and writes the stderr to the console
command 2> $file2 #saves the stderr of the command to $file2 and writes the stdout to the console

(gensym edit)
A more efficient way of doing this would be using tee (available in the repos).

command | tee blargh

Would print the output of the command to standard out as well as writing it to the file blargh.

(gensym end)
(gensym: Some user -- whose name is to be kept as a secret -- made this remark later at the thread)
There are cases when there are no ./'configure' and 'Makefile' in the source root dir, but files 'configure.ac' and 'Makefile.am' exist. In that case, or if you want to mess with 'configure.ac' and 'Makefile.am', you have to install autotools builders with:

$ sudo apt-get install autoconf autotools-dev

(Somehow, I think that #! users by default install that.)

Then you go to the source dir and there execute (in that order):

$ aclocal
$ autoconf
$ autoheader
$ automake --add-missing

(Note: YMMV ... sometimes you do not have to execute all of this, it depends on particular source package.)

This will create './configure' script and 'Makefile', and then you can continue with previous instructions.

(end)
Keep in mind that if you choose to do that you won't see any messages during the compilation.

(el_koraco start)
Maybe checkinstall is also good to note. make install simply installs the package, without notifying dpkg of the process. Checkinstall is a utility for creating a .deb (or rpm or txz or whatever) and installing it. You need to

sudo apt-get install checkinstall

and instead of running make install on the end, run

sudo checkinstall -D make install

dpkg will then know of the package, and you can remove it with dpkg -r or apt-get remove.

(el_koraco end)
</How to build>

<Getting the source code>

There are many ways of getting the source code the easiest one being installing the tarball from the corresponding website. Keep in mind though: If something feels fishy (i.e the source code is being distributed on tumblr, rapidshare or etc.) you should search for a different mirror (or use a different application).

( It might be useful to give a command line way of doing this:

tar -xzvf $package.tar.gz #(or .tgz) extracts a gzipped tarball
tar -xjvf $package.tar.bz2 # extracts a bzipped tarball

)


apt-get source $package

Providing that you have the source repositories enabled (/etc/apt/sources.list contains some uncommented lines starting with deb-src) and the sources are in the repos, this will get three files for you

1) $package.orig.tar.gz
The original source code of the package.
2) $package.dsc
which contains the source of the debian package (this gets extracted by dpkg-source, you should therefore have a file like $package-$version in your working directory after downloading the file)
3) $package.diff.gz which contains the diffs between the original source and the debian package.

Version Controlling Systems

Most developers store their code in git,mercurial or subversion repositories, because it makes managing source code a lot easier for them. That being said this gives you  an alternative way of getting the source code (you just clone the development repository to your computer).
Before I explain how to do that with git,mercurial and subversion, I should explain why you would want to do that:

1) Most version controlling systems store multiple versions of a file using the diffs/deltas. If you download the source code of an application  twice -- i.e two months apart  -- the first time you will download the entire source code and some little overhead, and the second time just the differences between the two versions and the new source will get automatically generated.
2) Applying patches gets easier: As mentioned above, most version controlling systems use diffs/deltas to store multiple versions of a file. This means that, they have their subtle ways of generating another version of the file from the diffs. (i.e git has am, mercurial has patch and svn has merge).

Anyways back to the topic, you can get the source code by using

#if the source is managed in a git repository
git clone $url_of_the_repo
#if the source is managed in an svn repository
svn checkout $url_of_the_repo
#if the source is managed in a mercurial repository
hg clone $url_of_the_repo

Debian has a nice feature for building dependencies, namely

apt-get build-dep $package

which downloads the compile time dependencies for $package. 

(Please keep in mind that this might not work if you are trying to build a more recent version of
$package than the one in the repositories).
If you just want to see which packages are needed to build $package try

apt-cache showsrc $package

</Getting the source code>

<Makefile Basics>
(gensym edit)
Now that I have read this one more time, I realised that I forgot explaining a couple of very important things about makefiles
Imagine you are to compile a huge project like KDE SC 4.8 or Android ICS, It is not hard to imagine that the compilation process is going to take FOREVER long. After you compiled the piece of software you realise, that you forgot, that you initially wanted to apply a patch. If you were to compile this piece of software without a make utility, you will end up compiling every single piece of code again (or you will have to compile the specific files you changed, but finding that out might be a pain in the back side, if you apply a monstrous patch.), which is of-course something terrible. If you use a make utility however, make will only compile the pieces of code, who are modified after that piece of code is compiled. This is a very useful thing, and actually it is the main feature why we use make utilities today.
The second thing I realise, that I forgot to mention is the suffix rules. Quite often, what a compiler does is changing one type of file in to another (i.e a c source code, to object code and object code to an  executable), in order to make your life easier you can use suffix rules, which automatise the process:

i.e Something like:

.c.o:
gcc -Wall  -c -$< 

Turns c source code in to object code, which you can link however the way (well not exactly) you want. I.e if I run make test.c  (providing that both test.c and Makefile are in my present working directory), the make utility creates the object code test.o for me.
(end gensym edit)
We have explained what makefiles and make do, now it is time to explain some basic syntax and conventions used in the makefiles, just in case you will need to edit one your self.

Now think of makefiles as very primitive scripts, when you call the command make it first search for a files named “GNUMakefile”, “makefile” or “Makefile”,  if there is one it reads it and does what it should do else it complains that it couldn’t find the makefile. If for some reason you decided to name your makefile $file, you can pass it to make with

make -f $file

Now that we know how to call makefiles, lets  dig a little further:

The basic structure of a makefile is as follows:

[Declarations]

target0:
        todo_0
target1:
        todo1
target2:
        todo2
target3: 
        todo3
...
...
...

When you call the makefile with no target (that is make all or make -f $file all), it executes the chunk of commands that are listed as todo_0, if you want to use the other functionalities of the makefile you just call it with the appropriate target.

Example:

make #executes the chunk todo_0
make target1 #executes the chunk todo1
make target2 #executes the chunk todo2 
...
...
...
make targetn #executes the chunk todon

Example:

% touch test.c
% $EDITOR test.c  #paste the following in to the file
#include <stdio.h>

int main() 
{
    printf(”This is a test!\n”);
    return 0;
}

% $EDITOR Makefile #lets create a simple makefile for compiling this simple C file


all:
        @echo Compiling!
        gcc -o test test.c #compiles the source code and names it test
        ./test # runs the application
remove:
        rm test #deletes the executable file 

% make # this compiles and runs the source code test.c
% make remove #this deletes the executable file

Notice how the “@”s that precedes the echo line prevent  “echo Compiling” being printed out unlike the gcc -o test test.c line and rm test line.

Although this style of explicitly naming the commands gets the job done, if we had more than one compilation lines, configuring the makefile to compile the source with a different compiler (i.e clang) would be tedious (you would have to change every compilation command accordingly). It would be better, if we defined it once as a variable and used the variable instead of explicitly naming the name for the compiler. It turns out we can do that:

CC=gcc #c compiler
EXE=test #name of the executableş
CFLAGS=-o $(EXE) #compilation flags
SOURCE=test.c


all:
        $(CC) $(CFLAGS) $(SOURCE)
        ./$(EXE)

remove:
        rm $(EXE)

Notice how the $() substitutes the variable with its value.

Not only we can use variables in makefiles, we can  also make a target invoke another:

CC=gcc #c compiler
EXE=test #name of the executable
CFLAGS=-o $(EXE) #compilation flags
SOURCE=test.c

all:  build
        ./$(EXE)
build:
        @echo Compiling!
        $(CC) $(CFLAGS) $(SOURCE)

remove:
        rm $(EXE)


% make # or make all

This command now invokes the target all (as it is the first target in the Makefile), which in turn invokes build.

If there are more than one targets following the “:” each of them gets invoked in a row once the target is called.

More could be said about makefiles but this should be enough now, as the focus of this guide isn't creating a makefile but to edit one.

Now that we now some basics of makefile syntax, it might be useful learning some commonly used variable and target names in makefiles:

SHELL
The shell which executes commands generally /bin/sh is good enough. The GNU make utility reads the corresponding environment variable, so you don’t have to explicitly declare it.

CC
This specifies the C Compiler to be used.

CFLAGS
This specifies the compilation flags.

CDFLAGS
The C debugging flags.

AR
The utility files for extracting from archives or compressing files to archives.

LD
The linker to be used

SRC or SRCS
The source files.

OBJ
The object files.

PROG
The name of the program

PREFIX
The directory under which the application related files are going to be installed.
i.e /usr or /usr/local

LIBS
The libraries to be linked.

IGNORE
Extra components that aren’t necessarily needed for compilation.

VERSION
The version number of the application.

Most of these variables are already set accordingly or will be set accordingly once you call the configure script, you generally shouldn’t need to edit these.

And now some commonly used target names and what they do:

all:
Compiles the entire program. This is generally the first (and hence the default target)

install:
This compiles the program and moves the compiled executables and libraries to where they should be (i.e executables in /usr/local/bin and libraries in /usr/local/lib)

uninstall:
Self descriptive

clean:
Delete all the files which are created by building the program.

depend:
Builds the dependencies for the package

info:
Generates the info files.
   
</Makefile Basics>

<Make Errors>
Here is a common list of make errors: Clicky

You will probably not come across most of them (which is the reason why I am not covering all of them), if you use the Makefile provided with the source code.
Keep in mind: If it is a dependency issue you will get a message of the form

Bla: No such file or directory

You can easily resolve this by downloading the package which provides Bla. You can find out which package provides Bla with

apt-file search Bla

and install it with the package management tool of your choice.
</Make Errors>

<Configure Scripts Issues>
(Courtesy of el_koraco)
Often enough, one downloads a generic package in which the CC (compiler) variable isn't declared in the configure script, and the configure process will quit. You can then do (assuming you're on Statler or Debian Squeeze)

CC=gcc-4.3 ./configure

or

CC=gcc-4.3 make 

</Configure Script Issues>

<Building Debs From Compiled Packages>

This nice guide at the U-word forums, explains how to build a deb package from binaries.

</Building Debs From Compiled Packages>


<Sources>

http://web.mit.edu/gnu/doc/html/make_toc.html#SEC107
http://www.debian.org/doc/manuals/apt-h … ng.en.html (Obsolete but still helpful)
http://www.tuxfiles.org/linuxhelp/softinstall.html

</Sources>

Edit: If you have a lot of experience in this subject, don't feel shy sharing your expertise. I am pretty sure most of the things I have tried to explain here could be explained better and could be done better/faster/more efficient.
Edit2: Changed the title to How-To Building Programs From Source
Edit3: Added el_koraco's remarks to the How-To
Edit4: Added imbecil's remarks to the How-To
Edit5: Added imbecil's remarks on autoconfig
Edit6: tee.

Last edited by gensym (2012-12-28 19:54:12)


'Multiple exclamation marks,' he went on, shaking his head, 'are a sure sign of a diseased mind.', {Eric}

Offline

Be excellent to each other!

#2 2012-03-21 23:50:50

2ManyDogs
dv#!
From: elsewhere
Registered: 2011-11-22
Posts: 1,346

Re: How-To Building Programs From Source

This is awesome! Thank you. Very well done.


Be eggsalad to each other.

Offline

#3 2012-03-22 01:23:03

dkeg
#! Die Hard
From: Mid-Atlantic Grill
Registered: 2011-12-05
Posts: 716

Re: How-To Building Programs From Source

wow...impressive write up.  Great and useful info.    Thank you.   

Two beers worth of information.   Cheers.


grill it | the rocky path may just be the best path

Offline

#4 2012-03-22 03:34:23

VastOne
#! Ranger
From: #! Fringe Division
Registered: 2011-04-26
Posts: 10,163
Website

Re: How-To Building Programs From Source

Great How To gensym. 

I build from source all the time from git and svn sources to get the latest codes.  Now I can use this to point people to more info on building from source.

Please modify the original post's Title to take out the (HOWTO?) and make it

How-To Building Programs From Source

Added to Quick References..


VSIDO | SolusOS

Words That Build Or Destroy

Offline

#5 2012-03-22 08:44:31

el_koraco
#!/loony/bun
From: inside Ed
Registered: 2011-07-25
Posts: 4,748

Re: How-To Building Programs From Source

This is by far the best compiling guide I've ever seen on a board. It needs to be stickied five minutes ago!

Offline

#6 2012-03-22 09:51:56

gensym
#! Junkie
Registered: 2011-10-17
Posts: 447

Re: How-To Building Programs From Source

Thanks guys!
@VastOne: As you might notice while reading this, I've edited the title.


'Multiple exclamation marks,' he went on, shaking his head, 'are a sure sign of a diseased mind.', {Eric}

Offline

#7 2012-03-22 11:14:54

rhowaldt
#!*$%:)
Registered: 2011-03-09
Posts: 4,396

Re: How-To Building Programs From Source

wow, awesome. i thought at first this was simply a build-from-source guide, albeit pretty good. then he goes into all the Makefile-syntax and whatnot, and that is just fantastic. that's the kind of stuff i want to read about. really great, thanks gensym.

Offline

#8 2012-03-22 15:09:00

el_koraco
#!/loony/bun
From: inside Ed
Registered: 2011-07-25
Posts: 4,748

Re: How-To Building Programs From Source

I remembered something. Often enough, one downloads a generic package in which the CC (compiler) variable isn't declared in the configure script, and the configure process will quit. You can then do (assuming you're on Statler or Debian Squeeze)

CC=gcc-4.3 ./configure

or

CC=gcc-4.3 make

Maybe checkinstall is also good to note. make install simply installs the package, without notifying dpkg of the process. Checkinstall is a utility for creating a .deb (or rpm or txz or whatever) and installing it. You need to

sudo apt-get install checkinstall 

and instead of running make install on the end, run

sudo checkinstall -D make install

. dpkg will then know of the package, and you can remove it with dpkg -r or apt-get remove.

Last edited by el_koraco (2012-03-22 15:09:56)

Offline

#9 2012-03-22 15:39:06

gensym
#! Junkie
Registered: 2011-10-17
Posts: 447

Re: How-To Building Programs From Source

^ Thanks, I added those to the guide.


'Multiple exclamation marks,' he went on, shaking his head, 'are a sure sign of a diseased mind.', {Eric}

Offline

#10 2012-03-22 15:39:08

gensym
#! Junkie
Registered: 2011-10-17
Posts: 447

Re: How-To Building Programs From Source

edit: Stupid double post.

Last edited by gensym (2012-03-22 15:39:52)


'Multiple exclamation marks,' he went on, shaking his head, 'are a sure sign of a diseased mind.', {Eric}

Offline

#11 2012-03-22 17:42:46

PackRat
#! Die Hard
From: USA
Registered: 2011-03-03
Posts: 1,194

Re: How-To Building Programs From Source

Excellent.

Bookmarked.


"It does not require many words to speak the truth." - Chief Joseph, Nez Perce tribe

Offline

#12 2012-03-22 20:39:12

iMBeCil
WAAAAT?
From: Zgb, Croatia
Registered: 2012-03-22
Posts: 656

Re: How-To Building Programs From Source

Nice post.

I would add that, often, it can be useful to invoke './configure' and 'make' as:

$ ./configure > somefile 2>&1
$ make > someotherfile 2>&1

'> somefile' will redirect stdout to 'somefile', and '2>&1' will redirect stderr(!) to 'somefile' as well. This way, you can inspect lengthy output from the commands.

It has happened to me that some errors at the end of the 'make' were triggered by some obscure error in the middle of the 'make'.


Postpone all your duties; if you die, you won't have to do them ..

Offline

#13 2012-03-22 20:44:05

dkeg
#! Die Hard
From: Mid-Atlantic Grill
Registered: 2011-12-05
Posts: 716

Re: How-To Building Programs From Source

nice addition ... I've had the same issue before where the error was somewhere in the middle.


grill it | the rocky path may just be the best path

Offline

#14 2012-03-22 20:53:21

gensym
#! Junkie
Registered: 2011-10-17
Posts: 447

Re: How-To Building Programs From Source

^^ Added them to the guide (it might be useful for some, thanks for mentioning that), though if the compilation process takes a little long those two might be a little annoying.

Last edited by gensym (2012-03-22 20:55:46)


'Multiple exclamation marks,' he went on, shaking his head, 'are a sure sign of a diseased mind.', {Eric}

Offline

#15 2012-03-22 21:23:29

iMBeCil
WAAAAT?
From: Zgb, Croatia
Registered: 2012-03-22
Posts: 656

Re: How-To Building Programs From Source

^ You may want to remove '(imbecil start/end)' from the guide, unless you want to confuse unsuspecting user into thinking that these are some sort of 'imbecil mode/instructions/commands' lol

(I certainly do not claim ownership of those commands.)

Edit: formatting.

Last edited by iMBeCil (2012-03-22 21:24:55)


Postpone all your duties; if you die, you won't have to do them ..

Offline

#16 2012-03-22 21:28:36

gensym
#! Junkie
Registered: 2011-10-17
Posts: 447

Re: How-To Building Programs From Source

^ I felt like giving you some credit for the idea. It is now edited accordingly (and it still gives you some credit).


'Multiple exclamation marks,' he went on, shaking his head, 'are a sure sign of a diseased mind.', {Eric}

Offline

#17 2012-03-22 21:37:31

iMBeCil
WAAAAT?
From: Zgb, Croatia
Registered: 2012-03-22
Posts: 656

Re: How-To Building Programs From Source

^ you are too kind smile

Thanks!


Postpone all your duties; if you die, you won't have to do them ..

Offline

#18 2012-03-22 22:48:43

rhowaldt
#!*$%:)
Registered: 2011-03-09
Posts: 4,396

Re: How-To Building Programs From Source

^ you work in 'imbecil mode' on daily basis and seem to know your way around. you're giving hope to imbeciles everywhere! big_smile

Offline

#19 2012-03-23 04:41:23

johnraff
#!Drunkard
From: Nagoya, Japan
Registered: 2009-01-07
Posts: 2,843
Website

Re: How-To Building Programs From Source

@gensym Thank you for this! A guide I will definitely come back to.

One small point:

iMBeCil wrote:
$ ./configure > somefile 2>&1
$ make > someotherfile 2>&1

But you posted:

command > $file 2> $file # saves both stdout and stderr of the command to $file

which I think might result in one or other of the output streams being overwritten?


John
--------------------
( a boring Japan blog , idle twitterings  and GitStuff )
#! forum moderator

Offline

#20 2012-03-23 09:08:08

gensym
#! Junkie
Registered: 2011-10-17
Posts: 447

Re: How-To Building Programs From Source

Yes it does. Thanks for the heads up, for some reason I thought it would append stderr to stdout. Fixed it now. (In my defense it was pretty late when I edited the post tongue)

Last edited by gensym (2012-03-23 09:13:12)


'Multiple exclamation marks,' he went on, shaking his head, 'are a sure sign of a diseased mind.', {Eric}

Offline

#21 2012-03-23 12:21:36

iMBeCil
WAAAAT?
From: Zgb, Croatia
Registered: 2012-03-22
Posts: 656

Re: How-To Building Programs From Source

rhowaldt wrote:

^ you work in 'imbecil mode' on daily basis and seem to know your way around. you're giving hope to imbeciles everywhere! big_smile

Now, that's what I call an original comment to my nick big_smile

Back to the topic: there are cases when there are no ./'configure' and 'Makefile' in the source root dir, but files 'configure.ac' and 'Makefile.am' exist. In that case, or if you want to mess with 'configure.ac' and 'Makefile.am', you have to install autotools builders with:

$ sudo apt-get install autoconf autotools-dev

(Somehow, I think that #! users by default install that.)

Then you go to the source dir and there execute (in that order):

$ aclocal
$ autoconf
$ autoheader
$ automake --add-missing

(Note: YMMV ... sometimes you do not have to execute all of this, it depends on particular source package.)

This will create './configure' script and 'Makefile', and then you can continue with previous instructions.

(I know the above might be too advanced for casual user requirement, but let it stay here. I have a habit of forgetting things, so it will at least be useful for me.)


Postpone all your duties; if you die, you won't have to do them ..

Offline

#22 2012-03-23 12:26:36

gensym
#! Junkie
Registered: 2011-10-17
Posts: 447

Re: How-To Building Programs From Source

^ I didn't want to go in to the specifics, hence the Lionel Richie remark in the guide. I will probably add them later to the guide, but I personally think autoconfiguration utilities are evil. (And if by any means this [that you must use autoconf] isn't mentioned anywhere (be it in the README or the website), the programmer is a jerk, it is not worth taking the time compiling the code,  and you are better  of using another piece software.)


Edith says: OK, the autoconf things are in the How-To now.

Last edited by gensym (2012-03-24 17:33:29)


'Multiple exclamation marks,' he went on, shaking his head, 'are a sure sign of a diseased mind.', {Eric}

Offline

#23 2012-04-04 22:03:10

kri5
#! Die Hard
From: L.G.C. UK
Registered: 2011-11-10
Posts: 568

Re: How-To Building Programs From Source

I installed sithWM with just the following command:

sudo make install

I've just noticed the following segment in your guide from el_koraco

Maybe checkinstall is also good to note. make install simply installs the package, without notifying dpkg of the process. Checkinstall is a utility for creating a .deb (or rpm or txz or whatever) and installing it. You need to

sudo apt-get install checkinstall

and instead of running make install on the end, run

sudo checkinstall -D make install

. dpkg will then know of the package, and you can remove it with dpkg -r or apt-get remove.

am I to presume there is no way of removing sithWM now?


#! Waldorf - 64bit - Xfce

Offline

#24 2012-04-04 22:10:30

gensym
#! Junkie
Registered: 2011-10-17
Posts: 447

Re: How-To Building Programs From Source

^ An "uninstall" command is generally implemented in the Makefile, so just browse to the source folder and try

sudo make uninstall

If such a functionality is implemented, it should do the trick. If it is not try implementing it on your own or go hunt the files that have newly been added to your system tongue
(study the make install command to see the files that have been moved to /usr/local, /etc/local and etc. implement a target to remove them all)

Last edited by gensym (2012-04-04 22:10:58)


'Multiple exclamation marks,' he went on, shaking his head, 'are a sure sign of a diseased mind.', {Eric}

Offline

Help fund CrunchBang, donate to the project!

#25 2012-04-04 22:18:25

kri5
#! Die Hard
From: L.G.C. UK
Registered: 2011-11-10
Posts: 568

Re: How-To Building Programs From Source

^ sad It would appear that the 'uninstall' command is not implemented, at least not with sithWM.  So I guess I'll just have to manually hunt down the files etc.


#! Waldorf - 64bit - Xfce

Offline

Board footer

Powered by FluxBB

Copyright © 2012 CrunchBang Linux.
Proudly powered by Debian. Hosted by Linode.
Debian is a registered trademark of Software in the Public Interest, Inc.

Debian Logo