Building an encapsulated library that uses GNAT sockets under Windows

Building an encapsulated library that uses GNAT sockets under Windows

[Dmitry A. Kazakov]

It seems I finally found a way to build it. The solution is quite 
perplexing. I would be glad if anybody could shed some light on it.

An encapsulated library requires that -lws2_32 -lwsock32 appeared *both* 
at the beginning and the end of the linker command line. Only then no 
"undefined reference" messages appear.

For this build this program:
--------------------------------------- gcc_wrapper.adb ---
with Ada.Command_Line;  use Ada.Command_Line;
with Ada.Exceptions;    use Ada.Exceptions;
with Ada.Text_IO;       use Ada.Text_IO;
with GNAT.OS_Lib;       use GNAT.OS_Lib;

procedure GCC_Wrapper is
    Prefix : String_List :=
             (  new String'("-lwsock32"),
                new String'("-lws2_32")
             );
    Options : String_List (1..Argument_Count);
begin
    for No in 1..Argument_Count loop
       Options (No) := new String'(Argument (No));
    end loop;
    declare
       List : String_List := Prefix & Options & Prefix;
    begin
       Put ("gcc.exe");
       for No in List'Range loop
          Put (" " & List (No).all);
       end loop;
       New_Line;
       Set_Exit_Status (Exit_Status (Spawn ("gcc.exe", List)));
    end;
exception
    when Error : others =>
       Put_Line
       (  Standard_Error,
          "Fault: " & Exception_Information (Error)
       );
       Set_Exit_Status (2);
end GCC_Wrapper;
--------------------------------------- gcc_wrapper.adb ---

The project file must contain:

    package Linker is
       for Driver use "<absolute-path-to>/gcc_wrapper.exe";
    end Linker;

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Building an encapsulated library that uses GNAT sockets under Windows

[ahlan.marriott]

On Thursday, 21 April 2016 15:00:04 UTC+2, Dmitry A. Kazakov  wrote:
> It seems I finally found a way to build it. The solution is quite 
> perplexing. I would be glad if anybody could shed some light on it.
> 
> An encapsulated library requires that -lws2_32 -lwsock32 appeared *both* 
> at the beginning and the end of the linker command line. Only then no 
> "undefined reference" messages appear.
> 
> For this build this program:
> --------------------------------------- gcc_wrapper.adb ---
> with Ada.Command_Line;  use Ada.Command_Line;
> with Ada.Exceptions;    use Ada.Exceptions;
> with Ada.Text_IO;       use Ada.Text_IO;
> with GNAT.OS_Lib;       use GNAT.OS_Lib;
> 
> procedure GCC_Wrapper is
>     Prefix : String_List :=
>              (  new String'("-lwsock32"),
>                 new String'("-lws2_32")
>              );
>     Options : String_List (1..Argument_Count);
> begin
>     for No in 1..Argument_Count loop
>        Options (No) := new String'(Argument (No));
>     end loop;
>     declare
>        List : String_List := Prefix & Options & Prefix;
>     begin
>        Put ("gcc.exe");
>        for No in List'Range loop
>           Put (" " & List (No).all);
>        end loop;
>        New_Line;
>        Set_Exit_Status (Exit_Status (Spawn ("gcc.exe", List)));
>     end;
> exception
>     when Error : others =>
>        Put_Line
>        (  Standard_Error,
>           "Fault: " & Exception_Information (Error)
>        );
>        Set_Exit_Status (2);
> end GCC_Wrapper;
> --------------------------------------- gcc_wrapper.adb ---
> 
> The project file must contain:
> 
>     package Linker is
>        for Driver use "<absolute-path-to>/gcc_wrapper.exe";
>     end Linker;
> 
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

Dear Dmitry,

Is this perhaps the solution to my question "Using Gnat.Sockets in a Windows DLL" that I posted on 8-Dec-2015?

Regards,
Ahlan

Re: Building an encapsulated library that uses GNAT sockets under Windows

[Dmitry A. Kazakov]

On 22/04/2016 09:58, ahlan.marriott@gmail.com wrote:
> On Thursday, 21 April 2016 15:00:04 UTC+2, Dmitry A. Kazakov  wrote:
>> It seems I finally found a way to build it. The solution is quite
>> perplexing. I would be glad if anybody could shed some light on it.
>>
>> An encapsulated library requires that -lws2_32 -lwsock32 appeared *both*
>> at the beginning and the end of the linker command line. Only then no
>> "undefined reference" messages appear.
>>
>> For this build this program:
>> --------------------------------------- gcc_wrapper.adb ---
>> with Ada.Command_Line;  use Ada.Command_Line;
>> with Ada.Exceptions;    use Ada.Exceptions;
>> with Ada.Text_IO;       use Ada.Text_IO;
>> with GNAT.OS_Lib;       use GNAT.OS_Lib;
>>
>> procedure GCC_Wrapper is
>>      Prefix : String_List :=
>>               (  new String'("-lwsock32"),
>>                  new String'("-lws2_32")
>>               );
>>      Options : String_List (1..Argument_Count);
>> begin
>>      for No in 1..Argument_Count loop
>>         Options (No) := new String'(Argument (No));
>>      end loop;
>>      declare
>>         List : String_List := Prefix & Options & Prefix;
>>      begin
>>         Put ("gcc.exe");
>>         for No in List'Range loop
>>            Put (" " & List (No).all);
>>         end loop;
>>         New_Line;
>>         Set_Exit_Status (Exit_Status (Spawn ("gcc.exe", List)));
>>      end;
>> exception
>>      when Error : others =>
>>         Put_Line
>>         (  Standard_Error,
>>            "Fault: " & Exception_Information (Error)
>>         );
>>         Set_Exit_Status (2);
>> end GCC_Wrapper;
>> --------------------------------------- gcc_wrapper.adb ---
>>
>> The project file must contain:
>>
>>      package Linker is
>>         for Driver use "<absolute-path-to>/gcc_wrapper.exe";
>>      end Linker;
>>
>> --
>> Regards,
>> Dmitry A. Kazakov
>> http://www.dmitry-kazakov.de
>
> Dear Dmitry,
>
> Is this perhaps the solution to my question "Using Gnat.Sockets in a Windows DLL" that I posted on 8-Dec-2015?

Yes, I think it is the same problem you reported. BTW, I built gprbuild 
from the latest Git sources. That did not fix the problem.

It looks really weird how GCC linker searches libraries under Windows. 
Not to mention its abysmal performance. It takes literally an hour to 
link an executable against 20-30 libraries.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Building an encapsulated library that uses GNAT sockets under Windows

[Ahlan]

On Friday, 22 April 2016 10:23:31 UTC+2, Dmitry A. Kazakov  wrote:
> On 22/04/2016 09:58, ahlan@marriott.org wrote:
> > On Thursday, 21 April 2016 15:00:04 UTC+2, Dmitry A. Kazakov  wrote:
> >> It seems I finally found a way to build it. The solution is quite
> >> perplexing. I would be glad if anybody could shed some light on it.
> >>
> >> An encapsulated library requires that -lws2_32 -lwsock32 appeared *both*
> >> at the beginning and the end of the linker command line. Only then no
> >> "undefined reference" messages appear.
> >>
> >> For this build this program:
> >> --------------------------------------- gcc_wrapper.adb ---
> >> with Ada.Command_Line;  use Ada.Command_Line;
> >> with Ada.Exceptions;    use Ada.Exceptions;
> >> with Ada.Text_IO;       use Ada.Text_IO;
> >> with GNAT.OS_Lib;       use GNAT.OS_Lib;
> >>
> >> procedure GCC_Wrapper is
> >>      Prefix : String_List :=
> >>               (  new String'("-lwsock32"),
> >>                  new String'("-lws2_32")
> >>               );
> >>      Options : String_List (1..Argument_Count);
> >> begin
> >>      for No in 1..Argument_Count loop
> >>         Options (No) := new String'(Argument (No));
> >>      end loop;
> >>      declare
> >>         List : String_List := Prefix & Options & Prefix;
> >>      begin
> >>         Put ("gcc.exe");
> >>         for No in List'Range loop
> >>            Put (" " & List (No).all);
> >>         end loop;
> >>         New_Line;
> >>         Set_Exit_Status (Exit_Status (Spawn ("gcc.exe", List)));
> >>      end;
> >> exception
> >>      when Error : others =>
> >>         Put_Line
> >>         (  Standard_Error,
> >>            "Fault: " & Exception_Information (Error)
> >>         );
> >>         Set_Exit_Status (2);
> >> end GCC_Wrapper;
> >> --------------------------------------- gcc_wrapper.adb ---
> >>
> >> The project file must contain:
> >>
> >>      package Linker is
> >>         for Driver use "<absolute-path-to>/gcc_wrapper.exe";
> >>      end Linker;
> >>
> >> --
> >> Regards,
> >> Dmitry A. Kazakov
> >> http://www.dmitry-kazakov.de
> >
> > Dear Dmitry,
> >
> > Is this perhaps the solution to my question "Using Gnat.Sockets in a Windows DLL" that I posted on 8-Dec-2015?
> 
> Yes, I think it is the same problem you reported. BTW, I built gprbuild 
> from the latest Git sources. That did not fix the problem.
> 
> It looks really weird how GCC linker searches libraries under Windows. 
> Not to mention its abysmal performance. It takes literally an hour to 
> link an executable against 20-30 libraries.
> 
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

Dear Dmitry,
The problem is not in Gprbuild.exe but in libexe/gprbuild/gprlib.exe
Have you tried building Gprlib from the git sources? - that might be a more elegant solution.

MfG
Ahlan

Re: Building an encapsulated library that uses GNAT sockets under Windows

[Dmitry A. Kazakov]

On 2016-04-23 11:20, Ahlan wrote:

> The problem is not in Gprbuild.exe but in libexe/gprbuild/gprlib.exe
> Have you tried building Gprlib from the git sources? - that might be a more elegant solution.

Yes I did. When you build gprbuild, it also builds all other utilities 
including gprlib.exe.

You can try it yourself. It is here:

    https://github.com/AdaCore/gprbuild

There are two problems to fix to be able to do so:

1. OS_Lib does not contain Kill and Kill_Process_Tree gprclear requires. 
You can comment them out. Kill is relatively easy, you must add win32ada 
to the project and do:

    procedure Kill (Pid : Process_Id; Hard_Kill : Boolean) is
       use Win32.Winbase;
       use Win32.Winnt;
       Process : HANDLE;
       Result  : Win32.BOOL;
    begin
       Process := OpenProcess
                  (  PROCESS_ALL_ACCESS,
                     1,
                     Win32.DWORD (Pid_To_Integer (Pid))
                  );
       Result  := TerminateProcess (Process, 1);
    end Kill;

Kill_Process_Tree is more complicated, but could be just Kill (:-))

2. There is a dynamic_constraint somewhere put on a type, that promptly 
crashes the compiler. I removed it.

However I was not aware of the directory ...\libexec\gprbuild. I 
replaced only the executables in ...\bin. Thank you for the hint. Maybe 
that would do the trick. I will try it next week and report back.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Building an encapsulated library that uses GNAT sockets under Windows

[ahlan.marriott]

On Saturday, 23 April 2016 11:49:13 UTC+2, Dmitry A. Kazakov  wrote:
> On 2016-04-23 11:20, Ahlan wrote:
> 
> > The problem is not in Gprbuild.exe but in libexe/gprbuild/gprlib.exe
> > Have you tried building Gprlib from the git sources? - that might be a more elegant solution.
> 
> Yes I did. When you build gprbuild, it also builds all other utilities 
> including gprlib.exe.
> 
> You can try it yourself. It is here:
> 
>     https://github.com/AdaCore/gprbuild
> 
> There are two problems to fix to be able to do so:
> 
> 1. OS_Lib does not contain Kill and Kill_Process_Tree gprclear requires. 
> You can comment them out. Kill is relatively easy, you must add win32ada 
> to the project and do:
> 
>     procedure Kill (Pid : Process_Id; Hard_Kill : Boolean) is
>        use Win32.Winbase;
>        use Win32.Winnt;
>        Process : HANDLE;
>        Result  : Win32.BOOL;
>     begin
>        Process := OpenProcess
>                   (  PROCESS_ALL_ACCESS,
>                      1,
>                      Win32.DWORD (Pid_To_Integer (Pid))
>                   );
>        Result  := TerminateProcess (Process, 1);
>     end Kill;
> 
> Kill_Process_Tree is more complicated, but could be just Kill (:-))
> 
> 2. There is a dynamic_constraint somewhere put on a type, that promptly 
> crashes the compiler. I removed it.
> 
> However I was not aware of the directory ...\libexec\gprbuild. I 
> replaced only the executables in ...\bin. Thank you for the hint. Maybe 
> that would do the trick. I will try it next week and report back.
> 
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

Dear Dmitry,
I downloaded the sources from Git using the link you supplied and built Gprlib.exe
I could build this without the problems you mentioned.
I guess these problem occur when you try and build the other utilities that GprBuild builds.
However as I was only interested in Gprlib I only built that.

I then copied this into the /libexe/gprbuild directory of my GNAT release
and this then solved the problem. :-)

Ie Using Gprlib.exe built from the latest git sources I was able to build a Windows encapsulated library (DLL) that uses Gnat.Sockets without have to use your Gcc_Wrapper workaround.

Best wishes,
Ahlan

Re: Building an encapsulated library that uses GNAT sockets under Windows

[Dmitry A. Kazakov]

On 2016-04-23 16:45, ahlan.marriott@gmail.com wrote:
> On Saturday, 23 April 2016 11:49:13 UTC+2, Dmitry A. Kazakov  wrote:

> I downloaded the sources from Git using the link you supplied and built Gprlib.exe
> I could build this without the problems you mentioned.
> I guess these problem occur when you try and build the other utilities that GprBuild builds.
> However as I was only interested in Gprlib I only built that.
>
> I then copied this into the /libexe/gprbuild directory of my GNAT release
> and this then solved the problem. :-)
>
> Ie Using Gprlib.exe built from the latest git sources I was able to
> build a Windows encapsulated library (DLL) that uses Gnat.Sockets
> without have to use your Gcc_Wrapper workaround.

Great! Will test that next week.

Can it build a static equivalent too? I.e. a static library containing a 
closure of all referenced objects plus initialization code.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Building an encapsulated library that uses GNAT sockets under Windows

[Simon Wright]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> Can [gprlib] build a static equivalent too? I.e. a static library
> containing a closure of all referenced objects plus initialization
> code.

I'm not sure it's relevant, but I posted a bug[1] on gnatmake & static
standalone libraries; I sent AdaCore a similar report on gprbuild, no
reply.

The problem was, for a static SAL, the using Ada main program needs to
see all the ALIs for it to be sure to call in all the dylibs required by
the library; so if e.g. libgnarl was only called by  non-interface units
it would get linked but not elaborated.

I wanted to use SALs because they automatically populate the include
directory with relevant source.

The GNAT GPL 2015 version of the patch is

diff --git a/src/gprlib.adb b/src/gprlib.adb
--- a/src/gprlib.adb
+++ b/src/gprlib.adb
@@ -555,7 +555,7 @@
       Status       : Boolean;
 
    begin
