[Coin-discuss] COIN with g++ 2.95.3

[Stephan Hennig]

Matthew Saltzman schrieb:
> On Thu, 18 Dec 2003, Stephan Hennig wrote:
> 
>> because of another software library which isn't supported anymore I have
>> to use COIN with g++ 2.95.3. Am I going to run into problems with that
>> compiler and do I have to care about something specific? Or does COIN
>> work fine with that?
>>
>> When I checked the discuss archive I found some advices to use 2.96.x or
>> above. But those postings did only address problems with optimization
>> switches enabled? I could live without compiler optimization. Speed is
>> not the most important issue at the moment.
>>
>> Sorry for the somewhat unspecific question. But as you can see I'm not
>> sure if I got the whole compiler issue right from the archive. Probably
>> someone still working with 2.95.3 can confirm COIN runs fine with that.
>>
> And I was just going to delete my 2.95.3 compiler...
> 
> At one time, gcc 2.95.3 was required.  Since then, we have made changes so
> that it compiles and runs with the latest gcc, but I don't believe we've
> made any changes known to break 2.95.3 compatibility.  The reference in
> the archives was to problems we had getting things to link and run with
> early builds of Red Hat's 2.96 "interim" compiler.  At the time, the
> clean gcc 2.95.3 was the fallback.  Later builds of the 2.96 compiler
> worked with no problem.
> 
> The Osi unitTest using CLP compiles with no errors on my machine (Red Hat
> Linux 9) but I haven't managed to get it to link to the older libraries.
> Object files from 2.95.3 will reliably fail to link with the newer glibc
> and libstdc++, but I doubt that will be a problem for you if you are
> already using the old compiler and libraries.

Thank's for making the tests. But the last sentence sounds a bit
worrying. At the moment g++ 3.2.2 is installed on my machine. I asked
that question to check for troubles in advance before downgrading g++.

As I said earlier I need to use a free but unsupported library which in
turn depends on an older version (one year) of a commercial library
which does only compile with 2.95.3 or less. When I asked the company
for an older version of their library (which is under constant
development) they told me, I could probably run into compiler issues
with that. Now, I think they mean the glibc/libstdc++ libraries. Is that
right? As I see it I have to move to some linux groups with that
problem. I don't even know how to downgrade gcc yet. But system
libraries too - that's hard work for me. The other way would be to
implement what the unsupported library does with actual versions of all
used components (sounds promising, but), it solves the multiple resource
constrained shortest path problem. Hard work either. :(

Thanks,
Stephan Hennig