improve header-depend solutions

[Jeff Johnson]

+++ This bug was initially created as a clone of Bug #3736 +++

Original comment:

Some of the rearranging of headers has exposed some tricky dependency loop
problems. One was referred to in bug 3717, following on from bug 3587.

Just for archival purposes, here's one story:

<sys/time.h> should include <sys/select.h> - glibc does, POSIX warns it *may*
happen. Once bug 3587 was implemented, we started stumbling across a problem
since we didn't this - several things had to be patched (appbat apps, for
example, which build fine against glibc). An attempt to force the dependency
using a header_depend Constant entry failed, as when time includes select it
happens at the top, before any of the types in time are defined. But select
has prototypes which use struct timeval, so things failed. select itself
includes sys/time, so going the other direction works fine.

This mechanism is handled in glibc by having separate sub-headers define
important types, this can be included separately so the loop doesn't happen.
These are the various /usr/include/bits headers.

LSB has avoided this mechanism so far, but it seems the easiest way to solve
this problem. We'll expand on it on demand, no need to try to follow all of
what glibc does here until we find an actual problem that needs solving.

+++

Some issues to record:

1. bits/ headers files have additional protection and commentary. Do we need to
do some of the same? Example:

/*
 * Never include this file directly; use <time.h> instead.
 */

#if defined __need_timeval || defined __USE_GNU
# ifndef _STRUCT_TIMEVAL
# define _STRUCT_TIMEVAL 1
# include <bits/types.h>

/* A time value that is accurate to the nearest
   microsecond but also has a range of years. */
struct timeval
  {
    __time_t tv_sec; /* Seconds. */
    __suseconds_t tv_usec; /* Microseconds. */
  };
# endif /* struct timeval */
#endif

I think mechanisms exist to do both things.

2. Since we now have small subsidiary headers, the header dependency
calculation in mkheader will decide what it needs, and may cause a file that
included, say <pthread.h> to now include just <lsb/pthread.h>. If it's truly
the case that all that was needed was the definition of pthread_t that's fine,
but what if apps are used to including a header that upstream includes
<pthread.h> and after our change ours no longer does? There is no KNOWN case
of this problem but the change was just applied, and it seems every technical
problem that could happen eventually does on this project.

Licquia suggested maybe there should be an equivalence table of "real includes"
- foo.h needs pthread.h not lsb/pthread.h - that mkheader could take into
account. This sounds a little complex, and definitely manual, but wanted to
make sure it was recorded as an idea.
[reply] [-] Comment 1