-      if Standalone = No then
+      if Standalone = No or Static then
          for Index in 1 .. ALIs.Last loop
             declare
                Destination : constant String :=

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56616

Re: Building an encapsulated library that uses GNAT sockets under Windows

[ahlan]

On Saturday, April 23, 2016 at 11:16:53 PM UTC+2, Simon Wright wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
> > Can [gprlib] build a static equivalent too? I.e. a static library
> > containing a closure of all referenced objects plus initialization
> > code.
> 
> I'm not sure it's relevant, but I posted a bug[1] on gnatmake & static
> standalone libraries; I sent AdaCore a similar report on gprbuild, no
> reply.
> 
> The problem was, for a static SAL, the using Ada main program needs to
> see all the ALIs for it to be sure to call in all the dylibs required by
> the library; so if e.g. libgnarl was only called by  non-interface units
> it would get linked but not elaborated.
> 
> I wanted to use SALs because they automatically populate the include
> directory with relevant source.
> 
> The GNAT GPL 2015 version of the patch is
> 
> diff --git a/src/gprlib.adb b/src/gprlib.adb
> --- a/src/gprlib.adb
> +++ b/src/gprlib.adb
> @@ -555,7 +555,7 @@
>        Status       : Boolean;
>  
>     begin
> -      if Standalone = No then
> +      if Standalone = No or Static then
>           for Index in 1 .. ALIs.Last loop
>              declare
>                 Destination : constant String :=
> 
> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56616

Dear Simon,

Unfortunately your bug fix isn't included in the sources maintained by AdaCore at GitHub.
So thank you for the improvement :-)

Regards,
Ahlan

Re: Building an encapsulated library that uses GNAT sockets under Windows

[Simon Wright]

ahlan@marriott.org writes:

> On Saturday, April 23, 2016 at 11:16:53 PM UTC+2, Simon Wright wrote:

>> I'm not sure it's relevant, but I posted a bug[1] on gnatmake & static
>> standalone libraries; I sent AdaCore a similar report on gprbuild, no
>> reply.

> Unfortunately your bug fix isn't included in the sources maintained by
> AdaCore at GitHub.
> So thank you for the improvement :-)

I guess I should post an issue there, then! Thanks for the nudge.

Re: Building an encapsulated library that uses GNAT sockets under Windows

[ahlan.marriott]

On Sunday, 24 April 2016 10:31:12 UTC+2, Simon Wright  wrote:
> ahlan@marriott.org writes:
> 
> > On Saturday, April 23, 2016 at 11:16:53 PM UTC+2, Simon Wright wrote:
> 
> >> I'm not sure it's relevant, but I posted a bug[1] on gnatmake & static
> >> standalone libraries; I sent AdaCore a similar report on gprbuild, no
> >> reply.
> 
> > Unfortunately your bug fix isn't included in the sources maintained by
> > AdaCore at GitHub.
> > So thank you for the improvement :-)
> 
> I guess I should post an issue there, then! Thanks for the nudge.

At the same time you might like to suggest that they remove the gotos from the code!
These caused me lots of problems because our IDE prohibits gotos.
Who in their right mind uses gotos?
In the late seventies we were taught that gotos were evil and never to be used yet here they are, three and a half decades later, still using them - what a disgrace - have people no shame? ;-)

MfG
Ahlan

Re: Building an encapsulated library that uses GNAT sockets under Windows

[Dmitry A. Kazakov]

On 2016-04-23 23:16, Simon Wright wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>
>> Can [gprlib] build a static equivalent too? I.e. a static library
>> containing a closure of all referenced objects plus initialization
>> code.
>
> I'm not sure it's relevant, but I posted a bug[1] on gnatmake & static
> standalone libraries; I sent AdaCore a similar report on gprbuild, no
> reply.
>
> The problem was, for a static SAL, the using Ada main program needs to
> see all the ALIs for it to be sure to call in all the dylibs required by
> the library; so if e.g. libgnarl was only called by  non-interface units
> it would get linked but not elaborated.
>
> I wanted to use SALs because they automatically populate the include
> directory with relevant source.

How do you build a static stand-alone library? In my case gprbuild wants 
it dynamic.

Another question is regarding the library interface. gprbuild rejects 
interface units from other projects. But usually the library is just a 
combination of many projects some of which providing interface units.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Building an encapsulated library that uses GNAT sockets under Windows

[Simon Wright]

ahlan.marriott@gmail.com writes:

> On Sunday, 24 April 2016 10:31:12 UTC+2, Simon Wright  wrote:
>> ahlan@marriott.org writes:
>> 
>> > On Saturday, April 23, 2016 at 11:16:53 PM UTC+2, Simon Wright wrote:
>> 
>> >> I'm not sure it's relevant, but I posted a bug[1] on gnatmake & static
>> >> standalone libraries; I sent AdaCore a similar report on gprbuild, no
>> >> reply.
>> 
>> > Unfortunately your bug fix isn't included in the sources maintained by
>> > AdaCore at GitHub.
>> > So thank you for the improvement :-)
>> 
>> I guess I should post an issue there, then! Thanks for the nudge.
>
> At the same time you might like to suggest that they remove the gotos
> from the code!

