How to supply O/S linker arguments with gprbuild?

How to supply O/S linker arguments with gprbuild?

[Warren]

I have a GNAT project that has these pragma statements embedded to get the sucker to link. However, the directory is only valid for an instance on my Mac, so I need a better solution to replace:

   pragma Linker_Options("-L/usr/local/Cellar/readline/8.0.4/lib");
   pragma Linker_Options("-lreadline");

I've tried to find the solution in the gnat documents but they seem to fall short of what I need to do (could not find an example nor direction in this -- perhaps I missed it).

My project file looks something like this:

project MyProject is
    for Languages use ("ada", "c");
    for Source_Dirs use ("src");
    for Object_Dir use "obj";
    for Main use ("main.adb");
end MyProject;

I've tried a variety of gpr things, but unsuccessfully. 

Warren

Re: How to supply O/S linker arguments with gprbuild?

[Mark Lorenzen]

On Monday, June 22, 2020 at 5:51:50 PM UTC+2, Warren wrote:
> I have a GNAT project that has these pragma statements embedded to get the sucker to link. However, the directory is only valid for an instance on my Mac, so I need a better solution to replace:
> 
>    pragma Linker_Options("-L/usr/local/Cellar/readline/8.0.4/lib");
>    pragma Linker_Options("-lreadline");
> 
> I've tried to find the solution in the gnat documents but they seem to fall short of what I need to do (could not find an example nor direction in this -- perhaps I missed it).
> 
> My project file looks something like this:
> 
> project MyProject is
>     for Languages use ("ada", "c");
>     for Source_Dirs use ("src");
>     for Object_Dir use "obj";
>     for Main use ("main.adb");
> end MyProject;
> 
> I've tried a variety of gpr things, but unsuccessfully. 
> 
> Warren

Take a look at this tiny example project file: http://docs.adacore.com/live/wave/gprbuild/html/gprbuild_ug/gprbuild_ug/gnat_project_manager.html#tools-options-in-project-files

You want to configure the linker options in package Linker. You can select between Mac, Linux, Windows, whatever using scenario variables: http://docs.adacore.com/live/wave/gprbuild/html/gprbuild_ug/gprbuild_ug/gnat_project_manager.html#scenarios-in-projects

Regards,
Mark L

Re: How to supply O/S linker arguments with gprbuild?

[Dennis Lee Bieber]

On Mon, 22 Jun 2020 08:51:48 -0700 (PDT), Warren <ve3wwg@gmail.com>
declaimed the following:

>
>I've tried a variety of gpr things, but unsuccessfully. 
>

	I've not used gprbuild (my personal experiments work with gnatmake, and
my pre-retirement life either didn't use GNAT or wrapped some department
specific build system around it)

	Based upon
https://docs.adacore.com/gprbuild-docs/html/gprbuild_ug/building_with_gprbuild.html
you should have the option of putting them on the command line invoking
gprbuild
"""
-largs

The arguments that follow up to the next command line separator are options
for the linker, when linking an executable.
"""

	Suspect it still requires something on the command line (to define
environment) but...
https://docs.adacore.com/gprbuild-docs/html/gprbuild_ug/gnat_project_manager.html#package-linker-attributes
in conjunction with
https://docs.adacore.com/gprbuild-docs/html/gprbuild_ug/gnat_project_manager.html#case-constructions
may be applicable -- and, at least, reduces the amount of command line
entry needed.


-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
	wlfraed@ix.netcom.com    http://wlfraed.microdiversity.freeddns.org/

Re: How to supply O/S linker arguments with gprbuild?

[Dmitry A. Kazakov]

On 22/06/2020 17:51, Warren wrote:
> I have a GNAT project that has these pragma statements embedded to get the sucker to link. However, the directory is only valid for an instance on my Mac, so I need a better solution to replace:
> 
>     pragma Linker_Options("-L/usr/local/Cellar/readline/8.0.4/lib");
>     pragma Linker_Options("-lreadline");
> 
> I've tried to find the solution in the gnat documents but they seem to fall short of what I need to do (could not find an example nor direction in this -- perhaps I missed it).
> 
> My project file looks something like this:
> 
> project MyProject is
>      for Languages use ("ada", "c");
>      for Source_Dirs use ("src");
>      for Object_Dir use "obj";
>      for Main use ("main.adb");
> end MyProject;
> 
> I've tried a variety of gpr things, but unsuccessfully.

