From: Jacob Kroon <jacob.kroon@gmail.com>
To: Tom Kacvinsky <tkacvins@gmail.com>
Cc: gcc-help <gcc-help@gcc.gnu.org>
Subject: Re: Reserving specified size of RUNPATH entry in the dynamic section during linking
Date: Sun, 28 Nov 2021 15:24:25 +0100 [thread overview]
Message-ID: <49c9c178-23d7-d916-03d2-94a32092e622@gmail.com> (raw)
In-Reply-To: <CAG_eJLcojgwRaWK4PzXNYy8RXT+pczffjynTdCKWx5WdU-+WNA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1064 bytes --]
On 11/27/21 23:27, Tom Kacvinsky wrote:
>
>
> On Sat, Nov 27, 2021 at 5:05 PM Jacob Kroon via Gcc-help
> <gcc-help@gcc.gnu.org <mailto:gcc-help@gcc.gnu.org>> wrote:
>
> Hi,
>
> As part of an effort to make binaries reproducible regardless of their
> build path, I need to enforce the same size of the RUNPATH entry in the
> dynamic section during linking, even though I don't fill it completely.
> Is it possible to give some flag to gnu ld that allows me to set it to a
> specific size ? Or is there a way to patch the elf file after linking,
> so that the entry has a specified size ?
>
>
> This tool doesn't quite do what you'd like (set a fixed size for the
> RUNPATH entry in the dynamic table), but I have found it quite
> useful:
>
> https://github.com/NixOS/patchelf <https://github.com/NixOS/patchelf>
>
Thanks for the tip, but I can't get patchelf to produce identical
binaries, unless the rpath is already padded up to a common size in both
of the binaries.
I've attached a small Makefile I use to test with.
Jacob
[-- Attachment #2: reproducible.mk --]
[-- Type: text/x-makefile, Size: 596 bytes --]
workdir := $(shell mktemp -d)
all : compare
compare : $(workdir)/test-a $(workdir)/test-b
diffoscope $(workdir)/test-a $(workdir)/test-b
rpath-a = "/foobar "
rpath-b = "/a/much/longer/foobar"
$(workdir)/test-% : $(workdir)/%/test.c
gcc -O2 $< -o $@ -Wl,--build-id=none -Wl,--rpath=$(rpath-$*)
#chrpath -r "replacement" $@
patchelf --set-rpath "my-new-rpath" $@
define sourcecode
#include <stdio.h>
int main() {
printf("HelloWorld");
return 0;
}
endef
define newline
endef
$(workdir)/%/test.c :
mkdir -p $(dir $@)
echo -e '$(subst $(newline),\n,$(sourcecode))' > $@
next prev parent reply other threads:[~2021-11-28 14:24 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-27 22:05 Jacob Kroon
2021-11-27 22:27 ` Tom Kacvinsky
2021-11-28 14:24 ` Jacob Kroon [this message]
2021-11-28 11:44 ` Florian Weimer
2021-11-28 14:31 ` Jacob Kroon
2021-11-28 15:09 ` Dan Kegel
2021-11-28 15:17 ` Florian Weimer
2021-11-28 15:54 ` Jacob Kroon
2021-11-28 17:06 ` Florian Weimer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49c9c178-23d7-d916-03d2-94a32092e622@gmail.com \
--to=jacob.kroon@gmail.com \
--cc=gcc-help@gcc.gnu.org \
--cc=tkacvins@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).