To add a request, edit this page. It's useful to include a date. It's even more useful to make sure an application that uses the requested interface has been scanned and entered in the LSB Navigator.
At LSB F2F November 2007, it was decided that libGLU is a good candidate for LSB 4.0. Current import tools are not sufficient to reasonably import a C++ library, however a new tool is due.
These were once part of the LSB but were removed (most likely reason for deprecation of these interfaces is that these do not handle IPV6). One could write a compatibility library which re-defines these interfaces with an implementation based on getaddrinfo(). Applications requiring these interfaces could then ship the compatibility library. However, all Linux distributions have the symbols, thus a compatibility library would really be an ugly solution.
Update: gethostbyaddr, gethostbyname, getservbyname have always been in LSB. gethostbyaddr_r and gethostbyname_r are added for LSB 3.2. As part of a separate request, gethostbyname2 and gethostbyname2_r were also added for 3.2.
Not part of POSIX, thus it is not included in the LSB at this point. However, all Linux distributions have the symbol, thus inclusion should be possible. Update: added for 3.2.
Workaround is possible by implementing a compatibility library which supplies a stub function to use sysconf(_SC_OPEN_MAX) (or alternatively, getrlimit with the RLIMIT_NOFILE option which amounts to the same thing) which can be shipped with any application. However, all Linux distributions have the symbol, thus a compatibility library would really be an ugly solution, and we'd have to maintain it. Further, such a compatibility library would likely grow to a whole bunch of hacks, better not to start.
Update: at LSB F2F November 2007, it was decided to "just add this one" (complete).
Not part of POSIX, thus it is not included in the LSB at this point. However, all Linux distributions have the symbol, thus inclusion should be possible.
Update: has been added for 3.2.
Notes from November 2007 F2F are italicized
At present LSB does not support a struct which allows the user to determine the file system on which a files resides.
Update: added for LSB 3.1 Update 1
Update: added for LSB 3.2
This is needed for parallel applications and applications using MPI. The HP MPI library uses this interface, others may as well. There is another approach using sysconf with _SC_NPROCESSORS_CONF and _SC_NPROCESSORS_ONLN.
At LSB F2F November 2007, probably need a bug, entry in database, more information before we act. Not in 3.2.
The following are the interfaces used by multiple ISVs who have been through the IBM Chiphopper program offering.
Update: mounting support has been discussed multiple times over the past seven years and mounting support is outside the scope of LSB at this time.
The netgroups question should be considered separately.
- We'd like to see the libnuma/numactl as part of the standard where it makes sense - which is, by now, only x86_64. Itanium-NUMA is vendor-specific (i.e. SGIs Altix), so we can't expect the NUMA-Support to be available out-of-the-box.
That makes excellent sense.
- A SSL-Interface would be really great, but IIRC this is already planned, isn't it?
- The colleagues from the support-team like to see a debugger as part of the standard-installation. As this doesn't make sense for all installations, some kind of "supportability-package", inculding a debugger, strace, ldd... would be great. I'm sure some other ISVs like to see this, too.
Indeed, we would. We've only worked with LSB on reasonably full-feature distributions (RHEL, SLES) where such things were available naturally, but having them available as part of the LSB would make life easier on less-comprehensive distros.
I'm writing some test code for various run-time error handling. So I need to be able to generate floating-point errors and control how they're handled. The errors I want to generate and trap are divide-by-zero, overflow, and invalid operation, and I'm working on x86 and x86-64.
Generating the errors is quite easy with code, but persuading an LSB-built program to trap on them is more difficult. It doesn't seem to be possible to enable or disable specific floating-point traps with the C99 facilities that LSB supports. Or if it's possible, some indication of how would be very welcome!
I can enable traps easily with feenableexcept(), which is a GNU extension to C99, but if I do that, I have to link with cc, rather than lsbcc, to get the full GNU libm which supplies feenableecept(). So an LSB way of doing this would be good. If I use feenableecept(), I get SIGFPE generated without further difficulty, which is what I want.
Editorial: the set of functions in question is feenableexcept, fedisableexcept, fegetexcept. Notes from the November 2007 F2F... if we add mremap, and these three we can get the most "bang for our buck" and suddenly certify two applications
Update: these were tracked as bug 1767 and added for LSB 3.2.