On 19. 5. 26 04:41, Nathan Hartman wrote:
On Mon, May 18, 2026 at 10:27 PM Branko Čibej <[email protected]> wrote:
I was playing around just now, trying to create a tarball using
release.py. Found an amazing bug that can in the right
circumstances create the tarball using the wrong libtool.
* release.py installs, and then requires presence of, a program
called 'libtool'. ✅
* It checks the libtool version before calling autogen.sh. ✅
* It will not consider any programs called 'glibtool'. ❓
* autogen.sh looks for 'glibtool' on the path before 'libtool'. ❌
If I have a different 'glibtool' on the path than the carefully
installed 'libtool', autogen.sh will use the wrong one. It prints
the version number, but that's likely to be missed.
Wow! Good catch!
Seems to me that release.py should look for the external tools
with the same names in the same order as autogen.sh.
That sounds like a good starting point.
And since these will need to stay synchronized, until there's a better
solution, probably they should both have a comment in the appropriate
place to remind anyone fiddling with either one to make the same
change in both.
Oops. I missed one important bit in release.py:
def build(self):
RollDep.build(self)
# autogen.sh looks for glibtoolize before libtoolize
bin_dir = os.path.join(get_prefix(self._base_dir), "bin")
os.symlink("libtoolize", os.path.join(bin_dir, "glibtoolize"))
os.symlink("libtool", os.path.join(bin_dir, "glibtool"))
In other words, it's already taken care of, albeit in a needlessly
roundabout way: release.py could configure the libtool build with
--program-prefix=g and use 'glibtool(ize)' everywhere. Oh well, not
worth following up on, I think.
-- Brane
