From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,df7cea30536a085f X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,UTF8 Path: g2news2.google.com!news2.google.com!news4.google.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: =?UTF-8?B?QmrDtnJu?= Persson Newsgroups: comp.lang.ada Subject: Re: Controlling the linking of shared libraries Followup-To: comp.lang.ada Date: Sun, 24 Jul 2011 13:08:59 +0200 Message-ID: <992cqbFm9mU1@mid.individual.net> References: <98r7sbFs66U1@mid.individual.net> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8Bit X-Trace: individual.net oHO4cUkOCg3OOwTjyVTEpAEtP2LAV2ClcNn0CVZLPApF9iYBpu Cancel-Lock: sha1:wIA68vtu4OcRqKwneMSLqxaezJs= User-Agent: KNode/4.4.11 Xref: g2news2.google.com comp.lang.ada:21303 Date: 2011-07-24T13:08:59+02:00 List-Id: 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