There are many ways to do this.

Here I give one rarely used but most flexible and consistent with the 
idea of projects.

If you have an alien library like readline, you can pack it in a 
separate library project like this:

project Readline is
    for Externally_Built use "true"; -- Do not build it
    for Source_Files use ();         -- No sources
    for Library_Dir use "/usr/local/Cellar/readline/8.0.4/lib";
    for Library_Name use "readline"; -- OS naming conventions applied
    for Library_Kind use "dynamic";  -- Or static,
end Readline;                       -- depending on what you have

In your project or projects you would simply do

with "readline.gpr";

and that is all.

Adjust the above using a scenario variable to select the target OS, e.g.

    type OS_Type is
         (  "Windows", "Windows_NT",
            "Linux",
            "UNIX",
            "OSX",
            "FreeBSD",
            ...
         );
    Target_OS : OS_Type := external ("Target_OS", "MS-DOS");

    case Target_OS is
       when "ms-dos" =>
          for Library_Dir use "...";
       when "osx" =>
          for Library_Dir use "...";
          ...

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

Re: How to supply O/S linker arguments with gprbuild?

[Warren]

On Monday, 22 June 2020 12:39:05 UTC-4, Dmitry A. Kazakov  wrote:
> On 22/06/2020 17:51, Warren wrote:
> > I have a GNAT project that has these pragma statements embedded to get the sucker to link. However, the directory is only valid for an instance on my Mac, so I need a better solution to replace:
> > 
> >     pragma Linker_Options("-L/usr/local/Cellar/readline/8.0.4/lib");
> >     pragma Linker_Options("-lreadline");
> > 
> > I've tried to find the solution in the gnat documents but they seem to fall short of what I need to do (could not find an example nor direction in this -- perhaps I missed it).
> > 
> > My project file looks something like this:
> > 
> > project MyProject is
> >      for Languages use ("ada", "c");
> >      for Source_Dirs use ("src");
> >      for Object_Dir use "obj";
> >      for Main use ("main.adb");
> > end MyProject;
> > 
> > I've tried a variety of gpr things, but unsuccessfully.
> 
> There are many ways to do this.
> 
> Here I give one rarely used but most flexible and consistent with the 
> idea of projects.
> 
> If you have an alien library like readline, you can pack it in a 
> separate library project like this:
> 
> project Readline is
>     for Externally_Built use "true"; -- Do not build it
>     for Source_Files use ();         -- No sources
>     for Library_Dir use "/usr/local/Cellar/readline/8.0.4/lib";
>     for Library_Name use "readline"; -- OS naming conventions applied
>     for Library_Kind use "dynamic";  -- Or static,
> end Readline;                       -- depending on what you have
> 
> In your project or projects you would simply do
> 
> with "readline.gpr";
> 
> and that is all.
> 
> Adjust the above using a scenario variable to select the target OS, e.g.
> 
>     type OS_Type is
>          (  "Windows", "Windows_NT",
>             "Linux",
>             "UNIX",
>             "OSX",
>             "FreeBSD",
>             ...
>          );
>     Target_OS : OS_Type := external ("Target_OS", "MS-DOS");
> 
>     case Target_OS is
>        when "ms-dos" =>
>           for Library_Dir use "...";
>        when "osx" =>
>           for Library_Dir use "...";
>           ...

The above might be useful for some projects, but I didn't want to define a package for each and every library I link with. I have a simple Makefile that drives this project, and I simply wanted a central place to configure the pathnames. 

So I managed to get this to work:

project MyProject is   
  for Languages use ("ada", "c");
  for Source_Dirs use ("src");
  for Object_Dir use "obj";
  for Main use ("main.adb");
  package Linker is
    for Required_Switches use ( "-L/usr/local/Cellar/readline/8.0.4/lib", "-lreadline" );
  end Linker;
