Problem with compile Q-Gears on Linux

LinuxDonald · Feb 17, 2007

Here is the log:

g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I ../../src -I ../../src -I/usr/include/libxml2 -O3 -g -O2 -Wall -W -fpermissive -pipe -MT display/actor/libcommon_la-Actor.lo -MD -MP -MF display/actor/.deps/libcommon_la-Actor.Tpo -c display/actor/Actor.cpp -fPIC -DPIC -o display/actor/.libs/libcommon_la-Actor.o
display/actor/../../TypeDefine.h:22: error: conflicting declaration 'typedef long unsigned int uint32_t'
/usr/include/stdint.h:52: error: 'uint32_t' has a previous declaration as 'typedef unsigned int uint32_t'
display/actor/../../TypeDefine.h:26: error: conflicting declaration 'typedef long int int32_t'
/usr/include/sys/types.h:197: error: 'int32_t' has a previous declaration as 'typedef int int32_t'
display/actor/../../input/../utilites/StdString.h:127: warning: unused parameter 'nNull'
display/actor/../../input/InputFilter.h: In constructor 'InputEvent::InputEvent()':
display/actor/../../input/InputFilter.h:46: warning: 'InputEvent::button' will be initialized after
display/actor/../../input/InputFilter.h:45: warning: 'InputEventType InputEvent::type'
display/actor/../../input/InputFilter.h:33: warning: when initialized here
display/actor/../../input/InputFilter.h: In constructor 'InputEvent::InputEvent(Button, InputEventType)':
display/actor/../../input/InputFilter.h:46: warning: 'InputEvent::button' will be initialized after
display/actor/../../input/InputFilter.h:45: warning: 'InputEventType InputEvent::type'
display/actor/../../input/InputFilter.h:39: warning: when initialized here
make[3]: *** [display/actor/libcommon_la-Actor.lo] Fehler 1

I have Fedora Core 64 Bit
GCC: 4.1.1

halkun · Feb 17, 2007

Pull down the newest version from SVN, There was a bug in TypeDefine.h that I fixed.

LinuxDonald · Feb 17, 2007

I have svn-rev: 142

halkun · Feb 17, 2007

That doesn't seem right.

The problem is this...
Code: [Select]

Code:

display/actor/../../TypeDefine.h:22: error: conflicting declaration 'typedef long unsigned int uint32_t'

In TypeDefine.h there is a #ifndef to see of a particular .h file has been incuded, and if not includes it. It used to use the #ifdef preprocessor directive and if it was there, included it, (Which made for conflicting declerations).

This header file is abusing the preprossesor a little, and can stand to be cleaned up a bit Checking out a brand-spanking new SVN package results in the system compiling fine for me with the #ifndef change.

Am I breaking things?

Googly · Feb 17, 2007

I don't know if this is a proper fix for TypeDefine.h but this gets it to compile for me:
remove line 18.

G · Feb 18, 2007

I had this problem earlier. For fixing I added checking for inttypes.h to configure.ac:

# Check inttypes.h header
AC_CHECK_HEADER([inttypes.h],
[AC_DEFINE([HAVE_INTTYPES_H])],
[AC_MSG_WARN([[warning: defining fixed int types explicitly]])])

so if we have inttypes.h header on the system we define HAVE_INTTYPES_H and #include it in TypeDefine.h, else we
have to define them by hand

#ifndef HAVE_INTTYPES_H -> I think this had to be #ifdef HAVE_INTTYPES_H
#include <inttypes.h>
#else
#ifndef _MSC_VER
typedef unsigned char uint8_t;
typedef unsigned short int uint16_t;
typedef unsigned long int uint32_t;

typedef signed char int8_t;
typedef signed short int int16_t;
typedef signed long int int32_t;
#else
typedef unsigned __int8 uint8_t;
typedef unsigned __int16 uint16_t;
typedef unsigned __int32 uint32_t;

typedef signed __int8 int8_t;
typedef signed __int16 int16_t;
typedef signed __int32 int32_t;
#endif // _MSC_VER
#endif // HAVE_INTTYPES_H

Now me have this problem - I can fix it, but I don't want to break someone else compilation

