Bug 62557 - CMake MSVC build started to fail on linking mod_lbmethod_bybusyness
Summary: CMake MSVC build started to fail on linking mod_lbmethod_bybusyness
Status: RESOLVED FIXED
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_lbmethod_(bybusyness|byrequests|bytraffic|heartbeat|rr) (show other bugs)
Version: 2.4.34
Hardware: PC All
: P2 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-07-19 15:23 UTC by Michal Karm Babacek
Modified: 2018-09-17 20:59 UTC (History)
0 users



Attachments
fix-2.4.34-bybusyness.patch (464 bytes, patch)
2018-07-19 18:12 UTC, William A. Rowe Jr.
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Michal Karm Babacek 2018-07-19 15:23:25 UTC
Hi,

This build script [1] has been successfully building httpd 2.4.29 with this single patch applied [2]. 2.4.34 and 2.4.x fails on linking mod_lbmethod_bybusyness. See the particular step passing just fine in the undermentioned 2.4.29 build:

2.4.29: PASSES
==============
> [ 80%] Linking C shared library mod_lbmethod_bybusyness.so
>    Creating library mod_lbmethod_bybusyness.lib and object mod_lbmethod_bybusyness.exp
> [ 80%] Built target mod_lbmethod_bybusyness
> Scanning dependencies of target httxt2dbm
> [ 80%] Building C object CMakeFiles/httxt2dbm.dir/support/httxt2dbm.c.obj
> httxt2dbm.c
> [ 80%] Building RC object CMakeFiles/httxt2dbm.dir/build/win32/httpd.rc.res
> Microsoft (R) Windows (R) Resource Compiler Version 10.0.10011.16384
> 
> Copyright (C) Microsoft Corporation.  All rights reserved.
> 
> 
> [ 81%] Linking C executable httxt2dbm.exe

Seeing full build log [3] requires an arbitrary GitHub account, but I can attach it if it is of interest to anyone.

2.4.34: FAILS
=============

