kicad-developers team mailing list archive

[Nick Østergaard <oe.nick@xxxxxxxxx>]

Rebuild wxpython.

2017-02-16 23:21 GMT+01:00 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
>>
>
> _______________________________________________
> 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