* Andrew Makhorin <[EMAIL PROTECTED]> [2007-10-16 15:34]:
> In 4.22 you can call that routine as _glp_lib_free_env not including
> glplib.h in your source code. In a next version of the package it will
> be available on api level as glp_free_env.
Thanks. Please, keep me posted about the 4.23 rel
> In 4.22 you can call that routine as _glp_lib_free_env not including
> glplib.h in your source code. In a next version of the package it will
> be available on api level as glp_free_env.
Great. Thanks!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Con
>> > All glpk routines always free all allocated memory, so if the
>> > application program has deleted all problem objects, only one memory
>> > block not longer than 1K remains unallocated.
>>
>> This is probably the problem meant by the bug reporter.
> It is. I thought the solution was to call l
Hi all,
> > All glpk routines always free all allocated memory, so if the
> > application program has deleted all problem objects, only one memory
> > block not longer than 1K remains unallocated.
>
> This is probably the problem meant by the bug reporter.
It is. I thought the solution was to call
package libglpk-dev
tags 445565 upstream confirmed
thanks
* Andrew Makhorin <[EMAIL PROTECTED]> [2007-10-15 18:12]:
> Currently lib_free_env is not api routine, however, if necessary, one
> could call it as _glp_lib_free_env that does not require glplib.h to
> be included in the source code.
Yes
Package: libglpk-dev
Version: 4.22-1
Hi,
The header glplib.h is a part of the glpk tarball. It contains the
prototype of the function lib_free_env. I would like to call this
function at the end of the program, in order to free memory used by
glpk (if I don't do this, valgrind complains that ther
6 matches
Mail list logo
