Re: CVS commit: pkgsrc

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

> Date: Wed, 2 Apr 2025 12:57:31 +0200
> From: Adam <adam%netbsd.org@localhost>
> 
> jimtcl is required only to build sqlite3. Tcl can't be used as lang/tcl itself depends on sqlite3. There is an internal jimsh included with sqlite3 distribution, but I thought:
> 
> 1. let's have an external jimsh built once, so it can be used for both sqlite3 and sqlite3-tcl

I think this is not a very strong motivation for adding dependencies
and we should weigh that against the maintenance cost of a very
important package.  sqlite3-tcl is a leaf package so it doesn't matter
for anything else (and it looks like it doesn't even use jimtcl? also
I'm confused why lang/tcl depends on sqlite3 if sqlite3-tcl is a
separate package).

> 2. jimtcl is a TOOL dependency, so probably sqlite3 can't be cross-compiled with the internal one, but I might be wrong.

Your change as is doesn't work for cross-compilation because

CONFIGURE_ENV+= autosetup_tclsh=${PREFIX}/bin/jimsh

needs to be

CONFIGURE_ENV+= autosetup_tclsh=${TOOLBASE}/bin/jimsh

instead.

However, sqlite3 can be cross-compiled without any new dependencies by
using the following block to set CC_FOR_BUILD:

.if ${USE_CROSS_COMPILE:tl} == "yes"
CONFIGURE_ENV+=         CC_FOR_BUILD=${TOOLS_CMD.native-cc:Q}
TOOLS_CREATE+=          native-cc
TOOLS_SCRIPT.native-cc= exec ${NATIVE_CC} "$$@"
.endif

(It can't just be  CONFIGURE_ENV+= CC_FOR_BUILD=${NATIVE_CC:Q}
because the sqlite3 build breaks ${CC_FOR_BUILD} into words, which is
a little silly but whatever, we can deal with it.)

> I don't understand the reasoning regarding pulling zlib as a
> dependency. jimtcl is used as a tool, and not buildlinked, right?

Correct.  It's not your fault that this particular weird failure mode
happened -- I raised it only to illustrate the importance of testing
major changes to such a critical package on many platforms.

What seems to have happened is:

1. lang/jimtcl brought in pkgsrc libz.so for some reason, say at
   /usr/pkg/lib/libz.so.1.

2. databases/sqlite3 built itself with _base_ libz (buildlink3 blocked
   it from finding pkgsrc libz), but _also_ added the pkgsrc rpath, so
   the elf object /usr/pkg/bin/sqlite3 has:

        NEEDED  libz.so.1
        RPATH   /usr/pkg/lib

   Thus, when the loader opens /usr/pkg/bin/sqlite3, it will look for
   /usr/pkg/lib/libz.so.1 before /usr/lib/whatever/libz.so.1, and when
   it finds /usr/pkg/lib/libz.so.1, that's what will go in the
   REQUIRES line.

This is really a bug in the REQUIRES generation (though it's not wrong
that the loader will find /usr/pkg/lib/libz.so.1 _if it's there_) but
it was provoked by pulling in lang/jimtcl which pulls in devel/zlib.

> >> How did you test this change?  I don't think this will work on Darwin.
> >> 
> >> I think we should have a bulk-test-sqlite3 and/or mandatory review for
> >> changes to such an important package, especially for major build
> >> system changes like this.
> > 
> > Agreed.  wiz: Please add to restricted list, when updates involve build
> > system changes, new dependencies, or ABI breaks.
> 
> I always build on NetBSD and Darwin (aka macOS).

How does this change work on Darwin?  Doesn't Darwin require .dylib?
Normally we get this via pkgsrc's magic .la handling, but that won't
happen with .so in the plist as far as I understand.  Are downstream
packages (and the new sqlite3 binary) actually linking against the new
sqlite3?  How did you verify that?