explore alternatives to setting LIBRARY_PATH
#118
Comments
|
@flavorjones, thank you for looking into this! @eregon, does this impact Nokogiri on Red Hat too? |
|
Nokogiri isn't impacted because its extconf.rb does not read the Ruby-magic likely is affected (and I would say the same for rcee/packaged_tarball) but I haven't yet attempted to reproduce it in CI to confirm. |
|
(And I've updated the description to be clearer that this only affect projects that are relying on a vendored |
and a local pkgconf file. This should catch the issue with fedora's pkgconf in #118.
|
See #131 where I'm working on this. |
and a local pkgconf file. This should catch the issue with fedora's pkgconf in #118.
This probably should have always been the behavior. This works around the behavior of Fedora's pkgconf described in #118. I'm a little worried that this might break packages in some subtle way, so the `set_ldflags` option will turn it off if needed.
|
Note for y'all who are following this issue: the approach I'm taking in #131 is for a new method, |
If MakeMakefile is loaded, assume we're in an `extconf.rb` and: - prepend a `-L lib_path` and `-l lib_name` to $LDFLAGS - prepend `-I include_path` to $CPPFLAGS This should mean we don't need to use the pkgconf trick in extconf.rb anymore, which completely avoids the behavior of Fedora's pkgconf described in #118. I'm a little worried that this might break packages in some subtle way, so it can be turned off by passing `mkmf: false` to `MiniPortile#activate` also: - fix up the windows paths in the the LDFLAGS env var and the tests - use assert_includes for better failure messages - extract public class methods MiniPortile.native_path and .posix_path
If MakeMakefile is loaded, assume we're in an `extconf.rb` and: - prepend a `-L lib_path` and `-l lib_name` to $LDFLAGS - prepend `-I include_path` to $CPPFLAGS This should mean we don't need to use the pkgconf trick in extconf.rb anymore, which completely avoids the behavior of Fedora's pkgconf described in #118. I'm a little worried that this might break packages in some subtle way, so it can be turned off by passing `mkmf: false` to `MiniPortile#activate` also: - fix up the windows paths in the the LDFLAGS env var and the tests - use assert_includes for better failure messages - extract public class methods MiniPortile.native_path and .posix_path
and a local pkgconf file. This should catch the issue with fedora's pkgconf in #118.
and a local pkgconf file. This should catch the issue with fedora's pkgconf in #118.
and a local pkgconf file. This should catch the issue with fedora's pkgconf in #118.
and a local pkgconf file. This should catch the issue with fedora's pkgconf in #118.
and a local pkgconf file. This should catch the issue with fedora's pkgconf in #118.
and a local pkgconf file. This should catch the issue with fedora's pkgconf in #118.
and a local pkgconf file. This should catch the issue with fedora's pkgconf in #118.
|
Reopening until I've made a final release that addresses this. |
|
See
which are both green, but currently there is a high risk of pulling in system shared libraries inadvertently. I've got a few options, but need to find the time to finish this work. |
|
Note: the re2 gem worked around shared linking in mudge/re2#93, there are probably lessons in there we can upstream. |
|
Picking this back up again this week after a related problem was raised in sparklemotion/nokogiri#3133 |
|
Note that the |
and others
Description
Currently,
mini_portilesets the environment variableLIBRARY_PATHin#activate. This behavior has been present since the first commit by Luis in 2011 (c06b4ab).This is OK the vast majority of the time, however an interesting and unfortunate edge case has shown up when the target system is using Fedora's alternative
pkgconf(more reading).The problem is this: on Fedora,
pkg-config --libswill not report any directories that are present inLIBRARY_PATH, which means that anyextconf.rbthat relies on a vendored library's.pcfile to set paths correctly will fail to find the vendored library.See sparklemotion/sqlite3-ruby#354 for an example of where this has generated a bug report, and https://gitlab.kitware.com/cmake/cmake/-/issues/22148#note_980802 for a related discussion in a non-Ruby context.
Possible solutions
mini_portilecould automaticallyappend_ldflags(lib_path)mini_portilecould stop settingLIBRARY_PATHmini_portilecould do both1and2I think any of these might be a reasonable solution, but only thorough testing against downstream projects is going to reveal whether we'll be introducing a subtle breaking change.
Next steps
Reproduce this issue in CI:
The text was updated successfully, but these errors were encountered: