Building the Native SP from Source on Solaris

If you are upgrading your system from an earlier release to V2.5 or newer, and using the Sun compiler, you MUST rebuild all of the dependencies because the new release requires a non-default standard C++ library. Mixing libraries is not possible, so the original builds will not work with the new software.

The following installation procedure will build the Shibboleth 2 SP and all its dependencies. Completion of the instructions will result in a functional and loaded but unconfigured SP installed under /opt/shibboleth-sp. If you'd like to use an alternative directory, modify all paths accordingly.

For most of the project's life, the use of gcc (the GNU compiler) was not recommended on Solaris because of questionable packaging/availability. More recent experience with it has been more positive, and this is particularly true with V2.5 of the SP, because of the addition of the Boost C++ libraries, which do not work with the default Sun C++ standard library. The Sun compiler can be used, but a non-default option is required.

At this point, the project will officially support either the GNU or Sun compilers, however the only formally supported source of the GNU compiler is from the OpenCSW packaging project. It does not provide actual packages for Shibboleth at this time, nor do we specifically require that you leverage any of its packages for dependencies like OpenSSL or libcurl (in fact, they aren't very current). But if we can't reproduce a problem in a gcc build based on the OpenCSW compiler stream, we will probably ask that rebuilding with it be tried.

Note, as always, that all C++ code must be built using the same compiler, and usually the same general set of options, in order for the software to link and run properly. Once you build anything with a particular compiler, you must use it for everything. It's generally advisable to stick to that policy for all the code, but it is possible to use C libraries built with other compilers.

Also note that you may run into conflicts if your Apache installation relies on modules that include C++ code, as this one does. In that event, you MUST rely on the same compiler and standard C++ library for all such modules. That can create problems if you don't have the ability to rebuild the other module, because you cannot use a module built with the Sun compiler if it relies (as it likely will) on the default standard C++ library. It is not standards-compliant enough at this point in time.

An additional problem is that many packaged sources of Apache will usually be built with the Sun compiler and will be configured such that the compiler options supplied by the Apache utilities will break if the GNU compiler is used. The particular source of Apache and how you build it may be the determining factor in how to build this software.

GNU make (gmake) is required in building some of the packages, and you can obtain that from OpenCSW as well (it's also included with newer versions of Solaris).

Finally, if you rely on your own custom installation of gcc, you MUST ensure that Sun's linker is used.

The extensive set of notes above should be a warning to you that if you are not deeply experienced with building software on Solaris, you should strongly consider a different platform, or a different SAML implementation. You will waste a lot of time, and probably not have a maintainable system. You have been warned.

The most recent version of the SP has been built successfully using the following OS and compiler combinations:

Solaris 10 (32-bit and 64-bit Sparc) using SunCC 5.12 and GCC 4.6.3
Solaris 11 (32-bit and 64-bit i386) using SunCC 5.12 and GCC 4.6.3

When building from source, you can accomodate any version of Apache (or its derivations) that is compatible, but we officially support only Apache installations built using the official Apache sources and for versions that are not EOL (end of life) by the ASF.

Configuring the Build Environment

Below are various build settings you MUST have in your shell or passed to the configure commands to set the right compiler names and non-standard flags. Failure to do so will result in errors, so if you have problems, the first thing you need to do is check that you have used these settings.

If you want to build a 64-bit set of binaries, you will need to add -m64 to the CFLAGS and CXXFLAGS variables for all builds (exception being OpenSSL, which doesn't have a "normal" configure step).

GCC Build

# Choose compilers
$ export CC=gcc
$ export CXX=g++
# Set LD_LIBRARY_PATH to your install location in case of linker issues
$ export LD_LIBRARY_PATH=/opt/shibboleth-sp/lib

SunStudio Compiler Build

 # Choose compilers
$ export CC=cc
$ export CXX=CC
# Set flags for build, particularly the non-standard STL library
$ export CFLAGS="-xO2"
$ export CXXFLAGS="-xO2 -library=stlport4"
# Set LD_LIBRARY_PATH to your install location in case of linker issues
$ export LD_LIBRARY_PATH=/opt/shibboleth-sp/lib

Building Shibboleth

The following packages must be built in the following order using the ./configure commands listed, or approximations thereof. Unless specific version notes are given, any modern release is sufficient. Be sure to make and make install as appropriate for each package, including Shibboleth itself. You may need to adjust some of the details for your system, but these are the options used in the author's test builds.

Boost: No build is needed, but you will need to unpack the source distribution to some location. The remaining steps assume /home/yourname/src/boost_1_55_0
OpenSSL: ./Configure config threads shared --prefix=/opt/shibboleth-sp
- Set config to an appropriate value for your platform, compiler, and architecture:
  - solaris-sparcv9-cc (Sparc, Sun, 32-bit)
  - solaris64-sparcv9-cc (Sparc, Sun, 64-bit)
  - solaris-sparcv9-gcc (Sparc, GCC, 32-bit)
  - solaris64-sparcv9-gcc (Sparc, GCC, 64-bit)
  - solaris-x86-cc (Intel, Sun, 32-bit)
  - solaris64-x86_64-cc (Intel, Sun, 64-bit)
  - solaris-x86-gcc (Intel, GCC, 32-bit)
  - solaris64-x86_64-gcc (Intel, GCC, 64-bit)
libcurl: ./configure --prefix=/opt/shibboleth-sp --disable-static --without-ca-bundle --with-ssl=/opt/shibboleth-sp
log4shib: ./configure --prefix=/opt/shibboleth-sp --disable-static --disable-doxygen
Xerces-C (3.x): ./configure --prefix=/opt/shibboleth-sp --enable-netaccessor-socket
XML-Security-C: ./configure --prefix=/opt/shibboleth-sp --with-openssl=/opt/shibboleth-sp --with-xerces=/opt/shibboleth-sp
XMLTooling-C: ./configure --prefix=/opt/shibboleth-sp --with-log4shib=/opt/shibboleth-sp --with-curl=/opt/shibboleth-sp --with-openssl=/opt/shibboleth-sp --with-boost=/home/yourname/src/boost_1_55_0 -C
OpenSAML-C: ./configure --prefix=/opt/shibboleth-sp --with-log4shib=/opt/shibboleth-sp --with-openssl=/opt/shibboleth-sp --with-boost=/home/yourname/src/boost_1_55_0 -C

When building Shibboleth, you may need to modify the apxs to be used and the version of Apache to be built against, e.g. --enable-apache-22 and --with-apxs22=/usr/local/apache2/bin/apxs or --enable-apache-13 and --with-apxs=/usr/local/apache/bin/apxs. The example builds a module for Apache 2.2.

Shibboleth: ./configure --prefix=/opt/shibboleth-sp --with-log4shib=/opt/shibboleth-sp --with-boost=/home/yourname/src/boost_1_55_0 --enable-apache-22 --with-apxs22=/usr/local/apache2/bin/apxs -C

Troubleshooting

If you're not comfortable researching and diagnosing configure and/or make errors, we strongly suggest you find somebody who is, or use a package of some sort rather than a direct source build. However, we have some tips on troubleshooting source builds.

Note that with this release, the use of the Sun compiler requires use of a non-default Standard C++ library, libstlport.so.1, which will not generally be in your system path. Loading the Apache module(s) or running the daemon may require including the path to this library in a LD_LIBRARY_PATH variable. It is located in the prod/lib/stlport4 directory beneath your compiler installation root.

Basic Configuration

These steps will configure Apache to load mod_shib, supply it with proper host and scheme information, and start shibd.

Set the LD_LIBRARY_PATH environment variable to the path containing Shibboleth dependencies and libraries. This is required both in the script that starts the shibd daemon and when starting Apache (so you might put it in /usr/sbin/apachectl).
```
export LD_LIBRARY_PATH=/opt/shibboleth-sp/lib:/opt/solarisstudio12.3/prod/lib/stlport4
```
Edit Apache configuration:
- Shibboleth includes sample Apache configuration files in /opt/shibboleth-sp/etc/shibboleth for each version of Apache. You can add an Include to httpd.conf itself, but this isn't advisable because the sample file will be overwritten on subsequent installs/upgrades. Use it as a sample to add the necessary commands to your own configuration.
- Ensure that the ServerName directive is properly set, and that Apache is being started with SSL enabled.
- Use of the <RequestMap> feature is not recommended for use with Apache, but its use requires that the UseCanonicalName directive be set.
Restart Apache.
shibd must be independently started and run. The daemon should in the future be loaded and monitored along with all other major services.
```
/opt/shibboleth-sp/sbin/shibd
```
By default, the Shibboleth module is configured to log information on behalf of Apache to /opt/shibboleth-sp/var/log/shibboleth-www/native.log
shibd creates its own separate logs in /opt/shibboleth-sp/var/log/shibboleth

Browser not supported