Bug#363514: agree with your evaluation

I looked over GLPK according to data size neutrality guidelines at http://www.unix.org/whitepapers/64bit.html I didn't see any problems in the GLPK code other than the data types in umalloc, ucalloc, and ufree. Now that I have a better understanding of this situation, I agree that switching the ty

Bug#363514: glpk should be compiled with -D_GLPLIB_HUGEMEM on AMD64

rrow, but I'm not certain. Brady Brady Hunsaker wrote: > Falk, > > I'm not an expert at these issues. I'm going to look at the situation > more carefully this weekend and get back to you. > > Brady > > > Falk Hueffner wrote: >> James Andrewartha &

Bug#363514: glpk should be compiled with -D_GLPLIB_HUGEMEM on AMD64

Falk, I'm not an expert at these issues. I'm going to look at the situation more carefully this weekend and get back to you. Brady Falk Hueffner wrote: > James Andrewartha <[EMAIL PROTECTED]> writes: > >> When compiled on platforms where sizeof(void *) > sizeof(int), which >> includes AMD64,

Bug#335237: glpk: GLPK should produce a shared library (patch for libtool included)

Rafael Laboissiere wrote: > Package: glpk > Version: 4.8-1 > Severity: normal > Tags: patch > > I am filing this bug report hoping that Bug#310226 will be fixed. In sum, > buildd for octave2.9 is failing for some arches because glpk dos not > provide a shared library. > > Attached below are two