|
23 | 23 | # https://github.com/rake-compiler/rake-compiler-dock/issues/69 |
24 | 24 | puts "Linking with '-static' flag" |
25 | 25 | $LDFLAGS << ' -static' |
| 26 | + else |
| 27 | + if RbConfig::CONFIG["target_os"].include?("darwin") |
| 28 | + ## In ruby 3.2, symbol resolution changed on Darwin, to introduce the `-bundle_loader` flag. |
| 29 | + ## |
| 30 | + ## See https://github.com/rake-compiler/rake-compiler-dock/issues/87 for a lot of context, but |
| 31 | + ## I'll try to summarize here. |
| 32 | + ## |
| 33 | + ## > -bundle_loader executable |
| 34 | + ## > This specifies the executable that will be loading the bundle output file being linked. |
| 35 | + ## > Undefined symbols from the bundle are checked against the specified executable like it |
| 36 | + ## > was one of the dynamic libraries the bundle was linked with. |
| 37 | + ## |
| 38 | + ## There are good reasons to do this, including faster initialiation/loading as the Darwin |
| 39 | + ## toolchain gets improved over time. |
| 40 | + ## |
| 41 | + ## Unfortunately, this flag prevents us from building a shared object that works with both a |
| 42 | + ## Ruby compiled with `--enable-shared` and one compiled with `--disabled-shared`. The result |
| 43 | + ## is usually an "Symbol not found" error about `_rb_cObject`, or a "dyld: missing symbol |
| 44 | + ## called" error. |
| 45 | + ## |
| 46 | + ## There are two workarounds that I know of (there may be others I don't know of), and |
| 47 | + ## they are ... |
| 48 | + |
| 49 | + ## ---------------------------------------- |
| 50 | + ## SOLUTION 1, the `-flat_namespace` flag |
| 51 | + ## |
| 52 | + ## > Two-level namespace |
| 53 | + ## > By default all references resolved to a dynamic library record the library to which |
| 54 | + ## > they were resolved. At runtime, dyld uses that information to directly resolve symbols. |
| 55 | + ## > The alternative is to use the -flat_namespace option. With flat namespace, the library |
| 56 | + ## > is not recorded. At runtime, dyld will search each dynamic library in load order when |
| 57 | + ## > resolving symbols. This is slower, but more like how other operating systems resolve |
| 58 | + ## > symbols. |
| 59 | + ## |
| 60 | + # |
| 61 | + # puts "Adding '-flat_namespace'" |
| 62 | + # $LDFLAGS << ' -flat_namespace' |
| 63 | + # |
| 64 | + ## This solution unfortunately introduces new behavior that any symbols statically linked into |
| 65 | + ## the shared object (e.g., libxml2 in nokogiri.bundle) may not be resolved locally from the |
| 66 | + ## shared object, but instead resolved from a shared object loaded in the main process. |
| 67 | + ## |
| 68 | + ## This solution might be good for you if: |
| 69 | + ## - you don't statically link things into your bundle, |
| 70 | + ## - or you don't export those symbols, |
| 71 | + ## - or you can avoid exporting those symbols (e.g., by using `-load_hidden`, or |
| 72 | + ## `-exported_symbols_list` or some other mechanism) |
| 73 | + ## |
| 74 | + |
| 75 | + ## ---------------------------------------- |
| 76 | + ## BUT ... if that is a problem, try SOLUTION 2, remove the `-bundle-loader` flag |
| 77 | + ## |
| 78 | + ## This returns us to the symbol resolution we had in previous Rubies. It feels gross but may |
| 79 | + ## be a workaround for gem maintainers until we all figure out a better way to deal with this. |
| 80 | + extdldflags = RbConfig::MAKEFILE_CONFIG["EXTDLDFLAGS"].split |
| 81 | + if found = extdldflags.index("-bundle_loader") |
| 82 | + removed_1 = extdldflags.delete_at(found) # flag |
| 83 | + removed_2 = extdldflags.delete_at(found) # and its argument |
| 84 | + puts "Removing '#{removed_1} #{removed_2}' from EXTDLDFLAGS" |
| 85 | + end |
| 86 | + RbConfig::MAKEFILE_CONFIG["EXTDLDFLAGS"] = extdldflags.join(" ") |
| 87 | + end |
26 | 88 | end |
27 | 89 |
|
28 | 90 | create_makefile("rcd_test/rcd_test_ext") |
|
0 commit comments