It says that, yes, but above that it is explicit about which interfaces go into which libraries. That these libs as separate non-file entities may be searched when specified does not, to me, imply they can be combined and still be considered conforming. This goes to which namespaces each library takes from, where an application that has its own pthread_join() doesn't want an -l c before pthread_join.c on a command lineusing a version stored in the libc, whether -l pthread follows or not.
On Thursday, April 18, 2019 Joel Sherrill <joel.sherr...@oarcorp.com> wrote: Thanks for quoting that. But just to be pedantic, it says "unspecified" and "may" so it is guidance. The RTEMS' GCC (and llvm) configuration implicitly links in libc, the BSP library, and the all RTEMS services including things in libpthread or librt on Linux. libm is the only common library that a user would need to specify. The flag -pthread is accepted by the compiler. FWIW RTEMS is a single process POSIX environment with ~1100 of the POSIX APIs. The OS and application are one executable. We track POSIX APIs provided versus multiple versions of POSIX, PSE5x, C99 and C11, FACE TS 2.1 and 3.0, and multiple versions of SCA as part of our user facing documentation. --joel On 4/18/2019 10:54 AM, enh wrote: > i think the requirement is only that the compiler accept -lpthread... > > "It is unspecified whether the libraries libc.a, libl.a, libm.a, > libpthread.a, librt.a, [OB] [Option Start] libtrace.a, [Option End] > libxnet.a, or liby.a exist as regular files. The implementation may > accept as -l option-arguments names of objects that do not exist as > regular files." > > Android has libpthread and librt in libc (though sadly libm is still > separate). > > On Thu, Apr 18, 2019 at 8:46 AM Joel Sherrill <joel.sherr...@oarcorp.com> > wrote: >> >> >> On 4/18/2019 4:31 AM, Geoff Clare wrote: >>> Shware Systems <shwares...@aol.com> wrote, on 17 Apr 2019: >>>> On Wednesday, April 17, 2019 Geoff Clare <g...@opengroup.org> wrote: >>>> >>>>> ... does anyone know of an implementation >>>>> that has pthreads and C11/C17 threads, with pthread_t and thrd_t defined >>>>> as different types? >>>> My implementation defines both as pointers, not int's, as 'typedef >>>> thrd_t pthread_t;'. Since threads.h is 99% a subset of pthreads.h, >>>> I see no reason to have them be different types, even as a breaking >>>> change. What is missing is in pthreads.h, to account for the new >>>> attributes C11 introduced, at least to mention them if support >>>> isn't going to be added. >>> What new attributes? As far as I can see the only attribute a >>> thread has in C17 (although it doesn't use that word) is whether it >>> has been detached. >>> >>>> The major hassle I see is POSIX wants the >>>> the threading stuff in libpthread, and C11 wants it in libc if the >>>> threading option is enabled. IMO C11 should have let interfaces in >>>> optional headers all be in header-specific libraries or libc, as an >>>> implentation-defined choice, but they didn't. >>> Last I knew the C standard says nothing at all about how programs >>> are built. >> Is there even a requirement to have libpthread in POSIX? >> >> --joel >>
