Milter-greylist

Hello,

I took time now to try to go higher version
from 1.5.3 with my patch up to version 1.5.8.
The 1.5.4 already includes the IPV6 support.
To have the IPV6 compiled on Tru64 UNIX
the _OSF_SOURCE symbol has to be defined.
But if I define the CFLAGS=-D_OSF_SOURCE there
are two additional things which break.
The /usr/include/c_excpt.h file (included from <pthread.h>)
has already the except identifier defined:
#define except __builtin_except
The /usr/include/arpa/nameser_compat.h file (included indirectly
from <netdb.h>) has already the C_NONE identifier defined (creates warning
only):
#define C_NONE ns_c_none
It is quiet unfortunate that the program name space
and the program development environment name space are not distinct.
I have no much chance to change the name definitions in the include files.
I already created a set of patch which changes the except
identifier to glexcept and the C_NONE to C_GLNONE in the milter-greylist
source codes.
With this change the compilation on Tru64 UNIX is more or less clean.
Is it possible to include this into the next release?
I do not think that it would break something on other platforms.

Bests,
Attila

<attila.bruncsak@...> wrote:

> I took time now to try to go higher version
> from 1.5.3 with my patch up to version 1.5.8.
> The 1.5.4 already includes the IPV6 support.
> To have the IPV6 compiled on Tru64 UNIX
> the _OSF_SOURCE symbol has to be defined.

Could you write a configure test that check that macro? The work is
easy, as we already have similar tests (for instance about
-D__EXTENSIONS__)

(namespace pollution)
> With this change the compilation on Tru64 UNIX is more or less clean.
> Is it possible to include this into the next release?

Sure.
You say more or less clean. Could we work on removing the warnings?

> I do not think that it would break something on other platforms.

No, your patch seems fine.

-- 
Emmanuel Dreyfus
Il y a 10 sortes de personnes dans le monde: ceux qui comprennent 
le binaire et ceux qui ne le comprennent pas.
manu@...

> > I took time now to try to go higher version
> > from 1.5.3 with my patch up to version 1.5.8.
> > The 1.5.4 already includes the IPV6 support.
> > To have the IPV6 compiled on Tru64 UNIX
> > the _OSF_SOURCE symbol has to be defined.
> 
> Could you write a configure test that check that macro? The work is
> easy, as we already have similar tests (for instance about
> -D__EXTENSIONS__)
> 

In Tru64 UNIX version 4.x there is no native IPV6 support
(maybe with special kits installed only).
Anyhow, I never succeeded to compile it on Tru64 UNIX V4.x only on V5.x.

In the <netinet/in.h> file just near to the end it looks like that:

#ifdef _OSF_SOURCE
#include <netinet/in6.h>
#endif

I tried explicitly including the in6.h header file but started to break
on missing definitions like u_short and u_long and others. I gave up on
that.

I tried to compile it without IPV6 support.
The problem is that sys/socket.h defines the
AF_INET6 even with _BSD_SOURCE and _X_OPEN_SOURCE=500 and without
_OSF_SOURCE defined.
I do not know what the standards say.
Is it correct that way?
The compilation fails on not finding any IPV6 related definitions,
since the AF_INET6 protects the IPV6 related code.

> > With this change the compilation on Tru64 UNIX is more or 
> less clean.
> 
> You say more or less clean. Could we work on removing the warnings?
> 

Here is the actual warning:

$ cc -D_OSF_SOURCE -I/usr/local/src/sendmail/libmilter/include -pthread
-D_XOPEN
_SOURCE=500 -D_BSD_SOURCE -c pending.c
cc: Warning: pending.c, line 523: In the definition of the function
"ipfromstrin
g", the promoted type of family is incompatible with the type of the
correspondi
ng parameter in a prior declaration. (promotmatchw)
        sa_family_t family;
--------------------^

And here is an example code which demonstrates the warning:

$ cat t.c
/* this declaration goes to the header file */
void func(char);

/* and that is the actual implementation */
void func(u)
  char u;
  {
  }
$ cc -c t.c
cc: Warning: t.c, line 6: In the definition of the function "func", the
promoted
 type of u is incompatible with the type of the corresponding parameter in a
pri
or declaration. (promotmatchw)
  char u;
-------^

Bests,
Attila

On Tue, Oct 12, 2004 at 01:30:29PM +0200, attila.bruncsak@... wrote:
> > Could you write a configure test that check that macro? The work is
> > easy, as we already have similar tests (for instance about
> > -D__EXTENSIONS__)

[That's tricky]

What about tryig to use an IPv6 related structure with and without OSF_SOURCE?
If the result is (fail, suceed), that means we need to add OSF_SOURCE to CFLAGS

That does not work?
-- 
Emmanuel Dreyfus
manu@...

> > > Could you write a configure test that check that macro? 
> The work is
> > > easy, as we already have similar tests (for instance about
> > > -D__EXTENSIONS__)
> 
> [That's tricky]
> 
> What about tryig to use an IPv6 related structure with and 
> without OSF_SOURCE?
> If the result is (fail, suceed), that means we need to add 
> OSF_SOURCE to CFLAGS
> 
> That does not work?

Here it is:

$ cat tst.c
#include <sys/socket.h>
#include <netinet/in.h>

main()
  {
#ifdef AF_INET6
  struct in6_addr s;
#endif
  }
$ cc -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_OSF_SOURCE -o tst tst.c
$ cc -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -o tst tst.c
cc: Error: tst.c, line 7: In this declaration, "s" has no linkage and is of
an i
ncomplete type. (incompnolink)
  struct in6_addr s;
------------------^
$

<attila.bruncsak@...> wrote:

> > That does not work? 
> Here it is:
[sample code]

Good. Can you make the patch for configure.ac? I could do it but I won't
be able to test. 

-- 
Emmanuel Dreyfus
Il y a 10 sortes de personnes dans le monde: ceux qui comprennent 
le binaire et ceux qui ne le comprennent pas.
manu@...

> 
> Good. Can you make the patch for configure.ac? I could do it 
> but I won't
> be able to test. 
> 

The patch is in the attachment.
I could not test it neither since I do not have the autoconf :-(
This is the first time in my life that I touch an configure.ac file.
I hope it works. I may get the autoconf later.

Bests,
Attila

On Wed, Oct 13, 2004 at 12:53:34PM +0200, attila.bruncsak@... wrote:
> The patch is in the attachment.
> I could not test it neither since I do not have the autoconf :-(
> This is the first time in my life that I touch an configure.ac file.

Welcome to hell :)
The patch sounds okay, but you really need to check that it builds okay
on your system. Note that you can generate configure on another system
where you have autoconf, it does not have to be done on the tru64 system.


-- 
Emmanuel Dreyfus
manu@...

Hi,

>>>>> On Wed, 13 Oct 2004 12:53:34 +0200
>>>>> attila.bruncsak@... said:

+ AC_COMPILE_IFELSE([AC_LANG_PROGRAM([
+ 		#include <sys/socket.h>
+ 		#include <netinet/in.h>
+ 	],[[

+ 		[AC_COMPILE_IFELSE([AC_LANG_PROGRAM([
+ 				#define _OSF_SOURCE
+ 				#include <sys/socket.h>
+ 				#include <netinet/in.h>
+ 			],[[

These should have #include <sys/types.h> also.

Sincerely,

--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
ume@...  ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/