Re: Multilib Project Example

On 6/9/26 12:03 PM, Zack Weinberg wrote:
> On Tue, Jun 9, 2026, at 10:28 AM, Joel Sherrill wrote:
>> One of the RTEMS.org GSoC projects is bringing the safelibc
>> (https://github.com/rurban/safeclib) to RTEMS.   This library
>> implements the C11 and later Annex K Bounds Checking functions.
> 
> I can't make you stop, but I urge you to reconsider whether this project
> is actually a good idea.  The Annex K functions do not actually do the
> job they were meant to do -- "dropping in" the Annex K equivalents of
> each core C runtime function, *at best*, only converts bugs into
> different bugs. Continuing to put effort into Annex K encourages the
> erroneous belief that a program written using exclusively these
> functions is somehow "safer" than a program that uses the traditional
> functions.  In all cases where it is genuinely impossible to use a core
> C library function without the program having a bug, there is an
> existing alternative within core C that can be used.

Agreed.

Please see:
Document number: N1967
"Field Experience With Annex K — Bounds Checking Interfaces"
Authors: Carlos O'Donell, Martin Sebor
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm

> It's especially important to disabuse *students* of this erroneous
> belief because several influential sources (notably, Microsoft's "Visual
> Studio" tools, which are very likely to be a student's first exposure to
> C these days) push said belief on students.  I would not have accepted
> this GSoC project in the first place.
> 
> That said ...
> 
>> I would appreciate any pointers to what is required of a library to
>> support being built multilib. A simple example would be even better.
> 
> ... Unfortunately, as far as I know, none of the Autotools have any built-
> in support for multilib builds.  The usual workaround is to have a higher-
> level Makefile or build script that invokes the library build several
> times with different CFLAGS, prefix, etc.  If you don't want your
> student to blow a huge amount of time and effort on build system issues,
> I would go with that approach.

That's what we do with glibc and the GNU Toolchain in general. We iterate
one level higher and build libraries multiple times with different
hardware configurations. Then each library is then dropped into a
glibc-hwcaps based directories where ld.so loads the multilib based on
hardware capabilities.

> For this specific task, [email protected] is probably a better place
> to get advice than autoconf@.

-- 
Cheers,
Carlos.