« July 2006 | Main | September 2006 »

August 30, 2006

Executing a binary in *nix

So last night I wrote about how you can compile a program's source code on your machine. After reading the entry, I realized that I left out two important pieces of information that may be necessary to properly compile. First, you need to make sure that a file is executable and second, you need to be able to execute the file.

First, I'll talk about verifying if a file is executable or not. Back in March, I wrote a blog entry on the chmod command and how it is used to set file permissions. Go ahead and read that entry first, and come back here once you're done.

...

Now that you've read up on that entry, you should have a general understanding of how file permissions work in *nix operating systems. In order to execute a file, it has to have the proper execution permissions set by chmod. Also, depending on who you want to be able to execute the file, the file needs to have the proper user permissions. It's generally a good rule of thumb to set an executable file completely read/write/executable by the file owner, but only read/execute for groups and users. This can be done by running the following command:

chmod 755 filename

This will set the proper permission flags for the file you wish to execute. At this point, we can now run the binary with no problems. However, you can't just type in the name of the binary in the terminal interface and expect it to run. In order to just type in the name of the file to get it to execute, the binary must be in the executable search path, aka PATH, of the user account. I won't go into detail on what a PATH is, but you can click on this link to read up on what it is and does and come back here when you're finished.

So, if you're binary doesn't exist in the PATH, you need some way to run it. Thankfully, there is a fairly simple method to running an executable that's outside of the PATH. By placing a period (or dot) and a forward slash (/) in front of the binary, you are telling your *nix based OS "I want to run this program", as seen in the example below:

./configure

In this example, the file configure is an executable binary. It is located outside of the executable search path, so we put a ./ in front of it to make it run.

Now, if you have a binary that you want to be able to run without using the ./ method, you can simply edit your PATH or copy the file to an existing PATH, such as /bin, /usr/bin or /usr/local/bin. If the file requires root permissions to operate properly, you can put it in /sbin, /usr/sbin or /usr/local/sbin to get the same effect.

~out...

Posted by ed at 08:56 AM | Comments (0)

August 29, 2006

How to compile a binary for Linux, Unix and even Mac OS X

I don't do too many "tech" entries on my blog, as there really isn't a great deal of people that hit this thing that would understand what I was talking about anyhow. However, a few days ago I ran across a blog entry where someone was talking about having the need for a binary ... but he didn't know how to compile a program from source.

Hence the reason for this entry.

For those of you that just have no clue, a program is written in a programming language, and often contains hundred, thousands or even million lines of code. It all depends on how complex the program is. It's these lines of code that tells a program how its supposed to work.

But, how do you get these lines of code to actually do something useful? Simple ... you compile them into a working executable binary. This is done by running the code against something called a compiler, such as gcc, in the terminal (or command line) of your system. This application will convert the code to a working binary for the system that it's compiled against (Linux, Unix or BSD). Please note that you must have the compiler installed on your *nix machine in order to compile a program's source code.

For *nix based systems, programmers will often include something called a makefile and possibly a configuration utility to make compiling a program source easier. The breakdown of using the makefile and configuration utility, if one is included, is as follows:

./configure (parameters)
make
make install
make clean

The ./configure option, if available, allows a user to pass specific parameters to the makefile, such as the binary's installation directory, location of supporting binaries and more. An example of this can be seen below:

./configure INSTALL_DIR=/usr/local

In the example above, we're passing the information "install directory" to the makefile. This will cause the binary, when it is compiled, to be installed in the /usr/local directory on the machine that it is being compiled on.

Please note that this is just an example. There can be *MANY* configuration options available to be used with the makefile. The best rule of thumb to determine these options is to pass a "help" command to the configure file, as in the example below:

./configure --help

If available, this will list all possible parameters that can be passed to the makefile, thus affecting how the source code is compiled. Be sure to read this information carefully, as a simple oversite can cause significant problems with your binary.

Once the configure script has been executed and all parameters have been passed, you can now compile the source code. This is done by running the make command. This command handles compiling and linking of the binary. Depending on the size of the source code and the speed of the machine that it is being compiled on, it may take a while for the make command to complete. The best bet is to sit back and be patient ... some programs can take hours to finish. Thankfully most binaries compile within a matter of seconds or minutes.

After make completes successfully, you can install the binary. This is done by running the make install command. This will put the binary in the proper default installation directory. If you passed a parameter to the makefile using the configure script, as shown in the example above, the binary will be placed in the user defined location instead.

To finish up the process, you can run the make clean command. This will clean up any temporary files that were created during the compiling and linking of the binary while running "make".

After this step is completed, you will now have a working binary, freshly compiled and installed from source code.

~out...

Posted by ed at 10:24 PM | Comments (0)

August 20, 2006

Being sick...

... sucks.

Amanda and I have been sick over the past week. It all started off with Amanda catching strep. She went to the doctor and was prescribed some antibiotics, went to her dad's last weekend and came back even more sick than when she left. She went back to the doctor this past week and found out that she was close to having pneumonia. She was put on even stronger antibiotics and is in the last steps of recovering.

I, on the other hand, started getting ill this past Wednesday. I woke up early in the morning and felt a tickle in the back of my throat. I also felt a need to cough, but wasn't actively doing so at that time. Over the past few days, my cough has actually become more productive and I've actually been working up phlegm.

Have I ever mentioned that I hate being sick?

This weekend, Amanda and I have stayed in. We're not doing it to get better really ... but I think that our bodies are tired from being sick and it's making us tired and lethargic.

Bleh.

Posted by ed at 12:13 AM | Comments (0)