Help needed: build failure trying to upgrade healpix

[Mattia Verga]

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

[Jerry James]

On Sat, Jul 30, 2022 at 9:53 AM Mattia Verga via devel
<devel(a)lists.fedoraproject.org&gt; 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/

[Mattia Verga]

Il 30/07/22 18:28, Jerry James ha scritto:
>  On Sat, Jul 30, 2022 at 9:53 AM Mattia Verga via devel
>  <devel(a)lists.fedoraproject.org&gt; 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.

[Kevin Kofler]

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

[Jerry James]

On Sat, Jul 30, 2022 at 10:35 AM Kevin Kofler via devel
<devel(a)lists.fedoraproject.org&gt; 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
http://www.jamezone.org/

[Kevin Kofler]

Jerry James wrote:

>  On Sat, Jul 30, 2022 at 10:35 AM Kevin Kofler via devel
>  <devel(a)lists.fedoraproject.org&gt; 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

[Richard W.M. Jones]

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(a)lists.fedoraproject.org&gt; 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.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v

[Jeff Law]

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(a)lists.fedoraproject.org&gt; 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:
>
>  https://wiki.debian.org/Autoreconf 
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

[Kevin Kofler]

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

[Jeff Law]

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

[Kevin Kofler]

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

[Jeff Law]

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' configure
>  ```
>  It'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