Arch Linux

Unable to reproduce, the netsurf PKGBUILD builds fine here. Do you have any netsurf-related libraries installed from AUR?

Reproduced in a fresh chroot, here is a step-by-step guide. You will need arch-install-scripts for pacstrap.

$ mkdir arch
$ sudo pacstrap -d arch
$ cd arch
$ sudo systemd-nspawn

=== Everything below is inside the chroot >>>
# pacman -S base-devel

# useradd -m test
# echo "test ALL = NOPASSWD:/usr/bin/pacman" > /etc/sudoers.d/99-aur-pacman
# su test
$ cd
$ curl 'https://projects.archlinux.org/svntogit/community.git/plain/trunk/PKGBUILD?h=packages/netsurf' -o PKGBUILD
$ curl 'https://projects.archlinux.org/svntogit/community.git/plain/trunk/netsurf.install?h=packages/netsurf' -o netsurf.install
$ md5sum PKGBUILD netsurf.install
(Do we really have the same PKGBUILD?)
c13a4645bdcef3777f1f63fdbc8bc27b PKGBUILD
f6a8b694e9e3b5981c6a18932fa0112f netsurf.install
$ makepkg -s
Fails with same error:
LINK: nsgtk
build-Linux-gtk/image_image.o: In function `image_init':
/home/test/src/netsurf-3.0/image/image.c:112: undefined reference to `webp_init'
collect2: error: ld returned 1 exit status
make: *** [nsgtk] Error 1
==> ERROR: A failure occurred in package().
Aborting...

$ curl 'https://bugs.archlinux.org/task/37104?getfile=11032' -o netsurf-3.0.4.patch
$ patch -p1 < netsurf-3.0.4.patch
$ rm -rf src pkg
$ makepkg -s
Succeeds.

Maybe you have something on your install that makes it work...

Thanks.

Unable to reproduce, it builds fine in a chroot here. Try building with extra-x86_64-build from the devtools package.

Ok, so I tried again:
$ sudo rm -rf /var/lib/archbuild/ (just to make sure I start fresh)
$ curl 'https://projects.archlinux.org/svntogit/community.git/plain/trunk/PKGBUILD?h=packages/netsurf' -o PKGBUILD
$ curl 'https://projects.archlinux.org/svntogit/community.git/plain/trunk/netsurf.install?h=packages/netsurf' -o netsurf.install
$ md5sum PKGBUILD netsurf.install
c13a4645bdcef3777f1f63fdbc8bc27b PKGBUILD
f6a8b694e9e3b5981c6a18932fa0112f netsurf.install
$ sudo extra-x86_64-build
...
LINK: nsgtk
build-Linux-gtk/image_image.o: In function `image_init':
/build/netsurf/src/netsurf-3.0/image/image.c:112: undefined reference to `webp_init'
collect2: error: ld returned 1 exit status
make: *** [nsgtk] Error 1
==> ERROR: A failure occurred in package().
Aborting...
==> ERROR: Build failed, check /var/lib/archbuild/extra-x86_64/nicolas/build

Are you 100% sure that we are using the same PKGBUILD?

Just to clarify, my reason for fixing this PKGBUILD was to get netsurf to work with Archlinux ARM (see https://github.com/archlinuxarm/PKGBUILDs/issues/574). I'm just trying to understand why I need to patch the PKGBUILD to get it to work (both on my x86_64 and ARM machines: this is not ARM specific), while you are able to build the package just fine.

It appears to be a different PKGBUILD file.

% svn checkout --depth=empty svn://svn.archlinux.org/community
Checked out revision 97761.
% cd community
% svn up -q netsurf
% md5sum netsurf/trunk/PKGBUILD
2c0d243c3f1ef4d9a12f88045a61ca6e netsurf/trunk/PKGBUILD

The only difference between the PKGBUILD in SVN and git is the $Id line:

$ diff PKGBUILD ../../../PKGBUILD
1c1
< # $Id: PKGBUILD 95886 2013-08-18 11:31:23Z arodseth $
---
> # $Id$

Just tried building on another computer and it builds fine there too. I'll ask someone else to test it as well.

I just grabbed the files from svntogit, built just fine in a clean chroot for both x86_64 and i686.

drinkcat, something wrong with the mirror you're getting your deps from, maybe?

Huh, weird...

# Make sure I refetch everything:
yes | sudo pacman -Scc

Change mirror to http://mirrors.kernel.org/archlinux/$repo/os/$arch (I was using http://mirror.nus.edu.sg/archlinux/$repo/os/$arch, but it is not out of sync)

pacman -Syu to make sure everything is up to date (it was).

Same steps as before (remove /var/lib/archbuild/, refetch the PKGBUILD: still the same md5sum)

sudo extra-x86_64-build
=> same error

sudo testing-x86_64-build
=> same error

Looking at your build log, it's rebuilding content/fetchers/about.c and desktop/version.c in the package function, which then makes it relink. This is what's causing the problem, mine doesn't do that. I'm guessing that for some reason it thinks that those files changed. Something strange with your filesystem?

md5sums are the same here as what you posted.

Double post, sorry.

Well, that's ext4, nothing fancy... I retried in a tmpfs, same result.

The issue here is that utils/testament.h is regenerated. That causes the 2 other C files to be rebuild, then nsgtk and the failure, because the build configuration has changed (NETSURF_USE_MOZJS := NO), while it was YES in the actual build (this is what I'm addressing in my patch: I make the configuration consistent).

Now utils/git-testament.pl, which generates utils/testament.h, is smart, and only updates that file if there is an MD5 mismatch. Added this line in the PKGBUILD/package() for testing:
cp utils/testament.h utils/testament.h.orig

$ sudo extra-x86_64-build

Now, $ diff testament.h.orig testament.h
11c11
< #define NETSURF_REVISION_TESTAMENT "80862964d331ebcb185c325f4342a3eb"
---
> #define NETSURF_REVISION_TESTAMENT "bd7347fa708a8850b12f9ce55e594c8a"
14c14
< * MD5:80862964d331ebcb185c325f4342a3eb
---
> * MD5:bd7347fa708a8850b12f9ce55e594c8a
18,19c18,19
< #define USERNAME "nobody"
< #define GECOS "nobody"
---
> #define USERNAME "root"
> #define GECOS "root"

See what is happening... user is changing (nobody for the build() part, root for package()).

Exactly the same results with "su -", followed by "extra-x86_64-build".

If you do a "normal" makepkg -s, as user, you get something similar:
11c11
< #define NETSURF_REVISION_TESTAMENT "ccbc6089b63fccba1a6c1c02857e22e0"
---
> #define NETSURF_REVISION_TESTAMENT "30602513db599d919226245a365469dd"
14c14
< * MD5:ccbc6089b63fccba1a6c1c02857e22e0
---
> * MD5:30602513db599d919226245a365469dd
18,19c18,19
< #define USERNAME "nicolas"
< #define GECOS ""
---
> #define USERNAME "root"
> #define GECOS "root"

Now if I do something that I'm not supposed to do:
$ sudo makepkg -s --asroot

I can build the package just fine. But, I'm not supposed to compile packages as root, right?

Mine regenerates testament.h as well, but still doesn't rebuild those C files. Attached my build logs so you can see what I mean.

Ok, so I modified a bit the PKGBUILD to throw more information (add -d parameter to make, and print the env, not sure if relevant).

PKGBUILD: modified PKGBUILD
netsurf-3.0-4-x86_64-build.log: build log
netsurf-3.0-4-x86_64-package.log.bz2: package log. Too big (4MB), so I had to compress it.
netsurf-3.0-4-x86_64-package_snips.log contains snips of the file above, that I think are interesting. I don't understand why the 2 C files are not rebuilt in your case (after all they depend on utils/testament.h...)

If nobody else is able to reproduce this (building with extra-x86_64-build) it seems like there is a problem with your system. Do you have access to another Arch Linux installation to try this on?

To investigate further, one of these guesses may perhaps, maybe, lead somewhere:
* What are the ext4 mount options in /etc/fstab? Do you have "noatime"? Does it work without it?
* Have you installed a different linker? Are repositories like [community-testing] enabled in /etc/pacman.conf?
* When listing foregein packages with pacman -Qm, is it possible that any one of those could interfere with the build process?
* Does it work if you create an empty large file, format it as say, XFS, loop mount it and build the package there?

Still not working, both on an x86_64 machine (ext4 or tmpfs, as mentionned before), and a ARM machine. I will retry in a QEMU.

[community-testing] is not enabled, but anyway extra-x86_64-build rebuilds a fresh chroot, right? I also tried with testing-x86_64-build, same results.

Also tried to stop chrony, in case the NTP client skews the clock.

Weirdness. Please let us know if someone else are able to reproduce the issue.

Allan McRae tried building it, and he was not able to reproduce the issue either.

Closing this bug, but please re-open if it if you can find anyone else that are also able to reproduce the issue.

Without further information, I don't see what we could possibly do about this.