kicad-developers team mailing list archive

[Clemens Koller <cko@xxxxxxxxx>]

Hi!

I would expect lib*.so's (future kifaces?) also in /usr/lib/kicad if it really is a lib...

My dev versions reside in ~/SW/... and I start kicad with:
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:~/SW/lib PYTHONPATH=~/SW/lib/python2.7/site-packages/ ./kicad

Which is IMO okay for testing in most cases.

Currently, I am just running into the warning:
"Mismatch between the program and library build versions detected.
The library used 3.0 (wchar_t,compiler with C++ ABI 1010,wx containers,compatible with 2.8),
and wxPython used 3.0 (wchar_t,compiler with C++ ABI 1009,wx containers,compatible with 2.8)."


Regards,

Clemens

On 2017-02-16 22:13, Cirilo Bernardo wrote:
> In Debian packages the files were moved to /usr/lib/kicad since
> lib/${APP} is where libraries are generally put if the app has more
> than one. lib/kicad already exists since the plugins and plugins/3d
> directories are there.
> 
> I think this is a matter of cleaning up the KIWAY::dso_search_path()
> function in common/kiway.cpp so that it searches reasonable locations
> for each OS which is what S3D_PLUGIN_MANAGER::loadPlugins()
> does in 3d_plugin_manager.cpp.  At this point in time I don't think we
> need to implement version control so there is no need to add version
> numbers or other such identifying information to the file names. After
> all it is only devs who might rebuild and install a single incompatible
> target; most people who build would install everything at once. For
> Windows nothing will change, and I have no clue what the situation
> is for OSX.
> 
> - Cirilo
> 
> 
> On Fri, Feb 17, 2017 at 5:36 AM, Simon Wells <swel024@xxxxxxxxx> 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
>>
>>
>> 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
> 
> _______________________________________________
> 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
>