sqlite3 @3.37.2_0: configure fails installing +universal variant

[bal-agates]

Attached are a sqlite3 config.log and main.log where the config failed. The failure appears to due to a compiler test trying to build an x86_64 object while linking against a library (/opt/local/lib/libunwind.dylib) that is only built for arm64.

I am not sure how to solve this. Is this a config tool problem or port problem? I suppose one of those could have a dependency added to make sure whatever port is providing libundind.dylib checks that it is built universal?

I put this at low priority because this doesn't really affect me. It was the result of another port errantly wanting to rebuild everything "+universal". See ​#64488.

[bal-agates]

sqlite3 config.log showing failure

[bal-agates]

sqlite3 main.log showing failure

[jmroot (Joshua Root)]

What does port provides /opt/local/lib/libunwind.dylib say?

[Schamschula (Marius Schamschula)]

Or perhaps file /opt/local/lib/libunwind.1.dylib?

To my knowledge sqlite3 is not built using libunwind. Perhaps the configure script opportunistically finds it?

[ryandesign (Ryan Carsten Schmidt)]

Right... libunwind probably gets used opportunistically by a lot of stuff. Either uninstall libunwind or build it universal before trying to build something else universal that might use it.

[kencu (Ken)]

having that ancient libunwind installed on an M1 system can only cause havoc.

Goodness knows how it ever got there. Now that it is there, the linker finds it first (as that is the link order that has been set up) but you should never have it installed. It is from about 6 years ago.

Just uninstall it. If something complains, let MacPorts know.

The libunwind port should be modified to not allow installation on anything newer than SnowLeopard.

[bal-agates]

$ port provides /opt/local/lib/libunwind.dylib
/opt/local/lib/libunwind.dylib is provided by: libunwind

I am not sure what libunwind is. After encountering the sqlite3 issue I updated my ports a got the message

Error: libgcc-devel cannot be built while libunwind-headers is active.
Error: Please forcibly deactivate libunwind-headers, e.g. by running:
Error: 
Error:     sudo port -f deactivate libunwind-headers
Error: 
Error: Then try again. You can reactivate libunwind-headers again later.

Possible multiple ports provide the same thing? I inactivated libunwind-headers, upgraded libgcc-devel, that activated libunwind-headers. That seemed to work. So they might be related to gcc?

$ port rdependents libunwind
The following ports are dependent on libunwind:
  PDAL
    grass7
      qgis3

I suspect "configure script opportunistically finds it" is true.

[jmroot (Joshua Root)]

The headers and library are two separate ports. The cctools port legitimately uses libunwind-headers, though not with +xcode which should be the default on arm64 systems. PDAL is one of several ports that depend on libunwind (I have no idea why):

% port echo 'depends::libunwind(\s|$)'
apache-arrow                    
fizz                            
folly                           
PDAL                            
py37-pyarrow                    
py38-pyarrow                    
py39-pyarrow                    
rspamd

The dependency was added to PDAL in [906b4adb59bcae34444c58d5cb873df558019e9c/macports-ports] with no explanation.

[bal-agates]

It looks like the PDAL dependence on libunwind was added in mid-2018 with ​https://github.com/PDAL/PDAL/commit/80f876b1d7df7ef6f51b2f3f856912faeeeb8039. Probably makes sense the Portfile was changed months later source change. The commit message indicates the possibility of building without libunwind but it wasn't obvious to me how to do that. Possible the PDAL Portfile could be changed to remove the dependence on libunwind? If that could be done it would only eliminate one dependence of libunwind listed above.

[jmroot (Joshua Root)]

As Ken mentioned, the libunwind port is only there for the benefit of much older OS versions. The system libunwind should be used on anything recent.

[kencu (Ken)]

Kind of messy now, then.

There would need to be tickets opened for each of those ports that depend on libunwind to remove the dep…and then a need verify each can find the system libunwind as it should, fix them to find it if they can’t, and then revbump them all once they are all fixed. Luckily not too many. But libunwind will need to be gone first.

The installed libunwind will need to be removed, probably manually…or libunwind could instead just install nothing on newer systems, like libcxx does, and be revbumped first…possibly easier, if less clean. Solves some problems, adds others.

However, it may then be discovered that perhaps many other ports, like sqlite3, built on user’s systems (not builds on the buildbots, for the most part) have surreptitiosly linked to the libunwind port’s library, and will need local rebuilding during rev-upgrade.

[bal-agates]

No easy solution. I am not advocating any changes. Once the problem is known it is relatively easy to workaround.

If the ultimate problem is the config tool is "surreptitiously linking to libunwind" (and likely only as a test of the compiler) has anyone thought about how to prevent that when the project doesn't need libunwind?

Before stumbling on the "sqlite +universal" configuration problem MacPorts rebuilt (14) other ports with +universal [gettext, gettext-runtime, gettext-tools-libs, icu, libedit, libffi, libiconv, libtextstyle, libxml2 libxslt, ncurses, xmlcatmgr, xz, zlib] without issue. I am not sure what config tool those used or why they didn't have the same issue.

[kencu (Ken)]

Replying to bal-agates:

If the ultimate problem is the config tool is "surreptitiously linking to libunwind" (and likely only as a test of the compiler) has anyone thought about how to prevent that when the project doesn't need libunwind?

The build wants libunwind, and so it asks for it. Nothing wrong with that.

The problem is that there is a old rogue libunwind.dylib (that should not exist) on the link path ahead of the system's libunwind.

That is MacPorts' issue to fix.

I am not sure what config tool those used or why they didn't have the same issue.

Presumably none of those link against libunwind.