Can make manually but not via PKGBUILD

Salkay · 2014-12-10 05:18:25

I'm trying to install exonerate from the AUR, where it is now an orphan. When I run makepkg -s, it fails.

The PKGBUILD looked a little bit funny (just old?) so I attempted to expand and modify the build section as follows.

build() {
  cd "$pkgname-$pkgver"
  ./configure --prefix=/usr
  make 
}
check() {
  cd "$pkgname-$pkgver"
  make check
}
package() {
  cd "$pkgname-$pkgver"
  make DESTDIR="$pkgdir/" install
}

This did not help.

Further, if I download the upstream source files I can run `./configure` then `make` fine, which seeemed to imply to me that the BUILDPKG should work fine. Is there a way to install this via pacman?

Scimmia · 2014-12-10 06:08:58

Without looking into it too deeply, try adding options=('!buildflags') to the PKGBUILD and see if it builds. If it does, the problem is being triggered by one of the CFLAGS/CPPFLAGS/CXXFLAGS/LDFLAGS in makepkg.conf.

Salkay · 2014-12-10 07:40:46

Oh wow, perfect! makepkg -s works fine now. Can I ask two follow-up questions?

1) Is this option okay for a final PKGBUILD? Someone here says "I doubt this option would ever be used in a "final" PKGBUILD, but it is very useful when trying to figure out build issues."
2) Given that I'm new to creating PKGBUILDs, is there ever a situation where I can mess a system up with an incorrect PKGBUILD? Of course there must be, but specifically, I presume that pacman will keep track of all files I install? Hence, would it ask if overwriting already existing files? And it should always allow packages to uninstall cleanly?

Thanks for your help.

Scimmia · 2014-12-10 15:36:00

1. You could, but it's kind of heavy handed. You should mess with the variables and see exactly what's causing the problem. You can then modify the variables before running make.
2. Pacman will keep track of whatever it installs and will refuse to install the package if the files already exist. The install script is where the real danger is. It can do whatever it wants.

Salkay · 2014-12-10 22:45:27

Scimmia wrote:

1. You could, but it's kind of heavy handed. You should mess with the variables and see exactly what's causing the problem. You can then modify the variables before running make.

I'm having a bit of trouble finding exactly how to do this. Would you have a reference that I could read?

Also, you say "heavy handed", but if this builds okay, would the resulting compiled file be essentially the same as the files if I tweaked the variables more precisely? What advantage would there be in defining variables more precisely?

Scimmia wrote:

2. Pacman will keep track of whatever it installs and will refuse to install the package if the files already exist. The install script is where the real danger is. It can do whatever it wants.

Thank you. This is good to know.

Scimmia · 2014-12-10 23:47:51

Salkay wrote:

Scimmia wrote:
1. You could, but it's kind of heavy handed. You should mess with the variables and see exactly what's causing the problem. You can then modify the variables before running make.
I'm having a bit of trouble finding exactly how to do this. Would you have a reference that I could read?
Also, you say "heavy handed", but if this builds okay, would the resulting compiled file be essentially the same as the files if I tweaked the variables more precisely? What advantage would there be in defining variables more precisely?

I don't have a reference. You can do it by changing the variables in makepkg.conf, but what I would do is to leave !buildflags in the options, then copy the variable definitions into the build function in the PKGBUILD. The defaults would look like this:

export CPPFLAGS="-D_FORTIFY_SOURCE=2"
export CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong --param=ssp-buffer-size=4"
export CXXFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong --param=ssp-buffer-size=4"
export LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro"

That should fail to build. You can then comment out each of them to see which one is causing the failure. Once you know that, you can remove the flags one at a time to figure out exactly which one is causing the failure.

As to what they do, you can check the gcc documentation. Google each of the flags and it should point you to the right part.

Salkay · 2014-12-11 00:41:50

Thanks again. So presumably these flags are just to optimise and speed up the build?

In the end, I found I could build fine if I removed the LD flag "--as-needed". Hence is the final solution to include "!buildflags", then manually add back the required flags? i.e.

pkgname=exonerate
pkgver=2.2.0
origver=2.2.0
pkgrel=1
pkgdesc="A general purpose tool for biological sequence comparison"
arch=('i686' 'x86_64')
url="http://www.ebi.ac.uk/~guy/exonerate"
license=('GPL3')
depends=('glib2' 'pkgconfig')
source=($url/$pkgname-$pkgver.tar.gz)
md5sums=('ad3f7fc413376201c4631687b2e0ae89')
makedepends=('gcc')
options=('!buildflags')
build() {
  export CPPFLAGS="-D_FORTIFY_SOURCE=2"
  export CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong --param=ssp-buffer-size=4"
  export CXXFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong --param=ssp-buffer-size=4"
  export LDFLAGS="-Wl,-O1,--sort-common,-z,relro"
  cd "$pkgname-$pkgver"
  ./configure --prefix=/usr
  make 
}
check() {
  cd "$pkgname-$pkgver"
  make check
}
package() {
  cd "$pkgname-$pkgver"
  make DESTDIR="$pkgdir/" install
}

I'm planning to release to AUR when it's sorted.

Trilby · 2014-12-11 00:52:50

No, you should not interfere with users' settings any more than needed to get the package to build. Did you read the man page as recommended to learn what that flag does? Do not use the !buildflags option. Only add the one flag you need: --no-as-needed.

Salkay · 2014-12-11 01:11:00

I'm not sure which man page to read. I couldn't find anything in `man makepkg`. I'm not sure that Scimmia recommended a man page, but I might be confused. I did have a read through this page, but I don't think any of the solutions there apply to this situation.

To have a minimal effect on users' settings, should I just append the flag? This seems to work. i.e. in the build block:

export LDFLAGS="${LDFLAGS},--no-as-needed"

Arch Linux

#1 2014-12-10 05:18:25

Can make manually but not via PKGBUILD

#2 2014-12-10 06:08:58

Re: Can make manually but not via PKGBUILD

#3 2014-12-10 07:40:46

Re: Can make manually but not via PKGBUILD

#4 2014-12-10 15:36:00

Re: Can make manually but not via PKGBUILD

#5 2014-12-10 22:45:27

Re: Can make manually but not via PKGBUILD

#6 2014-12-10 23:47:51

Re: Can make manually but not via PKGBUILD

#7 2014-12-11 00:41:50

Re: Can make manually but not via PKGBUILD

#8 2014-12-11 00:52:50

Re: Can make manually but not via PKGBUILD

#9 2014-12-11 01:11:00

Re: Can make manually but not via PKGBUILD

Board footer