Hello Robbie, the default installation path for the configure script is /usr/local (as ./configure --help reveals).
My Debian installation expects libraries to be placed in /usr/lib and not in /usr/local/lib. To overcome the problem, you might run the configure script with --prefix /usr or create symbolic links in /usr/lib to the libraries installed in /usr/local/lib. Shared library support is disabled by default (no need to specify --disable-dl). --enable-dl has to be specified when compiling with support for MySQL or ODBC. Best regards Xypron -------- Original-Nachricht -------- > Datum: Thu, 14 Aug 2008 21:10:10 +0400 > Von: Robbie Morrison <[EMAIL PROTECTED]> > An: [email protected] > Betreff: [Bug-glpk] static build workaround for 4.30 > > Hello GLPK API users, Andrew > > I had some trouble achieving a static build for GLPK > 4.30. However, I did succeed after installing two key > files by hand instead of using "sudo make install". > This posting describes the problem and my workaround. > > I started with one of these two presumably equivalent > configure calls: > > $ ./configure --disable-dl --with-gmp > $ ./configure --with-gmp > > Both variants gave exactly the same console reporting, > which included the lines: > > checking whether to use the GNU MP bignum library... yes > checking whether to enable shared library support... no > > I then made the usual calls: > > $ make > $ make check > $ sudo make install > > However, my application, named 'xeona', built with an > unresolved dynamic link for GLPK, hence: > > $ ldd xeona | grep libglpk > libglpk.so.0 => not found > > Which, for the record, also failed to run (no surprises > there): > > xeona: error while loading shared libraries: libglpk.so.0: cannot > open shared object file: No such file or directory > Command exited with non-zero status 127 > > I added the following code to my makefile (indirectly > via a custom build script, as it happens) and this > fixed the run-time crashes (the "l" are lowercase "L"): > > LDFLAGS="-Wl,-rpath -Wl,/usr/local/lib" > > I prefer static linking, so I then hand installed the > header and static archive files, as follows: > > $ sudo make uninstall > $ sudo /usr/bin/install -c -m 644 \ > ./include/glpk.h /usr/local/include/glpk.h > $ sudo /usr/bin/install -c \ > ./src/.libs/libglpk.a /usr/local/lib/libglpk.a > > My application now builds and runs fine with > compile-time linking and no run-time dependencies: > > $ ldd xeona | grep libglpk > # no output > > For completeness, 'glpsol' is statically linked under > the build process described above (so at least the > configure options stick sometimes): > > $ ldd examples/glpsol | grep libglpk > # no output > > There does appear to be a real issue with static-only > GLPK builds, starting for me with 4.28. My own build > process has remained substantially unchanged back to > about 4.20. I am not familiar with 'autoconf' and > friends, so I cannot suggest possible causes. > > For the record, my system is Linux 2.6.17 / i686 (Intel > Celeron) / Ubuntu GNU/Linux 6.10 (edgy) x86 released > Oct-2006. The compiler is g++ (GCC) 4.1.2. My last > routine upgrade (via APT) was 14-Apr-2008 (this Ubuntu > version is no longer supported). > > Just one other comment. The 4.30 API manual is still > versioned 4.29. Oops! > > best wishes to all and many thanks to Andrew > --- > Robbie Morrison > PhD student -- policy-oriented energy system simulation > Technical University of Berlin (TU-Berlin), Germany > Webmail (preferred) : [EMAIL PROTECTED] > [from IMAP client] > > > > > > > > _______________________________________________ > Bug-glpk mailing list > [email protected] > http://lists.gnu.org/mailman/listinfo/bug-glpk -- GMX Kostenlose Spiele: Einfach online spielen und Spaß haben mit Pastry Passion! http://games.entertainment.gmx.net/de/entertainment/games/free/puzzle/6169196 _______________________________________________ Bug-glpk mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-glpk
