On 26 September 2013 12:05, Brian Sidebotham <[email protected]>wrote:
> On 26 September 2013 10:51, Brian Sidebotham > <[email protected]>wrote: > >> On 22 September 2013 05:37, Dick Hollenbeck <[email protected]> wrote: >> >>> On 09/21/2013 09:23 PM, Dick Hollenbeck wrote: >>> > I will fix it if it does not work on linux.... >>> >>> >>> Did that, it works now, and brilliantly. >>> >>> >>> We had a namespace collision on FPL_CACHE, my destructor was going into >>> LEGACY_PLUGIN's >>> FPL_CACHE destructor. Linker did not catch that, because geez, it was >>> thinking it was the >>> same class. Have given each FPL_CACHE class a unique name, could have >>> used a namespace >>> but did not. >>> >>> >>> Then, I removed PCAD from FP_LIB_TABLE dialog, which does not support >>> Footprint*() >>> functions. *In its place I added "Github" plugin.* This was me >>> pulling the trigger. >>> >>> >>> It works now. And it is really exciting. >>> >>> >>> *I am all for getting our stock footprints on github ASAP!* >>> >>> Whoever is in charge of those now, please lets rock the footprints! >>> >>> Please talk to your platform sponsor about getting the PLUGIN to run on >>> the Windows and >>> OSX platforms. I don't have those, and will not be helping more than I >>> have. I wrote >>> CMakeModules/download_openssl.cmake and it might work with minor edits >>> if you have perl on >>> your windows system because the damn openssl Configure program uses >>> perl. Otherwise if >>> you have access to precompiled openssl libs and headers another way, you >>> can force the >>> issue at or around line 31 of pcbnew/github/CMakeLists.txt by defining >>> OPENSSL_INCLUDE_DIR and OPENSSL_LIBRARIES cmake symbols. >>> >>> Sort of like this: >>> >>> set( OPENSSL_INCLUDE_DIR >>> ${PREFIX}/include >>> CACHE FILEPATH "OPENSSL include directory" >>> ) >>> >>> set( OPENSSL_LIBRARIES >>> ${PREFIX}/lib/libssl.a >>> ${PREFIX}/lib/libcrypto.a >>> CACHE STRING "OPENSSL libraries" >>> ) >>> >>> >> On Windows, building without the msys environment means perl is an >> absolute no-go area for me; But cross-compiling openssl on linux with >> 1.0.1e is pretty straight forward anyway. Then it's just a case of >> -DOPENSSL_ROOT_DIR= to let CMake find the SSL libraries itself. >> >> However, building and installing Boost is a royal pain in the butt! The >> bootstrapping and compiling syntax is a bit different between windows and >> linux (On windows, libraries are not selected during bootstrapping, they >> are selected during compilation), and the install plain doesn't work for me >> - I have an outstanding question on Stack Overflow: >> http://stackoverflow.com/questions/19009456/boost-1-54-install-installing-nothing >> >> There were a few linking issues to sort out too, and after all that >> PCBNEW crashes with a c-runtime issue, yuk. So it's still not up and >> running on Windows through Winbuilder yet. There's some more grief to sort >> out yet! >> >> Best Regards, >> >> Brian. >> > > BTW, as an aside - from Winbuilder 3.1 (i.e. the next up-coming release) > I'm going to move to mingw-w64. I didn't realise the old MinGW project was > still Dwarf-2 which has problems throwing exceptions across DLL boundaries. > So I will move to mingw-w64 which uses sjlj exceptions which do work across > DLL boundaries. > > This is important given that I'm using mingw-w64 to create the openssl > dll's under Linux. > > Best Regards, > > Brian. > Final note - the different compilers being used is probably the source of the runtime error actually. So a move to mingw-w64 may well cure the current issue I have. Sorry for all the noise. Best Regards, Brian.
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
