kspalaiologos / bzip3

A better and stronger spiritual successor to BZip2.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Flat namespace on newer macOS

mrjbq7 opened this issue · comments

I'm having an issue building a homebrew formula to package bzip3 for macOS due use of flat namespaces.

Here is the relevant discussion:

https://github.com/orgs/Homebrew/discussions/4091#discussioncomment-4621749

It appears we need to update autoconf to make a better configure script for macOS that does not pass $wl-flat_namespace. Some other formula maintain patches that update the configure scripts, for example:

https://raw.githubusercontent.com/Homebrew/formula-patches/03cf8088210822aa2c1ab544ed58ea04c897d9c4/libtool/configure-pre-0.4.2.418-big_sur.diff

It would be nicer if we can instead get an updated release with updated configure scripts, rather than maintaining a patch diff.

Also, is there a bzip3 website I should reference, or just this github project page.

Hi! I will look into updating autoconf. We are packaging bzip3 using ubuntu-latest, which is Ubuntu 22.04, which has autoconf 2.71, which is the most recent version to my knowledge. To which version should we update?

As for the website - sadly no, referencing this Github page should suffice. Thanks for putting in the effort to package bzip3 for Homebrew!

That's a good question -- I see that autoconf 2.71 is the latest version, so perhaps Apple has a separate autoconf with patches. I will try and investigate that. Maybe a patch diff is what's required.

Interestingly, I use Debian Testing which supposedly uses the same version, but this piece of code linked in the patch is not present. The following is the comment header of generated configure on my machine:

#! /bin/sh
# Guess values for system-dependent variables and create Makefiles.
# Generated by GNU Autoconf 2.71 for bzip3 1.2.1.r5-g044136a.
#
# Report bugs to <https://github.com/kspalaiologos/bzip3>.
#
#
# Copyright (C) 1992-1996, 1998-2017, 2020-2021 Free Software Foundation,
# Inc.
#
#
# This configure script is free software; the Free Software Foundation
# gives unlimited permission to copy, distribute and modify it.

I have downloaded the tarball and the following is the comment header of the tarball:

#! /bin/sh
# Guess values for system-dependent variables and create Makefiles.
# Generated by GNU Autoconf 2.71 for bzip3 UNKNOWN.
#
# Report bugs to <https://github.com/kspalaiologos/bzip3>.
#
#
# Copyright (C) 1992-1996, 1998-2017, 2020-2021 Free Software Foundation,
# Inc.
#
#
# This configure script is free software; the Free Software Foundation
# gives unlimited permission to copy, distribute and modify it.

However, in the latter script, the patch can be applied.

I've got a fix for it using a patch diff from the homebrew project, thank you!

In working with homebrew to package bzip3 for all macOS users, they would like to have the configure script fixed upstream if at all possible. See this discussion:

Homebrew/homebrew-core#120028 (review)

I see a similar issue was opened and resolved on the ocaml project:

ocaml/ocaml#10723

They have their configure scripts committed to the repository to be able to take modifications. I suspect the autoconf on macOS has some patches from Apple that fix this versus the autoconf on ubuntu.

I am pretty certain that this issue is caused by an outdated version of libtool in Ubuntu repositories (check the build-aux/libtool.m4 file - it contains the patchable hunk)

I updated the discussion on homebrew, it does appear that the current stable release of libtool 2.4.6 has the issue with newer macOS, but the development version of libtool has been fixed.

Homebrew/homebrew-core#120028 (comment)

The homebrew project seems to have a surprisingly high bar for new formula if they want to require upstream projects use a development version of libtool or somehow patch the current stable libtool.

What are your thoughts?

Note: if you used ubuntu 22.10 for making releases, (I know it's not LTS), this issue might be fixed as it uses libtool 2.4.7 which has a fix for it...

I can't use Ubuntu 22.10, because the Github Actions runners do not provide it.

I appreciate your responsiveness here.

It does seems silly to upstream this patch when there is a perfectly good patching mechanism in homebrew for it, however I'm just trying to navigate their project to help macOS users use bzip3 more easily. Thank you!

It does seems silly to upstream this patch when there is a perfectly good patching mechanism in homebrew for it, however I'm just trying to navigate their project to help macOS users use bzip3 more easily. Thank you!

This is exactly how I feel about it. I have, all in all, decided to rollback the patch because it adds another layer of upstream maintainer effort and the hunk fails for some reason that I'm too tired to investigate now (I'll re-add it when I have enough time to do it properly)...

Please let the reviewers know that the issue will be fixed when there's libtool 2.4.7 in Ubuntu Jammy backports. In the meantime, I would recommend MacOS users to either use Nix (a better alternative to Homebrew) or MacPorts.

Thanks for putting in the effort!

PS: In the meantime, I've made sure to let the Ubuntu Jammy backports people know about this problem: https://bugs.launchpad.net/ubuntu/+source/libtool/+bug/2002251 - so a proper fix for this issue is presently pending another upstream (this time libtool and Ubuntu's) fix...

It does seems silly to upstream this patch when there is a perfectly good patching mechanism in homebrew for it, however I'm just trying to navigate their project to help macOS users use bzip3 more easily. Thank you!

The main reason is to not duplicate the efforts if the project can incorporate the change, and underlying dependencies would also change over the time (so that patch also needs to be updated, see https://github.com/Homebrew/formula-patches/). I wont go too far on this as package manager maintainer.

Sometimes, homebrew formulae are also using macport patch, so I definitely think it is better to fix the cause rather than fixing the symptom.

Is there a libtool backport package for the LTS release we're building with now? This might be an easy fix.

Also have to confirmed that building source bundles with a newer libtool will fix this or are we still speculating?