Re: [PATCH v3 2/4] libio: Remove the usage of __libc_IO_vtables

["Arsen Arsenović" <arsen@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 1794 bytes --]


Adhemerval Zanella Netto via Libc-alpha <libc-alpha@sourceware.org> writes:

> On 06/03/23 14:24, Adhemerval Zanella Netto wrote:
>> 
>> 
>> On 06/03/23 13:53, Andreas Schwab wrote:
>>> On Mär 06 2023, Adhemerval Zanella Netto wrote:
>>>
>>>> So could be an issue with my patch then? I did not added any new
>>>> dependency or rule with this patchset.
>>>
>>> The new dependency is gen-as-const-headers.
>>>
>>> I think it adds a cycle because libio-macros.h depends on
>>> $(common-objpfx)bits/stdio_lim.h, whereas other gen-as-const-headers
>>> don't depend on it.
>> 
>> Right, do we really have to autogenerate stdio_lim.h? It seems that no 
>> target currently requires to the overrides its values.  It would be way 
>> simpler if we can assume the sysdeps/posix/Makefile values instead.
>
> Alright, I could reproduce it and I am not sure how to fix it.  This fix
> requires libio-macros.sym to correctly setup _IO_file_jumps and 
> _IO_wfile_jumps alias symbol, and the libio/libio-macros.sym requires to 
> know the size ofstruct _IO_jump_t (which in turn uses function pointer 
> that uses FILE *).
>
> So libio-macros.sym does require stdio_lim.h in the end.  Best solution
> I can think of is to just remove stdio_lim.h autogeneration, the only
> real system dependent definition is FILENAME_MAX, obtained from kernel
> limits.h.  I think it should be feasible to just define is a 1024 for
> hurd and 4096 for Linux (these should not change in near future and
> change it might incur in some compatibility issues).

FWIW, I have an interest in making a new port (as time permits...), so
please also add an...

  #else
  # error "Update the port!"

... or such, if you choose to do that.

TIA, have a lovely night.
-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 251 bytes --]