| Summary: | CMake MSVC build started to fail on linking mod_lbmethod_bybusyness | ||
|---|---|---|---|
| Product: | Apache httpd-2 | Reporter: | Michal Karm Babacek <michal.babacek> |
| Component: | mod_lbmethod_(bybusyness|byrequests|bytraffic|heartbeat|rr) | Assignee: | Apache HTTPD Bugs Mailing List <bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | P2 | ||
| Version: | 2.4.34 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | All | ||
| Attachments: | fix-2.4.34-bybusyness.patch | ||
|
Description
Michal Karm Babacek
2018-07-19 15:23:25 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.
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. 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 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? @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.
(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. (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. 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 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' 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 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 This has been fixed on trunk and 2.4.x branch, for the 2.4.35 release. |