The one click from Jenkins does not include the SSL plugins
for Windows. With the recent additions of Zinc/Zodiac to Pharo 2.0 some tests fail. So one has to manually download the DLLs for Windows http://code.google.com/p/squeakssl/downloads/list and place it in the same directory as the VM. Apologize if this is a known and already on the (Jenkins) todo list. At least I havent found an issue for it. Should we open one? Bye T. |
You are of course right, Torsten.
I am beginning to get *very* tired of this situation. Has anybody ever tried downloading missing plugins from the image side and then install them ? Can that be done (correctly), I mean does the VM have to restart then ? What about needed permissions ? If it can be done, I would be more than willing to write and integrate the necessary Smalltalk code, beginning with the SSL plugin. Sven On 05 Jul 2012, at 14:49, Torsten Bergmann wrote: > The one click from Jenkins does not include the SSL plugins > for Windows. With the recent additions of Zinc/Zodiac > to Pharo 2.0 some tests fail. > So one has to manually download the DLLs for Windows > > http://code.google.com/p/squeakssl/downloads/list > > and place it in the same directory as the VM. > > Apologize if this is a known and already on the (Jenkins) > todo list. At least I havent found an issue for it. > Should we open one? > > Bye > T. |
On 5 July 2012 15:40, Sven Van Caekenberghe <[hidden email]> wrote:
> You are of course right, Torsten. > > I am beginning to get *very* tired of this situation. > > Has anybody ever tried downloading missing plugins from the image side and then install them ? > Can that be done (correctly), I mean does the VM have to restart then ? > What about needed permissions ? > > If it can be done, I would be more than willing to write and integrate the necessary Smalltalk code, beginning with the SSL plugin. > The necessary code should be downloaded after user's confirmation, this is what all systems do.. About SSL plugin on windows.. i will reply after checking > Sven > > On 05 Jul 2012, at 14:49, Torsten Bergmann wrote: > >> The one click from Jenkins does not include the SSL plugins >> for Windows. With the recent additions of Zinc/Zodiac >> to Pharo 2.0 some tests fail. >> So one has to manually download the DLLs for Windows >> >> http://code.google.com/p/squeakssl/downloads/list >> >> and place it in the same directory as the VM. >> >> Apologize if this is a known and already on the (Jenkins) >> todo list. At least I havent found an issue for it. >> Should we open one? >> >> Bye >> T. > -- Best regards, Igor Stasenko. |
Ok the problem is that it doesn't compiles.
The mingw/msys header (wincrypt.h) missing a number of definitions used by SqWin32SSL.c which i tried to add manually, to make it compile, but then on linking stage it fails with following: Creating library file: c:/COG/blessed/results/libSqueakSSL.dll.a CMakeFiles/SqueakSSL.dir/objects.a(sqWin32SSL.c.obj):sqWin32SSL.c:(.text+0x4d0): undefined reference to `CertFindRDNAttr@8' CMakeFiles/SqueakSSL.dir/objects.a(sqWin32SSL.c.obj):sqWin32SSL.c:(.text+0x508): undefined reference to `CertRDNValueToStr' of course, because libcrypt.dll.a file which also part of mingw seems to be missing exports for these symbols. unless there is workaround to not call these function(s) i don't see what can be done, at least by me. maybe updating mingw could solve that problem.. ---------------- Name: CMakeVMMaker-IgorStasenko.171 Author: IgorStasenko Time: 5 July 2012, 5:43:02.685 pm UUID: 542b4f30-481c-754e-adc6-df26d22df280 Ancestors: CMakeVMMaker-EstebanLorenzano.170 - added configuration for ssl plugin on windows (but it doesn't builds on my mingw installation, a lot of missing definitions in Wincrypt.h ) To try it, use ------- CogWindowsConfig new addExternalPlugins: #( SqueakSSLPlugin ); generateSources; generate -- Best regards, Igor Stasenko. |
As for including (copy/pasting) prebuilt binary, i am strongly against it.
We should have the way to reproduce things we use.. Otherwise how we can take responsibility for maintaining it, testing it , etc etc? If they are not reproducible, then it obviously cannot be a part of distribution (users should download & use these binaries at their own risk and contact with original author/maintainer concerning all problems with it). -- Best regards, Igor Stasenko. |
yes... if it is just a matter of copy&paste, all the maintainability of the system become: nil...
now, we want to create a process that is reproducible and sustainably in time, and not just for a bunch of people (no matter how cool is that people, they might be not here tomorrow). of course, that makes the process has it's annoyances... but we hope to improve with effort (and time, but effort first :) Esteban On Jul 5, 2012, at 5:52 PM, Igor Stasenko wrote: > As for including (copy/pasting) prebuilt binary, i am strongly against it. > > We should have the way to reproduce things we use.. > Otherwise how we can take responsibility for maintaining it, testing > it , etc etc? > > If they are not reproducible, then it obviously cannot be a part of > distribution > (users should download & use these binaries at their own risk and > contact with original author/maintainer > concerning all problems with it). > > > -- > Best regards, > Igor Stasenko. > |
In reply to this post by Igor Stasenko
On 5 July 2012 17:44, Igor Stasenko <[hidden email]> wrote:
> maybe updating mingw could solve that problem.. > didn't helped.. the functions/definitions are still missing in mingw header files. -- Best regards, Igor Stasenko. |
Administrator
|
Is this relevant? http://msdn.microsoft.com/en-us/library/windows/desktop/aa376069(v=vs.85).aspx
Cheers,
Sean |
On 5 July 2012 19:49, Sean P. DeNigris <[hidden email]> wrote:
> > Igor Stasenko wrote >> >> didn't helped.. the functions/definitions are still missing in mingw >> header files. >> > > Is this relevant? > http://msdn.microsoft.com/en-us/library/windows/desktop/aa376069(v=vs.85).aspx > but linker cannot find them in corresponding .dll.a file .. but you can look by yourself at an ugly hacks(attached) we're made with Camillo, trying to see if it just missing declarations and nothing else. > -- > View this message in context: http://forum.world.st/SSL-plugins-in-Jenkins-one-click-tp4638530p4638588.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- Best regards, Igor Stasenko. sqWin32SSL.c (41K) Download Attachment |
We had a discussion about SSL plugin yesterday,
and we decided to use OpenSSL library on windows. This has an advantage, that plugin code will be using same library across all platforms. So, if something works on platform A, then it 99% will be working on platform B, and vice verse. But for that, i must adopt the library bundling mechanism for windows platform, so far it works only on mac. This is on my roadmap, since we want to have freetype and cairo libs bundled as well.. so openssl is just another one.. -- Best regards, Igor Stasenko. |
Igor,
On 06 Jul 2012, at 14:20, Igor Stasenko wrote: > We had a discussion about SSL plugin yesterday, > and we decided to use OpenSSL library on windows. > This has an advantage, that plugin code will be using same library > across all platforms. > So, if something works on platform A, then it 99% will be working on platform B, > and vice verse. > > But for that, i must adopt the library bundling mechanism for windows platform, > so far it works only on mac. > This is on my roadmap, since we want to have freetype and cairo libs > bundled as well.. > so openssl is just another one.. OK, but keep in mind that the Mac version of the plugin is using OpenTransport, not OpenSSL. It would be a huge win if at least Mac and Linux would share the same codebase (I can't see any technical reasons why not, Mac OS 7 is died a long time ago), if Windows could do so too, that would be even better. But are there concrete plans to do this hard work ? Sven |
On 6 July 2012 14:32, Sven Van Caekenberghe <[hidden email]> wrote:
> Igor, > > On 06 Jul 2012, at 14:20, Igor Stasenko wrote: > >> We had a discussion about SSL plugin yesterday, >> and we decided to use OpenSSL library on windows. >> This has an advantage, that plugin code will be using same library >> across all platforms. >> So, if something works on platform A, then it 99% will be working on platform B, >> and vice verse. >> >> But for that, i must adopt the library bundling mechanism for windows platform, >> so far it works only on mac. >> This is on my roadmap, since we want to have freetype and cairo libs >> bundled as well.. >> so openssl is just another one.. > > OK, but keep in mind that the Mac version of the plugin is using OpenTransport, not OpenSSL. > Yes, then even better, we can also use OpenSSL on mac too. > It would be a huge win if at least Mac and Linux would share the same codebase (I can't see any technical reasons why not, Mac OS 7 is died a long time ago), if Windows could do so too, that would be even better. > > But are there concrete plans to do this hard work ? > Hard work? What you mean? Compiling OpenSSL on windows consists of 3 steps: ./config make make test -- this of course can be skipped .. as i writing this message an OpenSSL library compiles on my windows box. now i should copy the ssl plugin code for unix to windows and it should compile it just fine, unless there is something very specific for unix which using something outside openssl library itself. > Sven -- Best regards, Igor Stasenko. |
On 06 Jul 2012, at 14:36, Igor Stasenko wrote: > Hard work? > What you mean? Yes, not for you ;-) Yes, the Linux version should be a good starting point, hopefully it is well written. OK, good luck then, be sure to let me/us know how it goes, I will help if I can, I am just a noob with the VM+Plugins. Sven |
On 6 July 2012 14:57, Sven Van Caekenberghe <[hidden email]> wrote:
> > On 06 Jul 2012, at 14:36, Igor Stasenko wrote: > >> Hard work? >> What you mean? > > Yes, not for you ;-) > > Yes, the Linux version should be a good starting point, hopefully it is well written. > > OK, good luck then, be sure to let me/us know how it goes, I will help if I can, I am just a noob with the VM+Plugins. > > Sven A library builds just fine under mingw on windoze.. So, its only a question of configuring things properly to make our SSL plugin to use it. I going for 2 weeks on vacation and i probably will be more time offline than online.. so we return to that question after i come back. -- Best regards, Igor Stasenko. |
And (drumroll.... ) it works..
i copied the unix C sources for ssl plugin, changed 2 lines of code (to include SSL.h before sq.h because of conflicting definitions) and i were able to compile & link it: $ make SqueakSSL [100%] Building C object SqueakSSL/CMakeFiles/SqueakSSL.dir/C_/COG/blessed/src/plugins/SqueakSSL/SqueakSSL.c.obj [100%] Building C object SqueakSSL/CMakeFiles/SqueakSSL.dir/C_/COG/blessed/platforms/win32/plugins/SqueakSSL/sqUnixOpenSSL.c.obj c:/COG/blessed/platforms/win32/plugins/SqueakSSL/sqUnixOpenSSL.c: In function 'sqSetupSSL': c:/COG/blessed/platforms/win32/plugins/SqueakSSL/sqUnixOpenSSL.c:51:14: warning: assignment discards 'const' qualifier from pointer target type [enabled by default] Linking C shared library /C/COG/blessed/results/SqueakSSL.dll Creating library file: c:/COG/blessed/results/libSqueakSSL.dll.a [100%] Built target SqueakSSL and then run the tests (see screenshot). so, next step would be is to properly integrate it with library bundling mechanism to make sure cmake will automatically download , make & link openssl library used by plugin. (if you want i can send you the binaries of built plugin for more serious testing) -- Best regards, Igor Stasenko. Screen Shot 2012-07-06 at 4.46.20 PM.png (131K) Download Attachment |
On 06 Jul 2012, at 16:52, Igor Stasenko wrote: > And (drumroll.... ) it works.. > i copied the unix C sources for ssl plugin, > changed 2 lines of code (to include SSL.h before sq.h because of > conflicting definitions) > and i were able to compile & link it: > > $ make SqueakSSL > [100%] Building C object > SqueakSSL/CMakeFiles/SqueakSSL.dir/C_/COG/blessed/src/plugins/SqueakSSL/SqueakSSL.c.obj > [100%] Building C object > SqueakSSL/CMakeFiles/SqueakSSL.dir/C_/COG/blessed/platforms/win32/plugins/SqueakSSL/sqUnixOpenSSL.c.obj > c:/COG/blessed/platforms/win32/plugins/SqueakSSL/sqUnixOpenSSL.c: In > function 'sqSetupSSL': > c:/COG/blessed/platforms/win32/plugins/SqueakSSL/sqUnixOpenSSL.c:51:14: > warning: assignment discards 'const' qualifier from pointer target > type [enabled by default] > Linking C shared library /C/COG/blessed/results/SqueakSSL.dll > Creating library file: c:/COG/blessed/results/libSqueakSSL.dll.a > [100%] Built target SqueakSSL > > and then run the tests (see screenshot). > > so, next step would be is to properly integrate it with library > bundling mechanism > to make sure cmake will automatically download , make & link openssl > library used by plugin. That is great news, now you may go on holiday ;-) If this would also work for Mac OS X, we would be all set. Eventually, it could be a good idea to at least let the upstream people know about this. > (if you want i can send you the binaries of built plugin for more > serious testing) Yes, please do (but it will take me some time to test on a windows machine). > -- > Best regards, > Igor Stasenko. > <Screen Shot 2012-07-06 at 4.46.20 PM.png> |
I can try it in mac, yes :)
On Jul 6, 2012, at 5:08 PM, Sven Van Caekenberghe wrote: > > On 06 Jul 2012, at 16:52, Igor Stasenko wrote: > >> And (drumroll.... ) it works.. >> i copied the unix C sources for ssl plugin, >> changed 2 lines of code (to include SSL.h before sq.h because of >> conflicting definitions) >> and i were able to compile & link it: >> >> $ make SqueakSSL >> [100%] Building C object >> SqueakSSL/CMakeFiles/SqueakSSL.dir/C_/COG/blessed/src/plugins/SqueakSSL/SqueakSSL.c.obj >> [100%] Building C object >> SqueakSSL/CMakeFiles/SqueakSSL.dir/C_/COG/blessed/platforms/win32/plugins/SqueakSSL/sqUnixOpenSSL.c.obj >> c:/COG/blessed/platforms/win32/plugins/SqueakSSL/sqUnixOpenSSL.c: In >> function 'sqSetupSSL': >> c:/COG/blessed/platforms/win32/plugins/SqueakSSL/sqUnixOpenSSL.c:51:14: >> warning: assignment discards 'const' qualifier from pointer target >> type [enabled by default] >> Linking C shared library /C/COG/blessed/results/SqueakSSL.dll >> Creating library file: c:/COG/blessed/results/libSqueakSSL.dll.a >> [100%] Built target SqueakSSL >> >> and then run the tests (see screenshot). >> >> so, next step would be is to properly integrate it with library >> bundling mechanism >> to make sure cmake will automatically download , make & link openssl >> library used by plugin. > > That is great news, now you may go on holiday ;-) > > If this would also work for Mac OS X, we would be all set. > > Eventually, it could be a good idea to at least let the upstream people know about this. > >> (if you want i can send you the binaries of built plugin for more >> serious testing) > > Yes, please do (but it will take me some time to test on a windows machine). > >> -- >> Best regards, >> Igor Stasenko. >> <Screen Shot 2012-07-06 at 4.46.20 PM.png> > > |
Free forum by Nabble | Edit this page |