Description of problem: When trying to build an RPM package that in turns depends on autotools targeting Mageia through COPR, all attempts to build fail. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Submit a build of an SRPM file to COPR 2. Build fails on all Mageia hosts. 3. Build succeeds on all other hosts (Fedora, CentOS, OpenSUSE) During the build, the Mageia version of rpmbuild applies a number of updates to autotools as follows: + /usr/lib/rpm/mageia/force-as-needed-for-shared-lib-in-libtool Forcing -Wl,--as-needed in configure/libtool to workaround libtool bug (cf http://lists.gnu.org/archive/html/libtool-patches/2004-06/msg00002.html) + /usr/lib/rpm/mageia/drop-ld-no-undefined-for-shared-lib-modules-in-libtool Modifying build-aux/ltmain.sh underlinking for plugins (cf http://wiki.mandriva.com/en/Underlinking) + /usr/lib/rpm/mageia/fix-libtool-ltmain-from-overlinking + /usr/lib/rpm/mageia/fix-libtool-from-moving-options-after-libs . Fixing libtool inside configure to pass -Wl,xxx options before libraries + /usr/lib/rpm/mageia/fix-dlsearch-path-in-libtool-for-multilib . lib This triggers the deletion of the depcomp file, which is then not regenerated for some reason. This in turn causes the build to fail: + /usr/bin/make -O -j2 /usr/bin/make all-am make[1]: Entering directory '/builddir/build/BUILD/retry-1.0.0' source='retry.c' object='retry.o' libtool=no \ DEPDIR=.deps depmode=none /bin/sh ./build-aux/depcomp \ i586-mageia-linux-gnu-gcc -DHAVE_CONFIG_H -I. -O2 -g -pipe -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -fomit-frame-pointer -march=i586 -mtune=generic -fasynchronous-unwind-tables -c -o retry.o retry.c /bin/sh: ./build-aux/depcomp: No such file or directory Makefile:481: recipe for target 'retry.o' failed The spec file is as follows: https://github.com/minfrin/retry/blob/master/retry.spec.in
Created attachment 11455 [details] Logfile showing COPR build failure
The following workaround suppresses libtool and stops libtool breaking the build, it would be ideal if libtool could just work. Index: retry.spec.in =================================================================== --- retry.spec.in (revision 14) +++ retry.spec.in (working copy) @@ -10,6 +10,8 @@ URL: https://github.com/minfrin/%{name} BuildRequires: help2man, gcc, autoconf, automake, libtool +%define __libtoolize /bin/true + %description Repeat a command until the command succeeds.
Currently in Mageia %configure2_5x macro should be used instead of %configure. See bug 19902.
CC: (none) => jani.valimaa
Unfortunately the %configure2_5x macro doesn't work, as per https://forums.mageia.org/en/viewtopic.php?f=10&t=13261. The failure due to depcomp being missing remains. The %configure2_5x also breaks all other builds on COPR.
One can't build packages for every single RPM based distro with one .spec. %if..%else..%endif is needed to handle differencies between distros. In this case you could try the following in .spec before %configure call: %if 0%{?mageia:1} %global configure %configure2_5x %endif Usually also calling 'autoreconf -vfi' before %configure2_5x solves some autotools related build issues. And as a side note, we have already unified our rpm build macros in current cauldron for upcoming mga8 and I think we could and should also do it for %configure to resolve bug 19902.
In the case of https://copr.fedorainfracloud.org/coprs/minfrin/retry/build/1144100/, all of these builds are done with one spec file. The only per distro element is "%define __libtoolize /bin/true", and this is harmless on other distros. As I pointed out the "%configure2_5x" doesn't work in this case, so is moot alas. You are very close to one spec file, removing the attempt to libtoolize worked for me. In my experimentation with COPR on different targets regenerating autotools files from scratch is very hit and miss, the --force options don't work, and you end up with a mixture of different versioned files triggering failures.
Thanks Jani for your comments. Assigning, like bug 19902, to the rpmstack group.
Assignee: bugsquad => rpmstackSee Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=19902
Ultimately, what Jani said is correct. An autoreconf -fi before the %configure will fix the depcomp problem. As for why %configure2_5x isn't working, I've CC'd Neal.
CC: (none) => ngompa13
I had no problems to build retry using %configure2_5x macro. Tried with current cauldron, mga7 and mga6.
> Ultimately, what Jani said is correct. An autoreconf -fi before > the %configure will fix the depcomp problem. Not sure if I came across clearly on this one. I can confirm after a significant amount of time trying to to make this work, running autoreconf -fi does not solve the depcomp problem. The reason for this is that autoreconf is designed to bootstrap a bare autotools project where generated fields don't yet exist. In this case we are trying to build a tarball that has been created using "make dist". In this case, all autogenerated files are in their final form. autoreconf runs, updates some of the generated files but not others. The build then runs. ./configure then complains that macros come from different versions and the build fails. The build fails inconsistently at different places for different macro mismatches on each version of each target platform, basically because autoreconf is asking to do something it isn't designed to do. The solution here is to make Mageia work the same as every other distribution, and use the same macro names. In the bad old days, you had to create tailored spec files for every version of every distro, and it was a mess. Today, we just submit one spec file to COPR, select build for all platforms (within reason), and you're done. The only platform that consistently gives problems is Mageia, and it would be very sad if people "fixed" this problem by simply turning Mageia COPR builds off, and building for everyone else instead.
Graham, Could you try putting the following workaround at the top of your spec? %{?configure2_5x:%global configure %{configure2_5x}} This should "shim" the correct configure without too much goop in your spec.
Jani, Can we just do the necessary mass-change to kill off %configure2_5x?
(In reply to Neal Gompa from comment #12) > Jani, > > Can we just do the necessary mass-change to kill off %configure2_5x? Sure, but I need to update my cauldron SVN co first. Changes to rpm-mageia-setup are also needed.
%configure2_5x is now switched to %configure and old %configure behavior removed in current cauldron and thus upcoming mga8.
Can we close this bug?