Created attachment 216274 [details] Logfile of a failed build with poudriere. 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 running "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 (which isn't the case). Such hardcoded loopback addresses are used in "ext/socket/extconf.rb": if (strcmp(straddr, "127.0.0.1") != 0) { goto bad; If I understand correctly, this results in the build script trying to compile 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.
No time to dig into this issue.
Created attachment 230106 [details] GIT diff I'm using this patch (for 2.7) to compile in a jail: it just makes the test happy, so that Ruby's own version of getaddrinfo doesn't get pulled in. I guess it can be easily modified for 2.6. I'm not aware of any side-effect, but I only use ruby as a dependency for a couple of other ports.
I will report it to upstream.
If it might serve towards any workaround, perhaps the loopback address in ext/socket/extconf.rb could be patched during the build, to set it to some unique token e.g "@@LOOPBACK@@". After the diff for that patch would be applied in the port build, the patched file could then be processed with sed -perhaps it could be done during post-patch - such as to use some address provided with a variable in the port build. That variable's definition could be provided to the port build via make.conf, for site-local configuration. The port could provide a default value e.g `RUBY_LOOPBACK_IPV4?=127.0.0.1` in the port Makefile. An IPv6 option could be provided, too. if the variable was substituted during patch and post-patch, it may not need any changes for the configuration of the build environment? If the build contains a dependency on a specific networking configuration - as it seems to, in how that's been approached in that file - at least it might serve to make the loopback address (IPv4 or IPv6) a configurable feature for the port build? They've used that address a lot, and then there's the IPv6 version - looking at a recent changeset under Ruby 3. For purposes of supporting this under 'make test', perhaps more files would need to be patched/sed-subst'ed, not only this extconf.rb. While it may not serve to address any questions about the design of these tests, the patch/subst approach might at least serve to provide a portable workaround for the port build?
^Triage: 1) Clarification: Is this reproducible in a non jailed/poudriere setup with a loopback address other than 127.0.0.1 too? 2) Are lang/ruby3* ports affected similarly? 3) What are options for "upstream'able" fixes to this issue? 4) Can patches be updated with fix from (3), applying to all affected lang/ruby* ports
(In reply to Kubilay Kocak from comment #5) 2) Are lang/ruby3* ports affected similarly? Yes. At least lang/ruby30. I fixed it (in my own personal port tree) with the same patch I provided above.