2018-08-21 2:29 GMT-03:00 Laurent Bercot: >> >> Say this is the compiler's 'standard' headers directory (i.e. normally >> /usr/include). Then, it is likely also the location of the files of >> the same name supplied by the libc, and in that case, 'make install' >> would overwrite them. Or, if the directory is handled by a package >> manager and files are 'owned' by packages, this would result in file >> collisions or similar. > > That's normal and expected. > Those files provide libc functionality, so they're meant to replace > libc files if installed into /usr/include.
Oh. That's kind of drastic. I re-read the documentation of nsss and utmps, in case I missed it the first time, and still think none of it suggests that this is the intended behaviour. The system consistency argument is a good one, though, and getting these packages to install in parallel with libc headers is doable at packaging time, so OK I guess. But I think that more explicitly warning that 'make install' will likely overwrite libc files with the 'configure' script's defaults would be better. > The exact same pattern happens with utmps, which replaces the > libc's <utmpx.h> header, and you didn't seem to have a problem > with it at the time. :) That's because I didn't notice :P I wanted to see what the effect of --enable-nsss was on packages of the s6 stack, found surprising that it didn't affect the C code, not even #include directives, looked at the 'configure' script, found that it didn't add -I options either, wondered how could that possibly work, and finally realized where the nsss headers were installed by default. Thanks, G.
