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
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
_______________________________________________
Plplot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/plplot-devel
