#72021 closed defect (fixed)
sqlite3 @3.49.0: wrong install name for libsqlite3.dylib
| Reported by: | ryandesign (Ryan Carsten Schmidt) | Owned by: | ryandesign (Ryan Carsten Schmidt) |
|---|---|---|---|
| Priority: | High | Milestone: | |
| Component: | ports | Version: | 2.10.5 |
| Keywords: | haspatch | Cc: | Schamschula (Marius Schamschula) |
| Port: | sqlite3 |
Description
% port installed sqlite3 The following ports are currently installed: sqlite3 @3.49.0_0 (active)
% otool -L /opt/local/lib/libsqlite3.dylib /opt/local/lib/libsqlite3.dylib: libsqlite3.dylib (compatibility version 9.0.0, current version 9.6.0) /opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.3.1) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.100.3)
The install name of libsqlite3.dylib must be fixed to be the absolute path ASAP. Any ports that link to libsqlite3.dylib that get updated after sqlite3 was updated to 3.49.0 will get the wrong path baked into them and will not work and will thus need revbumps after this is fixed.
Previous versions of the port installed a library with install name /opt/local/lib/libsqlite3.0.dylib so I suggest we keep doing that.
I know the build system changed significantly in this version by the removal of libtool which had previously done all this. If it's too difficult to fix the build system properly, install_name_tool can be used to fix it in a post-build step.
Change History (8)
comment:1 Changed 10 months ago by ryandesign (Ryan Carsten Schmidt)
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
comment:2 Changed 10 months ago by ryandesign (Ryan Carsten Schmidt)
You're now setting the install name to /opt/local/lib/libsqlite3.dylib whereas before it was /opt/local/lib/libsqlite3.0.dylib. Both will work since both paths exist (as symlinks to the real library) however it seems like an unnecessary change. Shall we switch it back to the value it was using previously?
You're fixing the install name in post-destroot. Seems like post-build would be the more logical place.
You're manually inserting quotation marks around a path in the system call, which has the effect of handling some special characters within the variable value correctly (like spaces) while not handling other special characters correctly (like quotation marks). While neither values are likely to appear within the prefix variable, if we're going to escape, let's do it completely correctly. The shellescape procedure exists for this purpose.
comment:3 Changed 10 months ago by Schamschula (Marius Schamschula)
You are right. It should be set back to the previous version for consistency. However, no need to add a rev bump for this. It can wait until the next update. But it would be wise to add a note not to forget to do this.
comment:4 Changed 10 months ago by Schamschula (Marius Schamschula)
The quotation marks came in via code lifted lifted from another Portfile (apache-arrow).
I'll see about adding the above changes.
comment:5 Changed 10 months ago by ryandesign (Ryan Carsten Schmidt)
| Keywords: | haspatch added |
|---|
comment:6 Changed 10 months ago by ryandesign (Ryan Carsten Schmidt)
Yes, code using the old way of manually adding double or single quotation marks, or not quoting at all, is undoubtedly littered throughout the ports tree since shellescape only became available to portfiles to use in MacPorts 2.7.0.

Ah, you already fixed it in [baff5b306db9729fc8dcf2cde5781179029e5b41/macports-ports].