I could only see one (in gprbuild-link.adb). I'd be a lot more worried
about the general complexity of that code than one poor little goto.

You could raise your own issue.

> These caused me lots of problems because our IDE prohibits gotos.
> Who in their right mind uses gotos?

Who in their right mind prohibits code structures that are sometimes,
albeit rarely, the Right Way to do the job? (though I can't actually
remember the last time I used a goto).

Re: Building an encapsulated library that uses GNAT sockets under Windows

[Simon Wright]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On 2016-04-23 23:16, Simon Wright wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>
>>> Can [gprlib] build a static equivalent too? I.e. a static library
>>> containing a closure of all referenced objects plus initialization
>>> code.
>>
>> I'm not sure it's relevant, but I posted a bug[1] on gnatmake &
>> static standalone libraries; I sent AdaCore a similar report on
>> gprbuild, no reply.
>>
>> The problem was, for a static SAL, the using Ada main program needs
>> to see all the ALIs for it to be sure to call in all the dylibs
>> required by the library; so if e.g. libgnarl was only called by
>> non-interface units it would get linked but not elaborated.
>>
>> I wanted to use SALs because they automatically populate the include
>> directory with relevant source.
>
> How do you build a static stand-alone library? In my case gprbuild
> wants it dynamic.

I see what you mean, I've been calling it the wrong thing all these
years.

If you provide a Library_Interface and you're building a dynamic
library, gprbuild populates the include Library_Src_Dir directory with
the library interface units and builds a dynamic library with
auto-initialization.

If you provide a Library_Interface and you're building a static library,
gprbuild uses the same rule to populate the include directory; but this
mey be wrong if the non-visible units require elaboration (e.g. they
call in the tasking runtime).

The patch I provided meant that if you provided a Library_Interface for
a static library, the include directory would be populated with all the
units regardless of whether they were actually listed; I now see that
using Interfaces and naming all the source files achieves the same
effect! so no need for a patch (but maybe a blog posting?)

For the BCs this would mean

   case Library_Type is
      when "relocatable" =>
         for Library_Src_Dir use "./include";
         for Library_Interface use Source_Units;
      when "static" =>
         for Library_Src_Dir use "./include";
         for Interfaces use Sources;
   end case;

where I already have

   Source_Units :=
     (
      "BC.Containers.Bags.Bounded",
      "BC.Containers.Bags.Dynamic",
      ...

and

   Sources :=
     (
      "bc-containers-bags-bounded.adb",
      "bc-containers-bags-bounded.ads",
      "bc-containers-bags-dynamic.adb",
      "bc-containers-bags-dynamic.ads",
      ...

I don't really like the idea of using Library_Interface (what units
should be visible) to indicate that auto-initialization is required;
especially because there are already Library_Standalone and
Library_Auto_Init. Perhaps they weren't available at the time.

> Another question is regarding the library interface. gprbuild rejects
> interface units from other projects. But usually the library is just a
> combination of many projects some of which providing interface units.

You would only need to know about the interface units of other libraries
if you were going to call them yourself directly.

Re: Building an encapsulated library that uses GNAT sockets under Windows

[Jeffrey R. Carter]

On 04/26/2016 12:43 PM, ahlan.marriott@gmail.com wrote:
>
> At the same time you might like to suggest that they remove the gotos from the code!
> These caused me lots of problems because our IDE prohibits gotos.
> Who in their right mind uses gotos?
> In the late seventies we were taught that gotos were evil and never to be used yet here they are, three and a half decades later, still using them - what a disgrace - have people no shame? ;-)

Goto is sometimes a good idea; for example, when translating STDs, using goto 
for the transitions is often advocated to encode the state in the program counter.

In most other cases, though, goto is usually not needed and less clear than the 
alternatives.

-- 
Jeff Carter
"Of course, one couldn't think properly in Paris--
it was so uncomfortable and the houses were
central heated."
Clouds of Witness
153

Re: Building an encapsulated library that uses GNAT sockets under Windows

[Simon Wright]

Simon Wright <simon@pushface.org> writes:

>    case Library_Type is
>       when "relocatable" =>
>          for Library_Src_Dir use "./include";
>          for Library_Interface use Source_Units;
>       when "static" =>
>          for Library_Src_Dir use "./include";
>          for Interfaces use Sources;
>    end case;

Actually, the Library_Src_Dir won't normally have the same content in
the two cases, so they should be different (./include-relocatable,
./include-static for example).

Or

   for Library_Src_Dir use "./include-" & Library_Type;
   case Library_Type is
      when "relocatable" =>
         for Library_Interface use Source_Units;
      when "static" =>
         for Interfaces use Sources;
   end case;

Re: Building an encapsulated library that uses GNAT sockets under Windows

[ahlan]

On Wednesday, April 27, 2016 at 8:53:17 AM UTC+2, Simon Wright wrote:
> Simon Wright <simon@pushface.org> writes:
> 
> >    case Library_Type is
> >       when "relocatable" =>
> >          for Library_Src_Dir use "./include";
> >          for Library_Interface use Source_Units;
> >       when "static" =>
> >          for Library_Src_Dir use "./include";
> >          for Interfaces use Sources;
> >    end case;
> 
> Actually, the Library_Src_Dir won't normally have the same content in
> the two cases, so they should be different (./include-relocatable,
> ./include-static for example).
> 
> Or
> 
>    for Library_Src_Dir use "./include-" & Library_Type;
>    case Library_Type is
>       when "relocatable" =>
>          for Library_Interface use Source_Units;
>       when "static" =>
>          for Interfaces use Sources;
>    end case;

I have one last question concerning the build of gprlib.
When I use gprbuild to build applications that do not require a console I add "-mwindows" to the default_switches in package Linker within the gpr file.
However when I do this for Gprlib and then replace the AdaCore Gprlib with my version subsequent use of Gprbuild results in three console windows being momentarily displayed.
However if I omit the "-mwindows" then all is well and these consoles do not appear.
What confuses my small brain is that this is the opposite of what I expected.
Normally if I don't specify -mwindows I get a console application.
Does anyone have an explanation of why gprlib appears special in this regard?
What am I misunderstanding?

Confused,
Ahlan

Re: Building an encapsulated library that uses GNAT sockets under Windows

[Dmitry A. Kazakov]

On 26/04/2016 23:23, Simon Wright wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>
>> On 2016-04-23 23:16, Simon Wright wrote:
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>>
>>>> Can [gprlib] build a static equivalent too? I.e. a static library
>>>> containing a closure of all referenced objects plus initialization
>>>> code.
>>>
>>> I'm not sure it's relevant, but I posted a bug[1] on gnatmake &
>>> static standalone libraries; I sent AdaCore a similar report on
>>> gprbuild, no reply.
>>>
>>> The problem was, for a static SAL, the using Ada main program needs
>>> to see all the ALIs for it to be sure to call in all the dylibs
>>> required by the library; so if e.g. libgnarl was only called by
>>> non-interface units it would get linked but not elaborated.
>>>
>>> I wanted to use SALs because they automatically populate the include
>>> directory with relevant source.
>>
>> How do you build a static stand-alone library? In my case gprbuild
>> wants it dynamic.
>
> I see what you mean, I've been calling it the wrong thing all these
> years.
>
> If you provide a Library_Interface and you're building a dynamic
> library, gprbuild populates the include Library_Src_Dir directory with
> the library interface units and builds a dynamic library with
> auto-initialization.
>
> If you provide a Library_Interface and you're building a static library,
> gprbuild uses the same rule to populate the include directory; but this
> mey be wrong if the non-visible units require elaboration (e.g. they
> call in the tasking runtime).
>
> The patch I provided meant that if you provided a Library_Interface for
> a static library, the include directory would be populated with all the
> units regardless of whether they were actually listed; I now see that
> using Interfaces and naming all the source files achieves the same
> effect! so no need for a patch (but maybe a blog posting?)
>
> For the BCs this would mean
>
>    case Library_Type is
>       when "relocatable" =>
>          for Library_Src_Dir use "./include";
>          for Library_Interface use Source_Units;
>       when "static" =>
>          for Library_Src_Dir use "./include";
>          for Interfaces use Sources;
>    end case;
>
> where I already have
>
>    Source_Units :=
>      (
>       "BC.Containers.Bags.Bounded",
>       "BC.Containers.Bags.Dynamic",
>       ...
>
> and
>
>    Sources :=
>      (
>       "bc-containers-bags-bounded.adb",
>       "bc-containers-bags-bounded.ads",
>       "bc-containers-bags-dynamic.adb",
>       "bc-containers-bags-dynamic.ads",
>       ...

It is still deeply confusing to me. Does it mean that Interfaces must be 
the list of all source file from all projects?

The case is:

with "A.gpr";
with "B.gpr";
...
with "Z.gpr";

library project Foo is
    for Source_Files use (); -- No own sources, to stress the point
    for Library_Kind use "static";
    for Library_Standalone use "encapsulated"; -- ??
    for Library_Auto_Init use "true"; -- ??
    for Library_Interface use (<things-to-be-visible-are-outside>);
    for Interface use (<what?>);
end Foo;

> I don't really like the idea of using Library_Interface (what units
> should be visible) to indicate that auto-initialization is required;
> especially because there are already Library_Standalone and
> Library_Auto_Init. Perhaps they weren't available at the time.
>
>> Another question is regarding the library interface. gprbuild rejects
>> interface units from other projects. But usually the library is just a
>> combination of many projects some of which providing interface units.
>
> You would only need to know about the interface units of other libraries
> if you were going to call them yourself directly.

But there is no other libraries after libFoo.a is built. The whole 
purpose of the exercise to have libFoo a closure containing all static 
libraries it depends on and GNAT RTL too.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Building an encapsulated library that uses GNAT sockets under Windows

[Simon Wright]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> It is still deeply confusing to me. Does it mean that Interfaces must
> be the list of all source file from all projects?
>
> The case is:
>
> with "A.gpr";
> with "B.gpr";
> ...
> with "Z.gpr";
>
> library project Foo is
>    for Source_Files use (); -- No own sources, to stress the point
>    for Library_Kind use "static";
>    for Library_Standalone use "encapsulated"; -- ??
>    for Library_Auto_Init use "true"; -- ??
>    for Library_Interface use (<things-to-be-visible-are-outside>);
>    for Interface use (<what?>);
> end Foo;

I'm sorry, I really don't understand this either.

Tool documentation really needs to have use cases and the solutions that
the tool offers.

Or perhaps "It looks as though you're trying to build a standalone
library ..." :-)

Re: Building an encapsulated library that uses GNAT sockets under Windows

[Randy Brukardt]

<ahlan.marriott@gmail.com> wrote in message 
news:cf442cc4-8123-4815-8b49-ce1411ff4ed0@googlegroups.com...
...
> In the late seventies we were taught that gotos were evil and never
> to be used yet here they are, three and a half decades later, still using
> them - what a disgrace - have people no shame? ;-)