g++ -DHAVE_CONFIG_H -I. -I../.. -I ../../src -I ../../src -I/usr/include/libxml2 -g -O0 -fomit-frame-pointer -O3 -march=athlon64 -Wall -W -fpermissive -pipe -MT display/actor/libcommon_la-Actor.lo -MD -MP -MF display/actor/.deps/libcommon_la-Actor.Tpo -c display/actor/Actor.cpp -fPIC -DPIC -o display/actor/.libs/libcommon_la-Actor.o
display/actor/../../TypeDefine.h:22: error: conflicting declaration 'typedef long unsigned int uint32_t'
/usr/include/stdint.h:52: error: 'uint32_t' has a previous declaration as 'typedef unsigned int uint32_t'
display/actor/../../TypeDefine.h:26: error: conflicting declaration 'typedef long int int32_t'
/usr/include/sys/types.h:197: error: 'int32_t' has a previous declaration as 'typedef int int32_t'

halkun · Feb 18, 2007

Go head and fix it, I have a script on my side that deletes my local SVN copy and checks out a new copy from sourceforge and gets up the /output directory automaticlly. Do what you can to fix autoconf, and I'll test it on my side with a clean checkout and compile to see if it worked or not.

G · Feb 18, 2007

Fixed. Try to compile on your machine, halkun... rev.144

halkun · Feb 18, 2007

sorry about the wait...

Nope, it's broken.

-----------------------
g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I ../../src -I ../../src -I/usr/include/libxml2 -O3 -g -O2 -Wall -W -fpermissive -pipe -I/usr/include/SDL
-D_REENTRANT -MT display/actor/libcommon_la-Actor.lo -MD -MP -MF display/actor/.deps/libcommon_la-Actor.Tpo -c display/actor/Actor.cpp
-fPIC -DPIC -o display/actor/.libs/libcommon_la-Actor.o
/usr/include/sys/types.h:197: error: conflicting declaration 'typedef int int32_t'
....
--------------------------------

It's getting a second declration from my local types.h. (I'm guessing from glibc) It's also getting a double declare from /usr/include/stdint.h which is also part of the glibc package

This might be a problem...

G · Feb 18, 2007

Please look into your q-gears config.h if you have declared:
/* Define to 1 if you have the <inttypes.h> header file. */
#define HAVE_INTTYPES_H 1

my fragment of stdint.h (stdint.h is included by inttypes.h):
------------------------------------------------------------------------------------------------------------------
/* There is some amount of overlap with <sys/types.h> as known by inet code */
#ifndef __int8_t_defined
# define __int8_t_defined
typedef signed char      int8_t;
typedef short int      int16_t;
typedef int         int32_t;
# if __WORDSIZE == 64
typedef long int      int64_t;
# else
__extension__
typedef long long int      int64_t;
# endif
#endif

/* Unsigned. */
typedef unsigned char      uint8_t;
typedef unsigned short int   uint16_t;
#ifndef __uint32_t_defined
typedef unsigned int      uint32_t;
# define __uint32_t_defined
#endif
#if __WORDSIZE == 64
typedef unsigned long int   uint64_t;
#else
__extension__
typedef unsigned long long int   uint64_t;
#endif
------------------------------------------------------------------------------------------------------------------

my fragment if sys/types.h:
------------------------------------------------------------------------------------------------------------------
/* These types are defined by the ISO C99 header <inttypes.h>. */
# ifndef __int8_t_defined
# define __int8_t_defined
typedef   char int8_t;
typedef   short int int16_t;
typedef   int int32_t;
# if __WORDSIZE == 64
typedef long int int64_t;
# elif __GLIBC_HAVE_LONG_LONG
__extension__ typedef long long int int64_t;
# endif
# endif
------------------------------------------------------------------------------------------------------------------

hmmm...
maybe this headers from your version of glibc isn't protected by # ifndef __int8_t_defined, who knows?
dirty way to fix this is to define __int8_t_defined somewhere in q-gears source...

halkun · Feb 18, 2007

in config.h
-------
/* Define to 1 if you have the <inttypes.h> header file. */
#define HAVE_INTTYPES_H 1
-------

Yup it's there.

I guess since we are defining the intN_t vars in our application. It would be safe to toss a #define __int8_t_defined in the header to keep from colliding with glibc. I guess we can throw in a #ifndef __int8_t_defined, but I'm kind of getting confused on the preprocessor logic.

### EDIT ###
Nope, defining doing a #define __int8_t_defined causes glibc to puke because all the other intN_t vars are now not defined by the lib. (for example int64_t)

Question about some preprocesser stuff.

why is it written like this?
Code: [Select]

Code:

#ifdef HAVE_INTTYPES_H#include <inttypes.h>#else

