Adhemerval Zanella Netto via Libc-alpha 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ć