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@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 <EM>opaque data types</EM> (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 <EM>before using any other interface of the library</EM>. The application can release the resources allocated by the library by calling the <CODE>ppl_finalize</CODE> function. After this function is called <EM>no other interface of the library may be used</EM> 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 <EM>Linear Programming</EM> 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.