[rb-general] __DATE__ and other toolchain patches

[Eli Schwartz]

On 12/26/18 1:34 PM, Daniel Shahaf wrote:
> Eli Schwartz wrote on Tue, 25 Dec 2018 15:52 -0500:
>> Eh, it's hardly harmful either way. I don't believe there was any
>> explicit desire to avoid relying on toolchain fixes though. Especially
>> since the patch is definitely in Arch Linux's toolchain (we have gcc 8)
>> so in the ordinary way of things we would never notice any issues with
>> packages using __DATE__ at all.
> 
> Personally, this reminds me of the discussion about tar a few weeks ago,
> about some packages being reproducible using GNU tar but not reproducible
> using other tar implementations, so GNU tar becomes a non-interchangeable
> dependency for those packages.  Letting a package use __DATE__ because
> gcc DTRT's with that is exactly the same kind of dependency.

I think that's quite a different case, because the problem with tar is
that different implementations accept different options.

It's not a reproducibility problem, it's a portability/namespacing problem.

> Avoiding use of __DATE__ in a specific package will make that package
> reproducible regardless of what compiler it is built with.  However, the
> 80/20 rule applies: 80% of builds will use the most common 20% of
> compiler configurations, so getting those right should be the higher
> priority.  Thus, I think teaching clang to set __DATE__ from
> SOURCE_DATE_EPOCH should be higher priority than fixing use of __DATE__
> in a particular package, though both of these changes have merit.
> 
> After all, people will use compilers other than gcc and clang.  (The
> entire point of open source is that people can take the code and use it
> in places the original author never expected.)

I guess it would be even nicer if there were a de facto standard for
compilers that these macros should respect SOURCE_DATE_EPOCH, and
therefore all compilers would work.

-- 
Eli Schwartz
Bug Wrangler and Trusted User

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.reproducible-builds.org/pipermail/rb-general/attachments/20181226/7eed2f30/attachment.sig>