[Coin-discuss] COIN with g++ 2.95.3

[Matthew Saltzman]

On Fri, 19 Dec 2003, Stephan Hennig wrote:

> 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

Yes, that's the issue.

> 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. :(

What Linux are you actually running?

You almost certainly don't want to downgrade all system libraries.
Instead install the old libraries alongside your current ones and secify
that they are the ones you want to link with for this application only.
If you link statically, you should not have problems.  (I haven't tried
very hard to get it right yet, but I'll try to get better instructions
together soon.)

-- 
		Matthew Saltzman

Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs