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. 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'. 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. > > 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? Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
