kicad-developers team mailing list archive

[Simon Wells <swel024@xxxxxxxxx>]

The Filesystem Heirachy Standard v2.3 specifies:

for /usr/bin:
"This is the primary directory of executable commands on the system."

and for /usr/lib:
"/usr/lib includes object files, libraries, and internal binaries that
are not intended to be executed directly by users or shell scripts."

FHS v3.0

/usr/bin:
"This is the primary directory of executable commands on the system."

/usr/lib:
"/usr/lib includes object files and libraries. [21] On some systems,
it may also include internal binaries that are not intended to be
executed directly by users or shell scripts. [22]

Applications may use a single subdirectory under /usr/lib. If an
application uses a subdirectory, all architecture-dependent data
exclusively used by the application must be placed within that
subdirectory.  [23]"

/usr/libexec (optional):
"/usr/libexec includes internal binaries that are not intended to be
executed directly by users or shell scripts. Applications may use a
single subdirectory under /usr/libexec.

Applications which use /usr/libexec in this way must not also use
/usr/lib to store internal binaries, though they may use /usr/lib for
the other purposes documented here."

-

As the kifaces are NOT directly executable from command line it seems
that bin/ is not an appropriate place for them. Do you know any other
software that places non-executable support files into bin/?

I see libexec being used for a binary that is run from an executable
but itself still executable from the command line by a user. Also as
its optional it also doesn't seem the best choice.

Therefore to follow the FHS on linux it seems the most sane place for
the kiface files to be in <prefix>/lib and most likely under a
subdirectory as while they are not strictly data they are not
"libraries" nor are they "exectuables" and as such the most
appropriate term for them might be data

If they are continued to be treated as exectuables like they currently
are then there should be a bug report filed that they segfault when
you try to run them


Simon



On 17 February 2017 at 03:18, Wayne Stambaugh <stambaughw@xxxxxxxxx> wrote:
> I had to relearn what I forgot about why the kifaces are installed along
> side the executables.  The reason is kiface is short for KICad interFACE
> files.  They are the face of KiCad and are program files that happen to
> be in a form that is loadable from start up.  The allows kicad to
> operate in both the integrated and stand alone modes without linking the
> interFACE part in both modes.  The kiface changes frequently and is not
> a great candidate for a typical shared object.
>
> The original goal was to split libcommon (and possibly more granular
> libpcbcommon and libschcommon) to actual shared objects in the
> traditional fashion because this code does not change frequently like
> the interFACE part of kiface does.  I don't know if the libcommon
> objects are sufficiently decoupled from the kiface objects yet to build
> a libcommon shared object.  If they are, I would be more than happy
> accommodate that patch.  For now, I would prefer to keep things the way
> they are in the vein of "if it ain't broke don't fix it".
>
> Cheers,
>
> Wayne
>
> On 2/13/2017 4:54 PM, Cirilo Bernardo wrote:
>> If my memory's not too bad, these objects are loaded using hard-coded paths.
>> They are not objects which are automatically resolved and loaded by the
>> linker-loader. This makes any versioning trivial - so long as we *do*
>> provide some
>> version numbers so that the files have different names, kicad can still load the
>> correct blobs. The closest example of related code in kicad would be the 3D
>> plugins - in that case the plugin loader searches a number of given paths and
>> loads whatever files it can. In the case of the kiface blobs we can
>> have a similar
>> flow of searching paths, though the actual file names of the blobs to be loaded
>> may be set at compile time. Actually, the 3D plugin system does require an
>> auto-loaded library; that library does not currently have a version number in
>> its name although internally there are in fact version checks.
>>
>> - Cirilo
>>
>>
>> On Tue, Feb 14, 2017 at 1:45 AM, Chris Pavlina <pavlina.chris@xxxxxxxxx> wrote:
>>> rpath? Load by absolute path based on compile prefix? Relative
>>> (../lib/foo based on the current exe path)? Seems to me standard library
>>> versioning isn't the right way to handle this anyway, since these aren't
>>> *libraries* per se but just object bundles.
>>>
>>> On Mon, Feb 13, 2017 at 09:35:59AM -0500, Wayne Stambaugh wrote:
>>>> When multiple versions of kicad are installed in different install
>>>> paths, library versioning has to be correct or it's possible that the
>>>> wrong kiface gets linked.  I'm thinking more of users or developers who
>>>> build and install from source rather than packaged installs.  On linux,
>>>> I could install the stable version of kicad in /usr and my dev build in
>>>> /usr/local or /home.  If _pcbnew.so (kiface) exists in multiple ldconfig
>>>> paths with no or identical version information, how does ld know which
>>>> _pcbnew.so to use?
>>>>
>>>> On 2/13/2017 9:30 AM, Chris Pavlina wrote:
>>>>> Can you explain why you think installing them as .so to /usr/lib changes
>>>>> in any way our responsibility for library versioning vs installing them
>>>>> as .kiface to /usr/bin? They still get installed with the whole package,
>>>>> reinstalled on upgrade, uninstalled on package removal, etc...
>>>>>
>>>>> On Mon, Feb 13, 2017 at 09:21:26AM -0500, Wayne Stambaugh wrote:
>>>>>> I'm not opposed to this but once we head down this path, we will forever
>>>>>> be responsible for library versioning and any implications it has with
>>>>>> regard to multiple installed versions of kicad.  I'm not sure we are
>>>>>> ready to open that can of worms just yet.  Keep in mind that .kifaces
>>>>>> are not generic libraries, they can only be linked to a specific kicad
>>>>>> app.  Link to the wrong .kiface and your sure to have issues.
>>>>>>
>>>>>> On 2/12/2017 2:01 PM, Chris Pavlina wrote:
>>>>>>> Please!!:
>>>>>>>
>>>>>>> - Move .kiface into $PREFIX/lib on linux, and the equivalent place on
>>>>>>>   other systems
>>>>>>>
>>>>>>> - Rename them from _foo.kiface to foo.so on linux and osx and foo.dll on
>>>>>>>   windows
>>>>>>>
>>>>>>> - Stop installing them with the executable bit set on linux! Presumably
>>>>>>>   osx too. It's totally unnecessary for shared libs, and ESPECIALLY bad
>>>>>>>   if they're in $PREFIX/bin.
>>>>>>>
>>>>>>> On Mon, Feb 13, 2017 at 07:49:36AM +1300, Simon Wells wrote:
>>>>>>>> As the kifaces are just shared objects/libraries is there any reason
>>>>>>>> they must be named .kiface instead of .so (or other name used on
>>>>>>>> system for dynamic libs), It seems to just be making things more
>>>>>>>> difficult and confusing when people see .kiface and have no ideaa what
>>>>>>>> it means.
>>>>>>>>
>>>>>>>> These should really not be place in bin/ on linux systems either as
>>>>>>>> its really not designed for that sort of thing
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>>>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp