kicad-developers team mailing list archive

[Brian Sidebotham <brian.sidebotham@xxxxxxxxx>]

On 26 September 2013 12:05, Brian Sidebotham <brian.sidebotham@xxxxxxxxx>wrote:

> On 26 September 2013 10:51, Brian Sidebotham <brian.sidebotham@xxxxxxxxx>wrote:
>
>> On 22 September 2013 05:37, Dick Hollenbeck <dick@xxxxxxxxxxx> 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.