Bug 247817 - lang/ruby2[67]: Fails to build when 127.0.0.1 unavailable: ./addrinfo.h:165:12: error: conflicting types for 'getnameinfo'
Summary: lang/ruby2[67]: Fails to build when 127.0.0.1 unavailable: ./addrinfo.h:165:1...
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-ruby (Nobody)
URL:
Keywords: needs-patch, needs-qa
Depends on:
Blocks:
 
Reported: 2020-07-07 04:25 UTC by bugs.freebsd
Modified: 2023-11-28 01:00 UTC (History)
6 users (show)

See Also:
koobs: maintainer-feedback? (ruby)
koobs: merge-quarterly?


Attachments
Logfile of a failed build with poudriere. (58.07 KB, text/plain)
2020-07-07 04:25 UTC, bugs.freebsd
no flags Details
GIT diff (489 bytes, patch)
2021-12-14 10:19 UTC, ml
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description bugs.freebsd 2020-07-07 04:25:38 UTC
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.
Comment 1 Koichiro Iwao freebsd_committer freebsd_triage 2021-04-08 02:46:16 UTC
No time to dig into this issue.
Comment 2 ml 2021-12-14 10:19:32 UTC
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.
Comment 3 Koichiro Iwao freebsd_committer freebsd_triage 2021-12-23 16:39:54 UTC
I will report it to upstream.
Comment 4 Sean Champ 2021-12-29 07:09:32 UTC
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?
Comment 5 Kubilay Kocak freebsd_committer freebsd_triage 2022-01-17 00:11:12 UTC
^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
Comment 6 ml 2022-07-03 21:13:24 UTC
(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.