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=0.5 required=5.0 tests=BAYES_00,FREEMAIL_FROM, PP_MIME_FAKE_ASCII_TEXT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,df7cea30536a085f X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,UTF8 Path: g2news2.google.com!news1.google.com!news4.google.com!feeder.news-service.com!aioe.org!.POSTED!not-for-mail From: anon@att.net Newsgroups: comp.lang.ada Subject: Re: Controlling the linking of shared libraries Date: Sun, 24 Jul 2011 18:03:43 +0000 (UTC) Organization: Aioe.org NNTP Server Message-ID: References: <98r7sbFs66U1@mid.individual.net> <992cqbFm9mU1@mid.individual.net> Reply-To: anon@anon.org NNTP-Posting-Host: 1aA45Dxph6fKEetsqU0GgA.user.speranza.aioe.org X-Complaints-To: abuse@aioe.org X-Notice: Filtered by postfilter v. 0.8.2 X-Newsreader: IBM NewsReader/2 2.0 Xref: g2news2.google.com comp.lang.ada:21307 Date: 2011-07-24T18:03:43+00:00 List-Id: 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 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