Are we saying if HAVE_INTTYPES_H is defined then incude it? Are we in essence defining it again? Shouldn't that be a #ifndef?

G · Feb 18, 2007

I guess since we are defining the intN_t vars in our application. It would be safe to toss a #define __int8_t_defined in the header to keep from colliding with glibc.

yes, but if your stdint.h & sys/types.h is protected by __int8_t_defined and HAVE_INTTYPES_H is defined, that something other is wrong...
because if HAVE_INTTYPES_H is defined in q-gears, our TypeDefine.h would not allow to define our inttypes manually - I think problem is in those 2 headers in your system...
maybe for now we can simply do this:
//---------------------------------------------
#ifdef HAVE_INTTYPES_H
#include <inttypes.h>
#endif // HAVE_INTTYPES_H

#ifndef __int8_t_defined
# define __int8_t_defined
#ifndef _MSC_VER
typedef unsigned char uint8_t;
typedef unsigned short int uint16_t;
typedef unsigned long int uint32_t;

typedef signed char int8_t;
typedef signed short int int16_t;
typedef signed long int int32_t;
#else
typedef unsigned __int8 uint8_t;
typedef unsigned __int16 uint16_t;
typedef unsigned __int32 uint32_t;

typedef signed __int8 int8_t;
typedef signed __int16 int16_t;
typedef signed __int32 int32_t;
#endif // _MSC_VER
#endif
//-------------------------------------------------

*dirty* - but works...

halkun · Feb 18, 2007

No, it doesn't....

---------------
g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I ../../src -I ../../src -I/usr/include/libxml2 -O3 -g -O2 -Wall -W -fpermissive -pipe -I/usr/include/SDL
-D_REENTRANT -MT display/actor/libcommon_la-Actor.lo -MD -MP -MF display/actor/.deps/libcommon_la-Actor.Tpo -c display/actor/Actor.cpp
-fPIC -DPIC -o display/actor/.libs/libcommon_la-Actor.o
/usr/include/stdint.h:52: error: conflicting declaration 'typedef unsigned int uint32_t'
display/actor/../../TypeDefine.h:24: error: 'uint32_t' has a previous declaration as 'typedef long unsigned int uint32_t'
/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../../include/c++/4.1.1/bits/postypes.h:72: error: 'int64_t' does not name a type
-------------

I'm running GCC 4.1.1, just to get that out there

#### EDIT ####
It's 4:40am now and I'm going to bed. Before I go I guess I can leave you with this.
Why on earth are we defining these typedefs anyway when glibc takes care of it for us?

Anyways, I'm off to bed.

G · Feb 18, 2007

Code:
Question about some preprocesser stuff.

why is it written like this?
Code: [Select]

Code:

#ifdef HAVE_INTTYPES_H#include <inttypes.h>#else

it's so, because if autoconf found that header (inttypes.h), it define HAVE_INTTYPES_H and we know, if this HAVE_INTTYPES_H is defined, that we have this header on the system.

Are we saying if HAVE_INTTYPES_H is defined then incude it? Are we in essence defining it again? Shouldn't that be a #ifndef?

in q-gears I searched all code for possible defining that macro again - it is only in TypeDefine.h

autoconf developers prefer to define macros of type HAVE_<header name> to indicate, that this <header name> is on the system.

No, it doesn't....

/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../../include/c++/4.1.1/bits/postypes.h - I don't understand why in fedora (or redhat

) - there are so many intX_t definition files are included...
as last thing you can protect all intX_t & uintX_t definitions with __int8_t_defined and it would work...

Anyways, I'm off to bed.

Ok, bye. In my coutry now is 13:00 - I am going to have a dinner!

Dasaan · Feb 18, 2007

if anyone is interested...
rev 142 wouldn't compile for me but 144 compiles fine. This is with Debian Unstable (amd64)

G · Feb 18, 2007

I "corrected" that HAVE_INTTYPES_H issues, this works for me and for you, but this isn't work for halkun...

LinuxDonald · Feb 18, 2007

Now it compile on my system

Problem with compile Q-Gears on Linux

LinuxDonald

Guest

halkun

Guest

LinuxDonald

Guest

halkun

Guest

Googly

Guest

G

Guest

halkun

Guest

G

Guest

halkun

Guest

G

Guest

halkun

Guest

G

Guest

halkun

Guest

G

Guest

Dasaan

Guest

G

Guest

LinuxDonald

Guest