Rebuild wxpython. 2017-02-16 23:21 GMT+01:00 Clemens Koller <[email protected]>: > 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 <[email protected]> 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 <[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 >> > > _______________________________________________ > 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
