On Mon, 2007-08-20 at 23:18 +0200, Holger Levsen wrote:
> Hi,
> 
> On Monday 20 August 2007 17:14, Bernd Petrovitsch wrote:
> > We (thanks to Hannes for human-proxied remote FreeBSD access) tracked it
> > down: The "sed" on (at least) FreeBSD doesn't handle "\n" like the
> > GNU-sed. As a consequence we got an unresolvable target which broke the
> > dependency generation.
> 
> Is that the same as http://experimental.ftbfs.de/build.php?arch=&pkg=olsrd ? 

Only if there is no GNU-sed there.

> 0.5.3-3 (armel) (latest build at Aug 19 07:13: maybe-successful)
> 0.5.3-3 (hurd-i386) (latest build at Aug 20 07:01: maybe-failed)
> 0.5.3-3 (kfreebsd-amd64) (latest build at Aug 20 13:26: maybe-failed)
> 0.5.3-3 (kfreebsd-i386) (latest build at Aug 20 20:58: maybe-failed)

I checked only olsrd_0.5.3-3_kfreebsd-i386 (whatever this is? Debian on
a FreeBSD kernel?) and found on
http://experimental.ftbfs.de/fetch.php?&pkg=olsrd&ver=0.5.3-3&arch=kfreebsd-i386&stamp=1187636307&file=log&as=raw
----  snip  ----
make[1]: Entering directory `/build/buildd/olsrd-0.5.3'
In file included from src/olsr_protocol.h:50,
                 from src/defs.h:58,
                 from src/two_hop_neighbor_table.c:44:
src/olsr_types.h:86:9: error: #error "Unsupported system"
----  snip  ----

The error is produced by the following:
----  snip  ----
#if defined linux || defined __MacOSX__
typedef u_int8_t        olsr_u8_t;
typedef u_int16_t       olsr_u16_t;
typedef u_int32_t       olsr_u32_t;
typedef int8_t          olsr_8_t;
typedef int16_t         olsr_16_t;
typedef int32_t         olsr_32_t;
#elif defined __FreeBSD__ || defined __NetBSD__ || defined __OpenBSD__
typedef	uint8_t		olsr_u8_t;
typedef uint16_t       	olsr_u16_t;
typedef uint32_t       	olsr_u32_t;
typedef int8_t          olsr_8_t;
typedef int16_t         olsr_16_t;
typedef int32_t         olsr_32_t;
#elif defined WIN32
typedef unsigned char   olsr_u8_t;
typedef unsigned short  olsr_u16_t;
typedef unsigned int    olsr_u32_t;
typedef char            olsr_8_t;
typedef short           olsr_16_t;
typedef int             olsr_32_t;
#else
#       error "Unsupported system"
#endif
----  snip  ----
So if we know the defined preprocessor macros there (whatever there is)
and  - if necessary - add the appropriate types, we can add it.

BTW: I do not know why not everyone is using the defined types from
<stdint.h> like  int8_t, int16_t, uint8_t, uint16_t, etc. if you need a
fixed size (it is in POSIX and C99 and should thus be even on Windows
available) and invent their own set of "standard types".

But I cannot realistically see a possibility to change that (read:
global find and replace of s/olsr_16_t/int16_t/ etc.) without
potentially breaking compilation everywhere. And sf.net's compile farm
is dead since months .....-

Or at least define short (new) names like u8, u16, s8, s16, ....

Now that I read it: Thomas, the
----  snip  ----
typedef char            olsr_8_t;
----  snip  ----
should very, very probably actually be
----  snip  ----
typedef signed char olsr_8_t;
----  snip  ----
since this should be a signed 8 bit value. Or not?

> (maybe-successful usually is so, maybe-failed too. ;)
> 
> The usual 12 debian architectures have all built olsrd now, btw! Cheers!

ACK:-)

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services




