On Fri, 2014 Sep 19 23:54+0200, Andy Polyakov via RT wrote:
> >
> > What system(s) are you testing on?
>
> We have discussed it earlier, 5.1. And was under impression that you
> target 5.1 too. You had older compiler, but system headers should have
> been same.
I have a 5.1 system too (though no access to it currently), but the goal
was to get things working on both 4.0 and 5.1 so that I can build
OpenSSH on both systems. If OpenSSL works on 4.0, then it will probably
also work on 5.1 (but not necessarily the other way around).
> > Mine is "Digital UNIX V4.0G (Rev. 1530)".
>
> Even more reason to resort additional argument. I mean if something is
> broken and/or is not up to contemporary standard, why is it source
> code that is expected to be twisted to accommodate outdated system?
> When it's possible to work around the problem without modifying code.
There's a difference between modifying code, and modifying the auto-
configuration. OpenSSL supports systems that don't have IPv6, so that is
all that is needed in code. The problem is in detecting whether or not
IPv6 is available. And yes, you can work around the problem by giving an
argument, but the reason for having all that cpp logic in e_os.h is so
that this isn't necessary.
(As for outdated systems, how about NEXTSTEP? :-)
> Works for me with C V6.5. inline is part of C99, so that if compiler
> accepts -c99 and fails to compile recognize inline as keyword, it's
> formally a bug. So that guarding with __DECC alone is still formally
> inappropriate.
Okay, then do you have a better idea? Getting a bug-fix from Compaq is
not possible.
Here is some information on the compiler version:
$ cc -V
cc (cc)
Digital UNIX Compiler Driver 3.11
Compaq C V6.1-119 on Digital UNIX V4.0G (Rev. 1530)
$ echo __DECC __DECC_VER >ver.c
$ cc -E ver.c
# 1 "ver.c"
1 60190119
> And you still don't provide coherent problem description. I mean last
> time it was "problem with non-specified argument on 5.1", now "it's on
> 4.". There is no place for guessing and implying in bug reports.
I apologize for not specifying the non-default arguments I used earlier,
because I thought the new build error was more interesting. Yes, that
prevents you from reproducing the error, and that is not helpful.
For now, however, I am testing with a plain, default build, because if
that kind of build gives errors then it is a particularly bad problem. I
want OpenSSL to build cleanly on 4.0 and 5.1, and it is almost there.
> Well, formally speaking defining _XOPEN_SOURCE in the middle is
> inappropriate. Such macros should be defined first... But it wasn't me
> who added it, so I don't know the rationale...
I think someone did it this way because OPENSSL_SYS_VXWORKS is
#defined in e_os2.h, which is obtained via e_os.h. They didn't realize
that _XOPEN_SOURCE is useless if a system header has already been seen.
Maybe if the conditional were moved up and changed to use
OPENSSL_SYSNAME_VXWORKS? Isn't that supposed to be #defined on the
compiler command line? (Or maybe use some compiler built-in symbol, like
__VXWORKS__)
--Daniel
--
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
