[Solved] orbit2 fails to build due to missing file

PhotonX · 2018-09-27 06:21:38

Hello Community,

I maintain the Shutter AUR package and many of its dependencies, one of them is orbit2. Yesterday I got a bug report that building orbit2 fails with

libtool: link: gcc -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt -Werror-implicit-function-declaration -Wl,-O1 -Wl,--sort-common -Wl,--as-needed -Wl,-z -Wl,relro -Wl,-z -Wl,now -o .libs/orbit-name-server-2 boot.o -Wl,--export-dynamic -pthread libname-server-2.a ../../../src/orb/.libs/libORBit-2.so ./.libs/libORBitCosNaming-2.so /tmp/yaourt-tmp-ronj/aur-orbit2/src/ORBit2-2.14.19/src/orb/.libs/libORBit-2.so -lm -lgobject-2.0 -lgthread-2.0 -lgmodule-2.0 -lglib-2.0 -pthread 
gcc: error: libname-server-2.a: No such file or directory

I can reproduce this error with a clean build folder and using makepkg rather than an AUR helper. Google only finds this thread: https://forums.gentoo.org/viewtopic.php?t=156408 So for now I followed the proposal described there and included the missing file libname-server-2.a as source of the orbit2 PKGBUILD but this is just a temporary fix. This file is part of orbit2 and should be generated when orbit2 is compiled, but looks like it is not being generated and I have a hard time figuring out what goes wrong here - obviously some problem already appears earlier, before gcc realizes that the file is missing and spits an error.

Thanks for any input on where to start digging!

PhotonX

edit: I forgot to mention that the building process used to work for a long time, looks like some gcc or libtool update led to the problem but that's just a guess.

Last edited by PhotonX (2018-09-28 11:10:24)

Scimmia · 2018-09-27 06:33:40

Does it work with make -j1?

PhotonX · 2018-09-27 07:05:30

Unfortunately, no change with -j1.

Lone_Wolf · 2018-09-27 08:20:50

man makepkg.conf wrote:

staticlibs
Leave static library (.a) files in packages. Specify !staticlibs to remove them, if they have a shared counterpart.

pacman 5.1.1 default makepkg.conf settings

OPTIONS=(strip docs !libtool !staticlibs emptydirs zipman purge !debug)

Try adding options=(staticlibs) to the PKGBUILD

PhotonX · 2018-09-27 09:01:27

Actually, this is already set (the PKGBUILD originated from the official repositories but has been dropped at some point, so I uploaded its PKGBUILD to the AUR back then). But now I realize that another option which was set is "!makeflags". I removed it (such that the -j1 make option advised by Scimmia is applied) and it now builds fine.

Thanks for the input to both of you!

Thomas Krishan · 2018-09-27 11:46:18

I'm lost... This is still not working for me. When I try to install shutter, the orbit2 version 2.14.19-5 flags there error:
gcc: error: libname-server-2.a: No such file or directory.

Where is hte "!makeflags" option set?

Thanks for any help and apologies if I am missing something obvious.

PhotonX · 2018-09-27 12:19:22

In line 13 of https://aur.archlinux.org/cgit/aur.git/ … orbit2#n13 it is now (in 2.14.19-5) NOT set. The building works for me, I just rechecked. Could you please try building -5 in a clean build folder using makepkg?

vstuart · 2018-09-27 15:45:03

orbit2 version 2.14.19-5:

rm -fR ~/.cache/pacaur/orbit2/
pacaur -Syu
...
gcc: error: libname-server-2.a: No such file or directory
...
:: failed to verify integrity or prepare orbit2 package

Ditto re:
yaourt -Syua

------------------------------------------
Update -- more info:

$ pwd
/home/victoria
$ which gcc; gcc --version
/usr/bin/gcc
gcc (GCC) 8.2.1 20180831
...

$ find . -name "*libname-server-2.a"
$ find / -path /mnt -prune -o -name "*libname-server-2.a" -print
/usr/lib/libname-server-2.a

Last edited by vstuart (2018-09-27 19:07:14)

PhotonX · 2018-09-27 17:30:02

