Controlling the linking of shared libraries

Controlling the linking of shared libraries

[Björn Persson]

Does anyone know how to pass command line parameters to Gnatmake and 
GPRbuild that they should forward to gcc when they invoke gcc as a linker to 
build a shared library? -largs seems to be used only when a program is 
linked. When a shared library is linked it seems to be ignored.

-- 
Björn Persson
PGP key A88682FD

Re: Controlling the linking of shared libraries

[anon]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 727 bytes --]

gnatmake doc says use "-largs <linking options>" 
an example is

  gnatmake test.adb  -largs -Lmylibs one.o

which will cause gnatmake to add "mylibs" to the library search directories. 
And "one.o" object file will be added to the list of object files.

Shoukld work for GPBuild as well.


In <98r7sbFs66U1@mid.individual.net>, =?UTF-8?B?QmrDtnJu?= Persson <bjorn@xn--rombobjrn-67a.se> writes:
>Does anyone know how to pass command line parameters to Gnatmake and 
>GPRbuild that they should forward to gcc when they invoke gcc as a linker to 
>build a shared library? -largs seems to be used only when a program is 
>linked. When a shared library is linked it seems to be ignored.
>
>-- 
>Björn Persson
>PGP key A88682FD

Re: Controlling the linking of shared libraries

[Stephen Leake]

Björn Persson <bjorn@xn--rombobjrn-67a.se> writes:

> Does anyone know how to pass command line parameters to Gnatmake and 
> GPRbuild that they should forward to gcc when they invoke gcc as a linker to 
> build a shared library? -largs seems to be used only when a program is 
> linked. When a shared library is linked it seems to be ignored.

Read chapters 11.12 "GNAT Project Manager | Library Projects" and 19
"GNAT and Libraries" of the GNAT User manual.

-- 
-- Stephe

Re: Controlling the linking of shared libraries

[Simon Wright]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> Björn Persson <bjorn@xn--rombobjrn-67a.se> writes:
>
>> Does anyone know how to pass command line parameters to Gnatmake and
>> GPRbuild that they should forward to gcc when they invoke gcc as a
>> linker to build a shared library? -largs seems to be used only when a
>> program is linked. When a shared library is linked it seems to be
>> ignored.
>
> Read chapters 11.12 "GNAT Project Manager | Library Projects" and 19
> "GNAT and Libraries" of the GNAT User manual.

I did this and it took me a *long* time to see that you need
Linker'Linker_Options.

This is a subset of one I'm working on:

   with "tash_options";

   project Tashlib is

     for Library_Name use "tash";
     for Library_Kind use "static";
     for Library_Dir use "lib";
     for Source_Dirs use ("include");
     for Externally_Built use "true";

     package Linker is
        for Linker_Options use Tash_Options.Library_Options;
     end Linker;

   end Tashlib;

and

   project Tash_Options is

      for Source_Dirs use ();

      Library_Options :=
        (
         "-L/usr/lib",
         "-ltk8.5",
         "-ltcl8.5"
        );

   end Tash_Options;

The resulting link for a program using tashlib.gpr is

   $ gnatmake -P tash_tests.gpr tashtest.adb
   gnatbind -E -I- -x /Users/simon/sf/tcladashell/tests/.build/tashtest.ali
   gnatlink /Users/simon/sf/tcladashell/tests/.build/tashtest.ali -g \
     -L/Users/simon/sf/tcladashell/lib/ -ltash \                     <<<<a
     -Wl,-rpath,/opt/gcc-4.6.0......./4.6.0/adalib/ \
     -L/usr/lib -ltk8.5 -ltcl8.5 \                                   <<<<b
     -o /Users/simon/sf/tcladashell/tests/tashtest

where the part I've marked 'a' comes from the main part of tashlib.gpr
and the part marked 'b' comes from Tashlib.Linker'Linker_Options.

Note that this all works fine for static libraries, in spite of what you
might have expected from the documentation; the only thing missing is
that if you create a stand-alone library (SAL) the source files will be
copied to the right place, whereas for this static library I have to do
it in the Makefile.

Re: Controlling the linking of shared libraries

[Björn Persson]

I'll try to explain my problem in more detail and see if that makes it clear 
what I need.

First, please note that I'm not talking about compiling a program and 
linking it to a shared library. I'm talking about compiling the shared 
library itself. When you build a shared library there is a linking phase 
where you take all the .o files you just compiled and combine them into a 
.so file (or a .dll file if you're in Windows land, but I'm in GNU land 
here). I want to pass some options to the linker to control some details in 
how it generates the .so file.

