Very Computer

the biggest problem had to do with STL header file issues (names,
location of templates, etc...). Poking around /usr/include/c++/3.2, I
noticed a 'backwards' directory.

Simply adding a "-I /usr/include/c++/3.2/backwards" seemed to take care
of STL issues.

However, I also have other header file problems (that were lost in the
volumes of STL errors/warnings I had previously got). For example,
'struct timeval' no longer was getting defined (even tho time.h and
bit/time.h were getting included).

Rather than try to deal with individual issues of this type as they
appeared, it seems like there must be a more reasonable approach that I
am unaware of...for example some king of "compatibility" switch on the
compile-line. I looked thru gcc documentation but nothing jumped out at me.

So my question is this:

Is there a "canonical" way to deal with this issue; in particular, a
compile-time compatibility flag that will permit gcc 2.96 apps to build
w/o having to modify source code?

Tx

- rich coco

Quote:> So my question is this:

> Is there a "canonical" way to deal with this issue; in particular, a
> compile-time compatibility flag that will permit gcc 2.96 apps to build
> w/o having to modify source code?

Cheers,
Juergen

--
\ Real name     : Juergen Heinzl       \       no flames      /

Quote:> Is there a "canonical" way to deal with this issue; in particular, a
> compile-time compatibility flag that will permit gcc 2.96 apps to build
> w/o having to modify source code?

xavier

Andre'

--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)