bug-libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: warnings from openSuSE rpmlint


From: Křištof Želechovski
Subject: Re: warnings from openSuSE rpmlint
Date: Fri, 11 Feb 2011 17:52:56 +0100
User-agent: KMail/1.13.6 (Linux/2.6.34.7-0.7-desktop; KDE/4.6.0; x86_64; ; )

Dnia piątek, 11 lutego 2011 o 15:25:58 Peter O'Gorman napisał(a):
> On 02/11/2011 04:55 AM, Křištof Želechovski wrote:
> > libltdl7.x86_64: W: shared-lib-calls-exit /usr/lib64/libltdl.so.7.3.0 
> > address@hidden
> > 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.
> 
> Although lt__alloc.c contains a definition of lt__alloc_die 
> (alloc_die_default) which does exit() on memory allocation failures, 
> this definition is overridden with one that does not in lt_dlinit.

Can this definition be removed?

I hope it is a typo for lt_alloc_die?  Double underscores are restricted to 
compiler intrinsics and internal symbols of the run-time library, aren’t they?

> 
> >
> > libtool.x86_64: W: script-without-shebang 
> > /usr/share/libtool/config/ltmain.sh
> > This text file has executable bits set or is located in a path dedicated for
> > executables, but lacks a shebang and cannot thus be executed.  If the file 
> > is
> > meant to be an executable script, add the shebang, otherwise remove the
> > executable bits or move the file elsewhere.
> 
> Yeah, it's not meant to be executed as is, I guess it was easier to 
> install it with the same rule as every other file in that dir.

I would say it is easier to install it with permissions matching its status.  
What is easier depends on your POV.  In the end, what is easier to the customer 
should prevail because there are more customers than developers.

Thanks for your attention,
Chris



reply via email to

[Prev in Thread] Current Thread [Next in Thread]