Left alone the fact that neither the patch from [2] nor from [4] is present in the codebase, the build fails on linking mod_lbmethod_bybusyness. I have no idea why __imp_ap_proxy_balancer_get_best_worker has started to be a problem for the linker :-(

> [ 81%] Linking C shared library mod_lbmethod_bybusyness.so
>    Creating library mod_lbmethod_bybusyness.lib and object mod_lbmethod_bybusyness.exp
> mod_lbmethod_bybusyness.c.obj : error LNK2019: unresolved external symbol __imp_ap_proxy_balancer_get_best_worker referenced in function find_best_bybusyness
> mod_lbmethod_bybusyness.so : fatal error LNK1120: 1 unresolved externals
> LINK Pass 1 failed. with 1120
> NMAKE : fatal error U1077: '"C:\Program Files\CMake\bin\cmake.exe"' : return code '0xffffffff'
> Stop.
> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.10.25017\bin\HostX64\x64\nmake.exe"' : return code '0x2'
> Stop.
> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.10.25017\bin\HostX64\x64\nmake.exe"' : return code '0x2'
> Stop.

Seeing full build log [5] requires an arbitrary GitHub account, but I can attach it if it is of interest to anyone.


Thank you so much for comments. I might need just a nudge in the right direction to be able to arrange a patch.

Cheers
Karm


[1] https://github.com/modcluster/ci.modcluster.io/blob/master/windows/httpd/build.bat#L72
[2] https://bz.apache.org/bugzilla/show_bug.cgi?id=62190
[3] https://ci.modcluster.io/job/httpd-windows/72/label=w2k12r2/consoleText
[4] https://svn.apache.org/viewvc/httpd/httpd/trunk/CMakeLists.txt?r1=1743512&r2=1743511&pathrev=1743512
[5] https://ci.modcluster.io/job/httpd-windows/label=w2k12r2/71/consoleText
Comment 1 William A. Rowe Jr. 2018-07-19 18:12:51 UTC
Created attachment 36044 [details]
fix-2.4.34-bybusyness.patch

Can you retest with the attached patch? If you encounter the same in other
lbmethod providers, go ahead and list those in this ticket so we can get
this solved.
Comment 2 William A. Rowe Jr. 2018-07-19 18:15:15 UTC
A quick inspection indicates that mod_lbmethod_heartbeat.c handles this
using optional functions, no hard link-time dependency. No others seem
to touch the ap_proxy namespace. Please confirm.
Comment 3 Michal Karm Babacek 2018-07-20 09:29:02 UTC
Hello, the fix-2.4.34-bybusyness.patch went in the right direction, thank you so much. All in all, these are the patches needed to build 2.4.x and 2.4.34 with CMake on Windows. It enumerates all three lbmethod extras and the nghttp2 includes from #62190.

Patches
-------
2.4.x (head 60fe8463)
https://raw.githubusercontent.com/modcluster/ci.modcluster.io/master/windows/httpd/httpd-2.4.x_CMakeLists.txt.patch

2.4.34
https://raw.githubusercontent.com/modcluster/ci.modcluster.io/master/windows/httpd/httpd-2.4.34_CMakeLists.txt.patch


Successful builds (x86_64)
--------------------------
It requires one to have an arbitrary GitHub account (or a GitHub app token with cURL), keeps the silliest bots away...

2.4.x (head 60fe8463)
https://ci.modcluster.io/job/httpd-windows/75/label=w2k12r2/

2.4.34
https://ci.modcluster.io/job/httpd-windows/76/label=w2k12r2/


I set the Jenkins to poll and build 2.4.x each day. To be honest I don't know why I haven't had it set so in the first place.

Cheers
Comment 4 Ruediger Pluem 2018-07-20 19:40:42 UTC
r1836381 is a more general approach that also prevents a load order problem in the configuration (mod_proxy needs to be loaded before mod_lbmethod_*). Can you please test this one instead of the patch to CMakeLists.txt?
Comment 5 Michal Karm Babacek 2018-07-23 16:44:29 UTC
@Ruediger, are you sure it is supposed to work this way with CMakeLists.txt? When I run with trunk, it hits:

> proxy_util.c(27): fatal error C1083: Cannot open include file: 'mod_http2.h': No such file or directory

I did try to add extra includes in mod_proxy_extra_includes with no apparent luck.
I'll get back to it later. If you have any hint on mind, feel free to enlighten me, please.
Comment 6 Ruediger Pluem 2018-07-24 06:07:01 UTC
(In reply to Michal Karm Babacek from comment #5)
> @Ruediger, are you sure it is supposed to work this way with CMakeLists.txt?
> When I run with trunk, it hits:
> 
> > proxy_util.c(27): fatal error C1083: Cannot open include file: 'mod_http2.h': No such file or directory
> 
> I did try to add extra includes in mod_proxy_extra_includes with no apparent
> luck.
> I'll get back to it later. If you have any hint on mind, feel free to
> enlighten me, please.

The patch does not add mod_http2. It was already added in r1822878. I guess you just took the whole proxy_util.c of r1836381. But possibly we still have a bug here introduced by  r1822878. So please only take what  r1836381 patches.
Comment 7 Ruediger Pluem 2018-07-24 06:17:01 UTC
(In reply to Ruediger Pluem from comment #6)
> (In reply to Michal Karm Babacek from comment #5)
> > @Ruediger, are you sure it is supposed to work this way with CMakeLists.txt?
> > When I run with trunk, it hits:
> > 
> > > proxy_util.c(27): fatal error C1083: Cannot open include file: 'mod_http2.h': No such file or directory
> > 
> > I did try to add extra includes in mod_proxy_extra_includes with no apparent
> > luck.
> > I'll get back to it later. If you have any hint on mind, feel free to
> > enlighten me, please.
> 
> The patch does not add mod_http2. It was already added in r1822878. I guess
> you just took the whole proxy_util.c of r1836381. But possibly we still have
> a bug here introduced by  r1822878. So please only take what  r1836381
> patches.

Scratch the above. The include for mod_http2.h is already included in 2.4.34. But 2.4.34 also includes r1832855 which adjusts CMakeLists.txt as needed.
Comment 8 Michal Karm Babacek 2018-07-24 06:23:40 UTC
Thx for clarification, I got really confused for a sec.  I have no problem building neither 2.4.x nor 2.4.34 as described in https://bz.apache.org/bugzilla/show_bug.cgi?id=62557#c3  The CI polls 2.4.x nightly for new commits (set a couple of days ago) and it would send me an email if (when) it breaks.

The build script is build.bat [1]

I have issues building trunk. Gonna try r1832855.

[1] https://github.com/modcluster/ci.modcluster.io/tree/master/windows/httpd
Comment 9 Michal Karm Babacek 2018-07-24 06:45:47 UTC
Using trunk +  r1832855 seems to work for me just fine. The build runs right through mod_proxy stuff and it hits a completely different issue most likely related to my OpenSSL 1_0_2n being probably too old for mod_ssl's trunk? I'll look into the doc and see...

> [ 95%] Linking C shared library mod_ssl.so
>    Creating library mod_ssl.lib and object mod_ssl.exp
> ssl_engine_init.c.obj : error LNK2019: unresolved external
> symbol modssl_load_engine_keypair referenced in function ssl_init_server_certs
> mod_ssl.so : fatal error LNK1120: 1 unresolved externals
> LINK Pass 1 failed. with 1120
> NMAKE : fatal error U1077: '"C:\Program Files\CMake\bin\cmake.exe"' : return code '0xffffffff'
Comment 10 Michal Karm Babacek 2018-07-24 07:15:56 UTC
Hmm, no, building with OpenSSL 1.0.2o [1] gives the same error. If it is not required to move to 1.1.0, I will open a new BZ.

> [ 91%] Linking C shared library mod_ssl.so
>    Creating library mod_ssl.lib and object mod_ssl.exp
> ssl_engine_init.c.obj : error LNK2019: unresolved external
> symbol modssl_load_engine_keypair referenced in function ssl_init_server_certs
> mod_ssl.so : fatal error LNK1120: 1 unresolved externals

[1] https://ci.modcluster.io/job/openssl-windows/35/label=w2k12r2/artifact/OpenSSL_1_0_2o-64.zip
Comment 11 Michal Karm Babacek 2018-07-24 08:50:14 UTC
As soon as this fix [1] is not needed any more, i.e. as soon as somebody pushes r1832855 to trunk, this Bugzilla can be closed for trunk as far as I am concerned.

Regarding 2.4.x, this patch "fixes" it [2], but I suppose the issue awaits resolution of httpd dev email thread "AW: Current trunk win build error".

For the mod_ssl failure, I created a new BZ: #62563

At this point I am not planning on doing anything with regard to this BZ unless someone prompts me to.

Cheers
K.

[1] https://raw.githubusercontent.com/modcluster/ci.modcluster.io/master/windows/httpd/httpd-trunk_CMakeLists.txt.patch
[2] https://raw.githubusercontent.com/modcluster/ci.modcluster.io/master/windows/httpd/httpd-2.4.x_CMakeLists.txt.patch
Comment 12 William A. Rowe Jr. 2018-09-17 20:59:28 UTC
This has been fixed on trunk and 2.4.x branch, for the 2.4.35 release.