Re: svn commit: r1790999 - in /httpd/httpd/branches/2.4.x: Makefile.win docs/manual/platform/win_compiling.xml modules/ssl/mod_ssl.mak support/ab.c support/abs.mak

[William A Rowe Jr]

On Tue, Apr 11, 2017 at 9:16 PM, Gregg Smith  wrote:
>
> No applink.c is installed to PREFIX/include/openssl. I neglected to consider
> building with cmake, my bad.
>
> Adding the include is the easiest way to deal with this.

Yea, I was confused... https://github.com/openssl/openssl/pull/1314
made things clear.

You can file a ticket for source-based builders, similar to 1314, and
all the other group/component/header.h elements that get auto-gathered
into include/ in the build tree. That would simplify things greatly, and
follows their build tree structure.

Re: svn commit: r1790999 - in /httpd/httpd/branches/2.4.x: Makefile.win docs/manual/platform/win_compiling.xml modules/ssl/mod_ssl.mak support/ab.c support/abs.mak

[Gregg Smith]

On 4/11/2017 5:19 PM, William A Rowe Jr wrote:

On Tue, Apr 11, 2017 at 5:49 PM, Gregg Smith  wrote:


They will say fix ours. Bottom line, it's been moved from
include/openssl/applink.c to ms/applink.c

So, ok, will have to add /ms to the includes or do you have a better
suggestion?


That suggests that OpenSSL make install deploys ms/applink.c.
Guessing they do not. Pointer to the thread/github issue?

If it does not, I would suggest no change, and document to the user
that they must sweep ms/applink.c to the include/openssl/ directory
when they are working with openssl 'installed'. If you would like to
add ../../srcdir/openssl/ms/ to includes, a not-present directory is
no real obstacle to getting the build to work.

It's upstream that is responsible for a usable $PREFIX result tree.
The sources should be expected to be gone.



No applink.c is installed to PREFIX/include/openssl. I neglected to 
consider building with cmake, my bad.


Adding the include is the easiest way to deal with this.

Re: svn commit: r1790999 - in /httpd/httpd/branches/2.4.x: Makefile.win docs/manual/platform/win_compiling.xml modules/ssl/mod_ssl.mak support/ab.c support/abs.mak

[William A Rowe Jr]

On Tue, Apr 11, 2017 at 5:49 PM, Gregg Smith  wrote:
>
> They will say fix ours. Bottom line, it's been moved from
> include/openssl/applink.c to ms/applink.c
>
> So, ok, will have to add /ms to the includes or do you have a better
> suggestion?

That suggests that OpenSSL make install deploys ms/applink.c.
Guessing they do not. Pointer to the thread/github issue?

If it does not, I would suggest no change, and document to the user
that they must sweep ms/applink.c to the include/openssl/ directory
when they are working with openssl 'installed'. If you would like to
add ../../srcdir/openssl/ms/ to includes, a not-present directory is
no real obstacle to getting the build to work.

It's upstream that is responsible for a usable $PREFIX result tree.
The sources should be expected to be gone.

Re: svn commit: r1790999 - in /httpd/httpd/branches/2.4.x: Makefile.win docs/manual/platform/win_compiling.xml modules/ssl/mod_ssl.mak support/ab.c support/abs.mak

[Gregg Smith]

On 4/11/2017 3:16 PM, William A Rowe Jr wrote:

On Tue, Apr 11, 2017 at 11:36 AM,   wrote:

Author: gsmith
Date: Tue Apr 11 16:36:25 2017
New Revision: 1790999

URL: http://svn.apache.org/viewvc?rev=1790999=rev
Log:
Retro win32 command-line build

allow building with OpenSSL 1.1.0

ab.c (abs)
--
applink.c has been moved in this version of OpenSSL


--- httpd/httpd/branches/2.4.x/support/ab.c (original)
+++ httpd/httpd/branches/2.4.x/support/ab.c Tue Apr 11 16:36:25 2017
@@ -175,8 +175,12 @@ typedef STACK_OF(X509) X509_STACK_TYPE;
  * by the OpenSSL library build to another CRT used by the ab.exe build.
  * This became especially problematic with Visual Studio 2015.
  */
+#if (OPENSSL_VERSION_NUMBER >= 0x101fL)
+#include <../ms/applink.c>
+#else
 #include 
 #endif
+#endif

This change is absolutely wrong, please revert. On no planet does
one '../' out of the system/additional includes path.

I would guess you are trying to get at a file in a source package?
There's no assurance we are looking at a source package, LIBS
and INCLUDES may be set up to point to the installed build+devel
resources.

If the defect is in OpenSSL, let's coordinate the fix upstream.



They will say fix ours. Bottom line, it's been moved from 
include/openssl/applink.c to ms/applink.c


So, ok, will have to add /ms to the includes or do you have a better 
suggestion?

Re: svn commit: r1790999 - in /httpd/httpd/branches/2.4.x: Makefile.win docs/manual/platform/win_compiling.xml modules/ssl/mod_ssl.mak support/ab.c support/abs.mak

[William A Rowe Jr]

On Tue, Apr 11, 2017 at 11:36 AM,   wrote:
> Author: gsmith
> Date: Tue Apr 11 16:36:25 2017
> New Revision: 1790999
>
> URL: http://svn.apache.org/viewvc?rev=1790999=rev
> Log:
> Retro win32 command-line build
>
> allow building with OpenSSL 1.1.0
>
> ab.c (abs)
> --
> applink.c has been moved in this version of OpenSSL

--- httpd/httpd/branches/2.4.x/support/ab.c (original)
+++ httpd/httpd/branches/2.4.x/support/ab.c Tue Apr 11 16:36:25 2017
@@ -175,8 +175,12 @@ typedef STACK_OF(X509) X509_STACK_TYPE;
  * by the OpenSSL library build to another CRT used by the ab.exe build.
  * This became especially problematic with Visual Studio 2015.
  */
+#if (OPENSSL_VERSION_NUMBER >= 0x101fL)
+#include <../ms/applink.c>
+#else
 #include 
 #endif
+#endif

This change is absolutely wrong, please revert. On no planet does
one '../' out of the system/additional includes path.

I would guess you are trying to get at a file in a source package?
There's no assurance we are looking at a source package, LIBS
and INCLUDES may be set up to point to the installed build+devel
resources.

If the defect is in OpenSSL, let's coordinate the fix upstream.