OpenSSL ssleay32.lib

[Larry Rix]

Hi All,

So—I have 17.05 installed. I installing VS 17 CE. Interestingly enough, when ES 17.05 compiles it shows that it is using VC 14 (i.e. Preparing C compilation using Microsoft Visual Studio 2015 VC++ (14.0)... )

Ought I be expecting to see a different message when compiling (i.e. Preparing C compilation using Microsoft Visual Studio 2017 VC++ (16.0)... or something like that)?

Beyond that—I installed the 64 bit version of ES 17.05 GPL, which is fantastic. Love it. However, my use of SSL (for cUrl I think) is not working. I recall going through this before, where Javier provided me with appropriate ssleay32.lib and libeay32.lib files. I then had to create the appropriate subdirectory under $ES\unstable\library\network\socket\netssl\spec --> windows\lib\msc_vc140 and then copy in the two lib files.

In this case, I did a repeat of that action except using win64 instead of windows in the path creation. The compiler is then happy, but I think the system won't run because the lib files are 32 bit and ES is compiling in 64, so the resulting EXE fails to execute.

This makes me wonder about the solution:

1. Are there 64 bit lib files to use instead of the 32?

2. Are there switches for the compiler to make some sort of translation from 64-to-32-to-64 when it is compiling those lib file calls into the EXE?

3. Something else?

BTW: Manu had mentioned that the 17.05 version might handle the compiler error I was getting previously. It appears that this is in fact what has happened--the error has been handled. The only remaining matter is this ssleay/libeay.lib issue.

Thank you all for your assist!

[Larry Rix]

Well, well, well ... 3rd time is a charm perhaps?

I deleted the EIFGENs to force a clean compile.

I copied in files from http://www.indyproject.org/Sockets/fpc/OpenSSLforWin64.en.aspx --> FAIL! It would not link.

I deleted the files above, found the original *.lib files that Javier sent me and tried them again.

SUCCESS!! All's well that ends well, but I don't know what I did to make it work.

I do still have the question about the VC14 even after installing VS17CE. Makes me wonder if the VC14 has anything to do with the success and if I am really making 64-bit EXEs?

[javier hector]

Hi Larry,

1) You can get the list of C/C++ compilers, running  from the command line espawn -l 

On my side the output is

>Eiffel Environment Command Spawn Utility - Version: 17.05

>Copyright Eiffel Software 1985-2017. All Rights Reserved.

>Available C/C++ compilers:

  > VC140:  Microsoft Visual Studio 2015 VC++ (14.0)

2) You can check the Visual Studio C++ compiler version using the following command `cl' as follow

>cl

>Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24215.1 for x64

>Copyright (C) Microsoft Corporation.  All rights reserved.

>usage: cl [ option... ] filename... [ /link linkoption... ]

if you get a 32 version, go to the VisualStudio directory (%PATH_TO_VS%) and execute ``vcvarsall.bat x64`

you will find it under %PATH_TO_VS%\VC 

By the way, now there is a new tool provided by VC ++ Team to build C++ Open source libraries in a simple way.

The tool is vckpg, check the following link https://blogs.msdn.microsoft.com/vcblog/2016/09/19/vcpkg-a-tool-to-acquire-and-build-c-open-source-libraries-on-windows/

So to generate the OpenSSL static library for x64 you just need to run the following command (after you have installed vckpg tool).

vcpkg install openssl:x64-windows-static

Hope this helps

/Javier

[Larry Rix]

Looks like this for me, which I think is like yours:

EiffelStudio is ready to be used for the win64 platform and msc_vc140 C compiler.

C:\Program Files\Eiffel Software\EiffelStudio 17.05 GPL>espawn -l

Eiffel Environment Command Spawn Utility - Version: 17.05

Copyright Eiffel Software 1985-2017. All Rights Reserved.

Available C/C++ compilers:

   VC140:  Microsoft Visual Studio 2015 VC++ (14.0)

   VC120:  Microsoft Visual Studio 2013 VC++ (12.0)

   VC110:  Microsoft Visual Studio 2012 VC++ (11.0)

C:\Program Files\Eiffel Software\EiffelStudio 17.05 GPL>

Larry Rix
Moonshot Software

Rocket science for everyone!

Savannah, GA

770-295-9729

--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/eiffel-users.
For more options, visit https://groups.google.com/d/optout.

[Larry Rix]

And the cl returns:

C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin>cl

Microsoft (R) C/C++ Optimizing Compiler Version 19.00.23918 for x86

