6

I know that apt-get source <package_name> gives you the source package. It contains a debian folder with a file called rules. If I understand it correctly, this file describes how the source package can be transformed into a .deb package, including which compiler flags should be used.

Two questions:

  1. How do I get the compiler flags that are actually used? Is it necessary to run make -n (if this is even possible) or can I get them somehow by parsing the document(s) ?
  2. Given the case of a source package from an official repository. Are the compiler flags a 100% determined by the rules file or do they depend on the system that the .deb creation is done on? Do I need to 'mirror' the official build system to get to the same flags that were used in the official .deb building process? How can I do this?

I learned here, that debian does not have an official policy which compiler flags are used for the .deb-packed binaries.

4

The compiler flags used are a function of

  • the debian/rules file,
  • the package's build files (since the upstream author may specify flags there too),
  • the build system used (dh, cdbs etc.),
  • the default compiler settings.

To see the flags used you effectively need to at least compile the package:

debian/rules build

Trying things like

debian/rules -n

generally won't take you very far; for instance on a dh-based package it will just say

dh build

or something similar; asking dh to show what that would do (with --no-act) will produce

dh_testdir
dh_auto_configure
dh_auto_build

and so on.

There is no fool-proof, easy-to-explain way to determine the build flags by reading debian/rules; you can get some idea by looking for flags set there, and also (where appropriate) by looking for options for dpkg-buildflags (such as DEB_BUILD_MAINT_OPTIONS) and running that. For many packages the easiest way to see what flags were used is to look at the build logs for the packages shipped in the archives, starting from https://buildd.debian.org. For example the logs for coreutils on i386 show that the flags used were -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector-strong -Wformat -Werror=format-security for compilation, and -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wl,--as-needed -Wl,-z,relro for linking (thanks to Faheem Mitha for pointing out the latter!).

  • @StephenKitt You write: "To see the flags used you effectively need to at least compile the package: debian/rules build." Can I somehow make sure that this results in the same flags being used as in the official build? Using a vanilla debian of the same version? – stackoverflowwww Apr 6 '16 at 12:28
  • @StephenKitt: I like your suggestion to look at the logs of the official build server. Yet, they are not always there, e.g. for openssl, see buildd.debian.org/status/package.php?p=openssl&suite=sid , there is just an 'old' log from 2011 for the amd64 build. Is this a bug? – stackoverflowwww Apr 6 '16 at 12:31
  • @stackoverflowwww, regarding the availability of logs, if the maintainer uploads binaries directly then there won't be any logs on the server unfortunately; but the flags should be the same across a number of architectures, certainly amd64 and i386 in the vast majority of cases, so if either is missing you can look at the other. – Stephen Kitt Apr 6 '16 at 13:08
  • 1
    (For the really curious, Dpkg/Vendor/Debian.pm gives the architecture-related variations in build flags.) – Stephen Kitt Apr 6 '16 at 13:09
  • 2
    @stackoverflowwww, making sure you use the same build flags as the official build is quite difficult, since the official package will have used whatever flags were provided at the time it was built, in unstable in most cases, possibly many years ago. If you build in vanilla unstable now you can be sure you'll get the same flags as would be used for a new official build; likewise in testing or stable for an official build in the relevant backports suite. You can do this with pbuilder even in derivative distributions – Stephen Kitt Apr 6 '16 at 13:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.