Project

General

Profile

Actions

Bug #16836

open

configure-time LDFLAGS leak into ruby pkg-config file

Added by stapelberg (Michael Stapelberg) over 1 year ago. Updated 2 months ago.

Status:
Assigned
Priority:
Normal
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) 2 months ago

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

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) 2 months 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 :)

Actions

Also available in: Atom PDF