* 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 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-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-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-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