Opened 3 years ago
Last modified 3 years ago
#64494 assigned defect
sqlite3 @3.37.2_0: configure fails installing +universal variant
Reported by: | bal-agates | Owned by: | Schamschula (Marius Schamschula) |
---|---|---|---|
Priority: | Low | Milestone: | |
Component: | ports | Version: | 2.7.1 |
Keywords: | Cc: | Veence (Vincent) | |
Port: | sqlite3 |
Description (last modified by 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.
Attachments (2)
Change History (14)
Changed 3 years ago by bal-agates
Attachment: | sqlite3-config.log added |
---|
Changed 3 years ago by bal-agates
Attachment: | sqlite3-main.log added |
---|
sqlite3 main.log showing failure
comment:1 Changed 3 years ago by jmroot (Joshua Root)
Keywords: | sqlite3 universal removed |
---|---|
Owner: | set to Schamschula |
Status: | new → assigned |
comment:2 Changed 3 years ago by jmroot (Joshua Root)
What does port provides /opt/local/lib/libunwind.dylib
say?
comment:3 Changed 3 years ago by 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?
comment:4 Changed 3 years ago by ryandesign (Ryan Carsten Schmidt)
Description: | modified (diff) |
---|
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.
comment:5 Changed 3 years ago by 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.
comment:6 Changed 3 years ago by bal-agates
Description: | modified (diff) |
---|
$ 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.
comment:7 Changed 3 years ago by jmroot (Joshua Root)
Cc: | Veence added |
---|
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.
comment:8 Changed 3 years ago by 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.
comment:9 Changed 3 years ago by 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.
comment:10 Changed 3 years ago by 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.
comment:11 follow-up: 12 Changed 3 years ago by 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.
comment:12 Changed 3 years ago by 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.
sqlite3 config.log showing failure