end MyProject;   

In the final version of the .gpr file, I'll put some sentinel text like <readline_dir> and substitute it as required using sed from the Makefile.  Currently there is only one path I have to deal with but it might grow to several. I didn't want to define a package for each and every library referenced.

I find it amazing that there isn't a single instance of an example like this that I could goggle. The gprbuild doc seems to expend a great deal explaining every other use case, including building of library packages. All I wanted to do was to link an executable. That said, it is possible that my failing eyesight may have overlooked it.

Thanks everyone,
Warren

Re: How to supply O/S linker arguments with gprbuild?

[Dmitry A. Kazakov]

On 22/06/2020 19:52, Warren wrote:

> The above might be useful for some projects, but I didn't want to define a package for each and every library I link with.

Actually this is the way. I have 20+ alien libraries from GTK: atk, 
glib, gobject etc, all of them have a separate project file.

The linker switches you use are the end-of-the-chain parameters. They 
are ignored everywhere else, but when you build an executable. E.g. if 
you build a library and specify some linker switches for it, you will be 
warned that they are ignored.

Thus you have to copy-paste the package linker from one project to 
another once you have more than one. It is not scalable and barely 
maintainable.

For this case people usually define empty parent projects with switches 
or strings set there and pull them into the executable projects 
combining the linker switches from various sources. It is not nice.

The library parameters for the linker that are indeed transferred from 
the library project to the executable project are specified rather using:

    Library_Options (and similar attributes)

not per switches. See

https://docs.adacore.com/gprbuild-docs/html/gprbuild_ug/gnat_project_manager.html#building-libraries

The solution based on Library_Options is almost as good as separate 
third-party library projects if all your third-party dependencies are 
always come through your libraries. Yet there is still a chance to have 
conflicting definitions along different paths from different libraries.

E.g. if you have dependencies like (tree)

    A   C
     \ /
      B
      |
      D

You are OK with Library_Options.

But if you have this (ADG)

      A
     / \
    B   C
     \ /
      D

there is a chance that B and C could have conflicting definitions 
regarding A.

If each library has a project you will never have conflicts and there 
always be only one place to change library options, the library project.

> I have a simple Makefile that drives this project, and I simply wanted a central place to configure the pathnames.

Another idea to consider would be to ditch makefiles. gprbuild does 
everything makefiles do and better and more.

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

Re: How to supply O/S linker arguments with gprbuild?

[Simon Wright]

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

> Another idea to consider would be to ditch makefiles. gprbuild does
> everything makefiles do and better and more.

Almost everything! except determining which OS you're running under, or
building project documentation, or ...

Re: How to supply O/S linker arguments with gprbuild?

[Warren]

On Monday, 22 June 2020 16:43:32 UTC-4, Simon Wright  wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
> > Another idea to consider would be to ditch makefiles. gprbuild does
> > everything makefiles do and better and more.
> 
> Almost everything! except determining which OS you're running under, or
> building project documentation, or ...

That may be true, but I have a lifetime of experience in make. I only have a newb's level of experience with gprbuild and I find the documentation for gprbuild frightful. It talks a lot about syntax, but find it lacking in examples that would apply to the Unix build experience.

What's important for now is just getting this project off the ground in a reasonably portable way. It's just a pet project to give me an excuse to do Ada again. The Ada experience has been good. I'll wade more into gprbuild at a later time.

Warren

Re: How to supply O/S linker arguments with gprbuild?

[Dmitry A. Kazakov]

On 22/06/2020 22:43, Simon Wright wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> Another idea to consider would be to ditch makefiles. gprbuild does
>> everything makefiles do and better and more.
> 
> Almost everything! except determining which OS you're running under, or
> building project documentation, or ...

Are you sure that make has OS macro defined? [It would be great to have 
host OS/architecture + target OS/architecture attributes in gpr. I do 
not understand why gpruild still does not have them.]

Isn't there the package Documentation in grpbuild? [I must admit I never 
used it because I believe documentation must be written, not built.]

If you rather mean project cross reference GPS does the job to me.

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

Re: How to supply O/S linker arguments with gprbuild?

