lzma @22.01_0 does not use MacPorts CFLAGS/CXXFLAGS

[RobK88]

I am unable to upgrade lzma due to a cxx_stdlib mismatch. In other words, lzma is using libstdc++ (this installation is configured to use libc++).

--->  Found 1 broken port, determining rebuild order
--->  Rebuilding in order
     lzma @22.01_0
--->  Computing dependencies for lzma
--->  Fetching distfiles for lzma
--->  Verifying checksums for lzma
--->  Extracting lzma
--->  Applying patches to lzma
--->  Configuring lzma
--->  Building lzma
--->  Staging lzma into destroot                         
--->  Unable to uninstall lzma @22.01_0, the following ports depend on it:
--->  	boost171 @1.71.0_5+no_single+no_static+python310
--->  	boost176 @1.76.0_5+no_single+no_static+python310
Warning: Uninstall forced.  Proceeding despite dependencies.
--->  Deactivating lzma @22.01_0
--->  Cleaning lzma
--->  Uninstalling lzma @22.01_0
--->  Cleaning lzma
--->  Computing dependencies for lzma
--->  Installing lzma @22.01_0
--->  Activating lzma @22.01_0
--->  Cleaning lzma
--->  Scanning binaries for linking errors
--->  No broken files found.                             
Error: Port lzma is still broken (cxx_stdlib mismatch) after rebuilding it more than 3 times.
Error: Please run port -d -y rev-upgrade and use the output to report a bug.
Error: rev-upgrade failed: Port lzma still broken after rebuilding 3 times
Error: Follow https://guide.macports.org/#project.tickets if you believe there is a bug.
--->  Some of the ports you installed have notes:
  lzma has the following notes:
    The LZMA SDK program is installed as "lzma_alone", to avoid conflict with LZMA Utils

See the attachment for the output of sudo port -d -y rev-upgrade.

[RobK88]

Using a more modern compiler is the workaround until the port is fixed.

bash-3.2$ sudo port clean lzma
Password:
--->  Cleaning lzma
bash-3.2$ 
bash-3.2$ sudo port upgrade lzma configure.compiler=macports-clang-9.0
--->  Computing dependencies for lzma
--->  Fetching distfiles for lzma
--->  Verifying checksums for lzma
--->  Extracting lzma
--->  Applying patches to lzma
--->  Configuring lzma
--->  Building lzma
--->  Staging lzma into destroot                         
--->  Unable to uninstall lzma @22.01_0, the following ports depend on it:
--->  	boost171 @1.71.0_5+no_single+no_static+python310
--->  	boost176 @1.76.0_5+no_single+no_static+python310
Warning: Uninstall forced.  Proceeding despite dependencies.
--->  Deactivating lzma @22.01_0
--->  Cleaning lzma
--->  Uninstalling lzma @22.01_0
--->  Cleaning lzma
--->  Computing dependencies for lzma
--->  Installing lzma @22.01_0
--->  Activating lzma @22.01_0
--->  Cleaning lzma
--->  Scanning binaries for linking errors
--->  No broken files found.                             
--->  No broken ports found.
--->  Some of the ports you installed have notes:
  lzma has the following notes:
    The LZMA SDK program is installed as "lzma_alone", to avoid conflict with LZMA Utils
bash-3.2$ 
bash-3.2$ sudo port rev-upgrade
--->  Scanning binaries for linking errors
--->  No broken files found.                             
--->  No broken ports found.
bash-3.2$

[chillin-]

I am cautiously optimistic that I have the same issue on macmini5,1 w/ OS X 10.8.5, Mountain Lion and Xcode 5.1.1. Please let me know only if this is a different issue

lzma is using libstdc++ (this installation is configured to use libc++)
Error: Port lzma is still broken (cxx_stdlib mismatch) after rebuilding it more than 3 times.
Error: Please run port -d -y rev-upgrade and use the output to report a bug.
Error: rev-upgrade failed: Port lzma still broken after rebuilding 3 times
Error: Follow https://guide.macports.org/#project.tickets if you believe there
is a bug.
--->  Some of the ports you installed have notes:
lzma has the following notes:
The LZMA SDK program is installed as "lzma_alone", to avoid conflict with
LZMA Utils

The following installed ports are outdated:
lzma22.01_0 < 22.01_0  (C++ stdlib libstdc++ != libc++)

[RobK88]

Yes, it looks like the same issue that I was having on Lion 10.7.5.

Try building with a more modern compiler (e.g. clang-9.0). It will probably build just fine.

e.g sudo port upgrade lzma configure.compiler=macports-clang-9.0

[chillin-]

Thanks Rob, that worked, but I am unclear on why this install isn't building with clang9 by default. It's certainly critical that I understand, but this was new to me. Thanks again.

[RobK88]

I have not had time to dig into the source code to figure out what is going on. When ports do not build on old macOS's like Lion and Mountain Lion, it is a good idea to try again using a more modern compiler. e.g. Clang-7.0 or newer. That often fixes the problem.

Unfortunately, most of the MacPorts developers do not have time (or even an old Mac running an old MacOS) to fix build problems on old Macs.

So using a newer compiler is not really a fix but a workaround to the problem.

[ryandesign (Ryan Carsten Schmidt)]

Replying to chillin-:

I am unclear on why this install isn't building with clang9 by default.