Could you please post your /etc/makepkg.conf? Since in -5 I removed the "no makeflags" option, it uses the makeflags from this file which might differ from machine to machin - this would explain why it now builds fine for some users and doesn't for others.

eschwartz · 2018-09-27 17:54:22

The !makeflags option causes (caused) user-defined settings in makepkg.conf e.g. MAKEFLAGS=-j$(nproc) to be ignored. It most certainly does not prevent make -j1 from manually applying, and in fact you *want* makeflags to be ignored in this case.

You also/alternatively want make -j1 to be hardcoded... but currently you only do this in make install during package(), not for make during build().

This is obviously not going to work...

...

Aside: don't upload large binary blobs to the AUR, don't follow terrible advice from 2004, don't hastily upload questionable fixes without first taking a deep breath and asking for advice.

If you ever feel tempted to check a large binary blob into git and upload it to the AUR again, please don't, we don't have unlimited storage and we already set max filesize limits for this exact reason.

vstuart · 2018-09-27 18:06:58

@PhotonX:

$ cat /etc/makepkg.conf | grep -i -C2 "flags"

#########################################################################
# ARCHITECTURE, COMPILE FLAGS
#########################################################################
#
--
CHOST="x86_64-pc-linux-gnu"

#-- Compiler and Linker Flags
CPPFLAGS="-D_FORTIFY_SOURCE=2"
CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt"
CXXFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt"
LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now"
#-- Make Flags: change this for DistCC/SMP systems
#MAKEFLAGS="-j2"
#-- Debugging flags
DEBUG_CFLAGS="-g -fvar-tracking-assignments"
DEBUG_CXXFLAGS="-g -fvar-tracking-assignments"

#########################################################################
--
BUILDENV=(!distcc color !ccache check !sign)
#
#-- If using DistCC, your MAKEFLAGS will also need modification. In addition,
#-- specify a space-delimited list of hosts running in the DistCC cluster.
#DISTCC_HOSTS=""
--
#-- zipman: Compress manual (man and info) pages in MAN_DIRS with gzip
#-- purge: Remove files specified by PURGE_TARGETS
#-- debug: Add debugging flags as specified in DEBUG_* variables
#
OPTIONS=(strip docs !libtool !staticlibs emptydirs zipman purge !debug)

PhotonX · 2018-09-27 18:07:38

@Eschwartz: Well, I wanted to have a fix as fast as possible, I was well aware of the fact that such a fix could be only temporary. Concerning the filesize, I see the problem but I hope, that it is not that bad in this case as the file is just 35kb.

Thanks for the hint concerning the -j1 option, I guess, I was tired yesterday... I will test a corrected version asap and report back.

edit: I tested but unfortunately this (-j1 option at the correct make command, makeflags deactivated) still gives an error:

# $Id$
# Maintainer: PhotonX <photon89@googlemail.com>
# Contributor: Jan de Groot <jan@archlinux.org>

pkgname=orbit2
pkgver=2.14.19
pkgrel=6
pkgdesc="Thin/fast CORBA ORB"
arch=('i686' 'x86_64')
license=('LGPL' 'GPL')
depends=('libidl2')
makedepends=('gtk-doc')
options=('staticlibs' '!makeflags')
url="https://projects.gnome.org/ORBit2/"
source=(https://download.gnome.org/sources/ORBit2/2.14/ORBit2-${pkgver}.tar.bz2
        git-fixes.patch)
sha256sums=('55c900a905482992730f575f3eef34d50bda717c197c97c08fa5a6eafd857550'
            '7f145ed715d5a1d7f6ccf1e9bcce6a6a584a6b125845a84a3d69bfe30b0d6e04')

prepare() {
  cd ORBit2-$pkgver
  patch -Np1 -i ../git-fixes.patch
}

build() {
  cd ORBit2-$pkgver
  autoreconf -fi
  ./configure --prefix=/usr --disable-static
  make -j1
}

package() {
  cd ORBit2-$pkgver
  make DESTDIR="${pkgdir}" install
}

edit2: Interestingly, my makepkg.conf from a machine where building succeeds without the "!makeflags" option looks like this:

#
# /etc/makepkg.conf
#