[Warren]

On Monday, 22 June 2020 17:16:50 UTC-4, Dmitry A. Kazakov  wrote:
> On 22/06/2020 22:43, Simon Wright wrote:
> > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> > 
> >> Another idea to consider would be to ditch makefiles. gprbuild does
> >> everything makefiles do and better and more.
> > 
> > Almost everything! except determining which OS you're running under, or
> > building project documentation, or ...
> 
> Are you sure that make has OS macro defined? [It would be great to have 
> host OS/architecture + target OS/architecture attributes in gpr. I do 
> not understand why gpruild still does not have them.]
> 
> Isn't there the package Documentation in grpbuild? [I must admit I never 
> used it because I believe documentation must be written, not built.]
> 
> If you rather mean project cross reference GPS does the job to me.
> 
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

I don't need the OS defined in make. All I need is agree on a few conventions such as PREFIX and define some easily customized macros at the top of the Make file. 

Even knowing that your OS is Linux, doesn't really help. While there are the usual standard places for libraries, there is no guarantee that you'll be linking with those directories. On an older CentOS for example, the newer updates are often installed in custom places like /opt because the older libraries must be maintained for the rest of the system. Shared libraries can be quite the nightmare with the inter-dependencies and versions (same deal as the Windows DLL hell).

Re: How to supply O/S linker arguments with gprbuild?

[Simon Wright]

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

> On 22/06/2020 22:43, Simon Wright wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>
>>> Another idea to consider would be to ditch makefiles. gprbuild does
>>> everything makefiles do and better and more.
>>
>> Almost everything! except determining which OS you're running under, or
>> building project documentation, or ...
>
> Are you sure that make has OS macro defined? [It would be great to
> have host OS/architecture + target OS/architecture attributes in
> gpr. I do not understand why gpruild still does not have them.]

The first page of Gnoga's Makefile has

   ifeq ($(strip $(findstring darwin, $(TARGET))),darwin)
           PRJ_TARGET=OSX
   else
   ifeq ($(strip $(findstring mingw32, $(TARGET))),mingw32)
           PRJ_TARGET=Windows
   else
   etc etc etc

but I agree it'd be much better to have something built-in. The internal
mechanisms of gprconfig would support this kind of thing, in fact they
already do because of knowing hw to build .so/.dll/.dylib depending in
OS, I wonder whether we could surface that?

> Isn't there the package Documentation in grpbuild? [I must admit I
> never used it because I believe documentation must be written, not
> built.]

