[PPL-devel] Compiling PPL under Cygwin?

Wed Feb 11 22:53:15 CET 2004

Goran Frehse wrote:
> I am currently trying to compile the PPL under Cygwin. While the PPL 
> compiles ok, the tests (make check) fail at the linking stage with an 
> error 'could not find library: ' ... 'libstc++.la'.
> I tried setting various directories with ./configure, but without success.

Dear Goran,

I assume the library that could not be found is `libstdc++.la',
not `libstc++.la'.  If so, this is the standard C++ library and
should have been installed along with g++ on your installation.

> Are there any successfull attempts to compile under Cygwin that you are 
> aware of?

Yes, I have compile and check the library under Cygwin from time to
time.  I confess it may be a couple of months I am not doing it...
nonetheless I am surprised it does not work for you.  I have not
a Cygwin installation handy at the moment, but I will have it
during the weekend.  Meanwhile, a few questions: (1) which version of
the PPL are you trying to compile?  (2) Which version of Cygwin
are you using (if you use the updater http://sources.redhat.com/cygwin/
then we are using the same version)?  (3) Did you compile GMP yourself
and, if so, how did you configure it?

> Is there any other way to compile the PPL under Windows?

Not at the moment.  While the library code has been written for maximum
portability, the infrastructure we use (automake, autoconf, libtool,
make itself) is not easily portable.  However, we have a development
branch where we are trying to add build support for Borland C++.
The problem is that no one in the development team is using (let alone
developing under) Windows, so everything is more difficult.
If you are interested in support for Borland C++ and are willing to
assist us a little bit, then we can revive the efforts of that development
branch.

> P.S.: I think it's a wonderful library, great job of the development team.
> A (very) small  example and some installation instructions might be 
> nice, just to let people see how to compile and include the PPL. I would 
> be happy to produce one if you are busy.

On behalf of the development team, thanks for the nice words!
We have added some installation instructions to the section of the manual
concerning the C interface, and were thinking about adding the same
kind of information to the main, C++ interface (include file, namespace,
initialization, version checking, linking, pointers to examples).
I attach the current version of these instructions for the C interface
under the signature.  I will draft something for the C++ interface
and let you have it, so that you can suggest improvements and additions.
All the best,

     Roberto

--
Prof. Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:bagnara at cs.unipr.it

All the declarations needed for using the PPL's C interface
(preprocessor symbols, data types, variables and
functions) are collected in the header file <CODE>ppl_c.h</CODE>.
This file, which is designed to work with pre-ANSI and ANSI C compilers
as well as C99 and C++ compilers, should be included, either directly
or via some other header file, with the directive
\code
#include <ppl_c.h>
\endcode
If this directive does not work, then your compiler is unable to find
the file <CODE>ppl_c.h</CODE>. So check that the library is installed
(if it is not installed, you may want to <CODE>make install</CODE>,
perhaps with root privileges); that it is installed in the right place
(if not you may want to reconfigure the library using the appropriate
pathname for the <CODE>--prefix</CODE> option); and that your compiler
knows where it is installed (if not you should add the path to the
directory where <CODE>ppl_c.h</CODE> is located to the compiler's
include file search path; this is usually done with the
<CODE>-I</CODE> option).

The name space of the PPL's C interface is <CODE>PPL_*</CODE> for
preprocessor symbols, enumeration values and variables; and
<CODE>ppl_*</CODE> for data types and function names. The interface
systematically uses opaque data types (generic pointers that
completely hide the internal representations from the client code) and
provides all required access functions. By using just the interface,
the client code can exploit all the functionalities of the library yet
avoid directly manipulating the library's data structures. The advantages
are that (1) applications do not depend on the internals of the library
(these may change from release to release), and (2) the interface
invariants can be thoroughly checked (by the access functions).

The PPL's C interface is initialized by means of the
<CODE>ppl_initialize</CODE> function. This function must
be called before using any other interface of the library.
The application can release the resources allocated by the library by
calling the <CODE>ppl_finalize</CODE> function. After this function
is called no other interface of the library may be used
until the interface is re-initialized using <CODE>ppl_initialize</CODE>.

Any application using the PPL should make sure that only the
intended version(s) of the library are ever used. The version used can be
checked at compile-time thanks to the macros PPL_VERSION_MAJOR,
PPL_VERSION_MINOR, PPL_VERSION_REVISION and PPL_VERSION_BETA, which
give, respectively major, minor, revision and beta numbers of the PPL
version. This is an example of their use:
\code
#if PPL_VERSION_MAJOR == 0 && PPL_VERSION_MINOR < 6
# error "PPL version 0.6 or following is required"
#endif
\endcode
Compile-time checking, however, is not normally enough, particularly in
an environment where there is dynamic linking. Run-time checking can
be performed by means of the functions <CODE>ppl_version_major</CODE>,
<CODE>ppl_version_minor</CODE>, <CODE>ppl_version_revision</CODE>, and
<CODE>ppl_version_beta</CODE>. The PPL's C interface also provides
functions <CODE>ppl_version</CODE>, returning character string
containing the full version number, and <CODE>ppl_banner</CODE>,
returning a string that, in addition, provides (pointers to) other
useful information for the library user.

All programs using the PPL's C interface must link with the
following libraries: <CODE>libppl_c</CODE> (PPL's C interface),
<CODE>libppl</CODE> (PPL's core), <CODE>libgmpxx</CODE> (GMP's C++
interface), and <CODE>libgmp</CODE> (GMP's library core). On most
Unix-like systems, this is done by adding <CODE>-lppl_c</CODE>,
<CODE>-lppl</CODE>, <CODE>-lgmpxx</CODE>, and <CODE>-lgmp</CODE> to
the compiler's or linker's command line. For example:
\verbatim
gcc myprogram.o -lppl_c -lppl -lgmpxx -lgmp
\endverbatim
If this does not work, it means that your compiler/linker is not
finding the libraries where it expects. Again, this could be because you
forgot to install the library or you installed it in a non-standard
location. In the latter case you will need to use the appropriate
options (usually <CODE>-L</CODE>) and, if you use shared libraries,
some sort of run-time path selection mechanisms. Consult your
compiler's documentation for details. Notice that the PPL is built
using <A HREF="http://www.gnu.org/software/libtool/">Libtool</A> and
an application can exploit this fact to significantly simplify the
linking phase. See Libtool's documentation for details. Those
working under Linux can find a lot of useful information on how to use
program libraries (including static, shared, and dynamically loaded
libraries) in the
<A HREF="http://www.dwheeler.com/program-library/">Program Library
HOWTO</A>.

For examples on how to use the functions provided by the C interface,
you are referred to the <CODE>interfaces/C/lpenum/</CODE> directory in
the source distribution. It contains a toy Linear Programming
solver written in C. In order to use this solver you will need to install
<A HREF="http://www.gnu.org/software/glpk/">GLPK</A> (the GNU Linear
Programming Kit): this is used to read linear programs in MPS format.