bug-glpk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Robbie Morrison
Subject: Re: [Bug-glpk] static build workaround for 4.30
Date: Wed, 20 Aug 2008 23:39:10 +0400

Hello GLPK API users, Andrew, Xypron

Many thanks to Andrew for his quick response and also
Xypron.  Further tests confirm that I was indeed using
the wrong options for 'configure'.

For the record, from 4.28 on (inclusive), the
'configure' script options controlling static linking
comprise:

  --disable-dl

      statically link 'libglpk' with GLPK binaries
      including 'glpsol' (this is the default)

  --disable-shared

      statically link 'libglpk' with your application
      (the default is to dynamically link)

I needed --disable-shared but had used --disable-dl.
Here is the relevant screen capture from 'configure',
by difference, under two variations:

  $ ./configure --disable-shared

    checking whether to build shared libraries... no

  $ ./configure

    checking whether -lc should be explicitly linked in... no
    checking whether to build shared libraries... yes

    (I guess "-lc" is 'libc' or 'glibc', the C library
     which supports calls like 'malloc')

If you are wondering about the merits of static and
dynamic linking, here is a short summary:

  static linking

      - GLPK code is included in your application at
        build-time (via 'libglpk.a' on Linux)

      - you can distribute your binaries without
        requiring that GLPK be present on the host
        system

      - there is no need to worry about GLPK version
        compatibility and API mismatch on host systems,
        arising from either stale GLPK dynamic
        libraries and newer application code (forward
        incompatibility) or application code which
        calls APIs that have been depreciated and then
        removed from a more recent GLPK dynamic library
        (backward incompatibility)

  dynamic linking

      - GLPK code is made available to your application
        at run-time (though 'libglpk.so' on Linux and
        'libglpk.dll' (I guess) on Windows)

      - GLPK bug-fixes and improvements are
        automatically catered for (assuming the GLPK
        dynamic library is routinely upgraded)

      - application binaries are smaller in size

      - there COULD BE less memory consumption when
        multiple instances of your application are
        running

---

Please note: further testing revealed another related
problem for 4.30:

  $ make distclean
  $ ./configure --enable-dl
  $ make
   ...
   gcc -DHAVE_CONFIG_H -I. -I.. -I../include -g -O2 -MT glplib12.lo \
       -MD -MP -MF .deps/glplib12.Tpo -c glplib12.c  -fPIC -DPIC \
       -o .libs/glplib12.o
  glplib12.c:36:18: error: ltdl.h: No such file or directory
  glplib12.c: In function '_glp_xdlopen':
  glplib12.c:41: warning: passing argument 1 of '_glp_lib_err_msg'
                 makes pointer from integer without a cast
  glplib12.c:44: warning: assignment makes pointer from integer
                 without a cast
  glplib12.c:46: warning: passing argument 1 of '_glp_lib_err_msg'
                 makes pointer from integer without a cast
  glplib12.c: In function '_glp_xdlsym':
  glplib12.c:56: warning: assignment makes pointer from integer
                 without a cast
  make[2]: *** [glplib12.lo] Error 1
  make[2]: Leaving directory `/home/robbie/synk/xeona/code_glpk/glpk-4.30/src'
  make[1]: *** [all-recursive] Error 1
  make[1]: Leaving directory `/home/robbie/synk/xeona/code_glpk/glpk-4.30'
  make: *** [all] Error 2

I am afraid I did not put any effort into isolating the
issue, but can do if need be -- just ask please.

--

Some more comments follow in the quotings below.

with best wishes, Robbie

> ------------------------------------------------------------
> To:          Robbie Morrison <address@hidden>
> Subject:     Re: [Bug-glpk] static build workaround for 4.30
> Message-ID: <address@hidden>
> From:        Andrew Makhorin <address@hidden>
> Date:        Thu, 14 Aug 2008 21:20:34 +0400
> ------------------------------------------------------------

[snip: summary of earlier problem regarding 'configure' options]

> Probably there is some confusion. Options --enable-dl
> and --disable-dl concern the shared library support
> used by some glpk modules. If you need to build the
> shared/static glpk library, you should pass options
> --enable-shared and/or --enable-static to the
> configure script.

------------------------------------------------------------
To:          Robbie Morrison <address@hidden>, address@hidden
Subject:     Re: [Bug-glpk] static build workaround for 4.30
Message-ID: <address@hidden>
From:       "glpk xypron" <address@hidden>
Date:        Thu, 14 Aug 2008 20:50:03 +0200
------------------------------------------------------------

> 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.

Ubuntu seems to accept '/usr/local/lib' quite happily.

> 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.

This is not correct as far as I am aware, see my
posting above.

---
Robbie Morrison
PhD student -- policy-oriented energy system simulation
Technical University of Berlin (TU-Berlin), Germany
[from IMAP client]








reply via email to

[Prev in Thread] Current Thread [Next in Thread]