Author Topic: Problem with compile Q-Gears on Linux  (Read 8839 times)

LinuxDonald

  • Guest
Problem with compile Q-Gears on Linux
« on: 2007-02-17 09:18:58 »
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

  • Global moderator
  • *
  • Posts: 2097
  • NicoNico :)
    • View Profile
    • Q-Gears Homepage
Re: Problem with compile Q-Gears on Linux
« Reply #1 on: 2007-02-17 09:51:36 »
Pull down the newest version from SVN, There was a bug in TypeDefine.h that I fixed.

LinuxDonald

  • Guest
Re: Problem with compile Q-Gears on Linux
« Reply #2 on: 2007-02-17 11:01:27 »
I have svn-rev: 142

halkun

  • Global moderator
  • *
  • Posts: 2097
  • NicoNico :)
    • View Profile
    • Q-Gears Homepage
Re: Problem with compile Q-Gears on Linux
« Reply #3 on: 2007-02-17 16:54:15 »
That doesn't seem right.

The problem is this...
Code: [Select]
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

  • Guest
Re: Problem with compile Q-Gears on Linux
« Reply #4 on: 2007-02-17 17:46:48 »
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

  • *
  • Posts: 104
  • , kupo.
    • View Profile
Re: Problem with compile Q-Gears on Linux
« Reply #5 on: 2007-02-18 07:09:15 »
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'
« Last Edit: 2007-02-18 07:13:45 by G »

halkun

  • Global moderator
  • *
  • Posts: 2097
  • NicoNico :)
    • View Profile
    • Q-Gears Homepage
Re: Problem with compile Q-Gears on Linux
« Reply #6 on: 2007-02-18 07:22:25 »
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

  • *
  • Posts: 104
  • , kupo.
    • View Profile
Re: Problem with compile Q-Gears on Linux
« Reply #7 on: 2007-02-18 07:39:24 »
Fixed. Try to compile on your machine, halkun... rev.144
« Last Edit: 2007-02-18 07:45:34 by G »

halkun

  • Global moderator
  • *
  • Posts: 2097
  • NicoNico :)
    • View Profile
    • Q-Gears Homepage
Re: Problem with compile Q-Gears on Linux
« Reply #8 on: 2007-02-18 08:12:07 »
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...
« Last Edit: 2007-02-18 08:19:46 by halkun »

G

  • *
  • Posts: 104
  • , kupo.
    • View Profile
Re: Problem with compile Q-Gears on Linux
« Reply #9 on: 2007-02-18 08:57:33 »
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

  • Global moderator
  • *
  • Posts: 2097
  • NicoNico :)
    • View Profile
    • Q-Gears Homepage
Re: Problem with compile Q-Gears on Linux
« Reply #10 on: 2007-02-18 09:11:30 »
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]
#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?
« Last Edit: 2007-02-18 09:26:42 by halkun »

G

  • *
  • Posts: 104
  • , kupo.
    • View Profile
Re: Problem with compile Q-Gears on Linux
« Reply #11 on: 2007-02-18 09:34:29 »
Quote
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

  • Global moderator
  • *
  • Posts: 2097
  • NicoNico :)
    • View Profile
    • Q-Gears Homepage
Re: Problem with compile Q-Gears on Linux
« Reply #12 on: 2007-02-18 09:44:44 »
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.
« Last Edit: 2007-02-18 09:49:39 by halkun »

G

  • *
  • Posts: 104
  • , kupo.
    • View Profile
Re: Problem with compile Q-Gears on Linux
« Reply #13 on: 2007-02-18 09:53:08 »

Question about some preprocesser stuff.

why is it written like this?
Code: [Select]
#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.

Quote
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.



Quote
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...


Quote
Anyways, I'm off to bed.
Ok, bye. In my coutry now is 13:00 - I am going to have a dinner! :)
« Last Edit: 2007-02-18 09:55:57 by G »

Dasaan

  • Guest
Re: Problem with compile Q-Gears on Linux
« Reply #14 on: 2007-02-18 11:20:53 »
if anyone is interested...
rev 142 wouldn't compile for me but 144 compiles fine. This is with Debian Unstable (amd64)

G

  • *
  • Posts: 104
  • , kupo.
    • View Profile
Re: Problem with compile Q-Gears on Linux
« Reply #15 on: 2007-02-18 11:49:46 »
I "corrected" that HAVE_INTTYPES_H issues, this works for me and for you, but this isn't work for halkun...

LinuxDonald

  • Guest
Re: Problem with compile Q-Gears on Linux
« Reply #16 on: 2007-02-18 13:21:17 »
Now it compile on my system :)