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

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

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