public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Nick Clifton <nickc@redhat.com>
To: Johannes Schauer Marin Rodrigues <josch@debian.org>
Cc: Binutils <binutils@sourceware.org>
Subject: Re: [patch] objcopy embeds the current time and ignores SOURCE_DATE_EPOCH making the output unreproducible
Date: Thu, 20 Jul 2023 12:08:35 +0100	[thread overview]
Message-ID: <89d6a4a8-dc8d-c384-9fbe-2b6daa6b015e@redhat.com> (raw)
In-Reply-To: <168983055254.2785030.15255872242112800439@localhost>

Hi Johannes,

>>     * Updating the description of the --timestamp command line option in
>>       ld/ld.texi to mention that if SOURCE_DATE_EPOCH is defined in the
>>      environment then this will be used instead of the current time.
> 
> I'm a bit confused here. I'm fixing objcopy but am supposed to edit ld/ld.texi?

Ah - I think that we were both confused.  You see the code that you are patching
in bfd/peXXigen.c is used by both the linker and objcopy.  I was tracking down
where the timestamp field in the pe_data_type structure was set, and I got diverted
to ld/emultempl/pe.em, which is why I thought about updating the linker documentation.

So anyway, both the linker documentation *and* the objcopy documentation need to
be updated...

There is also the minor issue that there is no way to undo the effects of the
-p/--preserve-dates command line option.  This can be an issue for complex build
systems that like to build up command lines in stages, allowing later stages to
override the effects of earlier stages.  But that is not something that affects
the review of your patch.

> Also, that file does not contain docs for a --timestamp command line option. Do
> you mean the --insert-timestamp option?

I did.  Sorry.

> Also, there is another instance of something calling time(0) in ld/pe-dll.c. I
> don't know what that does. Does it need fixing as well?

Good catch.  Yes that will need the same kind of change as peXXigen.c.

If you could resubmit your patch (to the list) with these changes and accompanied
by a DCO then I will approve and apply it.

Cheers
   Nick


       reply	other threads:[~2023-07-20 11:08 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <168983055254.2785030.15255872242112800439@localhost>
2023-07-20 11:08 ` Nick Clifton [this message]
2023-07-20 23:15   ` Johannes Schauer Marin Rodrigues
2023-07-24 16:01     ` Nick Clifton
2023-07-19 10:54 Matthias Klose
2023-07-19 11:02 ` Nick Clifton

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=89d6a4a8-dc8d-c384-9fbe-2b6daa6b015e@redhat.com \
    --to=nickc@redhat.com \
    --cc=binutils@sourceware.org \
    --cc=josch@debian.org \
    /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).