[Ipopt] Ipopt 3.5.2 release

[Damien Hocking]

Is there any licensing reason why we couldn't just hand the patches or  
the files over to the MUMPS devs?  You've fixed it, I was halfway  
through fixing it almost the same way and then got this email, and  
then the MUMPS devs will try and fix it as well.  We should do the  
right thing by everyone and get the patches into the MUMPS codebase.

The Cygwin/MinGW thing might need an extra definition check.  Being  
gcc-based, I suspect it supports snprintf without the underscore.

Damien

On 20-Sep-08, at 12:41 PM, Stefan Vigerske wrote:

> Hi,
>
>> Here's a copy of what I just sent to the MUMPS list.  MUMPS 4.8.2  
>> uses C99 standard for its C files and this is the root cause of the  
>> problems.
>>
>> All,
>>
>>  I've got MUMPS 4.8.2 built and running under Windows using Visual   
>> Studio 8 for the C files and Intel Fortran.  I haven't tried with  
>> VS 9  yet.  There are two issues with compiling 4.8.2 using the  
>> Microsoft  compiler.  The first is an easy fix.  The snprintf is  
>> _snprintf on the  Windows platform.  All you need is this at the  
>> top of any file that  uses snprintf (e.g. mumps_io_err.c):
>>
>>  #if defined(MUMPS_WIN32)
>>  #define snprintf _snprintf
>>  #endif
>>
>>  That's an easy fix.
>
> Hope so, there are things like cygwin, mingw, and windows-gcc where it
> is never clear for me whether they have snprintf, _snprintf, or none  
> of
> them.
>
>>  The second problem is more difficult.  Visual Studio 8 complies  
>> with  the C89 standard and some parts of C99.  Unfortunately it's  
>> missing a  key part of C99, which is allowing variable declarations  
>> at any point  in a function.  C89 says that all variable  
>> declarations must be at the  start of any function.  The Intel  
>> compiler has a /C99 switch and  shouldn't be affected by this.
>
> Maybe not of interest for the Mumps people, but the coin buildsystem  
> for
> Mumps does not set the /C99 flag for icl I think, so I got the same
> problems (on Windows) as you with cl.
>
>> There's two solutions for the MS  compiler.  The first is a hack:   
>> Add the /TP flag to the compiler to  tell it to compile all the C  
>> files as C++, which allows variable  declarations anywhere.  Then  
>> you run into C++ name mangling where the  Fortran tries to call non- 
>> mangled C function names which it can't find  and then the linker  
>> complains.  The solution to that is to wrap all the  C function  
>> declarations in " extern "C" " to switch off name mangling.   This  
>> is a lot of extra work for the MUMPS devs for one compiler.  I did   
>> this and got it to work, but I should have used the second  
>> solution,  below.  I need to try with Visual Studio 9 as well to  
>> see if that has  the same problem.
>>
>>  The second solution that's not a hack involves changing the files  
>> like  mumps_io.c so that all the variable declarations are at the  
>> start of  each function so they're C89 compliant and the problem  
>> should go away.   I'll try this over the next couple of days to  
>> make sure it works and  you're welcome to the code.  That's  
>> probably the most straightforward  fix.
>
> I prefer the second solution.
> You do not necessarily need to move code around, it seem to be
> sufficient to put braces at the right places.
>
> What had worked for me is
> https://projects.coin-or.org/BuildTools/browser/ThirdParty/Mumps/trunk/mumps.patch
> But I've tested it only on Windows with Intel compilers.
> Well, but also haven't got complains from Kipps nightly builds either.
>
>>  end
>>
>> Once I've tested out the conversion back to C89 standard and proven  
>> it works, I can post the modified MUMPS files here (shouldn't be  
>> too many) if people *really* want to use MUMPS 4.8.2.  I suspect  
>> the MUMPS devs will put a 4.8.3 patch up once we get this sorted  
>> out and tested.
>
> Thanks.
>
> Stefan