kicad-developers team mailing list archive

[Chris Pavlina <pavlina.chris@xxxxxxxxx>]

On Fri, Feb 17, 2017 at 07:36:17AM +1300, Simon Wells wrote:
> 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

THIS. If we are going to continue to stick them in /usr/bin like fools
then we should consider it a bug that they do not run their respective
applications when executed. Our install script even sets them +x!

> 
> 
> 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
> 
> _______________________________________________
> 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