Source code is available as official releases, testing snapshots, daily development snapshots, and the bleeding edge of development directly from the Git repository As a rule, even the bleeding edge tarballs should configure and compile without error even though certain implementation work may be in progress and may be incomplete or have errors.
Daily snapshots of the development repository are available via the World Wide Web from Hamlib Git daily snapshots These are not official releases but are provided for testing new features and bug fixes.
The daily development snapshot is made and posted each day by around 1030 UTC. Daily snapshots should compile but sometimes a bug creeps in that prevents compilation. If that should happen, please report it to the hamlib-developer mailing list
To clone the repository use the following command:
git clone https://git.code.sf.net/p/hamlib/code hamlib
or:
git clone https://github.com/Hamlib/Hamlib.git
Odds are that you will want to run the above command in a sub directory of your home directory. The hamlib directory will be created by Git and the master branch will be checked out for you as the working copy. The master branch is one of several branches used in Hamlib development. It is the main branch of new features and bug fixes. The working copy will be the latest revision of every file at the time of the clone. Later updates from the developers will require using another Git command to update your local repository.
Before going further, this manual assumes familiarity with working from the command prompt in a Linux/BSD/Unix like system's Bourne shell environment (compatible Bourne shells include bash(1), ksh(1), zsh(1), and several more) either in a virtual console (a text only screen with no graphics) or in a terminal in a desktop environment (xterm(1), rxvt(1), konsole(1) (included with the KDE desktop), gnome-terminal(1), xfce4-terminal(1), terminal(1) (included in macOS), etc.). If this is new to you, take some time and read up on using the shell. A good tutorial can be found at LinuxCommand.org which also offers an in-depth book that can be purchased or downloaded for no cost (the Hamlib project is not associated with nor has any interest in the sale of this book, it just looks like a very good effort on the part of its author).
Compiling from a source tarball whether it is an official release or a testing or daily development snapshot follows the same set of commands, known as the three step which are each run from the top-level directory:
./configure make sudo make install
Run:
./configure
from the top-level directory.
Of course, things are usually complicated a bit by options and Hamlib is no exception. The good news is that the defaults, i.e., no options, work well in most situations. Options are needed to enable the compilation of certain portions of Hamlib such as the language bindings. Optional features usually require that more development tools are installed. The INSTALL and README.betatester files in the Hamlib top-level directory will have details on the options available for that release.
A useful option is --prefix which tells configure where in the file system hierarchy Hamlib should be installed. If it is not given, Hamlib will be installed in the /usr/local file system hierarchy. Perhaps you want to install to your home directory instead:
./configure --prefix=$HOME/local
As a result of this option, all of the files will be installed in the local directory of your home directory. local will be created if it does not exist during installation as will several other directories in it. Installing in your home directory means that root, or superuser (administrator) privileges are not required when running make install. On the other hand, some extra work will need to be done so other programs can use the library. The utilities that are compiled as a part of the Hamlib build system will work as they are linked to the library installed under local. Running them will require declaring the complete path:
local/bin/rigctl
or modifying your shell's PATH environment variable (see the shell tutorial site above).
Another useful option is --help which will give a few screens full of options for configure. If in a desktop environment the scroll bar can be used to scroll back up through the output. In either a terminal or a virtual console Linux supports the Shift-PageUp key combination to scroll back up. Conversely, Shift-PageDown can be used to scroll down toward the end of the output and the shell prompt (Shift-UpArrow/Shift-DownArrow may also work to scroll one line at a time (terminal dependent)).
After a fair amount of time, depending on your computer, and a lot of screen output, configure will finish its job. So long as the few lines previous to the shell prompt don't say "error" or some such failure message Hamlib is ready to be compiled. If there is an error and all of the required packages listed in README.betatester have been installed, please ask for help on the hamlib-developer mailing list
Run:
make
from the top-level directory.
Any error that causes make to stop early is cause for a question to the hamlib-developer mailing list
In general make will take longer than configure to complete its run. As it is a system command, and therefore found in the shell's PATH environment variable, prefixing make with ./ will cause a "command not found" error from the shell.
Run:
sudo make install
or:
$ su -l Password: # make install
as root from the top-level directory.
The -l option to su forces a login shell so that environment variables such as PATH are set correctly.
Running make install will call the installer to put all of the newly compiled files and other files (such as this document) in predetermined places set by the --prefix option to configure in the directory hierarchy (yes, this is by design and make is not just flinging files any old place!).
A lot of screen output will be generated. Any errors will probably be rather early in the process and will likely be related to your username not having write permissions in the system directory structure.
Run:
sudo ldconfig
as root from any directory or while logged in as root from above.
On some distributions a bit of configuration will be needed before ldconfig will add locally compiled software to its database. Please consult your distribution's documentation.
In the top-level directory is the bootstrap script from which the build system is bootsrapped---the process of generating the Hamlib build system from configure.ac and the various Makefile.ams. At its completion the configure script will be present to configure the build system.
Next configure is run with any needed build options (configure --help is useful) to enable certain features or provide paths for locating needed build dependencies, etc. Environment variables intended for the preprocessor and/or compiler may also be set on the configure command line.
After the configuration is complete, the build may proceed with the make step as for the source tarballs above. Or configure --help may be run, and configure run again with specific options in which case the Makefiles will be regenerated and the build can proceed with the new configuration.
To remove even the generated Makefiles, run make distclean from the top-level directory. After this target is run, configure will need to be run again to regenerate the Makefiles. This command may not be as useful as the Makefiles do not take up much space, however it can be useful for rebuilding the Makefiles when modifying a Makefile.am or confgure.ac during build system development.
Parallel builds can be very useful as one build directory can be configured for a release and another build directory can be configured for debugging with different options passed to configure from each directory. The generated Makefiles are unique to each build directory and will not interfere with each other.
Run:
../hamlib/configure CFLAGS=-ggdb3 -O0 CXXFLAGS=-ggdb3 -O0
from a sibling build directory intended for a debugging build.
The -ggdb3 option tells the C compiler, in this case the GNU C Compiler, gcc, to add special symbols useful for GDB, the GNU debugger. The -O0 option tells gcc to turn off all optimizations which will make it easier to follow some variables that might otherwise be optimized away. CFLAGS and CXXFLAGS may be set independently for each compiler.
Official releases are available through the SourceForge.net file download service
Daily development snapshots are available from the daily snapshots page
Beginning with the Hamlib 1.2.15.3 release a self-extracting installer is available. Among its features are selecting which portions of Hamlib are installed. The PATH environment variable will need to be set manually per the included README.w32-bin or README.w64-bin file.
Daily development snapshots feature both a .ZIP archive and the self extracting installer.
Bug reports and questions about these archives should be sent to the hamlib-developer mailing list
Copyright © 2001-2020 Hamlib Group (various contributors)
This is free software; see the file COPYING for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.