#########################################################################
# SOURCE ACQUISITION
#########################################################################
#
#-- The download utilities that makepkg should use to acquire sources
#  Format: 'protocol::agent'
DLAGENTS=('ftp::/usr/bin/curl -fC - --ftp-pasv --retry 3 --retry-delay 3 -o %o %u'
          'http::/usr/bin/curl -fLC - --retry 3 --retry-delay 3 -o %o %u'
          'https::/usr/bin/curl -fLC - --retry 3 --retry-delay 3 -o %o %u'
          'rsync::/usr/bin/rsync --no-motd -z %u %o'
          'scp::/usr/bin/scp -C %u %o')

# Other common tools:
# /usr/bin/snarf
# /usr/bin/lftpget -c
# /usr/bin/wget

#-- The package required by makepkg to download VCS sources
#  Format: 'protocol::package'
VCSCLIENTS=('bzr::bzr'
            'git::git'
            'hg::mercurial'
            'svn::subversion')

#########################################################################
# ARCHITECTURE, COMPILE FLAGS
#########################################################################
#
CARCH="x86_64"
CHOST="x86_64-pc-linux-gnu"

#-- Compiler and Linker Flags
# -march (or -mcpu) builds exclusively for an architecture
# -mtune optimizes for an architecture, but builds for whole processor family
CPPFLAGS="-D_FORTIFY_SOURCE=2"
CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong"
CXXFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong"
LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro"
#-- Make Flags: change this for DistCC/SMP systems
MAKEFLAGS="-j5"
#-- Debugging flags
DEBUG_CFLAGS="-g -fvar-tracking-assignments"
DEBUG_CXXFLAGS="-g -fvar-tracking-assignments"

#########################################################################
# BUILD ENVIRONMENT
#########################################################################
#
# Defaults: BUILDENV=(!distcc color !ccache check !sign)
#  A negated environment option will do the opposite of the comments below.
#
#-- distcc:   Use the Distributed C/C++/ObjC compiler
#-- color:    Colorize output messages
#-- ccache:   Use ccache to cache compilation
#-- check:    Run the check() function if present in the PKGBUILD
#-- sign:     Generate PGP signature file
#
BUILDENV=(!distcc color !ccache check !sign)
#
#-- If using DistCC, your MAKEFLAGS will also need modification. In addition,
#-- specify a space-delimited list of hosts running in the DistCC cluster.
#DISTCC_HOSTS=""
#
#-- Specify a directory for package building.
#BUILDDIR=/tmp/makepkg

#########################################################################
# GLOBAL PACKAGE OPTIONS
#   These are default values for the options=() settings
#########################################################################
#
# Default: OPTIONS=(strip docs !libtool !staticlibs emptydirs zipman purge !optipng !upx !debug)
#  A negated option will do the opposite of the comments below.
#
#-- strip:      Strip symbols from binaries/libraries
#-- docs:       Save doc directories specified by DOC_DIRS
#-- libtool:    Leave libtool (.la) files in packages
#-- staticlibs: Leave static library (.a) files in packages
#-- emptydirs:  Leave empty directories in packages
#-- zipman:     Compress manual (man and info) pages in MAN_DIRS with gzip
#-- purge:      Remove files specified by PURGE_TARGETS
#-- upx:        Compress binary executable files using UPX
#-- optipng:    Optimize PNG images with optipng
#-- debug:      Add debugging flags as specified in DEBUG_* variables
#
OPTIONS=(strip docs !libtool !staticlibs emptydirs zipman purge !optipng !upx !debug)

