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

[Mark Lorenzen]

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

[Dmitry A. Kazakov]

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

[Warren]

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

[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.

[Simon Wright]

"Dmitry A. Kazakov" <mai...@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 ...

[Warren]

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

[Dmitry A. Kazakov]

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.

[Warren]

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).

[Simon Wright]

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

> On 22/06/2020 22:43, Simon Wright wrote:
>> "Dmitry A. Kazakov" <mai...@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.

[Simon Wright]

Warren <ve3...@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, ...

[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

[Björn Lundin]

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