You are not logged in.
Packages distributed via repositories have been compiled by the maintener/build system. Is there a way to tell exactly what compiler and linker flags were used by makepkg to build a particular binary package? I.e. what was in the builders 'makepkg.conf'? One way is to ask the maintainer, but is there a more solid way? Thanks for help.
The question comes from the experience of having a package installed but not being able to build it from the same PKGBUILD (due to nontrivial issues). The package must have been built successfully by *a* build system, so ideally one would want to replicate that build. The relevant differences I could think of are the compiler flags and to a lesser extent the hardware build platform.
Offline
This bug report looks relevant to your question.
EDIT: As does this one.
Last edited by clfarron4 (2015-01-12 00:00:16)
Claire is fine.
Problems? I have dysgraphia, so clear and concise please.
My public GPG key for package signing
My x86_64 package repository
Offline
It is not an answer to your question. But the packages installed in the build system can have an influence. Many packages autodetect the available libraries at build time and link accordingly (it is usually the job of the ./configure script). If you have not exactly the same set of libraries that can make a difference. Normally the package maintainer put explicit options to the configure script to make the build more robust but I don't think it is 100% guaranteed.
For your question, I assume the packages (in the official repositories) are build with a default makepkg.conf. Any change needed for a particular package is done in the PKGBUILD of the package (am I wrong?).
Last edited by olive (2015-01-12 10:13:10)
Offline
For your question, I assume the packages (in the official repositories) are build with a default makepkg.conf.
There are the Developer Wiki Guidlines for packaging which outline what is supposed to happen, but I wonder how much it answers the question.
Claire is fine.
Problems? I have dysgraphia, so clear and concise please.
My public GPG key for package signing
My x86_64 package repository
Offline
The question comes from the experience of having a package installed but not being able to build it from the same PKGBUILD (due to nontrivial issues). The package must have been built successfully by *a* build system, so ideally one would want to replicate that build. The relevant differences I could think of are the compiler flags and to a lesser extent the hardware build platform.
You should describe these supposedly non-trivial issues. I've never experienced what you describe in my years using Arch, nor have I ever heard it suggested that the famously vanilla Arch packages are built using some sort of unconventional compiler flags. I have heard multiple developers say using highly modified CPU optimizations and modified linking and such are mostly pointless, however. So I'd bet a week's pay that the build system uses vanilla GCC with the default settings. Why would the thing that actually builds Arch Linux be the one part of the Arch ecosystem that doesn't abide by the Arch standards? Why would only some packages have library linking problems and such when all packages are built on the same machine against the same library versions---and thus the conditions resulting in a failed build would be identical to those in a successful build? I could be wrong, but I think you're on the wrong track. The quickest way to find out is to describe what the real problem is, not what you imagine the solution to be.
Offline
To add to the off topic chatter: I believe that all of the packages in the official repos are built using the build scripts in the devtools package. These scripts use a clean-chroot and they use the default, /etc/makepkg.conf.... but that didn't directly answer the question the OP asked:
Is there a way to tell exactly what compiler and linker flags were used by makepkg to build a particular binary package?
Last edited by graysky (2015-01-12 16:40:10)
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline