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 <[email protected]> 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 <[email protected]> > >> 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 : [email protected] > >>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers > >>>>>>>> More help : https://help.launchpad.net/ListHelp > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> Mailing list: https://launchpad.net/~kicad-developers > >>>>>>> Post to : [email protected] > >>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers > >>>>>>> More help : https://help.launchpad.net/ListHelp > >>>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Mailing list: https://launchpad.net/~kicad-developers > >>>>>> Post to : [email protected] > >>>>>> Unsubscribe : https://launchpad.net/~kicad-developers > >>>>>> More help : https://help.launchpad.net/ListHelp > >>> > >>> _______________________________________________ > >>> Mailing list: https://launchpad.net/~kicad-developers > >>> Post to : [email protected] > >>> Unsubscribe : https://launchpad.net/~kicad-developers > >>> More help : https://help.launchpad.net/ListHelp > > > > _______________________________________________ > > Mailing list: https://launchpad.net/~kicad-developers > > Post to : [email protected] > > Unsubscribe : https://launchpad.net/~kicad-developers > > More help : https://help.launchpad.net/ListHelp > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
