Difficulty compiling with g++ after system change

Difficulty compiling with g++ after system change

[Chris Angelico]

Hi! I'm having some trouble with a mixed shop, where we have some
Windows and some Linux work, and would greatly appreciate advice on
how to get the new system going.

Apologies for the length of this. I've cut the code down as far as I
can, but I'm stuck for where the actual problem is.

I have two Linux computers, one of which has been in operation for
some time, and the other has just been commissioned. I copied my
source files over and tried to compile, but it's not working - see
below for error messages. The working system is:
$ g++ --version
g++ (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu4)

The nonworking:
g++ (Ubuntu 4.4.104ubuntu9) 4.4.1

The working system uses Python 2.5, the nonworking uses 2.6.

The program uses Python, MySQL, and network sockets, and I think the
problem may perhaps be in Python, but there's also an issue with
fstream that is unconnected to Python.

With an extremely cut-down program, I got the following:

#include <sys/types.h>
#include <fstream.h> // the Windows side needed it to be .h
#include <Python.h>

On the older system, this three-line file compiles just fine (and then
fails with a link error, no main). On the new system, I get the
following errors:

lcmini.cpp:10:21: error: fstream.h: No such file or directory
In file included from /usr/include/python2.6/Python.h:8,
                 from lcmini.cpp:16:
/usr/include/python2.6/pyconfig.h:1028:1: warning: "_POSIX_C_SOURCE" redefined
In file included from /usr/include/sys/types.h:27,
                 from lcmini.cpp:1:
/usr/include/features.h:158:1: warning: this is the location of the
previous definition
In file included from /usr/include/python2.6/Python.h:8,
                 from lcmini.cpp:16:
/usr/include/python2.6/pyconfig.h:1037:1: warning: "_XOPEN_SOURCE" redefined
In file included from /usr/include/sys/types.h:27,
                 from lcmini.cpp:1:
/usr/include/features.h:160:1: warning: this is the location of the
previous definition

If the answer is "convert to using <fstream> instead of <fstream.h>",
I can handle that, although the Windows build may require some
alterations (or else just #if it across). I'm puzzled, though, as to
why it should work on the old system without a hitch.

The build command is:
$ g++ -Wno-deprecated -I/usr/include/mysql -DBIG_JOINS=1 -fPIC
-I/usr/include/python2.6 -Wl,-Bsymbolic-functions -L/usr/lib/mysql
-lmysqlclient -lpython2.6 lcmini.cpp

Can anyone advise me as to what components I need to update/install?
I'm seeing lots of differences between the systems (different versions
of the same software), but am unable to recognize anything crucial.

Many thanks for your consideration.

Chris Angelico
Melbourne, AU

Re: Difficulty compiling with g++ after system change

[Ian Lance Taylor]

Chris Angelico <rosuav@gmail.com> writes:

> The working system is:
> $ g++ --version
> g++ (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu4)
>
> The nonworking:
> g++ (Ubuntu 4.4.104ubuntu9) 4.4.1

> lcmini.cpp:10:21: error: fstream.h: No such file or directory

g++ does not provide a file named fstream.h, either in 4.2.4 or in
4.4.1.  I recommend finding out where fstream.h is coming from on the
working system.

Ian

Re: Difficulty compiling with g++ after system change

[Ian Lance Taylor]

Chris Angelico <rosuav@gmail.com> writes:

> The working system is:
> $ g++ --version
> g++ (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu4)
>
> The nonworking:
> g++ (Ubuntu 4.4.104ubuntu9) 4.4.1

> lcmini.cpp:10:21: error: fstream.h: No such file or directory

My apologies.  I looked in the wrong place.  gcc 4.2.4 does provide
<backward/fstream.h>.  However, that deprecated file was removed for
the gcc 4.3 release.

Ian

Re: Difficulty compiling with g++ after system change

[Chris Angelico]

On Wed, Feb 3, 2010 at 2:58 AM, Ian Lance Taylor <iant@google.com> wrote:
> My apologies.  I looked in the wrong place.  gcc 4.2.4 does provide
> <backward/fstream.h>.  However, that deprecated file was removed for
> the gcc 4.3 release.

Ahh. Thank you. That explains it!

Now to figure out why Python conflicts with sys/types...

ChrisA