Second, I'm writing this with my Fedora packager hat on. Packagers take 
programs and libraries that others have written and compile them into Fedora 
packages that the Fedora project distributes. Ideally we should be able to 
do this without modifying the upstream source code. Rather than writing 
custom patches for each and every package, we want to define a common set of 
command line parameters and/or environment variables that control how 
packages are built. In practice we often have to patch the upstream 
projects' build systems, as they arent written to be flexible enough, but 
the less we have to patch, and the more we can control the build with 
command line parameters and environment variables, the better.

The Fedora project recently decided to start using a linker option called 
"relro" in all packages as a security measure. This means that we need to 
pass the command line parameter "-Wl,-z,relro" to gcc so that gcc will in 
turn pass "-z relro" to ld. This parameter is not to be used in the 
compilation phase, only in the linking phase when gcc is invoked as a linker 
driver. This was the first distribution-wide linker option that was defined 
in Fedora. Previously the common set of parameters contained only compiler 
options, used in the compilation phase.

Now, some projects are built using makefiles and let the makefile handle the 
linking phase by invoking gcc directly. Those cases are not what I'm 
concerned over right now. Other projects have Gnat project files that 
control the whole build process, and in those cases I need to find a way to 
make Gnatmake or GPRbuild pass "-Wl,-z,relro" to gcc in the linking phase. I 
tried using "-largs -Wl,-z,relro" for this, and found that it has the 
desired effect when the project being built is a program. It does however 
not have any noticeable effect when the project being built is a shared 
library.

According to the manual the attribute Library_Options can be used in project 
files to specify linker options, but as I explained above patching each and 
every project file is undesirable. Therefore I came here to ask you guys: 
Does anyone know how to pass command line parameters to Gnatmake and 
GPRbuild that they should forward to gcc when they invoke gcc as a linker 
driver to build a shared library, given that -largs is not the answer? A 
solution using environment variables might also be preferable to patching.

-- 
Björn Persson
PGP key A88682FD

Re: Controlling the linking of shared libraries

[anon]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3815 bytes --]

For a package: 
  Files: libtest.adb, libtest.ads

  gnat make libtest.adb -o libtest.so -cargs -fPIC -largs -shared

For seperate files: 
  Files: test1.adb, test2.adb

  gnat compile test1.adb  -cagrs -fPIC
  gnat make    test2.adb  -o libtest.so  -cargs -fPIC -largs -shared test1.o



All shared source code must be compiled with "-fPIC' option and be linked 
using "-sharded". And should have ".so" as part of the file.

You could compile as "-o libtest.so.xxx" and then link this file to name
"libtest.so"

The "-cargs" sets gcc compiler options 
The "-bargs" sets gcc binder options 
The "-largs" sets gcc linker options 


In <992cqbFm9mU1@mid.individual.net>, =?UTF-8?B?QmrDtnJu?= Persson <bjorn@xn--rombobjrn-67a.se> writes:
>I'll try to explain my problem in more detail and see if that makes it clear 
>what I need.
>
>First, please note that I'm not talking about compiling a program and 
>linking it to a shared library. I'm talking about compiling the shared 
>library itself. When you build a shared library there is a linking phase 
>where you take all the .o files you just compiled and combine them into a 
>..so file (or a .dll file if you're in Windows land, but I'm in GNU land 
>here). I want to pass some options to the linker to control some details in 
>how it generates the .so file.
>
>Second, I'm writing this with my Fedora packager hat on. Packagers take 
>programs and libraries that others have written and compile them into Fedora 
>packages that the Fedora project distributes. Ideally we should be able to 
>do this without modifying the upstream source code. Rather than writing 
>custom patches for each and every package, we want to define a common set of 
>command line parameters and/or environment variables that control how 
>packages are built. In practice we often have to patch the upstream 
>projects' build systems, as they arent written to be flexible enough, but 
>the less we have to patch, and the more we can control the build with 
>command line parameters and environment variables, the better.
>
>The Fedora project recently decided to start using a linker option called 
>"relro" in all packages as a security measure. This means that we need to 
>pass the command line parameter "-Wl,-z,relro" to gcc so that gcc will in 
>turn pass "-z relro" to ld. This parameter is not to be used in the 
>compilation phase, only in the linking phase when gcc is invoked as a linker 
>driver. This was the first distribution-wide linker option that was defined 
>in Fedora. Previously the common set of parameters contained only compiler 
>options, used in the compilation phase.
>
>Now, some projects are built using makefiles and let the makefile handle the 
>linking phase by invoking gcc directly. Those cases are not what I'm 
>concerned over right now. Other projects have Gnat project files that 
>control the whole build process, and in those cases I need to find a way to 
>make Gnatmake or GPRbuild pass "-Wl,-z,relro" to gcc in the linking phase. I 
>tried using "-largs -Wl,-z,relro" for this, and found that it has the 
>desired effect when the project being built is a program. It does however 
>not have any noticeable effect when the project being built is a shared 
>library.
>
>According to the manual the attribute Library_Options can be used in project 
>files to specify linker options, but as I explained above patching each and 
>every project file is undesirable. Therefore I came here to ask you guys: 
>Does anyone know how to pass command line parameters to Gnatmake and 
>GPRbuild that they should forward to gcc when they invoke gcc as a linker 
>driver to build a shared library, given that -largs is not the answer? A 
>solution using environment variables might also be preferable to patching.
>
>-- 
>Björn Persson
>PGP key A88682FD

Project file version: was Re: Controlling the linking of shared libraries

[anon]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3543 bytes --]

Project file version:
 
for gnatmake or gpBuild 
  from the example directory use the following for shared lib

project Sa_Lib is
   for Languages    use ("Ada", "C");
   for Source_Dirs use ("lib_src");
   for Library_Dir  use "lib3";
   for Library_Kind use "dynamic";
   for Library_Interface use ("ada_lib");
   for Library_Name use "ada";
end Sa_Lib;



In <992cqbFm9mU1@mid.individual.net>, =?UTF-8?B?QmrDtnJu?= Persson <bjorn@xn--rombobjrn-67a.se> writes:
>I'll try to explain my problem in more detail and see if that makes it clear 
>what I need.
>
>First, please note that I'm not talking about compiling a program and 
>linking it to a shared library. I'm talking about compiling the shared 
>library itself. When you build a shared library there is a linking phase 
>where you take all the .o files you just compiled and combine them into a 
>..so file (or a .dll file if you're in Windows land, but I'm in GNU land 
>here). I want to pass some options to the linker to control some details in 
>how it generates the .so file.
>
>Second, I'm writing this with my Fedora packager hat on. Packagers take 
>programs and libraries that others have written and compile them into Fedora 
>packages that the Fedora project distributes. Ideally we should be able to 
>do this without modifying the upstream source code. Rather than writing 
>custom patches for each and every package, we want to define a common set of 
>command line parameters and/or environment variables that control how 
>packages are built. In practice we often have to patch the upstream 
>projects' build systems, as they arent written to be flexible enough, but 
>the less we have to patch, and the more we can control the build with 
>command line parameters and environment variables, the better.
>
>The Fedora project recently decided to start using a linker option called 
>"relro" in all packages as a security measure. This means that we need to 
>pass the command line parameter "-Wl,-z,relro" to gcc so that gcc will in 
>turn pass "-z relro" to ld. This parameter is not to be used in the 
>compilation phase, only in the linking phase when gcc is invoked as a linker 
>driver. This was the first distribution-wide linker option that was defined 
>in Fedora. Previously the common set of parameters contained only compiler 
>options, used in the compilation phase.
>
>Now, some projects are built using makefiles and let the makefile handle the 
>linking phase by invoking gcc directly. Those cases are not what I'm 
>concerned over right now. Other projects have Gnat project files that 
>control the whole build process, and in those cases I need to find a way to 
>make Gnatmake or GPRbuild pass "-Wl,-z,relro" to gcc in the linking phase. I 
>tried using "-largs -Wl,-z,relro" for this, and found that it has the 
>desired effect when the project being built is a program. It does however 
>not have any noticeable effect when the project being built is a shared 
>library.
>
>According to the manual the attribute Library_Options can be used in project 
>files to specify linker options, but as I explained above patching each and 
>every project file is undesirable. Therefore I came here to ask you guys: 
>Does anyone know how to pass command line parameters to Gnatmake and 
>GPRbuild that they should forward to gcc when they invoke gcc as a linker 
>driver to build a shared library, given that -largs is not the answer? A 
>solution using environment variables might also be preferable to patching.
>
>-- 
>Björn Persson
>PGP key A88682FD

Re: Controlling the linking of shared libraries

[Simon Wright]

Would it be possible to use an amended gprbuild configuration file? Here
on Mac OS X there's an option

   for Shared_Library_Minimum_Switches use
         ("-dynamiclib", "-Wl,-flat_namespace", "-shared-libgcc");

and you could add your required option in there.

No good for gnatmake, of course.

I put in "-Wl,-foo" and rebuilt a shared library, and as expected the
result was

$ gprbuild -Pbc --config=botched.cgpr
gprlib bc.lexch
/opt/gnat-gpl-2011/bin/g++ \
  -dynamiclib -Wl,-flat_namespace -shared-libgcc -Wl,-foo \
[...]

(don't know where g++ came from!)

Re: Controlling the linking of shared libraries

[anon]

I testing the project file fot both gnatmake gnat gpbuild
it works. 

In <m2bowjze3k.fsf@pushface.org>, Simon Wright <simon@pushface.org> writes:
>Would it be possible to use an amended gprbuild configuration file? Here
>on Mac OS X there's an option
>
>   for Shared_Library_Minimum_Switches use
>         ("-dynamiclib", "-Wl,-flat_namespace", "-shared-libgcc");
>
>and you could add your required option in there.
>
>No good for gnatmake, of course.
>
>I put in "-Wl,-foo" and rebuilt a shared library, and as expected the
>result was
>
>$ gprbuild -Pbc --config=botched.cgpr
>gprlib bc.lexch
>/opt/gnat-gpl-2011/bin/g++ \
>  -dynamiclib -Wl,-flat_namespace -shared-libgcc -Wl,-foo \
>[...]
>
>(don't know where g++ came from!)

Re: Controlling the linking of shared libraries

[Björn Persson]

Simon Wright wrote:

> Would it be possible to use an amended gprbuild configuration file? Here
> on Mac OS X there's an option
> 
> for Shared_Library_Minimum_Switches use
> ("-dynamiclib", "-Wl,-flat_namespace", "-shared-libgcc");
> 
> and you could add your required option in there.
> 
> No good for gnatmake, of course.

Well, at least that looks like a better solution than patching project 
files. Too bad it works only for GPRbuild, but I suppose it's better than 
nothing. Thanks.

-- 
Björn Persson
PGP key A88682FD

Re: Controlling the linking of shared libraries

[Stephen Leake]

Björn Persson <bjorn@xn--rombobjrn-67a.se> writes:

> According to the manual 

That same manual (assuming it is the gprbuild manual) has a section
"command line", which says -largs will do what you want.

-- 
-- Stephe

Re: Controlling the linking of shared libraries

[Simon Wright]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> Björn Persson <bjorn@xn--rombobjrn-67a.se> writes:
>
>> According to the manual 
>
> That same manual (assuming it is the gprbuild manual) has a section
> "command line", which says -largs will do what you want.

Yes, but Björn reports that -largs doesn't work if you're building a
dynamic library!

   $ gprbuild -Pbc -largs -Wl,-foo
   gprlib bc.lexch
   /opt/gnat-gpl-2011/bin/gcc \
   -dynamiclib -Wl,-flat_namespace -shared-libgcc \
   -o /Users/simon/sf/booch95/lib-release//libbc.dylib \
   -L/opt/gnat-gpl-2011/lib/gcc/x86_64-apple-darwin10.2.0/4.5.3/adalib/ \
   -lgnarl-2011 -lgnat-2011 [...]

vs

   $ gprbuild -Pbc --config=botched.cgpr
   gprlib bc.lexch
   /opt/gnat-gpl-2011/bin/g++ \
   -dynamiclib -Wl,-flat_namespace -shared-libgcc -Wl,-foo \
   -o /Users/simon/sf/booch95/lib-release//libbc.dylib \
   -L/opt/gnat-gpl-2011/lib/gcc/x86_64-apple-darwin10.2.0/4.5.3/adalib/ 
   -lgnarl-2011 -lgnat-2011 \
   [...]
   ld: unknown option: -foo
   collect2: ld returned 1 exit status
   gprlib: /opt/gnat-gpl-2011/bin/g++ execution error
   gprbuild: could not build library for project bc

Re: Controlling the linking of shared libraries

[Dmitry A. Kazakov]

On Mon, 25 Jul 2011 13:06:34 +0100, Simon Wright wrote:

> Stephen Leake <stephen_leake@stephe-leake.org> writes:
> 
>> Bj�rn Persson <bjorn@xn--rombobjrn-67a.se> writes:
>>
>>> According to the manual 
>>
>> That same manual (assuming it is the gprbuild manual) has a section
>> "command line", which says -largs will do what you want.
> 
> Yes, but Bj�rn reports that -largs doesn't work if you're building a
> dynamic library!

Yes, last time I checked it, I was forced to use two different gpr files
for building and using the library. Since I generated them anyway that was
not a big problem.

In general it is a murky issue how linker and other package attributes (or
how they call them) get propagated and composed upon "with"-ing, renaming
etc.

I wished AdaCore had documented that stuff, and gave thoughts too. E.g.
recently they changed the behavior of the attributes recognized as file
paths, so that path relative to the gpr file get broken.

Of course file paths should have been a type, distinct for "option",
distinct from "library name", distinct from String. But that is likely too
late now.

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

Re: Controlling the linking of shared libraries

[Björn Persson]

Stephen Leake wrote:

> Björn Persson <bjorn@xn--rombobjrn-67a.se> writes:
> 
>> According to the manual
> 
> That same manual (assuming it is the gprbuild manual) has a section
> "command line", which says -largs will do what you want.

It seems Gnatmake and GPRbuild haven't read the manual then.

-- 
Björn Persson
PGP key A88682FD

Re: Controlling the linking of shared libraries

[Stephen Leake]

Björn Persson <bjorn@xn--rombobjrn-67a.se> writes:

> Stephen Leake wrote:
>
>> Björn Persson <bjorn@xn--rombobjrn-67a.se> writes:
>> 
>>> According to the manual
>> 
>> That same manual (assuming it is the gprbuild manual) has a section
>> "command line", which says -largs will do what you want.
>
> It seems Gnatmake and GPRbuild haven't read the manual then.

:)

-- 
-- Stephe

Re: Controlling the linking of shared libraries

[Vincent]

On Jul 28, 3:18 am, Stephen Leake <stephen_le...@stephe-leake.org>
wrote:
> Björn Persson <bj...@xn--rombobjrn-67a.se> writes:
> > Stephen Leake wrote:
>
> >> Björn Persson <bj...@xn--rombobjrn-67a.se> writes:
>
> >>> According to the manual
>
> >> That same manual (assuming it is the gprbuild manual) has a section
> >> "command line", which says -largs will do what you want.
>
> > It seems Gnatmake and GPRbuild haven't read the manual then.
>
> :)

