EE_ X-MS-Office365-Filtering-Correlation-Id: 23e12980-12fa-4a8b-1d4e-08deeb8040d9 X-Microsoft-Antispam: BCL:0;ARA:14566002|15080799012|39105399006|24021099003|23021999003|25010399006|4140399003|5072599009|41001999006|20031999006|6090799003|24121999003|25031999004|22091999003|24071999003|19110799012|8060799015|3412199025|440099028|40105399003|25131999003; X-Microsoft-Antispam-Message-Info: =?utf-8?B?UWhDNWU3anp5MkhCZ1JsbllSQ2hEdjU3QWNtWXBITVhGbDQrWDZqemdEMFFU?= =?utf-8?B?U1hqRFBVTFhNd29sVzdJRGU2bWcwazRzZ3ZYQmhkaXV4SVkycXAyNEVCdHA3?= =?utf-8?B?WU5GMEpkVjRWZnZIVlREczNpaTY2OWtTdUpTWjIycnJsaUlUNDlwQ2J5bDZv?= =?utf-8?B?amxCT3RBT0hvT3ZWQS95emdMYUgrSFpsQ3FvRDVCK2ZvZGYyL21yL0F2Qmtp?= =?utf-8?B?V2tZc1lES013WVMyUWRETkQyaEphcUd6d3RCQ0pjRm9oZnBkU21HMG1SVFFB?= =?utf-8?B?aUNVRXlTVXJRNUQ0UHFKYllkZHRmV1RvdWFjdmpzbm03ZzJIamRiVHpkUXJ3?= =?utf-8?B?TWdMQWphd1hKZUI1clpyNnBNd3Z2Z2FQcnhRMUpxNVIvRjRONGlPNWxUZ1A0?= =?utf-8?B?Wm5TeHNhV3dLUFAyUDd2ZlFIREpNODEvaFdwS0UzTHZmQTFMMGZURVFILzBF?= =?utf-8?B?eVVpenoxc3BISlE5by92bG85ZFdOeVZlWVhFRmswbldnYjdBdjFGZzdrVy9x?= =?utf-8?B?K0RGcUN0a2VoWDQrRVFPREtvazVETDJYRHJaeEFoQVdTVmswdWJhZytpZkdO?= =?utf-8?B?VWxwbWRRS0Y3VGswWUU2RVB5Z0lpMGJVQ3RYQzBERFl6VnEwWkg1S3VmcDhM?= =?utf-8?B?b0NobTMvcC82ZlFaOFVTcWZKc2RWUll0czlYM2grTUVocDJENWtPWFEzTEhO?= =?utf-8?B?WFZFaGYrWDRic0FqakQ0U0FuTTVQaWNLSU4zSUdhbDNZcitIWEJmeVU2S3B2?= =?utf-8?B?bGlxZzIyK2JqeFpvY2ZHT2lYNkhmUkFIM00rMUhJaTRidWI3RERxYXJPNUVO?= =?utf-8?B?a3p1emtWc3hhS3NEdGo0Yi8zc25Zb09TWFJ0NWZQM1JWRFJKc254citTR0ZM?= =?utf-8?B?RmtmNmlMM0lNczlscWdwR2tjdEpEbVR6YTlubEh4dG02R3FMbml3WW5YUHFU?= =?utf-8?B?dFlUNHZRVEQ1RjNJWW5JVkRNNVRGZXhNWEs0SmEwQjN4ellRanptNTVnaXdC?= =?utf-8?B?MlNsYyt4WnA5V3RybUZHUFAwYnV1aDk0dVVVNzVMT285K1o0SXhXcmluSmF0?= =?utf-8?B?Q0JjNVJrRFVyYVdWU1hzUDBJK1NManJTWkJ2b3FsdUtUdXdwTEc3SDVkSFk4?= =?utf-8?B?V1VyM2pLcFcyRW1tU1FpMmREckJtZzRYWXM3RzhMQUVvejdVcFVIdTNlaDRh?= =?utf-8?B?NENzM0N4V09YOUZvcXNkZzNRQ09WZlI4UmRTR1Jvb2s0aUJuN0wyeWtCTGhq?= =?utf-8?B?aStveDFyS29meU45VGdPdHlDZysvYmN1eStlRnRORXozR0ZCVDJKMmhyQkty?= =?utf-8?B?SjRMa3l3OVBLZ0U1WTFHWW1YWjlXemJKUml3RVdqYUlvN2h2RkE0MVpJTHFY?= =?utf-8?B?a0ZQekpYN3NlVGtXY09EbGZ6aXk2VU9kdmJhTmlnd2lqcVk1YUl4R0pNRCtJ?= =?utf-8?B?aENjS0pIakZlUm9lSXZNSkFpdGUxQi96NUtkbGhjMi9uL0hIaEpKS1BqckZa?= =?utf-8?B?SkFnYXgyL3FlUlFSVW50dEx6dStselFFMkZJV2xyMGVsbjJRVHFnb1hmMVNS?= =?utf-8?Q?9YFbwVkxzIBUuwCc/zebgzN972+Vk8Q1hkxFpELWbKH6IG?= X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?eUtLRXRwekpOeUhJV2VOR0dTSGNjbTZVa3VucDlha1J1cnFXTUtuQ1N6Z3Ny?= =?utf-8?B?Nk55RVJsNGprTnBrTkYwcm1Qb2ZMeGtzVDhKMHN2V3RldFR3NHo0Q0Z6RnZ4?= =?utf-8?B?ZzhZR25QNjNqaDRwRmdvejl2QkJlQTBGYUJETE92eG40WFFHUjdPcDNsVGQ3?= =?utf-8?B?SDdpYmphMzNLbHdFRFUvWHl3WThhM2hWWkd5UkhwRmVpYXI0K1NQSXgvVkQy?= =?utf-8?B?TXlLZVRWUjh3eUNNbkhyZnYranU0c1NTMmlMdGFkcXFCNFhjNVJ2TW5ieElV?= =?utf-8?B?MDlPaWRPTi9NRmhQN3RUUGZEQzJyN2dCOGtCaTZydjNqOHNCWFFuMTFWWGJh?= =?utf-8?B?WnlwZXBEQzJBVXcwZ3FpeFRNNDgxQ2tyOFZXeUpxZ05OWkpDbzNObnhsd2Zy?= =?utf-8?B?Sy9xVGh6TVFFTnE1R3pMbmV6NC9aTHhWNXZrUWMyNDY3T2puSmgrRTFwNHRq?= =?utf-8?B?bCtMQ25ONWhUYUEwMDA5bkhqRXdRSjNQN096dnRKbTV1bVBadmEvOGhjR0g2?= =?utf-8?B?OFFoZHdjK3hFQ3l1ZEhCeHRKVGwva3Z1a29CM3pMM3FpOVYrUTFDRzlOS3Vw?= =?utf-8?B?MUhRK3diUVowajF6QkxyeEF5S2FydHZKQzNUaGMrMmtGWkdYc1d6dGVXZUdj?= =?utf-8?B?cGlkNlloQW5MUXJEUDhEU0V3a2k4TEtNSjAxZXMwc05QTHdiblU0S3RGcllW?= =?utf-8?B?Uy9IcWFsL0pRZ0s5R2Z4RG1ZU0NzakY5dFRFWTFVNDZhT1NRdHVtVVdqd0JP?= =?utf-8?B?TE9jZ1YvbUl2bytMWjAvNzdWYUJrVmI2QjBnenpxQ0hBZFNDcDgyczl4UE9t?= =?utf-8?B?dUdDQXRLUzJVTjNFT0gvck5kUlNTRlU0eXlZbTAwOFFrZzRxSElxbVZLSE9S?= =?utf-8?B?SDRjUm9PZWlaQWc4QVl6Qmx6Nm42SWcxZ0R4cVZMd2lWV3hNRkxZOEZGaFZ0?= =?utf-8?B?dUc2ZE9pU2RNK05qM0J4MGFiRWdiVW85eTJjQ2tJakF2bEhXM2txY1FsWXRp?= =?utf-8?B?aERsVzhEM2YvS3VVRFNETTJ6MkZ0c0tRL3VjeU1CL0pYY3VOT2orbEdEVEhI?= =?utf-8?B?ZGtkWUZrcFVpZUZXbUtFSGQ0VXBtVVM5ZjJKRS9CWDFRWG94ajFoaU9KTjdD?= =?utf-8?B?aHFXOEdCZjE4eEI5eWltUVlVeGFiKy9VeXRXMnFnaGQyWFBFRFV4RGtSN2ZX?= =?utf-8?B?K0RqMzVVbGQ0eVhxTmowTGFlN2Q2WGNNMGxoVkJTa3lxUlJsbWdRL3cvTXFQ?= =?utf-8?B?c2NsRXBaMURFODJ1bjN2eWN3VXJ6MG9ablNZRFRxbTJZQTFBNWRHbW8zR2NC?= =?utf-8?B?U0xxczZ4SjN4RFlrQzVJOU1ZMElZQVIyMDVJVWV2UWZiaHZhM1BSODQvY0NN?= =?utf-8?B?S0tRUHUxZWx1Y0k4WllYTW1RbGpmWEwvOXBVQURxWGNOaWZzUUtKQ3g0aHFX?= =?utf-8?B?djl6ekY2aHhiTlNYYXEvTHhyc0EzamdQSGs3czMyNWpVSktmbXhab0VsNklS?= =?utf-8?B?WlRHRjNIcUcvU29Gc3U4c1VJaHQrWDJSWWNDejJaUjdzbXFKbVlnOUVVMys3?= =?utf-8?B?TzNrZllKUVZlSzFFMHlLcUFxYmtZeS9aeGdkY0hNMmsxTWlGWDJtT3Q1cTdm?= =?utf-8?B?cUh4QVZ2S3JRa2FmT0p6QmxZMVVWWmtzbFhBaTd0TjBNdGNrQmtPclR0MXlT?= =?utf-8?B?ZjBpOUZSL3V1RVR3NWZpZEN1WTlwWTY2bGNITkYyUW5qY0RqekMwU1JPTThW?= =?utf-8?B?cGhycjlrekpCZUFTcG56dTJHall5d1dNSXlXeDNyL2p0bkVOaXN0K0Y5dm1K?= =?utf-8?B?cDB1a0ZXVzRaMXFYMENvSUlnQ2hzSXJ3VXFFalF5cjkyd1llL25pV2J0bmdP?= =?utf-8?Q?fh19aIZU7s7jZ?= X-OriginatorOrg: sct-15-20-9412-4-msonline-outlook-a6b68.templateTenant X-MS-Exchange-CrossTenant-Network-Message-Id: 23e12980-12fa-4a8b-1d4e-08deeb8040d9 X-MS-Exchange-CrossTenant-AuthSource: SA1PR11MB8811.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jul 2026 01:42:01.3680 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA4PR11MB8943 X-Spamd-Result: default: False [-1.49 / 15.00]; FORGED_MUA_THUNDERBIRD_MSGID_UNKNOWN(2.50)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector10001:i=1]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.987]; DMARC_POLICY_ALLOW(-0.50)[hotmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a01:111:f403:d000::/53]; R_DKIM_ALLOW(-0.20)[hotmail.com:s=selector1]; MIME_GOOD(-0.10)[text/plain]; ASN(0.00)[asn:8075, ipnet:2a01:111:f000::/36, country:US]; FREEMAIL_FROM(0.00)[hotmail.com]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[hotmail.com:dkim]; FREEMAIL_ENVFROM(0.00)[hotmail.com]; RCPT_COUNT_ONE(0.00)[1]; MLMMJ_DEST(0.00)[ports@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; DKIM_TRACE(0.00)[hotmail.com:+] X-Rspamd-Queue-Id: 4h7hCx5Gy5z3Sh2 X-Spamd-Bar: - Flavors are a way to have separate packages created for different configurations of a port. That way users of pkg do not need to go manually build software for relatively common software variation possibilities that they may want or need in place of a single default set of options. On 7/26/26 13:18, Steve Kargl wrote: > On 7/26/26 12:51, Gleb Popov wrote: >> On Sun, Jul 26, 2026 at 10:43 PM Steve Kargl wrote: >>> >>> Hi, >>> >>> Updating a laptop that had a year old FreeBSD on it >>> to top-of-tree. >>> >>> % portmaster -Byd --force-config sqlite3 |& tee sgk.log >> >> Try updating libclc first using portmaster or plain make. > > I did try plain make in libclc.  See the end of original email. > make dies with an error about llvm15 no longer being supported. > If llvm15 is no longer supported on fbsd 16, then the libclc > Makefile should simply skip trying to build for llvm15. > >> Figure out what flavor you need by looking at the installed package's >> name > > That's the question.  What is a FLAVOR and how do I determine what > FLAVOR is the right flavor? > >> pkg info -x libclc >> >> If going the plain make route, append FLAVOR=llvmXY to make invocation. > > Is there a comprehensive list of FLAVORs?  'man make.conf' does not > mention FLAVOR.  Is it possible to set FLAVORS there? Flavors are a property of each port individually and not an externally defined property; some different ports use common flavors like 'nox11' but there is no hard rule to it. In the ports tree you can list flavors with `make -C /usr/ports/devel/libclc -VFLAVORS` and drop -C if you run it in the port's folder. The problem with setting FLAVOR in make.conf is make.conf will be applied to everything you build (kernel, base system, and 'every' port. You would need to write it within a conditional test such as what port is being built or what directory it is in and that test will then run during every build instead of just for that one port. portmaster supports a format such as `portmaster devel/libclc@llvm21` but if a port requests libclc as a dependency then it could also request a particular flavor (not usually the case, but doable). This seems to be a syntax similar to or the same to how you can do it with other tools like pkg and poudriere. For manually running make, `make -C /usr/ports/devel/libclc FLAVOR=llvm17` would be an example of overriding it. Not sure if there are other ways to express it. Some changes I assume should happen: 1. The default of libclc should be reconsidered if it is broken on a platform unless it is being actively worked on. Why are we defaulting to the oldest compiler, a compiler not included as a base compiler on any supported FreeBSD version, and not even having a comment as to why? 2. That flavor should be removed from the list at least in the case of the incompatible system. Broken may be appropriate if the default flavor is the only one that works on most supported systems and with most programs. 3. If the libclc message is accurate, then devel/llvm15 should probably be altered to request it be built with a compatible port of llvm when the base version is known to be incompatible. > In the old days, one could cd into any directory under /usr/port > and simply type 'make'. Unless things are broken. Having been building things since 2004, you can usually find broken things when you look. at over 30,000 port folders, its hard to have the tree in a state where 'nothing' fails. This port self declared the build conditions are known to be broken. In this case it is the OS version (a non-RELEASE one) and the requested port flavor. Defining a BROKEN condition is better than some ports that are known to be broken but don't say so and that results in users and the build system spending time to reach a known failure. BROKEN and IGNORE are preferable to the ports tree trying when it is known to fail. > My actual problem is building devel/node24, which dies with an > error: > ld.lld: error: undefined symbol: sqlite3session_patchset. I'd have to see a more complete error log to guess properly. If devel/note24 completed all dependency steps then I'd assume it may have an issue with bundling its own copy of sqlite3 and the build system messed up and used some stuff from its bundled copy and other stuff from the copy that databases/sqlite3 installed. Otherwise, maybe there is a real incompatibility with our sqlite3 port vs what node24 needs. If you somehow reached a point where you had additional older versions of sqlite3 files on your system then it too could cause mismatches. I never was a big portmaster user as it was incapable of completing a run when I tried it and any error caused a complete abort in the middle of rebuilding; portupgrade could be forced to proceed anyway with other ports and I thought I recalled an ability to keep older libraries around so less would break during the transition from old to new. A quick skim I see that sqlite3 runs a series of "@${RM}" (wrong way to do it, but better than nothing) steps including to remove a bundled sqlite3 so I would have thought that build/link steps would not see it. When a port messes up due to things that are installed onto the system (other versions, things not listed as a dependency/option, etc.) it is still a bug and should be reported and fixed appropriately. Think it was about 15 years ago now but I looked and found there were quite a few ports that would refer to installed files before they referred to build directory files which without a fix means the port should register as conflicting with itself and require uninstall to guarantee some build failures are avoided. I'd love to learn how to properly fix such issues but never have found how to understand+fix. To avoid any "contamination" of a build by an existing version of the port already being installed or any other non-dependency data on the system influencing how it is built, many maintainers and committers build packages from ports inside of a clean environment using poudriere or synth and then when complete they use the created collection of packages to upgrade/install as needed. Beyond less build failures from contamination, it also minimizes downtime caused by an installed program breaking because a dependency was built+installed but is not compatible until the program is rebuild+reinstalled too. At over 5 days for a non-ccache build of everything I have installed + a few other things to complete, I upgraded to such a workflow before poudriere existed for both of those reasons.