Issue #14474 has been updated by jeremyevans0 (Jeremy Evans).
Status changed from Open to Closed
This test has not been skipped since commit:5ec3450438150e7cb05422c04dc18901161a13ea in January 2022, and I don't think this has been a problem since, so I'm closing this.
----------------------------------------
Bug #14474: skip "TestException#test_thread_signal_location" as known bug
https://bugs.ruby-lang.org/issues/14474#change-104243
* Author: ko1 (Koichi Sasada)
* Status: Closed
* Priority: Normal
* ruby -v: 2.6
* Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN
----------------------------------------
`TestException#test_thread_signal_location` fails randomly
https://gist.github.com/ko1/797b0f058f2d09ae57c9af1ee07a42b2#file-brlog-tru…
> `[BUG] pthread_mutex_lock: Invalid argument (EINVAL)`
https://gist.github.com/ko1/df41bb11a19792a14417c9332e70171e#file-brlog-tru…
> `[BUG] Segmentation fault at 0x0000000000000000`
and so on.
This test consists of signal, threads, termination process, and so on.
I've tried to investigate but no idea. Additionally, it is hard to reproduce.
To keep CI clean, I skip this test, file about this issue and wait for a person who can solve this issue.
Thanks,
Koichi
--
https://bugs.ruby-lang.org/
Issue #14422 has been updated by jeremyevans0 (Jeremy Evans).
Status changed from Open to Closed
vo.x (Vit Ondruch) wrote in #note-8:
> Unfortunately, this does not address the original issue. So is there any hope this will be improved upstream? I would like to avoid some rbconfig.rb hacks to remove the configuration flags in question.
As @nobu stated in https://bugs.ruby-lang.org/issues/14422#note-1, use `XCFLAGS` and `XLDFLAGS` to specify options only for building Ruby, that you do not want used when building extensions. You implied you didn't want to do this, apparently without trying this approach. However, be aware that is the Ruby-supported way of supporting what you want.
@nobu pointed out the issues with not using Ruby's `CFLAGS` or `LDFLAGS` by default when building Ruby extensions, so we definitely cannot make the behavior you are requesting the default as it would break things on other platforms.
I don't think this is a general issue with building Ruby. If you are building packages for Ruby extensions, you should have all of Ruby's dependencies installed. If Fedora doesn't populate its buildroot with Ruby's dependencies when building packages for Ruby extensions, that does seem like a problem to be fixed in Fedora. I know not all packaging systems have Fedora's problem, because OpenBSD's packaging system does not.
----------------------------------------
Bug #14422: Ruby configuration options should not be reused for gem builds
https://bugs.ruby-lang.org/issues/14422#change-104242
* Author: vo.x (Vit Ondruch)
* Status: Closed
* Priority: Normal
* ruby -v: ruby 2.5.0p0 (2017-12-25 revision 61468) [x86_64-linux]
* Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN
----------------------------------------
When Fedora started to harden its packages, we quite often seen complains from our users about problems installing their gems, with errors such as [1]:
~~~
gcc: error: /usr/lib/rpm/redhat/redhat-hardened-cc1: No such file or directory
~~~
The issue as analyzed by Mamoru TASAKA is [2]:
> Well, if I am not mistaken, the real problem here is that rpm's %optflags is always embedded into Fedora's ruby config file, that is
>
> /usr/lib64/ruby/rbconfig.rb:167: CONFIG["CXXFLAGS"] = "-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -mtune=generic"
> /usr/lib64/ruby/rbconfig.rb:171: CONFIG["CFLAGS"] = "-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -mtune=generic -fPIC"
>
> on x86_64, for example.
>
> Although I am not sure this is already discussed somewhere or not, basically I think changing the default CFLAGS of "system" ruby like this way is undesirable and ? installed "rbconfig.rb" should have some "minimal" CFLAGS / CXXFLAGS.
> ( for example, just like CONFIG["CFLAGS"] = "-fPIC" )
>
> Only when we build Fedora gems or so (on koji), we should change CFLAGS / CXXFLAGS explicitly afterwards using %optflags.
and Red Hat toolchain team responds [3]:
> The current advice of the Red Hat toolchain team is to keep distribution build flags and toolchain default flags separate. This is why running “gcc” gives you the upstream defaults, and not the flags we use to compile Fedora packages. For consistency, Ruby (and other compilation support tools) follow this pattern: Use distribution flags when building for Fedora, but use upstream flags when the user compiles packages (i.e., what Ruby uses, probably something involving -O2).
>
> Our build flags are fully ABI-compatible with each other, so mismatches will not cause any problems at the C/C++/ABI level.
The question is why Ruby does this and how we can avoid this behavior. We could force installation of redhat-rpm-config package, providing the "/usr/lib/rpm/redhat/redhat-hardened-cc1", to every ruby user, but that does not seems right. There are also other similar issues discussing this situation [4], [5]. Any thoughts?
[1]: https://bugzilla.redhat.com/show_bug.cgi?id=1284684
[2]: https://bugzilla.redhat.com/show_bug.cgi?id=1284684#c6
[3]: https://bugzilla.redhat.com/show_bug.cgi?id=1284684#c11
[4]: https://bugzilla.redhat.com/show_bug.cgi?id=1218294
[5]: https://bugzilla.redhat.com/show_bug.cgi?id=1432191
--
https://bugs.ruby-lang.org/
Issue #14418 has been updated by jeremyevans0 (Jeremy Evans).
Status changed from Open to Closed
Thanks to very impressive work by @makenowjust, this issue has been fixed in Ruby 3.2.
----------------------------------------
Bug #14418: ruby 2.5 slow regexp execution
https://bugs.ruby-lang.org/issues/14418#change-104241
* Author: jakub.wozny (Kuba W)
* Status: Closed
* Priority: Normal
* ruby -v: 2.5
* Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN
----------------------------------------
I have simple regexp that performing very slow.
~~~ ruby
"fußball "*20 =~ /^([\S\s]{1000})/i
~~~
It works fast if I remove `/i` flag. I figured out that is also depends on string length or on quantifier value (in this case it is `{1000}`).
When you remove `ß` form the string it also works fast.
I tested on 2.3.1, 2.4.3 and 2.5.0.
I'm not sure it is a bug or it just works that way.
--
https://bugs.ruby-lang.org/
Issue #14064 has been updated by jeremyevans0 (Jeremy Evans).
Status changed from Open to Closed
It looks like a fix for this was committed in commit:dd3851d2786412de019350a11e749c56fa5a07cc
----------------------------------------
Bug #14064: test-all with and without -j - incorrect assertions and missing test methods
https://bugs.ruby-lang.org/issues/14064#change-104240
* Author: MSP-Greg (Greg L)
* Status: Closed
* Priority: Normal
* ruby -v: ruby 2.5.0dev (2017-10-29 trunk 60531) [x64-mingw32]
* Backport: 2.3: UNKNOWN, 2.4: UNKNOWN
----------------------------------------
I always run test-all with a `-v` parameter, and although both Travis & Appveyor scripts do not, many of the https://rubyci.org builds seem to. With `-v`, one has a log of all test methods.
For quite a while, I ran ruby-loco (MinGW trunk build) with `test-all` having no `-j` parameter. I've now changed to using `-j`, and I'm surprised at what I'm finding.
When run without a `-j` parameter, the total test count is correct, but the total assertions count is high.
When run with a `-j` parameter (even set to 1), the test count drops (along with tests not appearing in the log), and the total assertions count is correct. Often, whole test files (classes) disappear from the log.
Re the test count variance, I wrote code to parse the logs (the total test count variance), which showed which test methods were present in non-parallel test logs that were missing in parallel test logs.
As to the assertions, I ran test-all on a few single files, and added the assertion count to each test method line, then compared with and without `-j`. Finally, by checking individual methods for their respective number of assertions, it was clear that the numbers shown in a non-parallel run were high. At first, it seemed that they were high by a count of three, but that only held for a few files.
First of all, I'm wondering if anyone else has found similar results.
Secondly, I've spent some time verifying this, but I can't seem to find where the code needs corrections to function properly. I hoped it might be a timeout issue, but that doesn't seem to be the case. Hence, suggestions as to where to start are welcome.
Finally, in Travis, the line for test-all is:
```
make -s $JOBS test-all -o exts TESTOPTS='-q --color=never --job-status=normal'
```
Using MinGW, adding $JOBS as a make parameter seems to have no effect.
--
https://bugs.ruby-lang.org/
Issue #13571 has been updated by jeremyevans0 (Jeremy Evans).
Status changed from Open to Closed
Starting in Ruby 3.0, arguments provided to Ruby (in `ARGV`) are now in correct UTF-8 encoding.
----------------------------------------
Bug #13571: Script arguments, encoding, windows / MinGW
https://bugs.ruby-lang.org/issues/13571#change-104237
* Author: MSP-Greg (Greg L)
* Status: Closed
* Priority: Normal
* ruby -v: ruby 2.5.0dev (2017-05-17 trunk 58774) [x64-mingw32]
* Backport: 2.2: UNKNOWN, 2.3: UNKNOWN, 2.4: UNKNOWN
----------------------------------------
The following is windows/MinGW specific.
I have been patching around a failure in [TestRubyOptions#test_command_line_progname_nonascii](https://github.com/rub… for a while, and decided to investigate further, assuming it was a simple issue.
The following code -
```ruby
# set dir to valid directory
dir = "E:/temp"
fn_1 = 'äÖü.rb'
fn_2 = 'テスト.rb'
puts
puts "ENV['RUBYOPT'] #{ENV['RUBYOPT']}" \
"\nfilesystem #{Encoding.find('filesystem')}" \
"\nexternal #{Encoding.default_external}" \
"\n`chcp` #{`chcp`}" \
"locale #{Encoding.find('locale')}" \
"\n__ENCODING__ #{__ENCODING__}" \
"\ninternal #{Encoding.default_internal}\n" \
"\nfn_1 #{fn_1.encoding.to_s}" \
"\näÖü.rb #{'äÖü.rb'.encoding.to_s}" \
"\nfn_2 #{fn_2.encoding.to_s}" \
"\nテスト.rb #{'テスト.rb'.encoding.to_s}"
Dir.chdir(dir) do |dir|
open(fn_1, "w") { |f| f.puts "puts File.basename($0)" }
open(fn_2, "w") { |f| f.puts "puts File.basename($0)" }
puts
puts "File.exist?(fn_1) #{File.exist?(fn_1)}"
puts "File.exist?(fn_2) #{File.exist?(fn_2)}"
puts
puts `ruby #{fn_1}`
puts `ruby #{fn_2}`
end
```
produces the following output -
```
ENV['RUBYOPT']
filesystem Windows-1252
external IBM437
`chcp` Active code page: 437
locale IBM437
__ENCODING__ UTF-8
internal
fn_1 UTF-8
äÖü.rb UTF-8
fn_2 UTF-8
テスト.rb UTF-8
File.exist?(fn_1) true
File.exist?(fn_2) true
äÖü.rb: No such file or directory @ realpath_rec - E:/temp/„™�.rb (Errno::ENOENT)
ruby: Invalid argument -- ???.rb (LoadError)
```
Of note is that both files are created (and appear correctly in Explorer), but neither can be used as a script argument.
Copy and pasting the names (from Explorer) on the command line produces the following similar output -
```
E:\temp>ruby äÖü.rb
äÖü.rb: No such file or directory @ realpath_rec - E:/temp/„™�.rb (Errno::ENOENT)
E:\temp>ruby テスト.rb
ruby: Invalid argument -- ???.rb (LoadError)
```
Lastly, if before running the code I do a `chcp 1252` command to match up 'locale' and 'filesystem', the first script file runs and produces the correct output.
Hence, it appears that some (or all?) `File` methods deal properly with `filesystem` encoding, but ruby script arguments are not correctly encoded.
--
https://bugs.ruby-lang.org/
Issue #13269 has been updated by jeremyevans0 (Jeremy Evans).
Status changed from Assigned to Closed
The readline extension was removed in commit:59fd67fc3d405e529e038172e769ff20a8fb5535. If this is still an issue, please file it upstream: https://github.com/ruby/readline-ext
----------------------------------------
Bug #13269: test/readline/test_readline.rb and mingw
https://bugs.ruby-lang.org/issues/13269#change-104233
* Author: MSP-Greg (Greg L)
* Status: Closed
* Priority: Normal
* Assignee: nobu (Nobuyoshi Nakada)
* ruby -v: ruby 2.5.0dev (2017-03-02 trunk 57755) [x64-mingw32]
* Backport: 2.2: UNKNOWN, 2.3: UNKNOWN, 2.4: UNKNOWN
----------------------------------------
When running test-all on a mingw build, [`test_readline.rb`](https://github.com/ruby/ruby/blob/trunk/test/readline/test_readline.rb) generates failures and errors. Several of the errors are due to the `with_temp_stdio` method in `test_readline.rb`. It also leaves several undeleted files in the temp dir.
Current link is: [TestReadline#with_temp_stdio](https://github.com/ruby/ruby/blob/trunk/test/…
The current code is:
```ruby
def with_temp_stdio
Tempfile.create("test_readline_stdin") {|stdin|
Tempfile.create("test_readline_stdout") {|stdout|
yield stdin, stdout
}
}
end
```
Replacing it with the following solved the problems.
```ruby
def with_temp_stdio
stdin = Tempfile.new("test_readline_stdin")
stdout = Tempfile.new("test_readline_stdout")
yield stdin, stdout
if stdout
stdout.closed? ? stdout.unlink : stdout.close!
end
if stdin
stdin.closed? ? stdin.unlink : stdin.close!
end
end
```
I can only test on Windows, but I assume the changed code would work on other os's. If someone could test it, I'd submit a PR. Maybe the code in `Tempfile::Remover` is really where the change should occur, but I haven't looked at that.
After this update, I only had one failure and three errors. Text below.
Odd thing for two errors it that they report `NoMethodError: undefined method assert_separately`, but the highlighted line is `return if assert_under_utf8`. I didn't do an exhaustive search, but I can't find a reference to that function. But, I'm pulling the test files out of ruby and running separately...
```
Failure: test_input_metachar(TestReadline)
D:/r_test/Readline/test_readline.rb:420:in `test_input_metachar'
417: wo = w.dup
418: wo.write("\C-re\ef\n")
419: end
=> 420: assert_equal("hello", line, bug6601)
421: ensure
422: wo.close
423: Readline.delete_text
[ruby-core:45682]
<"hello">(UTF-8) expected but was
<"hfello">(IBM437)
diff:
? hfello
? Encoding: UTF-8
? IBM437
====================================================================================================================================================
Error: test_input_metachar_multibyte(TestReadline):
NoMethodError: undefined method `assert_separately' for #<TestReadline:0x00000003bcfef0>
Did you mean? assert_empty
D:/r_test/Readline/test_readline.rb:618:in `assert_under_utf8'
D:/r_test/Readline/test_readline.rb:429:in `test_input_metachar_multibyte'
426:
427: def test_input_metachar_multibyte
428: unless Encoding.find("locale") == Encoding::UTF_8
=> 429: return if assert_under_utf8
430: skip 'this test needs UTF-8 locale'
431: end
432: bug6602 = '[ruby-core:45683]'
====================================================================================================================================================
Error: test_refresh_line(TestReadline):
NoMethodError: undefined method `assert_ruby_status' for #<TestReadline:0x00000003bcf6f8>
Did you mean? assert_raises
D:/r_test/Readline/test_readline.rb:459:in `block (2 levels) in test_refresh_line'
456: bug6232 = '[ruby-core:43957] [Bug #6232] refresh_line after set_screen_size'
457: with_temp_stdio do |stdin, stdout|
458: replace_stdio(stdin.path, stdout.path) do
=> 459: assert_ruby_status(%w[-rreadline -], <<-'end;', bug6232)
460: Readline.set_screen_size(40, 80)
461: Readline.refresh_line
462: end;
D:/r_test/Readline/test_readline.rb:567:in `block (2 levels) in replace_stdio'
D:/r_test/Readline/test_readline.rb:557:in `open'
D:/r_test/Readline/test_readline.rb:557:in `block in replace_stdio'
D:/r_test/Readline/test_readline.rb:556:in `open'
D:/r_test/Readline/test_readline.rb:556:in `replace_stdio'
D:/r_test/Readline/test_readline.rb:458:in `block in test_refresh_line'
D:/r_test/Readline/test_readline.rb:583:in `with_temp_stdio'
D:/r_test/Readline/test_readline.rb:457:in `test_refresh_line'
====================================================================================================================================================
Error: test_using_quoting_detection_proc_with_multibyte_input(TestReadline):
NoMethodError: undefined method `assert_separately' for #<TestReadline:0x00000003bcf2c0>
Did you mean? assert_empty
D:/r_test/Readline/test_readline.rb:618:in `assert_under_utf8'
D:/r_test/Readline/test_readline.rb:517:in `test_using_quoting_detection_proc_with_multibyte_input'
514: saved_completer_word_break_characters = Readline.completer_word_break_characters
515: return unless Readline.respond_to?(:quoting_detection_proc=)
516: unless Encoding.find("locale") == Encoding::UTF_8
=> 517: return if assert_under_utf8
518: skip 'this test needs UTF-8 locale'
519: end
520:
```
--
https://bugs.ruby-lang.org/
Issue #19436 has been reported by byroot (Jean Boussier).
----------------------------------------
Bug #19436: Call Cache for singleton methods can lead to "memory leaks"
https://bugs.ruby-lang.org/issues/19436
* Author: byroot (Jean Boussier)
* Status: Open
* Priority: Normal
* Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN
----------------------------------------
Using "memory leaks" with quotes, because strictly speaking the memory isn't leaked, but it can nonetheless lead to large memory overheads.
### Minimal Reproduction
```ruby
module Foo
def bar
end
end
def call_bar(obj)
# Here the call cache we'll keep a ref on the method_entry
# which then keep a ref on the singleton_class, making that
# instance immortal until the method is called again with
# another instance.
# The reference chain is IMEMO(callcache) -> IMEMO(ment) -> ICLASS -> CLASS(singleton) -> OBJECT
obj.bar
end
obj = Object.new
obj.extend(Foo)
call_bar(obj)
id = obj.object_id
obj = nil
4.times { GC.start }
p ObjectSpace._id2ref(id)
```
### Explanation
Call caches keep a strong reference onto the "callable method entry" (CME), which itself keeps a strong reference on the called object class
and in the cache of a singleton class, it keeps a strong reference onto the `attached_object` (instance).
This means that any call site that calls a singleton method, will effectively keep a strong reference onto the last receiver.
If the method is frequently called it's not too bad, but if it's infrequently called, it's effectively a (bounded) memory leak.
And if the `attached_object` is big, the wasted memory can be very substantial.
### Practical Implications
Once relative common API impacted by this is [Rails' `extending` API](https://api.rubyonrails.org/classes/ActiveRecord/QueryMethods.html#met…. This API allow to extend a "query result set" with a module.
These query results set can sometimes be very big, especially since they keep references to the instantiated `ActiveRecord::Base` instances etc.
### Possible Solutions
#### Only keep a weak reference to the CME
The fairly "obvious" solution is to keep a weak reference to the CME, that's what I explored in https://github.com/ruby/ruby/pull/7272, and it seems to work.
However in debug mode It does fail on an assertion during compaction, but it's isn't quite clear to me what the impact is.
Additionally, something that makes me think this would be the right solution, is that call caches already try to avoid marking the class:
```c
# vm_callinfo.h:275
struct rb_callcache {
const VALUE flags;
/* inline cache: key */
const VALUE klass; // should not mark it because klass can not be free'd
// because of this marking. When klass is collected,
// cc will be cleared (cc->klass = 0) at vm_ccs_free().
```
So it appears that the class being also marked through the CME is some kind of oversight?
#### Don't cache based on some heuristics
If the above isn't possible or too complicated, an alternative would be to not cache CMEs found in singleton classes, except if it's the the singleton class of a `Class` or `Module`.
It would make repeated calls to such methods slower, but the assumption is that it's unlikely that these CME would live very long.
#### Make `Class#attached_object` a weak reference
Alternatively we could make the `attached_object` a weak reference, which would drastically limit the amount of memory that may be leaked in such scenario.
The downside is that `Class#attached_object` was very recently exposed in Ruby 3.2.0, so it means changing its semantic a bit.
cc @peterzhu2118 @ko1
--
https://bugs.ruby-lang.org/
Issue #19785 has been reported by peterzhu2118 (Peter Zhu).
----------------------------------------
Feature #19785: Deprecate `RUBY_GC_HEAP_INIT_SLOTS `
https://bugs.ruby-lang.org/issues/19785
* Author: peterzhu2118 (Peter Zhu)
* Status: Open
* Priority: Normal
----------------------------------------
GitHub PR: https://github.com/ruby/ruby/pull/8116
The `RUBY_GC_HEAP_INIT_SLOTS` environment variable is replaced by
`RUBY_GC_HEAP_INIT_SIZE_%d_SLOTS` (introduced in commit
[3ab3455](https://github.com/ruby/ruby/commit/3ab34551450c7a3a3e1ae0b24bf6b7…),
which allows for more fine-grained tuning of size pools. So it doesn't make
sense to keep the environment variable `RUBY_GC_HEAP_INIT_SLOTS`.
I'm proposing to deprecate `RUBY_GC_HEAP_INIT_SLOTS` and eventually remove it.
--
https://bugs.ruby-lang.org/
Issue #10416 has been updated by duerst (Martin Dürst).
The next version of Unicode (15.1) will be released in about 3 weeks. I'll check at that point, and close if no longer relevant.
----------------------------------------
Bug #10416: Create mechanism for updating of Unicode data files downstreams when we want
https://bugs.ruby-lang.org/issues/10416#change-104227
* Author: duerst (Martin Dürst)
* Status: Open
* Priority: Normal
* Assignee: nobu (Nobuyoshi Nakada)
* ruby -v: ruby 2.2.0dev (2014-10-22 trunk 48092) [x86_64-cygwin]
* Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN
----------------------------------------
The current mechanism for updating Unicode data files will create the following problem:
Downstream compilers/packagers will download Unicode data files ONE time (they may already have done so).
However, if they don't activate ALWAYS_UPDATE_UNICODE = yes, these files will never get updated, and they will stay on Unicode version 7.0 even if in five years Unicode is e.g. on version 12.0.
On the other hand, if they activate ALWAYS_UPDATE_UNICODE = yes (and assuming issue #10415 gets fixed), they constantly update to the latest version of Unicode. That's good for those who actually want this, but now what our current policy is.
What's missing is that we (Ruby core) can make sure downstream checkouts update to a new Unicode version when we want then to do so (as we e.g. can do for other parts that are based on Unicode data, see e.g. https://bugs.ruby-lang.org/issues/9092), without sending an email to everybody and hoping they read and follow it.
[Currently, the only solution I know will work is the one pointed out by Yui Naruse in https://bugs.ruby-lang.org/issues/10084#note-17, but I'm okay with any other solution.]
--
https://bugs.ruby-lang.org/
Issue #19005 has been updated by stanhu (Stan Hu).
We can close this now that XCode 14.3, which ships with clang 14.0.3, now fixes this issue: https://github.com/python/cpython/issues/97524#issuecomment-1458855301
----------------------------------------
Bug #19005: Ruby interpreter compiled XCode 14 cannot build some native gems on macOS
https://bugs.ruby-lang.org/issues/19005#change-104223
* Author: stanhu (Stan Hu)
* Status: Open
* Priority: Normal
* ruby -v: ruby 2.7.6p219 (2022-04-12 revision 44c8bfa984) [arm64-darwin21]
* Backport: 2.7: DONE, 3.0: DONE, 3.1: DONE
----------------------------------------
This seems related to https://bugs.ruby-lang.org/issues/18912 and https://bugs.ruby-lang.org/issues/18981 .
Steps to reproduce:
1. Upgrade to XCode 14.
2. Compile a new Ruby interpreter. I used the version provided in https://github.com/ruby/ruby/pull/6297 with `./configure --prefix=/tmp/ruby --with-openssl-dir=$(brew --prefix openssl(a)1.1) --with-readline-dir=$(brew --prefix readline) --enable-shared`.
3. Confirm that `-Wl,-undefined,dynamic_lookup` is no longer available:
```
irb(main):001:0> RbConfig::CONFIG['DLDFLAGS']
=> "-Wl,-multiply_defined,suppress"
```
4. Ran `gem install pg_query` (`gem install ffi-yajl` will also fail).
Error:
```
linking shared-object pg_query/pg_query.bundle
Undefined symbols for architecture arm64:
"Init_pg_query", referenced from:
-exported_symbol[s_list] command line option
(maybe you meant: _Init_pg_query)
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
```
I can workaround the problem by doing:
```
gem install pg_query -- --with-ldflags="-Wl,-undefined,dynamic_lookup"
```
--
https://bugs.ruby-lang.org/