[lsb-discuss] LSB 4.0 vs LSB 4.1 certification

Mats Wichmann mats at wichmann.us
Thu Aug 11 17:05:15 UTC 2016


On 08/09/2016 06:20 AM, Dallman, John wrote:
> I'm trying to change the Linux I build products on, from SLES11 to CentOS 7. I have these version of LSB build packages installed on CentOS 7:
> 
> lsb-build-base-5.0.5-3.x86_64
> lsb-build-c++-5.0.0-1.x86_64
> lsb-build-cc-5.0.5-3.x86_64
> lsb-build-desktop-5.0.5-3.x86_64                # Not actually using this.
> lsb-build-qt3-5.0.0-1.x86_66            # Or this.
> lsb-build-qt4-5.0.0-1.x86_64            # Or this.
> 
> I have been building to LSB 4.0 standards, but it seems that I need to move up to LSB 4.1 if I build on CentOS 7, because /opt/lsb/lib64-4.0 doesn't provide the symbol "dl_iterate_phdr", which GCC-run-by-lsbcc is using, but /opt/lsb/lib64-4.1 does have it, and it's noted as new in the LSB 4.1 release notes.
> 
> But I need to carry on supporting SLES11 and RHEL6. Those are LSB 4.0 systems, and lsb_release on them doesn't say anything about 4.1. The Wiki page at https://wiki.linuxfoundation.org/lsb/lsb-41-release-notes doesn't say that LSB 4.1 code will run on 4.0 systems, although dl_iterate_phdr is present on both SLES11 and RHEL6.
> 
> What can I expect in the way of compatibility? I can avoid using LSB 4.1-specific APIs in my own code, but I can't do much about the compiler's use of support functions.

Hi, John.  Not sure I can advise in a helpful way: try it and see if it
works. LSB releases typically trailed behind distro releases though
there was an effort in the older days to try to sync with certain
"enterprise" type releases a bit.  So the odds are pretty good that
anything modern (CentOS 7 being in that category) will support a lot
more interfaces than the set required by LSB.

You can always check on the history of interfaces in LSB by checking the
Navigator, for example:

http://linuxbase.org/navigator/browse/int_single.php?cmd=list-by-name&Ilibrary=libc&Iname=dl_iterate_phdr

You can look down in the "Presence in distributions" section to get some
hints on how well it's likely to go; it looks like all surveyed distros
provide the interface.  It was originally left out not because it wasn't
implemented, but because it wasn't part of the POSIX dl*() set.


The idea with the "stub libraries" was to make sure unexpected
references didn't creep into code, but it's not a perfect solution, and
in particular if you have to reach out into non-LSB libraries, it
usually goes wrong.  As I think you've found out before.


More information about the lsb-discuss mailing list