Re: [Bug-glpk] static build workaround for 4.30

[glpk xypron]

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 <address@hidden>
> An: address@hidden
> 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)           : address@hidden
> [from IMAP client]
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Bug-glpk mailing list
> address@hidden
> 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