Copyright (C) Microsoft Corporation.  All rights reserved.

usage: cl [ option... ] filename... [ /link linkoption... ]

C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin>

So--looks like I have VS17CE installed okay for 32-bit and ES 64-bit is okay with that. I presume the 32-bit compiler and compile 64 bit EXEs based on switches or no?

[Larry Rix]

https://developers.slashdot.org/story/16/06/04/1429248/microsoft-declines-to-make-a-64-bit-visual-studio

Looks like MS won't make a 64 bit VS, so the C compiler must be capable of making 64 bit EXEs based on switches, yes?

[Jonathan Ostroff]

I have a question about ECF files in 17.05 for complete Void safety. The ECF file below seems to work ok, i.e. all the libraries and clusters appear to satisfy complete Void safety, attached by default, full class checking etc. 

But I am not sure why that is. Previously there would be a Void safe settings. What we now have, it appears, is a capability declaration

<capability>

<concurrency support="scoop"/>

<void_safety support="all" use="all"/>

</capability>

1. What is the effect of the above capability declaration on clusters such as cluster “root", etc.? Is it the above declaration that ensures that all the clusters and libraries are Void safe?

2. The project below imports the library “espec” (this is a testing library developed by us at York University) in the contributed folder. The ESPEC.ECF file makes no mention of Void safety, yet it appears to operate in a Void safe manner for the project defined below. So it would seem that library ECF files need not state anything about their Void safety? [Presumably because of the capability declaration in #1]

3. It also seems that the above Void safety automatically results in the effect that all types as attached by default?

Just checking to ensure that our tools generate the correct ECF files for what was previously explicitly declared in ECF files to achieve attached by default, complete Void safety and standard syntax. Also Full Class Checking. 

Thanks for any help,

Jonathan

P.S. Void safety is a substantial step forward! Thank you Bertrand, Manu & the Eiffel team, and the ECMA members for moving forward on this. It’s been a demanding but productive journey. 

=====

<?xml version="1.0" encoding="ISO-8859-1"?>

<system xmlns="http://www.eiffel.com/developers/xml/configuration-1-16-0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.eiffel.com/developers/xml/configuration-1-16-0 http://www.eiffel.com/developers/xml/configuration-1-16-0.xsd" name="messenger" uuid="36ACE60F-96C1-445E-9755-6F88602EB468">

<target name="messenger">

<root class="ROOT" feature="make"/>

<file_rule>

<exclude>/CVS$</exclude>

<exclude>/EIFGENs$</exclude>

<exclude>/\.git$</exclude>

<exclude>/\.svn$</exclude>

</file_rule>

<option warning="true" is_obsolete_routine_type="true">

<assertions precondition="true" postcondition="true" check="true" invariant="true" loop="true" supplier_precondition="true"/>

</option>

<capability>

<concurrency support="scoop"/>

<void_safety support="all" use="all"/>

</capability>

<precompile name="base_pre" location="$ISE_PRECOMP\base-scoop-safe.ecf"/>

<library name="base" location="$ISE_LIBRARY\library\base\base.ecf">

<renaming old_name="SET" new_name="EIFFEL_SET"/>

<renaming old_name="BAG" new_name="EIFFEL_BAG"/>

</library>

<library name="espec" location="$ISE_LIBRARY\contrib\library\testing\framework\espec\library\espec.ecf"/>

<library name="mathmodels" location="$MATHMODELS\library\mathmodels.ecf"/>

<library name="encoding" location="$ISE_LIBRARY\library\encoding\encoding.ecf"/>

<library name="gobo_kernel" location="$ISE_LIBRARY\library\gobo\gobo_kernel.ecf"/>

<library name="gobo_lexical" location="$ISE_LIBRARY\library\gobo\gobo_lexical.ecf"/>

<library name="gobo_parse" location="$ISE_LIBRARY\library\gobo\gobo_parse.ecf"/>

<library name="gobo_structure" location="$ISE_LIBRARY\library\gobo\gobo_structure.ecf"/>

<library name="gobo_utility" location="$ISE_LIBRARY\library\gobo\gobo_utility.ecf"/>

<library name="time" location="$ISE_LIBRARY\library\time\time.ecf"/>

<library name="vision2" location="$ISE_LIBRARY\library\vision2\vision2.ecf"/>

  <cluster name="messenger" location=".\messenger\" recursive="true"/>

<cluster name="generated_code" location=".\generated_code\" recursive="true"/>

<cluster name="root" location=".\root\" recursive="true"/>

</target>

</system>

[Alexander Kogtenkov]

Dear Jonathan,

Capabilities were introduced in EiffelStudio 17.01 as mentioned in the release notes

   https://www.eiffel.org/doc/eiffelstudio/Release%20notes%20for%20EiffelStudio%2017.01 

Some lower-level details could also be found at the developers site:

   https://dev.eiffel.com/EiffelStudio_17.01_Releases#New_features 

Answering your specific questions:

1. Capabilities are specified at the level of a target, not a cluster or a class, and are applied to all classes from the clusters belonging to the target. This is the part "support", i.e. what the classes are capable of. E.g., <void_safety support="all"/> means all classes of the associated target are completely void-safe.

As to libraries or an inherited target, their capabilities should be sufficient for the current target, i.e. they should provide the same or better guarantees. If the current target has complete void safety, all used libraries should be completely void-safe as well.

So, yes, with <void_safety support="all"/>, all used libraries are also completely void-safe.

As to the part "use", this is the current setting used to compile the target, not to check the rules. E.g., one can build a single-threaded application even if it supports SCOOP capability - this depends on the application requirements.

2. According to compatibility table at

   https://www.eiffel.org/doc/eiffelstudio/Eiffel%20compatibility%20options 

if no specific setting is given, starting from EiffelStudio 14.05 the default void safety is complete. This applies to "espec" library ECF as well, i.e. it is completely void safe according to the default void safety settings. These defaults are tightly coupled with ECF schema version, so old projects can be compiled even with a newer compiler using default settings of the earlier ECF version.

3. Attached-by-default is another compatibility setting that is True by default starting from EiffelStudio 7.0. This option is going to disappear altogether soon.

You can consult default values of other compatibility options in the table mentioned above.

Best regards,
Alexander Kogtenkov

Среда, 7 июня 2017, 20:16 +03:00 от Jonathan Ostroff <jonathan....@gmail.com>:

[Jonathan Ostroff]

Thanks for your replies, Alexander, which I very much appreciate. 

I assume that a library would have to specifically declare a Scoop capability for it to be used with Scoop?

Is there any documentation of when a library developed prior to Scoop would be Scoop compatible? For example, the “espec” library does not use threading etc. There are no declarations of “separate” anywhere in the code. It would seem to be Scoop compatible. Are there any precautions that need to be taken?

Thanks and regards,

Jonathan

<system xmlns="http://www.eiffel.com/developers/xml/configuration-1-16-0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.eiffel.com/developers/xml/configuration-1-16-0http://www.eiffel.com/developers/xml/configuration-1-16-0.xsd" name="messenger" uuid="36ACE60F-96C1-445E-9755-6F88602EB468">

-- 
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.

[Alexander Kogtenkov]

By default a project is SCOOP-capable. And usually if it does not use native multithreading directly, and does not use separate types, it is SCOOP-compatible, except for generic classes with unconstrained genericity, where the default constraint is "detachable separate ANY". For most existing code this is indeed the case. The same applies to "espec".

With unconstraint genericity one would either need to take care about calls on expressions of formal generic types - they have to be wrapped. Alternatively, non-separate constraints could be added.

At the moment the following libraries are SCOOP-incompatible:
- Thread - it breaks SCOOP assumptions by using free threading model without any guarantee for transactional access to objects
- Process - it uses Thread (an alternative is to use BaseProcess (a slightly limited version of Process) that does not rely on Thread)
- Testing - it relies on Thread and there is no good replacement yet
So, if a project or a library does not rely on these SCOOP-incompatible libraries, there are good chances that it is SCOOP-compatible.

Best regards,
Alexander Kogtenkov

Jonathan Ostroff <jonathan....@gmail.com>:

[Louis M]

Hi,

There is also the "once ("PROCESS")" feature that is not handled well in SCOOP. In fact, in my case, it is a very big deal since I have a lot of singletons (with shared object) in my projects.

Good day,

Louis M

[Emmanuel Stapf]

What do you mean by not handled well? The only impact of a once per
process is that in SCOOP its type should be marked `separate` to
highlight the fact the instance will be shared among multiple SCOOP
processors.

Manu

> --
> You received this message because you are subscribed to the Google Groups
> "Eiffel Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to eiffel-users...@googlegroups.com.
> Visit this group at https://groups.google.com/group/eiffel-users.
> For more options, visit https://groups.google.com/d/optout.

--
------------------------------------------------------------------------
Eiffel Software
805-685-1006
http://www.eiffel.com
Customer support: http://support.eiffel.com
User group: http://groups.eiffel.com/join
------------------------------------------------------------------------

[Louis M]

Maybe it is me who do not understand SCOOP very well, but I think that marking the singleton as separate force you to put every thing that use the singleton as separate. So, if the singleton is used a lot in a system, it means changing a lot of code (attribute definition and separate code statement). I tried to made one of my library SCOOP compatible, but with the once("PROCESS") that I used in my library, the usage of the library (the interface) was a lot more complicated for the users. It is of course my humble opinion.

Good day,

Louis

[Emmanuel Stapf]

You are right, the handling separate objects has its trade-off but we
made it simpler with inline separate:

my_routine
do
separate my_singleton as singleton do
singleton.do_something
end
end

It is more than before but if you compare this to a traditional
approach in multithreaded programming it is still acceptable:

my_routine
do
my_singleton_mutex.lock
my_singleton.do_something
my_singleton_mutex.unlock
end

and I'm not including the rescue clause to unlock the mutex in case of
exceptions.

Also if the singleton is created using a passive region as in :

create <NONE> Result.make

the separate calls are more efficient since only synchronization and
context switching are done, and the routine `do_something` is executed
locally.

Manu

[Eric Bezault]

On 6/14/2017 19:37, Emmanuel Stapf wrote:
> It is more than before but if you compare this to a traditional
> approach in multithreaded programming it is still acceptable:
>
> my_routine
> do
> my_singleton_mutex.lock
> my_singleton.do_something
> my_singleton_mutex.unlock
> end

I have many cases in my code where the 'once ("PROCESS")' actually
defines a immutable object (like a user-defined constants when the
types is not a basic type or STRING). In that case, in a multithreaded
environment I don't use mutexes (several threads can access the same
object at the same time). How would that translate in a SCOOP
environment?

