Skip to content
This repository was archived by the owner on Aug 31, 2021. It is now read-only.

Precisely preserve the timestamps when stripping debugging symbols#2642

Merged
livecodesebastien merged 3 commits into
livecode:developfrom
livecodestephen:build-timestamps
Sep 8, 2015
Merged

Precisely preserve the timestamps when stripping debugging symbols#2642
livecodesebastien merged 3 commits into
livecode:developfrom
livecodestephen:build-timestamps

Conversation

@livecodestephen

Copy link
Copy Markdown
Contributor

The --preserve-dates flag for strip and objcopy only has whole
second resolution. This meant that the modification time was being
truncated to an integer number of seconds. Consequently, when
stripping a file, some of the dependencies of that file would appear
to be newer, and hence the file would be unnecessarily remade during a
second call to make.

Simple solution: copy the timestamps to a separate file before we
strip and copy them back after.

The `--preserve-dates` flag for `strip` and `objcopy` only has whole
second resolution.  This meant that the modification time was being
truncated to an integer number of seconds.  Consequently, when
stripping a file, some of the dependencies of that file would appear
to be newer, and hence the file would be unnecessarily remade during a
second call to make.

Simple soultion: copy the timestamps to a separate file before we
strip and copy them back after.
@livecodeali

Copy link
Copy Markdown
Member

@livecode-vulcan review ok 005d6d6

@livecode-vulcan

Copy link
Copy Markdown
Contributor

💙 review by @livecodeali ok 005d6d6

livecode-vulcan added a commit that referenced this pull request Jul 31, 2015
Precisely preserve the timestamps when stripping debugging symbols

The `--preserve-dates` flag for `strip` and `objcopy` only has whole
second resolution.  This meant that the modification time was being
truncated to an integer number of seconds.  Consequently, when
stripping a file, some of the dependencies of that file would appear
to be newer, and hence the file would be unnecessarily remade during a
second call to make.

Simple solution: copy the timestamps to a separate file before we
strip and copy them back after.
@livecode-vulcan

Copy link
Copy Markdown
Contributor

😞 test failure 005d6d6

@runrevmark

Copy link
Copy Markdown
Contributor

It would seem that the --attributes-only option is understood on vulcan :(

@livecodestephen

Copy link
Copy Markdown
Contributor Author

The --attributes-only option was added in coreutils 8.6 and works on my laptop which has 8.21. Which version is vulcan using?

@livecodefraser

Copy link
Copy Markdown
Contributor

The 32-bit linux build is built on Debian Squeeze which only has coreutils 8.5.  Version >= 8.6 is required for the `--attributes-only` option on `cp`, so ignore failure of these commands.
@livecodestephen

Copy link
Copy Markdown
Contributor Author

I've changed it so that any failure of the cp command are ignored.

@livecode-vulcan

Copy link
Copy Markdown
Contributor

📝 Hi @livecodestephen, I haven't been able to verify that you've signed our LiveCode Contributor's Agreement.

If you have previously signed the Contributor's Agreement, I may not be able to detect it because you haven't linked your GitHub account to your LiveCode account.

Please see the information for contributors for more information.

@livecodefraser

Copy link
Copy Markdown
Contributor

@livecode-vulcan review okay b7180c7

@livecode-vulcan

Copy link
Copy Markdown
Contributor

💙 review by @livecodefraser ok b7180c7

@livecodesebastien

Copy link
Copy Markdown
Contributor

@livecodestephen: Could you sign the CLA, so that we can merge that it? Thanks

@livecodestephen

Copy link
Copy Markdown
Contributor Author

I didn't realise that was required for LiveCode staff. Will do it now.

livecode-vulcan added a commit that referenced this pull request Sep 8, 2015
Precisely preserve the timestamps when stripping debugging symbols

The `--preserve-dates` flag for `strip` and `objcopy` only has whole
second resolution.  This meant that the modification time was being
truncated to an integer number of seconds.  Consequently, when
stripping a file, some of the dependencies of that file would appear
to be newer, and hence the file would be unnecessarily remade during a
second call to make.

Simple solution: copy the timestamps to a separate file before we
strip and copy them back after.
@livecode-vulcan

Copy link
Copy Markdown
Contributor

😎 test success b7180c7

livecodesebastien added a commit that referenced this pull request Sep 8, 2015
Precisely preserve the timestamps when stripping debugging symbols
@livecodesebastien livecodesebastien merged commit c042606 into livecode:develop Sep 8, 2015
@livecodestephen livecodestephen deleted the build-timestamps branch September 8, 2015 14:10
livecodeali pushed a commit that referenced this pull request Sep 16, 2015
@livecodeali

Copy link
Copy Markdown
Member

I have reverted this as it was causing problems with the build - running under gdb I got the error message

"Workspace/livecode/linux-x86_64-bin/LiveCode-Community": not in executable format: File truncated

@livecodestephen

Copy link
Copy Markdown
Contributor Author

Which system was having problems? I'll see if I can reproduce it.

@livecodeali

Copy link
Copy Markdown
Member

I can reproduce on my Debian Wheezy VM

livecode-vulcan added a commit that referenced this pull request Sep 30, 2015
Precisely preserve the timestamps when stripping debugging symbols

This is an update to #2642.

On Debian Wheezy the `cp --attributes-only --preserve=timestamps` command was emptying the contents of the destination.  I've changed it to using `mv` and `touch` instead.  This should now work on Squeeze, so it no longer has to ignore any failures.

I also removed an unnecessary `mkdir` from `util/build-extensions.sh`.  This line was causing an error as `basename` doesn't have an `-s` flag on Debian Wheezy.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants