FS#37104 - [netsurf] PKGBUILD does not build (undefined reference to `webp_init')
Attached to Project:
Community Packages
Opened by Nicolas Boichat (drinkcat) - Saturday, 28 September 2013, 04:53 GMT
Last edited by Alexander F. Rødseth (xyproto) - Wednesday, 23 October 2013, 12:17 GMT
Opened by Nicolas Boichat (drinkcat) - Saturday, 28 September 2013, 04:53 GMT
Last edited by Alexander F. Rødseth (xyproto) - Wednesday, 23 October 2013, 12:17 GMT
|
Details
Description:
netsurf-3.0-4 PKGBUILD from SVN fails to build (undefined reference to `webp_init'). Steps to reproduce: 1. Fetch PKGBUILD and netsurf.install from https://projects.archlinux.org/svntogit/community.git/tree/trunk?h=packages/netsurf . 2. Run makepkg -s . It fails with: ==> Entering fakeroot environment... ==> Starting package()... ... M.CONFIG: WebP (libwebp) disabled (NETSURF_USE_WEBP := NO) ... LINK: nsgtk build-Linux-gtk/image_image.o: In function `image_init': /home/nicolas/dev/chromebook/tmp/netsurf/src/netsurf-3.0/image/image.c:112: undefined reference to `webp_init' Full build log attached. I put together a patch that fixes the problem. I do not know what was the original intent setting 'NETSURF_USE_MOZILLA_JS=YES', but this flag is not a valid configuration flag anymore. |
This task depends upon
Closed by Alexander F. Rødseth (xyproto)
Wednesday, 23 October 2013, 12:17 GMT
Reason for closing: Works for me
Additional comments about closing: Works for everyone but the bug reporter. Feel free to reopen if there is new information.
Wednesday, 23 October 2013, 12:17 GMT
Reason for closing: Works for me
Additional comments about closing: Works for everyone but the bug reporter. Feel free to reopen if there is new information.
$ 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.
$ 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.
% 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
$ diff PKGBUILD ../../../PKGBUILD
1c1
< # $Id: PKGBUILD 95886 2013-08-18 11:31:23Z arodseth $
---
> # $Id$
drinkcat, something wrong with the mirror you're getting your deps from, maybe?
# 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
md5sums are the same here as what you posted.
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?
netsurf-3.0-4-x86_64-package.... (2.7 KiB)
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...)
netsurf-3.0-4-x86_64-build.log (436.8 KiB)
netsurf-3.0-4-x86_64-package.... (98.9 KiB)
netsurf-3.0-4-x86_64-package_... (15.1 KiB)
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?
[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.
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.