To be clear, I'll restate the issue as I understand it: - GLPK is not "data-size neutral". Some code assumes 32-bit memory addresses.
- A previous upstream bug report on this issue resulted in Andrew (upstream author) putting in a workaround, but the workaround also removes at least one feature (specifying a memory limit) So, the correct long-term solution is to submit upstream patches to make GLPK data-size neutral. I found some online resources to guide this and am willing to put some time into it. For the short term, we need to decide what to do. I see three possibilities: 1. Status quo: wait for our upstream corrections to work their way down. In the meantime, 64-bit architectures may not work correctly. 2. Apply upstream patches as soon as we have them. Put debian-only patches in the current version as soon as we have them, but also submit them upstream. 3. Apply Andrew's workaround for 64-bit architectures. This could be done immediately, but it removes the memory limit feature. (I guess there's some way to tell the architectures to build with the preprocessor variable set?) We should do 2 or 3, depending on how much work it will take to identify all the patches. Falk, do you have any sense on how much effort this will be? If we can get it done with a few hours work, then we should do 2. If we think it will be more than that, then we should do 3 immediately. I may be able to start looking at what will be necessary tomorrow, 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 <[EMAIL PROTECTED]> writes: >> >>> When compiled on platforms where sizeof(void *) > sizeof(int), which >>> includes AMD64, glpk should be compiled with -D_GLPLIB_HUGEMEM to >>> allow allocating more than 2GB (MAX_INT). See the GLPK 4.5 >>> changelog and http://article.gmane.org/gmane.comp.gnu.glpk/1017. >> Unfortunately, _GLPLIB_HUGEMEM disables the memory limit checking, >> which may be of use to other users. So I'd rather not enable it. >> Instead, it might be feasible to fix this properly by using size_t >> instead of int at the appropriate places. Brady, what do you think? >> >> Also, do you have a test case for this? >> > > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
