Your package fails to build with the newest upcoming autoconf-2.71, which is part of a wide Fedora change. Please see the attached copr: https://copr.fedorainfracloud.org/coprs/odubaj/autoconf-2.70/packages/. More information about testing your package when building with autoconf available here: https://fedoraproject.org/wiki/Changes/Autoconf_271#How_To_Test
Gentle ping.
A rebase to the latest portaudio upstream was pending, I've just merged that into rawhide. So now I tried to "to rebuild new version of package against autoconf-2.71 is to create a pull-request against your dist-git repository" but if I go here: https://copr.fedorainfracloud.org/coprs/odubaj/autoconf-2.70/package/portaudio/ And then click on the "Dist Git Repo" link on the packages tab I get a 404 :| Can you try a new build with autoconf-2.71 against the rawhide branch from dist-git ?
Never mind I see now that copr automatically tries to do a new build for each commit pushed to the rawhide branch on distgit and that it failed for the rebased version to. The error is: configure: error: cannot find required auxiliary files: ltmain.sh compile missing configure: error: ./configure failed for bindings/cpp This is for a separate ./configure run for the bindings/cpp sub-project. The .spec runs autoreconf -i -f and that says: + autoreconf -i -f autoreconf: warning: autoconf input should be named 'configure.ac', not 'configure.in' aclocal: warning: autoconf input should be named 'configure.ac', not 'configure.in' libtoolize: putting auxiliary files in '../..'. libtoolize: copying file '../../ltmain.sh' libtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to configure.ac, libtoolize: and rerunning libtoolize and aclocal. libtoolize: Consider adding '-I m4' to ACLOCAL_AMFLAGS in Makefile.am. configure.ac:37: warning: The macro `AC_LIBTOOL_WIN32_DLL' is obsolete. configure.ac:37: You should run autoupdate. aclocal.m4:8518: AC_LIBTOOL_WIN32_DLL is expanded from... configure.ac:37: the top level configure.ac:37: warning: AC_LIBTOOL_WIN32_DLL: Remove this warning and the call to _LT_SET_OPTION when you configure.ac:37: put the 'win32-dll' option into LT_INIT's first parameter. ./lib/autoconf/general.m4:2434: AC_DIAGNOSE is expanded from... aclocal.m4:8518: AC_LIBTOOL_WIN32_DLL is expanded from... configure.ac:37: the top level configure.ac:38: warning: The macro `AC_PROG_LIBTOOL' is obsolete. configure.ac:38: You should run autoupdate. aclocal.m4:121: AC_PROG_LIBTOOL is expanded from... configure.ac:38: the top level configure.ac:35: installing '../../compile' configure.ac:17: installing '../../missing' bin/Makefile.am:8: warning: source file '$(BINDIR)/devs.cxx' is in a subdirectory, bin/Makefile.am:8: but option 'subdir-objects' is disabled automake: warning: possible forward-incompatibility. automake: At least a source file is in a subdirectory, but the 'subdir-objects' automake: automake option hasn't been enabled. For now, the corresponding output automake: object file(s) will be placed in the top-level directory. However, automake: this behaviour will change in future Automake versions: they will automake: unconditionally cause object files to be placed in the same subdirectory automake: of the corresponding sources. automake: You are advised to start using 'subdir-objects' option throughout your automake: project, to avoid future incompatibilities. bin/Makefile.am:9: warning: source file '$(BINDIR)/sine.cxx' is in a subdirectory, bin/Makefile.am:9: but option 'subdir-objects' is disabled bin/Makefile.am: installing '../../depcomp' lib/Makefile.am:10: warning: source file '$(SRCDIR)/BlockingStream.cxx' is in a subdirectory, lib/Makefile.am:10: but option 'subdir-objects' is disabled lib/Makefile.am:10: warning: source file '$(SRCDIR)/CallbackInterface.cxx' is in a subdirectory, lib/Makefile.am:10: but option 'subdir-objects' is disabled lib/Makefile.am:10: warning: source file '$(SRCDIR)/CallbackStream.cxx' is in a subdirectory, lib/Makefile.am:10: but option 'subdir-objects' is disabled lib/Makefile.am:10: warning: source file '$(SRCDIR)/CFunCallbackStream.cxx' is in a subdirectory, lib/Makefile.am:10: but option 'subdir-objects' is disabled lib/Makefile.am:10: warning: source file '$(SRCDIR)/CppFunCallbackStream.cxx' is in a subdirectory, lib/Makefile.am:10: but option 'subdir-objects' is disabled lib/Makefile.am:10: warning: source file '$(SRCDIR)/Device.cxx' is in a subdirectory, lib/Makefile.am:10: but option 'subdir-objects' is disabled lib/Makefile.am:10: warning: source file '$(SRCDIR)/DirectionSpecificStreamParameters.cxx' is in a subdirectory, lib/Makefile.am:10: but option 'subdir-objects' is disabled lib/Makefile.am:10: warning: source file '$(SRCDIR)/Exception.cxx' is in a subdirectory, lib/Makefile.am:10: but option 'subdir-objects' is disabled lib/Makefile.am:10: warning: source file '$(SRCDIR)/HostApi.cxx' is in a subdirectory, lib/Makefile.am:10: but option 'subdir-objects' is disabled lib/Makefile.am:10: warning: source file '$(SRCDIR)/InterfaceCallbackStream.cxx' is in a subdirectory, lib/Makefile.am:10: but option 'subdir-objects' is disabled lib/Makefile.am:10: warning: source file '$(SRCDIR)/MemFunCallbackStream.cxx' is in a subdirectory, lib/Makefile.am:10: but option 'subdir-objects' is disabled lib/Makefile.am:10: warning: source file '$(SRCDIR)/Stream.cxx' is in a subdirectory, lib/Makefile.am:10: but option 'subdir-objects' is disabled lib/Makefile.am:10: warning: source file '$(SRCDIR)/StreamParameters.cxx' is in a subdirectory, lib/Makefile.am:10: but option 'subdir-objects' is disabled lib/Makefile.am:10: warning: source file '$(SRCDIR)/System.cxx' is in a subdirectory, lib/Makefile.am:10: but option 'subdir-objects' is disabled lib/Makefile.am:10: warning: source file '$(SRCDIR)/SystemDeviceIterator.cxx' is in a subdirectory, lib/Makefile.am:10: but option 'subdir-objects' is disabled lib/Makefile.am:10: warning: source file '$(SRCDIR)/SystemHostApiIterator.cxx' is in a subdirectory, lib/Makefile.am:10: but option 'subdir-objects' is disabled libtoolize: putting auxiliary files in '.'. libtoolize: copying file './ltmain.sh' libtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to configure.in, libtoolize: and rerunning libtoolize and aclocal. libtoolize: Consider adding '-I m4' to ACLOCAL_AMFLAGS in Makefile.am. aclocal: warning: autoconf input should be named 'configure.ac', not 'configure.in' configure.in:64: warning: back quotes and double quotes must not be escaped in: unknown Windows API \"$api\" (do you need --help?) configure.in:113: warning: The macro `AC_LIBTOOL_WIN32_DLL' is obsolete. configure.in:113: You should run autoupdate. aclocal.m4:8510: AC_LIBTOOL_WIN32_DLL is expanded from... configure.in:113: the top level configure.in:113: warning: AC_LIBTOOL_WIN32_DLL: Remove this warning and the call to _LT_SET_OPTION when you configure.in:113: put the 'win32-dll' option into LT_INIT's first parameter. ./lib/autoconf/general.m4:2434: AC_DIAGNOSE is expanded from... aclocal.m4:8510: AC_LIBTOOL_WIN32_DLL is expanded from... configure.in:113: the top level configure.in:114: warning: The macro `AC_PROG_LIBTOOL' is obsolete. configure.in:114: You should run autoupdate. aclocal.m4:113: AC_PROG_LIBTOOL is expanded from... configure.in:114: the top level configure.in:472: warning: AC_OUTPUT should be used without arguments. configure.in:472: You should run autoupdate. configure.in:472: warning: AC_C_BIGENDIAN should be used with AC_CONFIG_HEADERS Notice how it says: libtoolize: putting auxiliary files in '../..'. libtoolize: copying file '../../ltmain.sh' and: libtoolize: putting auxiliary files in '.'. libtoolize: copying file './ltmain.sh' Just as it does for autoconf-2.69 I guess I could try setting AC_CONFIG_MACRO_DIRS([m4]) in both portaudio/configure.in and portaudio/bindings/cpp/configure.ac and then perhaps they will both get their own portaudio/m4 resp portaudio/bindings/cpp/m4 dir and that will work better with autoconf-2.71 ?
That might solve the issue. For testing the best way is to download mock config and test the changes locally, see here: https://fedoraproject.org/wiki/Changes/Autoconf_271#How_To_Test.
Also looking at common fialures and fixed might help (https://docs.google.com/document/d/1SAGTJZEF9z_nkHMbXTF-YTTvKRja7ygfOOMzl-DYBSk/edit)
(In reply to Ondrej Dubaj from comment #5) > Also looking at common fialures and fixed might help > (https://docs.google.com/document/d/1SAGTJZEF9z_nkHMbXTF-YTTvKRja7ygfOOMzl- > DYBSk/edit) I just tried a mockbuild with AC_CONFIG_MACRO_DIRS([m4]) added to both configure.in/.ac files and this does not help. I've also taken a look at the mentioned "common fialures and fixes" doc and this case is not mentioned there. I'm in no way an autoconf / libtool expert to I'm afraid that I'm going to need some help with getting this fixed.
I would personally try the following fixes: https://src.fedoraproject.org/rpms/ORBit2/c/3e373f9fbcd4f4a31eda656df590d78de1595fa9?branch=rawhide https://src.fedoraproject.org/rpms/SDL_Pango/c/a8662b2c999beec3ebfd11350bb9ac8703ebed61?branch=rawhide https://src.fedoraproject.org/rpms/openchange/c/8231ec4c2e7e0c701982fe441a858ecf721fa07e?branch=rawhide and see if one of them will somehow work (maybe with some small modifications). The problem resolved by these fixes is very similar to your problem. So I will at least give it a chance. Thanks.
Hi, any updates to this issue please ? Did you manage to create a patch ? Thanks.
(In reply to Ondrej Dubaj from comment #8) > Hi, any updates to this issue please ? Did you manage to create a patch ? I have not had time to look into this; and to be honest I don't see myself having time to work on this anytime soon. If you can take a try at fixing this yourself then that would be great.
The patch is quite straight-forward diff --git a/portaudio.spec b/portaudio.spec index 91a0f5d..17e0bb1 100644 --- a/portaudio.spec +++ b/portaudio.spec @@ -47,6 +47,7 @@ autoreconf -i -f %build +autoreconf -fi %configure --disable-static --enable-cxx sed -i 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g' bindings/cpp/libtool sed -i 's|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' bindings/cpp/libtool Can you please backport it to fedora? I do not think it worth creating a pull-request. Thanks.
Ondrey, thank you for the quick answer, but the .spec already has a "autoreconf -i -f" call in %setup and last time I tried a mockbuild against a mockcfg generated with: copr mock-config odubaj/autoconf-2.70 fedora-rawhide-x86_64 It failed with the following error: configure: error: cannot find required auxiliary files: ltmain.sh compile missing configure: error: ./configure failed for bindings/cpp As mentioned in more detail in comment 3. I've done another fedpkg mockbuild in case something was fixed in rawhide since my previous attempt, but it still fails this way: === configuring in bindings/cpp (/builddir/build/BUILD/portaudio/bindings/cpp) configure: running /bin/sh ./configure ... configure: error: cannot find required auxiliary files: ltmain.sh compile missing configure: error: ./configure failed for bindings/cpp
Huh, I tried with your change and now it does work, that is weird.
Ok, this is weird. I've run a couple of mockbuilds and the trick that: autoreconf -fi Needs to run twice for things to work, whether it is run from %setup or %install and written as "autoreconf -fi" or "autoreconf -i -f" does not appear to matter. The trick is it needs to run twice. I can add this as a workaround for now, but this feels like it is a bug in autoreconf ? So how do you want to proceed with this ?
I neither do not understand this. Let me investigate this more deeply, as I do not know the package. I don't think it is a bug in autoconf, as there are hundreds of packages working properly with autoreconf -fi.
I have no idea what is going on there, I see backuping the configure and multiple strange things in the log. I would choose to use the workaround with using 2x autoreconf and post this issue to upstream to deal with it. Do you agree ?
(In reply to Ondrej Dubaj from comment #15) > I have no idea what is going on there, I see backuping the configure and > multiple strange things in the log. I would choose to use the workaround > with using 2x autoreconf and post this issue to upstream to deal with it. Do > you agree ? That works for me, I'll take care of this in the coming days. Thank you for your help with this.
Fixed (with the run autoreconf twice workaround) in rawhide now, closing.