4 ms·

The problem you now have two identical but not identical versions. I would not like to be part of a team that does binary edits. Unless there is no other way.

anon4 13y ago
Assuming they just compiled the old version with a bumped version number, that's exactly what they ended up with. If you compile the same source twice you get the exact same binary.
- awalton 13y ago
  > If you compile the same source twice you get the exact same binary. You wish this were true. You really, really wish it were. But it's not always. Reproducibility is a really tough problem when you support 25+ Linuxes, each with their own versions of GCC and libc, different compiler flags by default, etc. There's some work being done to make this "better" like GNU ld's build-id hashing binary sections so it's easier to tell if they changed, and projects that stash the compiler's flags in a binary section with -frecord-gcc-switches/-grecord-gcc-switches. But we've still got a long way to go, at least in the wonderfully fragmented landscape of Linux software development. Furthermore, the example in the article is rather specious. Versioning is very often done by macros and string replacement and not some constant somewhere in a .section that's easy to just "lemme tweak this" and push a new release. No, you'd have to go through the entire object file to find any place that version number is used. It's not the exceptional case in real world software with multiple supported releases that you see code like: if (version_number == 2 || version_number == 3) { do this thing; } else if (version_number == 4) { do that thing instead; } or its equivalent with #ifdefs, which the compiler can then fold away in preprocessing or dead code elimination leaving you with the right chunk for the product version. Hex editing the binary won't catch this, leaving you with a broken binary. tl;dr: rebuild the software if you screwed up.
jevinskie 13y ago
Yeah I think it may be short sighted to shortcut a build+release process just to save a few hours. I can only imagine what might go wrong or what I might miss. Someone else mentioned code signatures which is a good point.

anon4 13y ago

Assuming they just compiled the old version with a bumped version number, that's exactly what they ended up with. If you compile the same source twice you get the exact same binary.

awalton 13y ago
> If you compile the same source twice you get the exact same binary. You wish this were true. You really, really wish it were. But it's not always. Reproducibility is a really tough problem when you support 25+ Linuxes, each with their own versions of GCC and libc, different compiler flags by default, etc. There's some work being done to make this "better" like GNU ld's build-id hashing binary sections so it's easier to tell if they changed, and projects that stash the compiler's flags in a binary section with -frecord-gcc-switches/-grecord-gcc-switches. But we've still got a long way to go, at least in the wonderfully fragmented landscape of Linux software development. Furthermore, the example in the article is rather specious. Versioning is very often done by macros and string replacement and not some constant somewhere in a .section that's easy to just "lemme tweak this" and push a new release. No, you'd have to go through the entire object file to find any place that version number is used. It's not the exceptional case in real world software with multiple supported releases that you see code like: if (version_number == 2 || version_number == 3) { do this thing; } else if (version_number == 4) { do that thing instead; } or its equivalent with #ifdefs, which the compiler can then fold away in preprocessing or dead code elimination leaving you with the right chunk for the product version. Hex editing the binary won't catch this, leaving you with a broken binary. tl;dr: rebuild the software if you screwed up.

jevinskie 13y ago

Yeah I think it may be short sighted to shortcut a build+release process just to save a few hours. I can only imagine what might go wrong or what I might miss. Someone else mentioned code signatures which is a good point.