glibc SFrame support for newer versions

[Indu Bhagat]

On 11/27/25 12:19 PM, Adhemerval Zanella Netto wrote:
> 
> On 26/11/25 12:41, Florian Weimer wrote:
>> * Adhemerval Zanella Netto:
>>
>>> On 25/11/25 17:29, Florian Weimer wrote:
>>>> * Adhemerval Zanella Netto:
>>>>
>>>>> My point is how we should handle glibc SFrame support in upcoming
>>>>> versions, especially given potential mismatches across
>>>>> libraries. Would just bump support to v3 and ignore v2 objects, as we
>>>>> currently do on sframe_header_sanity_check_p for v1?
>>>> It depends on whether there any v2 objects in circulation at all.  The
>>>> format is simple enough that we could include parsers for both versions.
>>> It does complicate testing, specially when we have different objects with
>>> different SFrame versions along with toolchain that supports versions.
>> I think it will be impossible to test v2 objects soon enough because
>> there's no toolchain left that produces it.
> Which circles back the my original question whether should we keep
> the v2 support and just replace once v3 becomes the current one.
> 
> I think if/when we set --enable-sframe as default we might not have
> this freedom.

Aside: When time comes to set --enable-sframe by default though, the 
system call to register SFrame data for (dlopen'd) shared libraries 
should ideally have landed too.