* Controlling the linking of shared libraries
@ 2011-07-21 18:01 Björn Persson
2011-07-21 23:14 ` anon
` (3 more replies)
0 siblings, 4 replies; 18+ messages in thread
From: Björn Persson @ 2011-07-21 18:01 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Controlling the linking of shared libraries
2011-07-21 18:01 Controlling the linking of shared libraries Björn Persson
@ 2011-07-21 23:14 ` anon
2011-07-22 6:36 ` Stephen Leake
` (2 subsequent siblings)
3 siblings, 0 replies; 18+ messages in thread
From: anon @ 2011-07-21 23:14 UTC (permalink / raw)
[-- 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Controlling the linking of shared libraries
2011-07-21 18:01 Controlling the linking of shared libraries Björn Persson
2011-07-21 23:14 ` anon
@ 2011-07-22 6:36 ` Stephen Leake
2011-07-22 23:50 ` Simon Wright
2011-07-24 11:08 ` Björn Persson
2011-07-26 9:20 ` Vincent
3 siblings, 1 reply; 18+ messages in thread
From: Stephen Leake @ 2011-07-22 6:36 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Controlling the linking of shared libraries
2011-07-22 6:36 ` Stephen Leake
@ 2011-07-22 23:50 ` Simon Wright
0 siblings, 0 replies; 18+ messages in thread
From: Simon Wright @ 2011-07-22 23:50 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Controlling the linking of shared libraries
2011-07-21 18:01 Controlling the linking of shared libraries Björn Persson
2011-07-21 23:14 ` anon
2011-07-22 6:36 ` Stephen Leake
@ 2011-07-24 11:08 ` Björn Persson
2011-07-24 18:03 ` anon
` (3 more replies)
2011-07-26 9:20 ` Vincent
3 siblings, 4 replies; 18+ messages in thread
From: Björn Persson @ 2011-07-24 11:08 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Controlling the linking of shared libraries
2011-07-24 11:08 ` Björn Persson
@ 2011-07-24 18:03 ` anon
2011-07-24 19:07 ` Project file version: was " anon
` (2 subsequent siblings)
3 siblings, 0 replies; 18+ messages in thread
From: anon @ 2011-07-24 18:03 UTC (permalink / raw)
[-- 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Project file version: was Re: Controlling the linking of shared libraries
2011-07-24 11:08 ` Björn Persson
2011-07-24 18:03 ` anon
@ 2011-07-24 19:07 ` anon
2011-07-24 19:13 ` Simon Wright
2011-07-25 11:43 ` Stephen Leake
3 siblings, 0 replies; 18+ messages in thread
From: anon @ 2011-07-24 19:07 UTC (permalink / raw)
[-- 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Controlling the linking of shared libraries
2011-07-24 11:08 ` Björn Persson
2011-07-24 18:03 ` anon
2011-07-24 19:07 ` Project file version: was " anon
@ 2011-07-24 19:13 ` Simon Wright
2011-07-25 1:05 ` anon
2011-07-26 8:18 ` Björn Persson
2011-07-25 11:43 ` Stephen Leake
3 siblings, 2 replies; 18+ messages in thread
From: Simon Wright @ 2011-07-24 19:13 UTC (permalink / raw)
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!)
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Controlling the linking of shared libraries
2011-07-24 19:13 ` Simon Wright
@ 2011-07-25 1:05 ` anon
2011-07-26 8:18 ` Björn Persson
1 sibling, 0 replies; 18+ messages in thread
From: anon @ 2011-07-25 1:05 UTC (permalink / raw)
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!)
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Controlling the linking of shared libraries
2011-07-24 11:08 ` Björn Persson
` (2 preceding siblings ...)
2011-07-24 19:13 ` Simon Wright
@ 2011-07-25 11:43 ` Stephen Leake
2011-07-25 12:06 ` Simon Wright
2011-07-26 8:19 ` Björn Persson
3 siblings, 2 replies; 18+ messages in thread
From: Stephen Leake @ 2011-07-25 11:43 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Controlling the linking of shared libraries
2011-07-25 11:43 ` Stephen Leake
@ 2011-07-25 12:06 ` Simon Wright
2011-07-25 12:29 ` Dmitry A. Kazakov
2011-07-26 8:19 ` Björn Persson
1 sibling, 1 reply; 18+ messages in thread
From: Simon Wright @ 2011-07-25 12:06 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Controlling the linking of shared libraries
2011-07-25 12:06 ` Simon Wright
@ 2011-07-25 12:29 ` Dmitry A. Kazakov
0 siblings, 0 replies; 18+ messages in thread
From: Dmitry A. Kazakov @ 2011-07-25 12:29 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Controlling the linking of shared libraries
2011-07-24 19:13 ` Simon Wright
2011-07-25 1:05 ` anon
@ 2011-07-26 8:18 ` Björn Persson
1 sibling, 0 replies; 18+ messages in thread
From: Björn Persson @ 2011-07-26 8:18 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Controlling the linking of shared libraries
2011-07-25 11:43 ` Stephen Leake
2011-07-25 12:06 ` Simon Wright
@ 2011-07-26 8:19 ` Björn Persson
2011-07-28 10:18 ` Stephen Leake
1 sibling, 1 reply; 18+ messages in thread
From: Björn Persson @ 2011-07-26 8:19 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Controlling the linking of shared libraries
2011-07-21 18:01 Controlling the linking of shared libraries Björn Persson
` (2 preceding siblings ...)
2011-07-24 11:08 ` Björn Persson
@ 2011-07-26 9:20 ` Vincent
2011-07-26 23:37 ` Björn Persson
3 siblings, 1 reply; 18+ messages in thread
From: Vincent @ 2011-07-26 9:20 UTC (permalink / raw)
> 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Controlling the linking of shared libraries
2011-07-26 9:20 ` Vincent
@ 2011-07-26 23:37 ` Björn Persson
0 siblings, 0 replies; 18+ messages in thread
From: Björn Persson @ 2011-07-26 23:37 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Controlling the linking of shared libraries
2011-07-26 8:19 ` Björn Persson
@ 2011-07-28 10:18 ` Stephen Leake
2011-07-29 22:47 ` Vincent
0 siblings, 1 reply; 18+ messages in thread
From: Stephen Leake @ 2011-07-28 10:18 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Controlling the linking of shared libraries
2011-07-28 10:18 ` Stephen Leake
@ 2011-07-29 22:47 ` Vincent
0 siblings, 0 replies; 18+ messages in thread
From: Vincent @ 2011-07-29 22:47 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2011-07-29 22:47 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-07-21 18:01 Controlling the linking of shared libraries Björn Persson
2011-07-21 23:14 ` anon
2011-07-22 6:36 ` Stephen Leake
2011-07-22 23:50 ` Simon Wright
2011-07-24 11:08 ` Björn Persson
2011-07-24 18:03 ` anon
2011-07-24 19:07 ` Project file version: was " anon
2011-07-24 19:13 ` Simon Wright
2011-07-25 1:05 ` anon
2011-07-26 8:18 ` Björn Persson
2011-07-25 11:43 ` Stephen Leake
2011-07-25 12:06 ` Simon Wright
2011-07-25 12:29 ` Dmitry A. Kazakov
2011-07-26 8:19 ` Björn Persson
2011-07-28 10:18 ` Stephen Leake
2011-07-29 22:47 ` Vincent
2011-07-26 9:20 ` Vincent
2011-07-26 23:37 ` Björn Persson
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox