Re: Testing of lsbdev and sample implementation
Marvin Heffler writes:
> I have been running some tests combining the latest LSB Development Package
> (lsbdev-1.0.7) and the latest LSB Sample Implementation
> (minimal-runtime-0.8.tar.gz) and have run into some problems getting the
> sample application, rsync, to execute. Basically I built rsync in lsbdev
> using the system headers (Debian system). The rsync app will not build
> using the set of headers currently in lsbdev. Following this I copied the
> resulting rsync file to the sample implementation directory. When I tried
> to run it I ran into a series of problems. Here's what I saw.
>
> 1. When I first tried running the rsync command, I got the following error
> messsage:
>
> rsync: /lib/lsb/libc.so.6: version 'GLIBC_2.2.3' not found (required
> by rsync)
>
If you're using lsbdev to compile your program its very difficult to
dynamically link against an interface which is not in the LSB
specification. So if you take a program into the sample implementation
and it fails due to missing or wrongly versioned interfaces the most
likely causes are:
- a bug in the stub libraries in lsbdev
- a bug in the sample implementation
In this case when running libchk on the current CVS snapshot of the
SI, the following error is shown:
Didn't find fnmatch (GLIBC_2.2.3) in libc.so.6
fnmatch has version GLIBC_2.0, expecting GLIBC_2.2.3
So I'm pretty that what you're seeing is a problem with the sample
implementation. It hasn't been updated in a while and given that the
specification has also been updated in the meantime it doesn't contain
a recent enough version of glibc. If you run lsbappchk against the
binary produced I'm guessing that it would have not complained about
that function.
> The problem appears to be caused by a call to the function fnmatch, which
> is not defined by the LSB. This can probably be resolved by having rsync
> statically link fnmatch, but I couldn't get it to work. Instead I worked
Whilst it's reasonably easy to statically link interfaces which are in
the same library as an LSB interface but not in the LSB specification,
its a different matter if you want to link against a different version
of an LSB interface. Its possible, but it would require source code
changes.
> command in it. To work around this problem I simply copied /usr/bin/rsh to
> /tmp/live/usr/bin/rsh.
>
> 3. After getting around the problem with rsh, I tried rsync again and got
> this message:
>
> rsh: shell/tcp: unknown service.
>
> This problem happens because the sample implementation does not have an
> /etc/services file. To work around this problem I copied /etc/services to
> /tmp/live/etc/services.
/etc/services is marked optional in the FHS. This one of those cases
where for the purposes of the LSB we want to make it required. There
are a few other files/directories in the FHS that we similarly want to
make optional components compulsory.
> implementation seems to be pretty old with no changes since the summer.
> Does anyone know what its status is and when a new version will be
> available? The problems I found with /usr/bin/rsh and /etc/services missing
> lead me to believe we probably need some more files added to the sample
> implementation. There are most likely other basic applications that need
> other missing files. Is there a list somewhere of candidates to be added to
> the sample implementation?
With regards to commands & utilities the SI is not yet
complete. Really what someone needs to do is to compare the list of
commands in the FHS and LSB and add the missing ones. This will
require the slicing up of a few RPMs if you only want to add the LSB
required commands and not the other programs which will be bundled in
the same packages.
> apps for LSB compliance. To do this I need to point them to a good build
> environment and sample implementation. If we can't provide a fairly robust
> sample implementation, the app teams will lower the priority of getting
> their products LSB compliant.
For those looking for work to do I believe the other part we're
missing is an implementation of the initscripts as defined in the LSB.
Regards,
Chris
--
cyeoh@au.ibm.com
IBM OzLabs Linux Development Group
Canberra, Australia
Reply to: