Hello folks,
I've been trying to update healpix package to latest version, so that I can submit a PR to the package maintainer. Current version is a couple of years old.
Unfortunately, the automated build process available in the package itself isn't suitable for our needs, so each component (currently the package provides Fortran, C, C++ and Java) must be compiled on its own. Moreover, a library is bundled (libsharp), which is needed by the C++ component... there are some reasons why not unbundle it, I will not list them here as they're not related to my request.
I did an heavy rewrite of the spec file to adapt to the new version and I can build everything fine locally, but when I try a koji scratch build it fails because the configure script of the C++ component cannot find a cfitsio header. That's weird, because the C component is able to find cfitsio and the header, while the C++ component finds cfitsio but not the header...
I'm at a dead end, can someone have a look at the scratch build [1] and explain me where's the fault?
Thanks Mattia
[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=90263817
On Sat, Jul 30, 2022 at 9:53 AM Mattia Verga via devel devel@lists.fedoraproject.org wrote:
Hello folks,
I've been trying to update healpix package to latest version, so that I can submit a PR to the package maintainer. Current version is a couple of years old.
Unfortunately, the automated build process available in the package itself isn't suitable for our needs, so each component (currently the package provides Fortran, C, C++ and Java) must be compiled on its own. Moreover, a library is bundled (libsharp), which is needed by the C++ component... there are some reasons why not unbundle it, I will not list them here as they're not related to my request.
I did an heavy rewrite of the spec file to adapt to the new version and I can build everything fine locally, but when I try a koji scratch build it fails because the configure script of the C++ component cannot find a cfitsio header. That's weird, because the C component is able to find cfitsio and the header, while the C++ component finds cfitsio but not the header...
I'm at a dead end, can someone have a look at the scratch build [1] and explain me where's the fault?
The actual configure error is:
/usr/bin/ld: cannot find -lz: No such file or directory
Try adding a BuildRequires on zlib-devel.
Il 30/07/22 18:28, Jerry James ha scritto:
On Sat, Jul 30, 2022 at 9:53 AM Mattia Verga via devel devel@lists.fedoraproject.org wrote:
Hello folks,
I've been trying to update healpix package to latest version, so that I can submit a PR to the package maintainer. Current version is a couple of years old.
Unfortunately, the automated build process available in the package itself isn't suitable for our needs, so each component (currently the package provides Fortran, C, C++ and Java) must be compiled on its own. Moreover, a library is bundled (libsharp), which is needed by the C++ component... there are some reasons why not unbundle it, I will not list them here as they're not related to my request.
I did an heavy rewrite of the spec file to adapt to the new version and I can build everything fine locally, but when I try a koji scratch build it fails because the configure script of the C++ component cannot find a cfitsio header. That's weird, because the C component is able to find cfitsio and the header, while the C++ component finds cfitsio but not the header...
I'm at a dead end, can someone have a look at the scratch build [1] and explain me where's the fault?
The actual configure error is:
/usr/bin/ld: cannot find -lz: No such file or directory
Try adding a BuildRequires on zlib-devel.
Jerry James http://www.jamezone.org/
Well, it was a stupid mistake indeed, as I was focused on the latest error in the build log and I didn't notice the missing build requires... everything works after I've added zlib-devel (and libcurl-devel) to BuildRequires.
Thanks.
Mattia Verga via devel wrote:
I'm at a dead end, can someone have a look at the scratch build [1] and explain me where's the fault?
What I see is that the hacks that you apply to configure are apparently not working:
checking command to parse /usr/bin/nm -B output from gcc object... ./configure: line 7304: -e 's/^T .* (.*)$/extern int \1();/p' -e 's/^[ABCDGIRSTW][ABCDGIRSTW]* .* (.*)$/extern char \1;/p': No such file or directory
It is possible that that is what is causing the: checking for ffgnrwll in -lcfitsio... no configure: error: could not find the cfitsio library failure in the C++ part's configure.
Or maybe it is the code from this hack: + /usr/bin/sed -r --in-place=.backup 's/^char (*f) () = /__attribute__ ((used)) char (*f) () = /g' ./configure + /usr/bin/sed -r --in-place=.backup 's/^char (*f) ();/__attribute__ ((used)) char (*f) ();/g' ./configure + /usr/bin/sed -r --in-place=.backup 's/^char $2 ();/__attribute__ ((used)) char $2 ();/g' ./configure that is not accepted by the C++ compiler?
Kevin Kofler
On Sat, Jul 30, 2022 at 10:35 AM Kevin Kofler via devel devel@lists.fedoraproject.org wrote:
What I see is that the hacks that you apply to configure are apparently not working:
checking command to parse /usr/bin/nm -B output from gcc object... ./configure: line 7304: -e 's/^T .* (.*)$/extern int \1();/p' -e 's/^[ABCDGIRSTW][ABCDGIRSTW]* .* (.*)$/extern char \1;/p': No such file or directory
I think that's redhat-rpm-config. See %_fix_broken_configure_for_lto in /usr/lib/rpm/redhat/macros. I see the same output from every package I maintain that uses autoconf-generated configure scripts.
Jerry James wrote:
On Sat, Jul 30, 2022 at 10:35 AM Kevin Kofler via devel devel@lists.fedoraproject.org wrote:
What I see is that the hacks that you apply to configure are apparently not working:
checking command to parse /usr/bin/nm -B output from gcc object... ./configure: line 7304: -e 's/^T .* (.*)$/extern int \1();/p' -e 's/^[ABCDGIRSTW][ABCDGIRSTW]* .* (.*)$/extern char \1;/p': No such file or directory
I think that's redhat-rpm-config. See %_fix_broken_configure_for_lto in /usr/lib/rpm/redhat/macros. I see the same output from every package I maintain that uses autoconf-generated configure scripts.
So somebody needs to fix redhat-rpm-config then. It's funny when something called "fix_broken_configure" produces… a broken configure. ;-)
Kevin Kofler
On Sun, Jul 31, 2022 at 03:33:51PM +0200, Kevin Kofler via devel wrote:
Jerry James wrote:
On Sat, Jul 30, 2022 at 10:35 AM Kevin Kofler via devel devel@lists.fedoraproject.org wrote:
What I see is that the hacks that you apply to configure are apparently not working:
checking command to parse /usr/bin/nm -B output from gcc object... ./configure: line 7304: -e 's/^T .* (.*)$/extern int \1();/p' -e 's/^[ABCDGIRSTW][ABCDGIRSTW]* .* (.*)$/extern char \1;/p': No such file or directory
I think that's redhat-rpm-config. See %_fix_broken_configure_for_lto in /usr/lib/rpm/redhat/macros. I see the same output from every package I maintain that uses autoconf-generated configure scripts.
So somebody needs to fix redhat-rpm-config then. It's funny when something called "fix_broken_configure" produces… a broken configure. ;-)
That macro looks very hairy.
At some point we should just require autoreconf. I think Debian have been advising (not requiring) that for a while:
https://wiki.debian.org/Autoreconf
Rich.
On 8/3/2022 6:55 AM, Richard W.M. Jones wrote:
On Sun, Jul 31, 2022 at 03:33:51PM +0200, Kevin Kofler via devel wrote:
Jerry James wrote:
On Sat, Jul 30, 2022 at 10:35 AM Kevin Kofler via devel devel@lists.fedoraproject.org wrote:
What I see is that the hacks that you apply to configure are apparently not working:
checking command to parse /usr/bin/nm -B output from gcc object... ./configure: line 7304: -e 's/^T .* (.*)$/extern int \1();/p' -e 's/^[ABCDGIRSTW][ABCDGIRSTW]* .* (.*)$/extern char \1;/p': No such file or directory
I think that's redhat-rpm-config. See %_fix_broken_configure_for_lto in /usr/lib/rpm/redhat/macros. I see the same output from every package I maintain that uses autoconf-generated configure scripts.
So somebody needs to fix redhat-rpm-config then. It's funny when something called "fix_broken_configure" produces… a broken configure. ;-)
That macro looks very hairy.
They are 100% totally insane. I suspect we've got a quoting issue that needs to be fixed.
At some point we should just require autoreconf. I think Debian have been advising (not requiring) that for a while:
That would eliminate the need for those crazy macros. The problem is many packages have configury bits that are ancient and can't be rebuilt with modern autotools.
Jeff
Jeff Law wrote:
That would eliminate the need for those crazy macros. The problem is many packages have configury bits that are ancient and can't be rebuilt with modern autotools.
I have a hard time believing that.
Even the gigantic KDE 3 autotools mess last updated by upstream in 2008 can be regenerated with current autotools with only 6 patches (2 of which only fix hardcoded maximum version numbers).
Kevin Kofler
On 8/3/2022 2:00 PM, Kevin Kofler via devel wrote:
Jeff Law wrote:
That would eliminate the need for those crazy macros. The problem is many packages have configury bits that are ancient and can't be rebuilt with modern autotools.
I have a hard time believing that.
Well, having been the one that did the work, I can tell you that trying to convert circa 2008 autoconf files to anything modern isn't always trivial. I'll also note that locally I was testing things by capturing the generated config.h files before/after all these bits went in and comparing them - across all of the Fedora packages. That's actually how we knew what insanity we had to fix in the generated configure scripts to ensure the resulting config.h files were identical. BUt if you think there's a good way to get to a place where we consistently use a reasonably modern autoconf, then by all means, be my guest to make it happen and we can zap the configure sed hacking insanity.
Even the gigantic KDE 3 autotools mess last updated by upstream in 2008 can be regenerated with current autotools with only 6 patches (2 of which only fix hardcoded maximum version numbers).
"gigantic KDE 3 autotools mess" -- now imagine whatever effort there was to fix that and apply it to potentially hundreds of packages. Worse yet, ponder how you're going to determine if you got it right, particularly on a package you don't know anything about :-)
I'd *love* to it to be policy that things work after an autoconf -fiv (or whatever args we choose), but someone will have to step up and do the work.
jeff
Richard W.M. Jones wrote:
At some point we should just require autoreconf.
I have been arguing for that for years. IMHO, it is a logical consequence of the general rule that everything in Fedora must be built from source. Generated files are NOT source code. Patching anything in the configure stuff without running autoreconf is always a pain. (By the way, autoreconf with no arguments is not all that helpful, you need at least "autoreconf -i -f". That is just one of the many annoyances with the autotools.)
Kevin Kofler
On 8/14/2022 6:29 AM, Jarryd Lisher via devel wrote:
Hey, I figured out that this is mainly caused by the configure script containing multi-line definitions. So, the hacks only operate on the first part and land up leaving random lines of nonsense in the file. You can fix this by adding the following "unwrap" `sed` script just before the `%{configure}` line:
%{__sed} -i -z -e 's/\\\n//g' configureIt's not perfect, but is a simple fix to remove those errors from the configure.
That seems like a pretty big hammer with fair potential for changing something we didn't really want to. Can we key it's behavior somehow on lines we care about?
Thanks, Jeff
devel@lists.stg.fedoraproject.org
-
Jarryd Lisher -
Jeff Law -
Jerry James -
Kevin Kofler -
Mattia Verga -
Richard W.M. Jones