I hope the smiley face applies to the entire rant about Gotos.

When we discussed whether Ada should have a loop continue statement, the 
conclusion was that goto is good enough for such cases. They aren't common 
enough to justify adding a new kind of statement, especially one that can 
get lost (some people dislike deeply nested return statements, and 
"continue" would be worse). We even changed the syntax slightly to make it 
legal for a label to be the last thing in a sequence of statements.

That is:

     loop
          {some code}
          if something then
              goto Continue;
          end if;
          {more code}
     <<Continue>> -- Ada 95 requires "null;" here, Ada 2012 does not.
     end loop;

See AI05-0179-1 for details.

To completely eliminate the goto, one has to use a Boolean variable instead, 
or duplicate parts of the loop; both of those obscure what is going on more 
than the goto.

Moral: all gotos aren't bad. Coding standards that reject them out of hand 
are just like coding standards that reject exception handling or 
finalization out of hand -- deeply flawed.

                                      Randy.

Re: Building an encapsulated library that uses GNAT sockets under Windows

[Jeffrey R. Carter]

On 04/27/2016 03:16 PM, Randy Brukardt wrote:
>
>      loop
>           {some code}
>           if something then
>               goto Continue;
>           end if;
>           {more code}
>      <<Continue>> -- Ada 95 requires "null;" here, Ada 2012 does not.
>      end loop;
>
> To completely eliminate the goto, one has to use a Boolean variable instead,
> or duplicate parts of the loop; both of those obscure what is going on more
> than the goto.

This claim is completely untrue. The example loop is equivalent to

loop
    {some code}
    if not something then
       {more code}
    end if;
end loop;

No Boolean variable (not already present), no duplication of parts of the loop, 
and less obscuration that the goto, which could go almost anywhere, while the if 
must terminate within the loop. It's easier to find the end of the if than it is 
to find the target of the goto. A conditional continue statement is always 
equivalent to such an if.

-- 
Jeff Carter
"We'll make Rock Ridge think it's a chicken
that got caught in a tractor's nuts!"
Blazing Saddles
87

Re: Building an encapsulated library that uses GNAT sockets under Windows

[J-P. Rosen]

Le 28/04/2016 à 00:16, Randy Brukardt a écrit :
> Moral: all gotos aren't bad. Coding standards that reject them out of hand 
> are just like coding standards that reject exception handling or 
> finalization out of hand -- deeply flawed.
Right, but remember:

when a coding standard says "X is forbidden", it really means "X shall
not be used, unless proper justification is given and approved by QA".

Or so should the coding standard say...

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Building an encapsulated library that uses GNAT sockets under Windows

[J-P. Rosen]

Le 28/04/2016 à 01:43, Jeffrey R. Carter a écrit :
> This claim is completely untrue. The example loop is equivalent to
> 
> loop
>    {some code}
>    if not something then
>       {more code}
>    end if;
> end loop;

In simple cases, yes. But what if the "continue" is nested?

loop
   loop
      {some code}
      if Found then
         goto Contine;
      end if;
      {some code}
    end loop;
    {some code}
<<Continue>>
end loop;

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Building an encapsulated library that uses GNAT sockets under Windows

[Jeffrey R. Carter]

On 04/27/2016 10:18 PM, J-P. Rosen wrote:
>
> loop
>    loop
>       {some code}
>       if Found then
>          goto Contine;
>       end if;
>       {some code}
>     end loop;
>     {some code}
> <<Continue>>
> end loop;

People ask for features like a continue statement because they're used to it in 
some other language. I'm not aware of any language that has such a statement 
that exits an inner loop and skips to the end of an outer loop. So I think this 
is a contrived example to try to justify such a statement given that the actual 
uses of the statement in other languages don't justify it. (I hope that makes 
sense.)

Anyway, this can be written as

Outer : loop
    Inner : loop
       {code 1}
       exit Inner when Found;
       {code 2}
    end loop Inner;
    if not Found then
       {code 3}
    end if;
end loop Outer;

I think that is clearer than the goto, and no doubt any efficiency difference 
due to the double evaluation of the condition will be too small to measure. More 
complex cases become

Outer : loop
    Middle : loop
       Inner : loop
          {code 1}
          exit Middle when Found;
          {code 2}
       end loop Inner;
       {code 3}
    end loop Middle;
    if not Found then
       {code 4}
    end if;
end loop Outer;

(I think every loop should have a good name that describes why the loop exists. 
Outer, Middle, and Inner are not such names.)