I just had a look at this, it works on @param-style comments (and, in
the CE 2019 version anyway, goes away and builds "documentation" for all
the withed units from eg GNATCOLL unless you tell it
--no-subprojects. I'd have expected that to be the default.)

> If you rather mean project cross reference GPS does the job to me.

I use Emacs ada-mode, but yes.

Re: How to supply O/S linker arguments with gprbuild?

[Simon Wright]

Warren <ve3wwg@gmail.com> writes:

> I find the documentation for gprbuild frightful. It talks a lot about
> syntax, but find it lacking in examples that would apply to the Unix
> build experience.

Yes. It always takes me a while to find out what attributes are allowed
in a particular package. And the interaction between Switches,
Default_Switches, Global_Compilation_Switches, ... 

Re: How to supply O/S linker arguments with gprbuild?

[Jeffrey R. Carter]

On 6/22/20 11:47 PM, Simon Wright wrote:
> 
> The first page of Gnoga's Makefile has
> 
>     ifeq ($(strip $(findstring darwin, $(TARGET))),darwin)
>             PRJ_TARGET=OSX
>     else
>     ifeq ($(strip $(findstring mingw32, $(TARGET))),mingw32)
>             PRJ_TARGET=Windows
>     else
>     etc etc etc

Where TARGET is defined as

TARGET=$(shell gcc -dumpmachine)

-- 
Jeff Carter
"Death awaits you all, with nasty, big, pointy teeth!"
Monty Python & the Holy Grail
20

Re: How to supply O/S linker arguments with gprbuild?

[Björn Lundin]

Den 2020-06-22 kl. 17:51, skrev Warren:
> I have a GNAT project that has these pragma statements embedded to get the sucker to link. However, the directory is only valid for an instance on my Mac, so I need a better solution to replace:
> 
>     pragma Linker_Options("-L/usr/local/Cellar/readline/8.0.4/lib");
>     pragma Linker_Options("-lreadline");
> 
> I've tried to find the solution in the gnat documents but they seem to fall short of what I need to do (could not find an example nor direction in this -- perhaps I missed it).
> 
> My project file looks something like this:
> 
> project MyProject is
>      for Languages use ("ada", "c");
>      for Source_Dirs use ("src");
>      for Object_Dir use "obj";
>      for Main use ("main.adb");
> end MyProject;
> 
> I've tried a variety of gpr things, but unsuccessfully.
> 
> Warren
> 

This was just (basically) discussed recently in thread
'Checking for OS in gnatstudio project file(.gpr)'

I replied with scnenario/environment variables does the trick

db_libs := ();
case db is
   when Oracle     => db_libs := db_lib1;
   when Postgresql => db_libs := db_lib2;
   when sqlserver  => db_libs := db_lib3;
end case

then you can use  db_libs and fill it up and use it like



ORACLE_HOME   := external ("ORACLE_HOME", "ORACLE_HOME_not_set");
ORACLE_CLIENT := external ("ORACLE_CLIENT", "ORACLE_CLIENT_not_set");
ORA_INST      := external ("ORACLE_INST", "ORACLE_INST_not_set");
LIB_SATTMATE  := external ("SATTMATE_A",  "SATTMATE_A_not_set");
....

there is also
   Target_Machine : Environment.OS_Version_Type := Environment.Os_Version;

   Compiler_Version : Environment.Compiler_Version_Type := 
Environment.Compiler_Version;

  Data_Base : Environment.Database_Type := Environment.Database;

then it comes down to casing the correct combinations

case Target_Machine is
   when "AIX_7.1"      =>
     case Database is
        when "oracle_11" => db_libs :=
                (SMT & "/global/sqlifc_oracle.o",
                ORACLE_CLIENT & "/lib/libclntsh.a");

        when "oci"       => Data_Base_Libs :=
                (ORACLE_CLIENT & "/lib/libclntsh.a",
                 SATTMATE_OCILIB & "/lib/libocilib.a");
        when others => null;
     end case;

     Platform_Dependent_Compiler_Switches := ("-mminimal-toc") ;
     Platform_Dependent_Linker_Switches := ("-L" & SMT & "/global",
     LIB_SATTMATE,
     "-Xlinker",
     "-bhalt:5") &  db_libs;


  when "windows_6.2"  =>
    case Database is
      when "oracle_11" => db_libs :=
        (SMT & "/global/sqlifc_oracle.o",
         ORA_INST & "/precomp/lib/oraSQL11.LIB");
      when "oci"       => db_libs :=
         ("-L" & ORACLE_CLIENT & "/bin",
         "-loci",
         "-L" & SATTMATE_OCILIB,
         "-lociliba");
      when "sqlserver" => db_libs := ("-lodbc32");
      when others => null;
    end case;

    Platform_Dependent_Compiler_Switches := ("-gnatP");
    Platform_Dependent_Linker_Switches :=
    ("-L" & SMT & "/global",
    "-lsattmate") & db_libs;

  when "linux-x64"    => ....
  when "linux-arm32"  => ...

end case;


then use it like (the not previously shown varibles get values in other 
case statemets)

  package Compiler is
    for Default_Switches ("Ada") use
          Platform_Independent_Compiler_Switches &
          Compiler_Dependent_Compiler_Switches &
          Platform_Dependent_Compiler_Switches;
  end Compiler;


package Linker is
   for Default_Switches ("Ada") use Platform_Dependent_Linker_Switches;
end Linker;


Scenario variables are useful too to include a certain directory among 
sources or not, like having common specs but os/db depedent bodies.
make directories win_x86, winx64,Linux_x64/mac/aix/whaterever and 
include the correct one in Sources_dir


for Source_Dirs use common_dirs & (../win_x86);


-- 
Björn