You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by William A Rowe Jr <wr...@rowe-clan.net> on 2017/04/11 22:16:00 UTC

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

On Tue, Apr 11, 2017 at 11:36 AM,  <gs...@apache.org> wrote:
> Author: gsmith
> Date: Tue Apr 11 16:36:25 2017
> New Revision: 1790999
>
> URL: http://svn.apache.org/viewvc?rev=1790999&view=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 >= 0x1010000fL)
+#include <../ms/applink.c>
+#else
 #include <openssl/applink.c>
 #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.

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

Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Tue, Apr 11, 2017 at 9:16 PM, Gregg Smith <gl...@gknw.net> 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

Posted by Gregg Smith <gl...@gknw.net>.
On 4/11/2017 5:19 PM, William A Rowe Jr wrote:
> On Tue, Apr 11, 2017 at 5:49 PM, Gregg Smith <gl...@gknw.net> 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

Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Tue, Apr 11, 2017 at 5:49 PM, Gregg Smith <gl...@gknw.net> 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

Posted by Gregg Smith <gl...@gknw.net>.

On 4/11/2017 3:16 PM, William A Rowe Jr wrote:
> On Tue, Apr 11, 2017 at 11:36 AM,  <gs...@apache.org> wrote:
>> Author: gsmith
>> Date: Tue Apr 11 16:36:25 2017
>> New Revision: 1790999
>>
>> URL: http://svn.apache.org/viewvc?rev=1790999&view=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 >= 0x1010000fL)
> +#include <../ms/applink.c>
> +#else
>  #include <openssl/applink.c>
>  #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?