On Mon, Aug 7, 2017 at 5:35 PM, Chris Johns <chr...@rtems.org> wrote:
> On 08/08/2017 00:38, Joel Sherrill wrote: > > Hi > > > > Taking a private discussion public. Aditya is implementing the POSIX > > method confstr() next. This email is my current set of thoughts on the > > implementation of this method for RTEMS. > > > > First, I think confstr() belongs in the RTEMS source tree. It > > is very similar to sysconf() but has to take the following "names" as > > those to be able to retrieve: > > > > _CS_PATH > > _CS_POSIX_V7_ILP32_OFF32_CFLAGS > > _CS_POSIX_V7_ILP32_OFF32_LDFLAGS > > _CS_POSIX_V7_ILP32_OFF32_LIBS > > _CS_POSIX_V7_ILP32_OFFBIG_CFLAGS > > _CS_POSIX_V7_ILP32_OFFBIG_LDFLAGS > > _CS_POSIX_V7_ILP32_OFFBIG_LIBS > > _CS_POSIX_V7_LP64_OFF64_CFLAGS > > _CS_POSIX_V7_LP64_OFF64_LDFLAGS > > _CS_POSIX_V7_LP64_OFF64_LIBS > > _CS_POSIX_V7_LPBIG_OFFBIG_CFLAGS > > _CS_POSIX_V7_LPBIG_OFFBIG_LDFLAGS > > _CS_POSIX_V7_LPBIG_OFFBIG_LIBS > > _CS_POSIX_V7_THREADS_CFLAGS > > _CS_POSIX_V7_THREADS_LDFLAGS > > _CS_POSIX_V7_WIDTH_RESTRICTED_ENVS > > _CS_V7_ENV > > > > This is per http://pubs.opengroup.org/onlinepubs/9699919799/ > functions/confstr.html > > > > Does the Open Group define the purpose for each of these values? It looks > x86 > and Linux specific, ie how to build a 32bit app. > Agreed. I think we return an empty string for all of those but they were in the POSIX standard. :( > > What is the purpose of 'POSIX_V7' in the label? I see FreeBSD 11.1 has > '_CS_POSIX_V6_ILP32_OFF32_CFLAGS' etc and the Linux page you provided has > '_CS_XBS5_ILP32_OFF32_CFLAGS' and I think glibc has 'POSIX_V7'. > > V6 and V7 refer to the POSIX standard version. The rest if architecture specific uselessness. > Looking at the rationale and playing with the command on FreeBSD I see: > > $ command -p getconf _CS_PATH > getconf: no such configuration parameter `_CS_PATH' > $ command -p getconf PATH > /usr/bin:/bin:/usr/sbin:/sbin > $ command -p getconf POSIX_V6_LPBIG_OFFBIG_CFLAGS > unsupported programming environment > $ command -p getconf POSIX_V6_WIDTH_RESTRICTED_ENVS > _POSIX_V6_LP64_OFF64 > $ command -p getconf _POSIX_V6_LP64_OFF64 > > > > > 1 > > I find this a little confusing. > > > The value for those #define's should likely match what is in the Linux > Software > > Base: https://refspecs.linuxfoundation.org/LSB_1.2.0/gLSB.html That > much goes > > in newlib. > > For the numbering I see: > > $ uname > FreeBSD > $ grep -r _CS_PATH /usr/include/ > /usr/include/unistd.h:#define _CS_PATH 1 /* default > value > of PATH */ > > I would prefer we follow the FreeBSD lead here for numbering. > > Doesn't matter to me. > > > > The confstr() implementation will be a switch on those values and > > I honestly don't even know what most of those should be in an > > RTEMS environment. > > > > But those are the names and we have to answer the question of what > > is the appropriate value to return. A first implementation could return > > something like getenv("PATH") for __CS_PATH, and take a swing at > > the "obvious ones". > > > > The ones with CFLAGS, LDFLAGS, and LIBS would first have > > to evaluated to see if the name makes sense to provide a value > > for. And then return the value. I am tending to lean to returning > > empty string for all of those. > > > > Looks like Linux doesn't support most of them: > > > > http://man7.org/linux/man-pages/man3/confstr.3.html > > > > I don't think this is a commonly used method so I would be perfectly > > happy to support it in a minimal, but compliant manner. > > > > Any other thoughts? > > > > If no one has a common set of names I wonder how it is to be managed in a > portable way? > The names are consistent but vary based on the supported POSIX version. Deciding on the set of names is definitely a Cygwin discussion. > > Chris >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
