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

[anon@att.net]

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