Date: Tue, 07 Jul 2020 04:25:38 +0000 From: bugzilla-noreply@freebsd.org To: ruby@FreeBSD.org Subject: maintainer-feedback requested: [Bug 247817] lang/ruby26 and lang/ruby27: fails to build with poudriere when 127.0.0.1 unavailable Message-ID: <bug-247817-21402-a5hosVbxk4@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-247817-21402@https.bugs.freebsd.org/bugzilla/> References: <bug-247817-21402@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
Bugzilla Automation <bugzilla@FreeBSD.org> has asked freebsd-ruby (Nobody) <ruby@FreeBSD.org> for maintainer-feedback: Bug 247817: lang/ruby26 and lang/ruby27: fails to build with poudriere when 127.0.0.1 unavailable https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D247817 --- Description --- Overview: Both lang/ruby26 and lang/ruby27 fail to build with a jailed poudriere where the loopback interface has an address other than "127.0.0.1". How to reproduce: * On a FreeBSD 11.3 system, create a jail with a non-standard address on the loopback interface (such as 127.0.0.5). * Install poudriere inside the jail. * Build ruby26 using poudriere. The build-jails created by poudriere should also use some IP other than 127.0.0.1. With this setup, Ruby fails to build succesfully with "poudriere bulk -j default -p default lang/ruby26". See the attached logfile for details of a recent attempt. When poudriere is run in 'interactive' mode with "poudriere bulk -j default= -p default -i lang/ruby26", it is possible to simply compile the port by runni= ng "make" inside the build-jail. Manually building the port inside a jail (even without a loopback address) also works. It only seems to fail whenever poudriere is used to perform the build. Expected cause: The "configuring socket" stage of the build compiles and runs a test program with getaddrinfo. At this point, a check is made if "127.0.0.1" exists (whi= ch isn't the case). Such hardcoded loopback addresses are used in "ext/socket/extconf.rb": if (strcmp(straddr, "127.0.0.1") !=3D 0) { goto bad; If I understand correctly, this results in the build script trying to compi= le its own version of getaddrinfo (instead of using the one provided by the OS= ), which ultimately fails due to a conflicting function name (see the log). Credits to RhodiumToad on freenode, who helped diagnosing the problem and pointing out the likely culprit.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-247817-21402-a5hosVbxk4>