[ale] Battling Distros and unwrapped '#include's

John Mills johnmills at speakeasy.net
Wed Apr 30 15:43:13 EDT 2008


Thanks to Mike, Pete, and James for their comments.

First, as Mike and James said, this is no fix at all. The '#ifdef <type>" 
lines don't work at all; anyway we need typedefs, not macros.

Second, as Mike said, the correct definitions do [or should] exist in an 
orderly descent of the system '#include's, and we need to find the correct 
way to use them.

Third, as Pete suggested, we do have some target-specific issues and need 
conditional compilation. In particular our eCos targets need definitions 
of __[us]<size> if we are to use this convention across our code.

I'll fix the syntax the definitions needed for eCos, then go looking for 
the collisions in Linux.

The book's not closed on this one yet, so keep the cards and e-mails 
coming.

Thanks.

  - Mills

On Wed, 30 Apr 2008, Michael H. Warfield wrote:

> On Wed, 2008-04-30 at 13:23 -0400, John Mills wrote:
>> ALErs -
>
>> Different engineers in our development group use different Linux distros
>> and we seem to have a cross-file of system *.h files defining basic types.
>
>> In particular, one of our own product's files attempts to conditionally
>> define basic integer types as follows:
>
>> ************<common.h>********************
>> /* Types */
>>
>> #ifndef __u8
>> #define __u8 unsigned char
>> #endif
  ...

> 	This should not be necessary.  If you chose the correct headers in the
> first place, those definitions should be in place and they will be
> defined correctly as typedefs and not define macros.
>
>> *****************************************
>
>> Three distros react in different ways to this fragment:
>
>> 1. openSuSE-10.x can't build if these definitions are _not_ included, but
>> crashes on duplicated definitions from <asm/types.h> if I instead include
>> <linux/types.h>. Specifically with a flurry of:
>
>>   "/usr/include/asm/types.h:13: error: duplicate -1signed"

> 	Does including <linux/types.h> solve the problem without the defines
> above?  If not, what are you missing?

>> 2. FC8 can't build if these definitions _are_ included, on account of
>> duplicate declarations.

> 	Should be able to include <linux/types.h> without conflict.

>> 3. Ubuntu-8.04 doesn't care - it apparently wraps these types properly.

>> First, the "#ifndef/#endif" contructions clearly don't work properly with
>> 'typedef' defined types, and
>> Second, there seem to be problems with the system '#include's wrappers, at
>> least in openSuSE.

> 	Well, if you have to resort to those definitions above, I would say
> you've got a problem.  Scrap those defines and go find where they are
> suppose to be included from.  Sounds like Ubuntu should be a wash and F8
> should work without them as well.  So, what's the problem with Suse?
> Sounds like including <linux/types.h> should resolve the Suse problem
> from the statement under #1.

> 	In general, it can be a bit tricky tracking down the correct header to
> include.  You find a define in a header file and it's often tempting to
> include THAT header when what you really want is an include file that
> ultimately calls the one your after.  You've got a lot of defines
> beginning with "__".  Those are generally deeper system defines.  If you
> really need them, you probably should include them properly for it to be
> portable.

>> TIA for any clever ideas.

> 	Defining those types in that manner is barking up the wrong tree so
> fixing them is not fixing the problem.  Remove them and fix the problem
> that prompted you to insert them.  I'd like to hear more about the
> problem that prompted this workaround in the first place.


More information about the Ale mailing list