Opened 10 months ago

Closed 10 months ago

Last modified 10 months ago

#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: assignedclosed

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.

comment:7 Changed 10 months ago by Marius Schamschula <mschamschula@…>

In 1bcc669a98e54bdca00a9df47cdf380b2fb1413e/macports-ports (master):

sqlite3: use shellescape, add note to update library id version

See: #72021

comment:8 Changed 10 months ago by ryandesign (Ryan Carsten Schmidt)

In 8707fad8630a14d230bdcc612d08ca19d30f4180/macports-ports (master):

sqlite3: Avoid rpath; tweak install name

Don't use -rpath since it's never needed and causes an error with older
compilers.

Closes: #72018

Change the install name from /opt/local/lib/libsqlite3.dylib back to
/opt/local/lib/libsqlite3.0.dylib as it was in 3.48.0 and earlier.

Simplify how the install name is fixed and do so in post-build not
post-destroot.

See: #72021

Note: See TracTickets for help on using tickets.