--
Eric Bezault
mailto:er...@gobosoft.com
http://www.gobosoft.com

[Louis M]

It is more than before but if you compare this to a traditional
approach in multithreaded programming it is still acceptable:

The problem here is that multithread was not the default settings. So when somebody was using my library, they does not have to handle mutexes. Also, when a user actually enabled multithreading, they understand that multithread needed some synchronisation. But now that SCOOP is the default setting in EiffelStudio, when a new user want to use one of my library, it have to handle separate call almost everywhere in there code. Maybe it is because people does not understand SCOOP yet, but I had a lot's of complain about my library being too difficult to understand because of that.

Also if the singleton is created using a passive region as in :

    create <NONE> Result.make

Hmmm. What is this syntax. Is there a documentation about this?

Thanks,

Louis M

[Emmanuel Stapf]

Immutable objects are very important in simplifying SCOOP, but until
they are a first class citizen SCOOP cannot benefit from this.

My naive response for the time being is why do you need it per
process, why not making it a per processor/thread? We have done this
in many cases where there was no semantic differences between having
it per process or per processor/thread.

Manu

[Emmanuel Stapf]

This is the reason we introduced capabilities. Simply mark your
library not SCOOP-able and then your users will have to downgrade
their setting to match yours if they do not care about SCOOP. If they
do then they will most likely require you to upgrade their code.