-- 
Jeff Carter
"We'll make Rock Ridge think it's a chicken
that got caught in a tractor's nuts!"
Blazing Saddles
87

Re: Building an encapsulated library that uses GNAT sockets under Windows

[Randy Brukardt]

"Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> wrote in message 
news:nfrijv$k74$1@dont-email.me...
> On 04/27/2016 03:16 PM, Randy Brukardt wrote:
>>
>>      loop
>>           {some code}
>>           if something then
>>               goto Continue;
>>           end if;
>>           {more code}
>>      <<Continue>> -- Ada 95 requires "null;" here, Ada 2012 does not.
>>      end loop;
>>
>> To completely eliminate the goto, one has to use a Boolean variable 
>> instead,
>> or duplicate parts of the loop; both of those obscure what is going on 
>> more
>> than the goto.
>
> This claim is completely untrue.
[Followed by a bunch of true, but irrelevant discussion.]

It's completely true, because, of course, the if is likely to be deeply 
nested inside of other if and case statements. I should probably have said 
that, but it is so plainly obvious I didn't think anyone would be so silly 
as to ignore and beat up on a straw man. But of course this is the Internet, 
where even usually reasonable people enjoy beating straw men...

A typical case would be a lexer for numeric literals, where one wants to 
discard the underscores and keep the other characters. That would look 
something like:

    while not End_of_File loop
         case Next_Char is
               when '0'..'9' =>
                     null;
               when '+' | '-' =>
                     {some code}
               when 'E' | 'e' =>
                     {some code}
               when '_' =>
                     if Last_Char = '_' then
                           Error (...);
                     else
                           goto Continue; -- Skip further processing.
                     end if;
              when others =>
                     exit; -- We've reached the end of the number.
         end case;
         {Store the Next_Char into the literal token}
      <<Continue>>
    end loop;

To avoid the goto/continue, you'd have to introduce a Boolean, or duplicate 
the "Store" code, or make the "Store" code into a subprogram, and make 
duplicate calls on that. None of which is clearer, or faster, than the above 
code. (Faster matters here as this loop is the third most used of the inner 
lexer loops, behind comments and identifiers. And a lexer is one of the top 
CPU users in a typical compiler.)

                                                     Randy.

Re: Building an encapsulated library that uses GNAT sockets under Windows

[Jeffrey R. Carter]

On 04/28/2016 01:23 PM, Randy Brukardt wrote:
>
> A typical case would be a lexer for numeric literals, where one wants to
> discard the underscores and keep the other characters. That would look
> something like:
>
>     while not End_of_File loop
>          case Next_Char is
>                when '0'..'9' =>
>                      null;
>                when '+' | '-' =>
>                      {some code}
>                when 'E' | 'e' =>
>                      {some code}
>                when '_' =>
>                      if Last_Char = '_' then
>                            Error (...);
>                      else
>                            goto Continue; -- Skip further processing.
>                      end if;
>               when others =>
>                      exit; -- We've reached the end of the number.
>          end case;
>          {Store the Next_Char into the literal token}
>       <<Continue>>
>     end loop;
>
> To avoid the goto/continue, you'd have to introduce a Boolean, or duplicate
> the "Store" code, or make the "Store" code into a subprogram, and make
> duplicate calls on that. None of which is clearer, or faster, than the above
> code. (Faster matters here as this loop is the third most used of the inner
> lexer loops, behind comments and identifiers. And a lexer is one of the top
> CPU users in a typical compiler.)

Or do

               when '_' =>
                  if Last_Char = '_' then
                     Error (...);
                  end if;
               when others =>
                  exit; -- We've reached the end of the number.
          end case;
          if Next_Char /= '_' then
             {Store Next_Char into the literal token}
          end if;
     end loop;

which is still clearer than the goto.

Maybe you have some more complex, more deeply nested, real-world example where 
this kind of alternative isn't possible. I've never encountered one.

-- 
Jeff Carter
"[T]he Musgroves had had the ill fortune
of a very troublesome, hopeless son, and
the good fortune to lose him before he
reached his twentieth year ..."
Persuasion
154

Re: Building an encapsulated library that uses GNAT sockets under Windows

[David Thompson]

On Wed, 27 Apr 2016 22:59:01 -0700, "Jeffrey R. Carter"
<spam.jrcarter.not@spam.not.acm.org> wrote:

> On 04/27/2016 10:18 PM, J-P. Rosen wrote:
> >
> > loop
> >    loop
> >       {some code}
> >       if Found then
> >          goto Contine;
> >       end if;
> >       {some code}
> >     end loop;
> >     {some code}
> > <<Continue>>
> > end loop;
> 
> People ask for features like a continue statement because they're used to it in 
> some other language. I'm not aware of any language that has such a statement 
> that exits an inner loop and skips to the end of an outer loop. <snip>

Fortran >= 90.

PL/I at least IBM dialect since IDK when; I don't recall it there in
the '70s when I used OS/360, but it is in a recent z/OS manual.

perl -- if you accept perl as a programming language; personally I say
it is but not a very good one and certainly not an example to follow.

And I think LISP has it, but LISP has almost everything good AND bad.