./.libs/libsqlite3.so: undefined reference to `strchrnul' *** [sqlite3] Error code 1 Stop in /usr/ports/databases/sqlite3/work/sqlite-autoconf-3150100. *** [do-build] Error code 1 Stop in /usr/ports/databases/sqlite3. System is 9.3-RELEASE, latest patchlevel I understand that this function was added in 10.0, but I thought this should be handled more gracefully?
Hello. These changes are not mine. They are made in all ports. In this connection: "- Remove always-true/false conditions after FreeBSD 9, 10.1, 10.2 EOL. Approved by: portmgr blanket". Look at: https://svnweb.freebsd.org/ports/head/databases/sqlite3/Makefile?r1=429442&r2=430947
(1) Does a recent EoL of a legacy release ("Legacy releases are for users wishing to stay with a more conservative upgrade strategy") means intentionally breaking perfectly working installations? Sounds kinda Microsoftish to me. (2) Even if we decide that a port now must not work in a previous release anymore, should not this be handled by the 'required version', 'ignored' or similar option rather than by breaking the build process?
You're right. But it's not my decision.
In addition, should not the HAVE_STRCHRNUL and the like be handled automatically by the upstream configure script rather than hardcoded in port patches?
(In reply to Eugene R from comment #4) Configure script does not control this function.
Eugene, please look at patch #216107.
(In reply to Pavel Volkov from comment #5) Thank you for the patch! But the sqlite3 configure does seem to check for strchrnul: http://www.sqlite.org/src/artifact/fcfa56d5d66668c9 ######### # Figure out whether or not we have these functions # for ac_func in fdatasync gmtime_r isnan localtime_r localtime_s malloc_usable_size strchrnul usleep utime pread pread64 pwrite pwrite64 do : as_ac_var=`$as_echo "ac_cv_func_$ac_func" | $as_tr_sh` ac_fn_c_check_func "$LINENO" "$ac_func" "$as_ac_var" if eval test \"x\$"$as_ac_var"\" = x"yes"; then : cat >>confdefs.h <<_ACEOF #define `$as_echo "HAVE_$ac_func" | $as_tr_cpp` 1 _ACEOF fi done
FreeBSD 9.3 is no longer supported. We're removing (and not adding) specific support for it from the ports tree, sorry. You are free to stay with ports tree snapshot at the time of EoL to keep your system working, if you don't want to update. Note that because 9.x is no longer supported, you will no longer get security fixes to the base system.
(In reply to Eugene R from comment #7) It's different distribution. 1. amalgamation (http://www.sqlite.org/2017/sqlite-amalgamation-3160200.zip) 2. autoconf (http://www.sqlite.org/2017/sqlite-autoconf-3160200.tar.gz) - used in the port. 3. from source (http://www.sqlite.org/cgi/src) - from your comment. Source from sqlite-autoconf-3160200.tar.gz: # Check for library functions that SQLite can optionally use. for ac_func in fdatasync usleep fullfsync localtime_r gmtime_r do : as_ac_var=`$as_echo "ac_cv_func_$ac_func" | $as_tr_sh` ac_fn_c_check_func "$LINENO" "$ac_func" "$as_ac_var" if eval test \"x\$"$as_ac_var"\" = x"yes"; then : cat >>confdefs.h <<_ACEOF #define `$as_echo "HAVE_$ac_func" | $as_tr_cpp` 1 _ACEOF fi done
(In reply to Dmitry Marakasov from comment #8) I really believed 'unsupported' meant 'no further updates', not 'going to great lengths to break third-party software in working installations as soos as possible'. Even Microsoft did not try that. But apart from this ill-thought policy, should not the release-specific IGNORE mark be used for this instead of failing the entire ports update ungracefully?
(In reply to Eugene R from comment #10) > (In reply to Dmitry Marakasov from comment #8) > I really believed 'unsupported' meant 'no further updates' Pretty much yes, and that obviously includes `no portstree updates'. > not 'going to great lengths to break third-party software in working installations as soos as possible'. You are free to stay at the latest portstree snapshot which supported your release, otherwise you yourself are breaking your setup by switching to unsupported portstree version. This is not a problem of the portstree, which simply mirrors base system release cycle. > But apart from this ill-thought policy, should not the release-specific > IGNORE mark be used for this instead of failing the entire ports update > ungracefully? I've already told - release-specific conditions are removed as soon as the release goes EoL.
(In reply to Dmitry Marakasov from comment #11) Don't you see a difference between 'not actively supporting' and 'deliberately breaking as soon as we get an excuse'? Don't you think production users at least deserve a courtesy of warning that things will now get broken out of the blue? Via the 'pkg updating' mechanism, not some obscure email that no one but the core team reads and that did not explain the ramifications for ports clearly? > I've already told - release-specific conditions are removed as soon as the release goes EoL. I don't mean the release-specific conditions/patches, I mean an option specifically designed to handle such cases gracefully: IGNORE_${OPSYS}_${OSREL:R} - Port should be ignored on a single release of ${OPSYS}, e.g IGNORE_FreeBSD_8 would affect all point releases of FreeBSD 8.
(In reply to Pavel Volkov from comment #9) I suppose there were reasons to use a specific distribution, but would a switch be too complicated? The 'full-source' version seems more feature-complete anyway =)
(In reply to Eugene R from comment #12) > Don't you see a difference between 'not actively supporting' and > 'deliberately breaking as soon as we get an excuse'? It's not `deliberately breaking', it's cleaning up obsolete and unneeded code as soon as it's allowed, simplifying the codebase and reducing the maintenance cost. And yes, there's no difference cause `not supported' means just that. In practice, the portstree will break completely within a few weeks anyway, as soon as first non-fmake-compatible construct is introduced to the Mk/ infrastructure, so don't be fooled thinking that unsupported portstree may work for you. > Don't you think production users at least deserve a courtesy of warning that > things will now get broken out of the blue? Via the 'pkg updating' > mechanism, not some obscure email that no one but the core team reads and > that did not explain the ramifications for ports clearly? FreeBSD support lifecycle information is publicly available: https://www.freebsd.org/security/security.html#sup there were also multiple announcements on the maillists, duplicated on local news sites (such as opennet). `Production users' should at least be aware of their systems lifetimes. > > I've already told - release-specific conditions are removed as soon as the release goes EoL. > I don't mean the release-specific conditions/patches, I mean an option > specifically designed to handle such cases gracefully: > IGNORE_${OPSYS}_${OSREL:R} - Port should be ignored on a single release of > ${OPSYS}, e.g IGNORE_FreeBSD_8 would affect all point releases of FreeBSD 8. I've meant exactly that. These are removed. But you are right in a way that ports collection should probably be more explicit about running on an unsupported release, effectively refusing to build anything by default.
(In reply to Dmitry Marakasov from comment #14) > But you are right in a way that ports collection should probably be more > explicit about running on an unsupported release, effectively refusing to > build anything by default. This was done: https://svnweb.freebsd.org/ports?view=revision&revision=431746
Ok, well, at least it is now predictable =)) Life goes on =) Nice explanation of the situation there, by the way! )