[Bug bzip2/25513] Update Makefiles; add Makefile for Darwin

["sourceware at ryandesign dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=25513

Ryan Carsten Schmidt <sourceware at ryandesign dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sourceware at ryandesign dot com

--- Comment #5 from Ryan Carsten Schmidt <sourceware at ryandesign dot com> ---
Looks like you have similar ideas here to the ones MacPorts has
been using forever:

https://github.com/macports/macports-ports/blob/4c73180aeb5e08bad806cb76ed197a69d0de0c74/archivers/bzip2/files/patch-Makefile-dylib.diff

In the MacPorts patch, "__MacPorts_Version__" is a placeholder
that will be replaced with the bzip2 version (e.g. 1.0.8) and
"__MacPorts_Compatibility_Version__" will be replaced with the
version with the last component removed (e.g. 1.0).

In Makefile-libbz2_dylib you've set both the dylib current
version and its compatibility version to 1.0. Seems unlikely
that all 1.0.x versions of the library would be identical. It
seems like you should set the current version to 1.0.8 like
MacPorts does.

In Makefile-libbz2_dylib you're building with the wrong install
name and then fixing the install name at install time using
install_name_tool. It would be better to build with the correct
install name to begin with and avoid the need to run
install_name_tool later. Perhaps you didn't do that because it
caused the tests to fail? In the MacPorts patch we fix the tests
by setting DYLD_LIBRARY_PATH.

In Makefile-libbz2_dylib you added the comment "To assist in
cross-compiling. -stdlib=c++ may be desired for Xcode builds."
As far as I know, "c++" is not a valid value for "-stdlib".
Valid values are "libc++" and (for ancient versions of macOS)
"libstdc++". Since "libc++" has been the default value since OS
X 10.9 and very few people care about older versions anymore and
those that do are probably familiar with the issues involved, I
don't see a need for this comment. Most importantly, bzip2
doesn't contain any C++ code so "-stdlib" is completely
inapplicable to it.

You say you've tested this on a Power Mac with Mac OS X 10.5 but
you're setting CC=clang and Mac OS X 10.5 does not have clang
and clang is not compatible with PowerPC processors yet, at
least not on Macs. It seems like it would be better not to
override CC at all since make already provides a default value
of CC that should be appropriate for all systems and users can
of course override it on the command line if needed.

The next major version of bzip2 has already (in 2019) converted
its build system to autotools so libtool will handle building
the library and render all of this moot.

https://gitlab.com/bzip2/bzip2/-/commit/70ec984159c8263fdd4aac7c4670977aff0fe5b3

-- 
You are receiving this mail because:
You are on the CC list for the bug.