#-- File integrity checks to use. Valid: md5, sha1, sha256, sha384, sha512
INTEGRITY_CHECK=(md5)
#-- Options to be used when stripping binaries. See `man strip' for details.
STRIP_BINARIES="--strip-all"
#-- Options to be used when stripping shared libraries. See `man strip' for details.
STRIP_SHARED="--strip-unneeded"
#-- Options to be used when stripping static libraries. See `man strip' for details.
STRIP_STATIC="--strip-debug"
#-- Manual (man and info) directories to compress (if zipman is specified)
MAN_DIRS=({usr{,/local}{,/share},opt/*}/{man,info})
#-- Doc directories to remove (if !docs is specified)
DOC_DIRS=(usr/{,local/}{,share/}{doc,gtk-doc} opt/*/{doc,gtk-doc})
#-- Files to be removed from all packages (if purge is specified)
PURGE_TARGETS=(usr/{,share}/info/dir .packlist *.pod)

#########################################################################
# PACKAGE OUTPUT
#########################################################################
#
# Default: put built package and cached source in build directory
#
#-- Destination: specify a fixed directory where all packages will be placed
#PKGDEST=/home/packages
#-- Source cache: specify a fixed directory where source files will be cached
#SRCDEST=/home/sources
#-- Source packages: specify a fixed directory where all src packages will be placed
#SRCPKGDEST=/home/srcpackages
#-- Log files: specify a fixed directory where all log files will be placed
#LOGDEST=/home/makepkglogs
#-- Packager: name/email of the person or organization building packages
#PACKAGER="John Doe <john@doe.com>"
#-- Specify a key to use for package signing
#GPGKEY=""

#########################################################################
# COMPRESSION DEFAULTS
#########################################################################
#
COMPRESSGZ=(gzip -c -f -n)
COMPRESSBZ2=(bzip2 -c -f)
COMPRESSXZ=(xz -c -z -)
COMPRESSLRZ=(lrzip -q)
COMPRESSLZO=(lzop -q)
COMPRESSZ=(compress -c -f)

#########################################################################
# EXTENSION DEFAULTS
#########################################################################
#
# WARNING: Do NOT modify these variables unless you know what you are
#          doing.
#
PKGEXT='.pkg.tar.xz'
SRCEXT='.src.tar.gz'

# vim: set ft=sh ts=2 sw=2 et:

As you can see, the MAKEFLAGS variable is "-j5" (as I have a dualcore with hyperthreading). The "-j1" option set in the PKGBUILD seems to make problems though - I would expect things to be exactly the other way around...

Last edited by PhotonX (2018-09-27 18:17:34)

7314776 · 2018-09-27 18:44:53

"-j5" in PKGBUILD solved nothing for me. Same error, same clean build directory, no clean chroot. As far as I see, pkgrel=4 and pkgrel=5 differ in explicit exclusion of libname-server-2.a and in 'make' method. So, a question is - do we really need pkgrel=5 in such a situation?

PhotonX · 2018-09-27 19:13:27

I guess, the best thing to do for today is to revert to -4 till a proper solution is found.

edit: Reverted to the fix from -4 in -6. An actual fix is still not there though.

Last edited by PhotonX (2018-09-27 19:20:23)

7314776 · 2018-09-27 19:40:50

Thank you, ver. 6 worked for me, even if a substitute for now.

vstuart · 2018-09-27 19:47:45

Version 2.14.19-6 also worked for me, after I removed ~/.cache/pacaur/orbit2/ and ran the update (pacaur -Syu). Thanks, appreciated!

Last edited by vstuart (2018-09-27 19:48:56)

Stefan Husmann · 2018-09-27 19:49:39

Not a clean fix, but running make twice seems to do the trick.

build() {
  cd ORBit2-$pkgver
  autoreconf -fi
  ./configure --prefix=/usr --enable-static
  make -k || true
  make
}

Other thant that: your pacth git-fixes.patch seems to include the entire configure.in and renames it to configure.am, probably just for the sake of suppressing a warning. This is not needed. Remove the parts that change configure.am and configure.in from the patch and you get a 388 lines long file also that works.

Edit: if you want to avoid the warning, simply add

mv configure.in configure.ac

to the prepare function.

Last edited by Stefan Husmann (2018-09-27 19:58:42)

Stefan Husmann · 2018-09-27 20:03:54

-6 would not work for other architectures than x86_64 I guess.

eschwartz · 2018-09-27 20:10:06

PhotonX wrote:

@Eschwartz: Well, I wanted to have a fix as fast as possible, I was well aware of the fact that such a fix could be only temporary. Concerning the filesize, I see the problem but I hope, that it is not that bad in this case as the file is just 35kb.

Yeah, that's what everyone says. "It's just 35KB, who cares", but we do care when that happens lots of times and peoples' 35KB here and 100KB there build up and every time they update the file that's another 35KB and eventually we end up with a couple GB of peoples' unwanted binary artifacts inside a *source* control system.

In the general case, this should be hosted at external locations, just like any prebuilt binaries.

In the specific case, if upstream's build system is broken then I'd seriously question whether this fix is at all correct, no matter how ill-advised. How do I know your file is linked properly and will continue to be despite updates to system dependencies? What system headers does that file depend on? How did you manage to build it in the first place, and why not make people continue to do that? Does it bother you at all that your PKGBUILD claims to be i686-compatible, but you've blatantly uploaded x86_64 relocatable object files and hardcoded the build to use them?

...

Why did it not cross your mind to either file an upstream bug or like check to see if it was already fixed in https://bugzilla.gnome.org/show_bug.cgi?id=732274 and https://gitlab.gnome.org/GNOME/orbit2/c … 8113e61c06

This "let me throw spaghetti at the walls and hope something sticks" attitude to fixing problems is not encouraging. It's hardly a crime to ask for help *prior* to your attempts at fixing something you don't understand.

We'd really, honestly, sincerely, love to help and spread our knowledge (acknowledging that not everyone understands the complex, finicky nature of the Makefile language, much less the bizarre depths of autotools obfuscation)... but how can we possibly do that if you'd much rather upload half-compiled binaries directly to the AUR and call that a solution???

Last edited by eschwartz (2018-09-27 23:34:42)

7314776 · 2018-09-27 21:03:48

Always seen AUR as a feature, not a bug. So anyone reasonably contributing thereto should be encouraged. Know how to help? Tell it, do this. Support featuring, not buggy discussions, to be short.

Thomas Krishan · 2018-09-27 23:30:16

@PhotonX: Thanks for your work on this and getting something working for us Shutter users. I also appreciate Eschwartz's contribution, it's why I appreciate using Arch and AUR.

glitsj16 · 2018-09-28 00:38:48

@PhotonX: Eschwartz allready provided everything to fix the PKGBUILD in detail. Here's an example PKGBUILD that incorporates things noted in this thread. Thanks for all your work.

eschwartz · 2018-09-28 07:00:36

Except that builds directly from master.

While I agree that this ancient software that isn't maintained, should build from the last commit, it should do so by pinning the commit hash.

PhotonX · 2018-09-28 11:08:55

I pushed the proper fix in -7, please report if there are still problems!

To reply to some of the points raised here:

Eschwartz wrote:

Why did it not cross your mind to either file an upstream bug or like check to see if it was already fixed in https://bugzilla.gnome.org/show_bug.cgi?id=732274 and https://gitlab.gnome.org/GNOME/orbit2/c … 8113e61c06

Well, the first thing I did was googling the error message. Don't ask me why this bug report and commit log didn't show up in my search results - as you know Google personalizes the search results so "my" Google seems to be different than "your" Google. I only found the forum thread I linked in my initial post and I followed what people proposed there. As of the upstream bug report, I didn't expect people to fix bugs in such an ancient piece of software, in particular since building worked fine for many years and seemed to have got broken after some recent update. I am actually quite surprised that the bug is fixed upstream but the fix isn't part of the former official Arch package (it has been removed from the Arch repos in 2017).

Eschwartz wrote:

This "let me throw spaghetti at the walls and hope something sticks" attitude to fixing problems is not encouraging.

Good one, very pictorial!

Eschwartz wrote:

It's hardly a crime to ask for help *prior* to your attempts at fixing something you don't understand.
We'd really, honestly, sincerely, love to help and spread our knowledge (acknowledging that not everyone understands the complex, finicky nature of the Makefile language, much less the bizarre depths of autotools obfuscation)... but how can we possibly do that if you'd much rather upload half-compiled binaries directly to the AUR and call that a solution???

Of course. I asked for help just hours after pushing the temporary fix. My primary objective when pushing the temporary fix was to have something functional available as fast as possible. I am actually really happy that I got help so quickly but I couldn't be sure that things will go that way. In worst case, I would wait for a reply for several days, the package being broken for all that time.

glitsj16 wrote:

@PhotonX: Eschwartz allready provided everything to fix the PKGBUILD in detail. Here's an example PKGBUILD that incorporates things noted in this thread. Thanks for all your work.

Eschwartz wrote:

Except that builds directly from master.
While I agree that this ancient software that isn't maintained, should build from the last commit, it should do so by pinning the commit hash.

Thanks, I used the PKGBUILD and pointed the source to the latest commit.

Last edited by PhotonX (2018-09-28 11:12:55)

loqs · 2018-09-28 11:38:34

Alternative git based solution

# $Id$
# Maintainer: PhotonX <photon89@googlemail.com>
# Contributor: Jan de Groot <jan@archlinux.org>

pkgname=orbit2
pkgver=2.14.19.r18.g144be2e9
pkgrel=1
pkgdesc="Thin/fast CORBA ORB"
arch=('i686' 'x86_64')
license=('LGPL' 'GPL')
depends=('libidl2')
makedepends=('gtk-doc' 'git' 'gnome-common')
options=('staticlibs')
url="https://projects.gnome.org/ORBit2/"
COMMIT=144be2e9860286c83f009e7689250e0af977cc5e
source=(git+https://gitlab.gnome.org/GNOME/orbit2.git#commit=$COMMIT)
sha256sums=('SKIP')

pkgver() {
  cd $pkgname
  git describe --long | sed 's/^ORBIT2_//;s/\([^-]*-g\)/r\1/;s/-/./g;s/_/./g'
}

prepare() {
  cd $pkgname
  git tag -d HEAD
  NOCONFIGURE=1 ./autogen.sh
}

build() {
  cd $pkgname
  ./configure --prefix=/usr --disable-static
  make
}

package() {
  cd $pkgname
  make DESTDIR="${pkgdir}" install
}

Arch Linux

#1 2018-09-27 06:21:38

[Solved] orbit2 fails to build due to missing file

#2 2018-09-27 06:33:40

Re: [Solved] orbit2 fails to build due to missing file

#3 2018-09-27 07:05:30

Re: [Solved] orbit2 fails to build due to missing file

#4 2018-09-27 08:20:50

Re: [Solved] orbit2 fails to build due to missing file

#5 2018-09-27 09:01:27

Re: [Solved] orbit2 fails to build due to missing file

#6 2018-09-27 11:46:18

Re: [Solved] orbit2 fails to build due to missing file

#7 2018-09-27 12:19:22

Re: [Solved] orbit2 fails to build due to missing file

#8 2018-09-27 15:45:03

Re: [Solved] orbit2 fails to build due to missing file

#9 2018-09-27 17:30:02

Re: [Solved] orbit2 fails to build due to missing file

#10 2018-09-27 17:54:22

Re: [Solved] orbit2 fails to build due to missing file

#11 2018-09-27 18:06:58

Re: [Solved] orbit2 fails to build due to missing file

#12 2018-09-27 18:07:38

Re: [Solved] orbit2 fails to build due to missing file

#13 2018-09-27 18:44:53

Re: [Solved] orbit2 fails to build due to missing file

#14 2018-09-27 19:13:27

Re: [Solved] orbit2 fails to build due to missing file

#15 2018-09-27 19:40:50

Re: [Solved] orbit2 fails to build due to missing file

#16 2018-09-27 19:47:45

Re: [Solved] orbit2 fails to build due to missing file

#17 2018-09-27 19:49:39

Re: [Solved] orbit2 fails to build due to missing file

#18 2018-09-27 20:03:54

Re: [Solved] orbit2 fails to build due to missing file

#19 2018-09-27 20:10:06

Re: [Solved] orbit2 fails to build due to missing file

#20 2018-09-27 21:03:48

Re: [Solved] orbit2 fails to build due to missing file

#21 2018-09-27 23:30:16

Re: [Solved] orbit2 fails to build due to missing file

#22 2018-09-28 00:38:48

Re: [Solved] orbit2 fails to build due to missing file

#23 2018-09-28 07:00:36

Re: [Solved] orbit2 fails to build due to missing file

#24 2018-09-28 11:08:55

Re: [Solved] orbit2 fails to build due to missing file

#25 2018-09-28 11:38:34

Re: [Solved] orbit2 fails to build due to missing file

Board footer