Project

General

Profile

Actions

Bug #16836

closed

configure-time LDFLAGS leak into ruby pkg-config file

Added by stapelberg (Michael Stapelberg) almost 4 years ago. Updated over 1 year ago.

Status:
Feedback
Target version:
-
[ruby-core:98170]

Description

When building ruby with e.g. -Wl,-rpath=/ro/ruby-amd64-2.7.1-6/lib (to make it hermetic, see my work-in-progress post at https://website-review.zekjur.net/pull/hermetic/posts/2020-05-04-distri-hermetic-packages/), I noticed that the resulting pkg-config file (lib/pkgconfig/ruby-2.7.pc) includes the LDFLAGS!

This will result in software that links against ruby being built with the wrong rpath.

In general, LDFLAGS should not be persisted into pkg-config. The attached patch fixes the issue.

Thanks,


Files

pc-ldflags.patch (563 Bytes) pc-ldflags.patch stapelberg (Michael Stapelberg), 05/07/2020 07:17 AM

Updated by jeremyevans0 (Jeremy Evans) over 2 years ago

  • Status changed from Open to Assigned
  • Assignee set to nobu (Nobuyoshi Nakada)

According to the history, adding DLDFLAGS to Libs was a deliberate decision made back in 2010 in 51d25ca8c0eb7da192f5bdf2729fc856e8f81a9d. Assigning to @nobu (Nobuyoshi Nakada) as he was the one that made the change. I'm guessing there are environments where using DLDFLAGS is required for correct functioning, so reverting the commit is unlikely to be an option.

This sounds like something you could just easily patch out in distri. It looks like distri is still not recommended for production use according to https://distr1.org/, so the current behavior seems unlikely to affect users.

Updated by stapelberg (Michael Stapelberg) over 2 years ago

Thanks for taking a look!

jeremyevans0 (Jeremy Evans) wrote in #note-1:

According to the history, adding DLDFLAGS to Libs was a deliberate decision made back in 2010 in 51d25ca8c0eb7da192f5bdf2729fc856e8f81a9d. Assigning to @nobu (Nobuyoshi Nakada) as he was the one that made the change. I'm guessing there are environments where using DLDFLAGS is required for correct functioning, so reverting the commit is unlikely to be an option.

Perhaps the situation has changed in the 11 years since that commit, though :)

I took a look, but the commit doesn’t seem to mention any rationale for making the change.

This sounds like something you could just easily patch out in distri. It looks like distri is still not recommended for production use according to https://distr1.org/, so the current behavior seems unlikely to affect users.

That’s correct, distri is a research project and doesn’t directly serve users in that sense.

However, I figured that if it’s a problem for distri, it’s likely a problem for other hermetic environments, either now or in the future, so correctness bugs like these are good to fix upstream. If that turns out to be incorrect and nobody else cares, then fine, but I wanted to at least report it :)

Updated by nobu (Nobuyoshi Nakada) over 1 year ago

  • Status changed from Assigned to Feedback

IIRC, rpath is the path embedded in the linked binary, in order to resolve shared libraries at runtime.
There is no reason to set the path that won’t exist at runtime, I think.

Actions

Also available in: Atom PDF

Like0
Like0Like0Like0