Orion,

 

Thanks for the report. Lintian on Debian reports a number of the same issues.

 

More comments below.

 

 

 

On Thursday 17 Oct 2013 12:06:57 Alan W. Irwin wrote:

> Hi Orion:

>

> Thanks very much for your report. There are so

> many issues involved, that I am going to answer you in

> several parts.

>

> This is part 1.

>

> On 2013-10-16 20:42-0600 Orion Poplawski wrote:

> > I'm getting the following rpmlint issues with the Fedora plplot 5.9.10

> > package:

> >

> > plplot-doc.noarch: E: zero-length

> > /usr/share/doc/plplot/html/plplotdoc-html.proc

> >

> > Left over from something?

>

> Exactly. For some reason when xmlto produces html from our DocBook

> source (this method is still used now for html and will be used going

> forward), it creates that empty file which is then propagated further.

> I have fixed that (revision 12601) by deleting that file before

> propagation of the remaining files generated by xmlto.

>

> Please test this svn trunk fix.

 

For Debian I worked around the zero length file by just deleting the file myself in the packaging scripts. Better that Alan has now fixed upstream, but my approach works for the current release.

> > plplot-libs.x86_64: W: shared-lib-calls-exit

> > /usr/lib64/libqsastime.so.0.0.1 exit@GLIBC_2.2.5

> > plplot-libs.x86_64: W: shared-lib-calls-exit

> > /usr/lib64/libcsirocsa.so.0.0.1 exit@GLIBC_2.2.5

> > plplot-libs.x86_64: W: shared-lib-calls-exit

> > /usr/lib64/libplplotd.so.12.0.0 exit@GLIBC_2.2.5

> > plplot-libs.x86_64: W: shared-lib-calls-exit

> > /usr/lib64/libcsironn.so.0.0.1 exit@GLIBC_2.2.5

> >

> > This library package calls exit() or _exit(), probably in a non-fork()

> > context. Doing so from a library is strongly discouraged - when a library

> > function calls exit(), it prevents the calling program from handling the

> > error, reporting it to the user, closing files properly, and cleaning up

> > any state that the program has. It is preferred for the library to return

> > an actual error code and let the calling program decide how to handle the

> > situation.

>

> This is an issue that has been with us for a while, but I agree it

> should be addressed. I strongly encourage discussing issues here

> first so our bug tracker doesn't get clogged with meaningless stuff,

> but this is a case where you should generate a report on our bug

> tracker for this so we don't lose it.

 

This has been bounced around on the list a number of times (search the archives). Unfortunately it is a fairly fundamental result of the way plplot works. There is no graceful error handling and no way to propagate error

codes back up from a function to the user. In light of this the only safe way to deal with a fatal error is to exit. The user can override this by changing the exit handler routine with plsexit, but this is likely to result in undefined behaviour. It wouldn't fix these warnings anyway.

 

What plplot does is probably wrong, but to fix it properly would require a complete API change to allow functions to return an error code. We could do this, but it would be a large job and a huge API change. Shows the importance of making the right design decisions early on...

 

It's in Alan's subsequent emails, but for reference I also get a number of warnings from lintian about unnecessary linkage. Those I understand I put down to false alerts. The ocaml ones I don't understand, so I'm glad Alan is delving deeper here. I'd be keen to test any improvements.

 

Andrew