This is the notion of passive region introduced in 15.08 (see
https://www.eiffel.org/doc/eiffelstudio/Major%20changes%20between%20ISE%20Eiffel%2015.01%20and%20ISE%20Eiffel%2015.08).
There is not yet a documentation about the syntax but the definition
is : <<In the SCOOP model, a passive region does not have a processor
attached to it.This means that clients of the passive region need to
apply features logged against a passive region themselves.The logical
consequence of this is that all call to a passive region, including
commands, are executed synchronously.>>

Manu

[Eric Bezault]

On 6/14/2017 21:02, Emmanuel Stapf wrote:
> Immutable objects are very important in simplifying SCOOP, but until
> they are a first class citizen SCOOP cannot benefit from this.
>
> My naive response for the time being is why do you need it per
> process, why not making it a per processor/thread? We have done this
> in many cases where there was no semantic differences between having
> it per process or per processor/thread.

Most of the time there is indeed no semantic differences.
But there are speed and/or memory differences when it takes
time and/or memory to create these objects. There is also
a speed difference when we have to compare such objects
field by field instead of just doing a reference comparison.
We don't convert our code to use concurrency just for the
beauty of the exercise, but also to improve the performance
of our programs.

[Emmanuel Stapf]

It is a tradeoff, but usually for large objects it is much harder to ensure they are immutable.

Manu