Bug 247817
| Summary: | lang/ruby2[67]: Fails to build when 127.0.0.1 unavailable: ./addrinfo.h:165:12: error: conflicting types for 'getnameinfo' | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Ports & Packages | Reporter: | bugs.freebsd | ||||||
| Component: | Individual Port(s) | Assignee: | freebsd-ruby (Nobody) <ruby> | ||||||
| Status: | Open --- | ||||||||
| Severity: | Affects Some People | CC: | andrew, lab+bsd, lwhsu, meta, ml, ruby | ||||||
| Priority: | --- | Keywords: | needs-patch, needs-qa | ||||||
| Version: | Latest | Flags: | koobs:
maintainer-feedback?
(ruby) koobs: merge-quarterly? |
||||||
| Hardware: | Any | ||||||||
| OS: | Any | ||||||||
| Attachments: |
|
||||||||
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. |
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.