Because this port does not require such a new compiler.

Rather, this port's build system fails to pass some compiler flags on when it needs to. Xcode versions of clang from OS X 10.8 and earlier default to using libstdc++, whereas MacPorts switched some years ago to default to libc++ on those systems. In the absence of the required flags, the build system erroneously builds the port for libstdc++ when we want it to build for libc++.

Newer MacPorts clang versions default to using libc++ which is a workaround you can use but not something I will commit to the port because it's overkill. Instead, I'll fix the build system to pass along the flags. This will fix not only this problem but other as-yet-unreported problems as well.

Replying to RobK88:

Unfortunately, most of the MacPorts developers do not have time (or even an old Mac running an old MacOS) to fix build problems on old Macs.

It is not necessary to use an old Mac or an old OS X version to verify that the problem exists nor whether one has succeeded in fixing it; it suffices to examine the build log on any macOS version to see whether the -stdlib flags are present everywhere they need to be (on every C++ compiler and linker invocation). I can see by looking at the logs from the buildbot that the -stdlib flag hasn't been used anywhere, and neither have the optimization flags we want to use. (It has instead used -O2.)

[ryandesign (Ryan Carsten Schmidt)]

I'll also point out that I fixed this in 2018 and then last week somebody else updated the port and removed my work.

[mascguy (Christopher Nielsen)]

Replying to ryandesign:

I'll also point out that I fixed this in 2018 and then last week somebody else updated the port and removed my work.

Adding @judaew for awareness.

[mascguy (Christopher Nielsen)]

Replying to RobK88:

Unfortunately, most of the MacPorts developers do not have time (or even an old Mac running an old MacOS) to fix build problems on old Macs.

There's no need to keep an old Mac around, at least for Intel-based macOS releases 10.5 and later: They all run beautifully in VMs - particularly via Parallels - and a number of us do just that.

It's more a matter of issue prioritization, as most of our users run on the latest macOS releases. But we do go back and fix such issues, it simply takes time to get to them all.

[mascguy (Christopher Nielsen)]

Replying to ryandesign:

I'll also point out that I fixed this in 2018 and then last week somebody else updated the port and removed my work.

Ryan, this is my bad, as I merged the PR. And despite testing across-the-board prior, I still managed to miss the stdlib issue. Ugh, sorry folks!

[judaew (Vadym-Valdis Yudaiev)]

Between versions 4.65 and 22.01 there have been many changes in the build.

21.07: Some minor changes and fixes.
21.06: The bug in LZMA encoding function was fixed.
21.03 beta: LZMA dicrionary up to 4 GB. Speed optimizations.
21.02 alpha: macOS and Linux support. Speed optimizations.
19.00: Encryption strength for 7z archives was increased.
18.06: Some speed optimiztions in LZMA/LZMA2 code.
18.05: Some speed optimiztions in LZMA/LZMA2 code.
18.01: Some changes in LZMA2/xz multithreading code for compressing. Some bugs were fixed.
9.35: AES code and SFXs modules were included to SDK.
9.20: New small SFX module for installers.
9.11: PPMd support.
9.04: LZMA2 and XZ support.
4.62: LZMA SDK is placed in the public domain.

In version 4.65, the project was built from the LZMA_Alone directory via makefile.gcc, which had options for CXX, CXX_C, and so on. Through these options, MacPorts used via patch. Now in version 22.01, the project is built from the LzmaCon directory and the makefile.gcc file doesn't have such options. The file is only a list of object files.

[judaew (Vadym-Valdis Yudaiev)]

... Now in version 22.01, the project is built from the LzmaCon directory and the makefile.gcc file doesn't have such options. The file is only a list of object files.

It looks like the developer have moved all of these options into a separate files outside of the LzmaCon directory. These are cmpl_clang.mak which included var_clang.mak, warn_clang_mac.mak and Build.mak and so on. I don't know how to force the required flags to be used here.

[barracuda156]

Also fails on Rosetta:

ld: warning: in _o/7zCrc.o, file was built for unsupported file format which is not the architecture being linked (ppc)
…
ld: warning: in _o/Bench.o, file was built for unsupported file format which is not the architecture being linked (ppc)
Undefined symbols:
  "_main", referenced from:
      start in crt1.10.5.o
ld: symbol(s) not found

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #66130.

[rmottola (Riccardo)]

I have the same issue, I am bonking my head. First, I suggest using "-s" as port option, to actually force a build and not use the binary - which apparently is also broken.

I tried on 10.7 gcc 6, gcc 12 and I got the error. Only using clang 6 fixed it.

From what I remember and ask Ken gcc6 was fine.

[kencu (Ken)]

clang-6 fixes it for some because I changed the stdlib default in clang-5+ to match the MacPorts cxx_stdlib setting, therefore the defaults help. gcc6 won't fix this on Intel systems set up to build for libc++.

Just have to get those build flags MacPorts' sets onto the build lines again... eg <​https://github.com/macports/macports-ports/commit/536ead384df3ad8539bde8d02082a0aa5edf55be>

[kencu (Ken)]

​https://github.com/macports/macports-ports/pull/17133

[kencu (Ken)]

In ae7da160dec868a4b80c09a5c59c2f0965a247d6/macports-ports (master):

lzma: obey macports cc and cxx flags

fixes universal builds, amongst other things
closes: #65908