On Sat, 13 Apr 2019 at 08:27, Laurence Parry <greenrea...@gmail.com> wrote: > > I think the problem may be that code to use libcurl is compiled into > libphobos (std.net.curl) and tests for it are executed which do not correctly > handle its absence. > > Neither libgphobos-8-dev nor libgphobos76 appear to depend on, recommend or > suggest libcurl4 and it does not appear in the build logs; 'curl' is > suggested but not installed. > > In the absence of correct libcurl libraries, these tests were known to time > out: > https://issues.dlang.org/show_bug.cgi?id=18519 > In doing so there might be a deadlock. > > The issue was raised initially on FreeBSD and Windows, but Iain Buclaw > says there that it occurs on "Linux64 with MODEL=32" > (although this may be a lack of regular x86 32-bit libraries on a amd64 > system). > > This was meant to be fixed by a patch in March 2018, however it appears to > have been ineffective: > https://github.com/dlang/phobos/commit/35e9807bbec392658ecdc8b4ed93d1f6c02f2845 > > Iain committed further patches to resolve this in January (now in dmd > v2.085.1): > https://github.com/dlang/phobos/commit/1dcb92aade1c82c356e964c1ca15c51e7de8bf76 > https://github.com/dlang/phobos/commit/d36b28c3fc90919a2a3a98249ad2d65393e28507 > I'm not sure if this would go automatically into a 8.4, or maybe it can be > cherry-picked? > > I've no knowledge of D and other patches here (or elsewhere?) may also be > relevant: > https://github.com/dlang/phobos/commit/c6bd6743254584e292f82cbcbac644d1705d14b0 > https://github.com/dlang/phobos/commit/8d51519f3f11a5f9b538cd690521b61e9fbbf5df > https://github.com/dlang/phobos/commits/master/std/net/curl.d in general > > Just noticed this failure popping up regularly in the x32 build logs and > thought I'd have a look, since I'm hoping to build a home server on it > shortly. >
I don' think the hang should be happening anymore on trunk (only tested -m32 recently). I will be shortly be adding a `check_effective_target_libcurl_available` guard in the testsuite to SKIP the test rather than FAIL, or worse, hang. See also: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88654 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89254 -- Iain