The manual has been updated:

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

--  Vincent

Re: Controlling the linking of shared libraries

[Vincent]

> Does anyone know how to pass command line parameters to Gnatmake and
> GPRbuild that they should forward to gcc when they invoke gcc as a linker to
> build a shared library? -largs seems to be used only when a program is
> linked. When a shared library is linked it seems to be ignored.

There are no command line options directly available for this.

You need to specify the following attributes in the shared library
project file.

Library_Options:
    This attribute may be used to specify additional switches (last
switches) when linking a shared library.

Leading_Library_Options:
    This attribute, that is taken into account only by gprbuild, may
be used to specified leading options (first switches) when linking a
shared library.

However, if you specify the value of one of these attribute with an
external_as_list, you will be able to specify library options with a
switch -X.

Example:

project Prj is
   for Library_Name use "prj";
   for Library_Dir  use "lib";
   for Library_Kind use "relocatable";
   for Library_Options use external_as_list ("LOPTS", ",");
end Prj;

$ gprbuild -P prj.gpr "-XLOPTS=-v,-v"

--  Vincent

Re: Controlling the linking of shared libraries

[Björn Persson]

Vincent wrote:

> However, if you specify the value of one of these attribute with an
> external_as_list, you will be able to specify library options with a
> switch -X.
> 
> Example:
> 
> project Prj is
>    for Library_Name use "prj";
>    for Library_Dir  use "lib";
>    for Library_Kind use "relocatable";
>    for Library_Options use external_as_list ("LOPTS", ",");
> end Prj;
> 
> $ gprbuild -P prj.gpr "-XLOPTS=-v,-v"

It would be great if everybody would make a habit of always including that 
in library project files, only with two changes: Use the established name 
"LDFLAGS", not "LOPTS", and use a space for separator, not a comma:

    for Library_Options use external_as_list ("LDFLAGS", " ");

That would make it easy for users and packagers to add any linker options 
they might need in their environment.

Writing and maintaining custom patches to add support for LDFLAGS to x 
packages in y distributions is not so great.

-- 
Björn Persson
PGP key A88682FD