comp.lang.ada
 help / color / mirror / Atom feed
From: anon@att.net
Subject: Re: Controlling the linking of shared libraries
Date: Sun, 24 Jul 2011 18:03:43 +0000 (UTC)
Date: 2011-07-24T18:03:43+00:00	[thread overview]
Message-ID: <j0hmpt$kv0$1@speranza.aioe.org> (raw)
In-Reply-To: 992cqbFm9mU1@mid.individual.net

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




  reply	other threads:[~2011-07-24 18:03 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox