Re: Planning to start unifying native and mingw packages

[Sandro Mani]

On 03.09.22 18:09, Richard Shaw wrote:
>  On Sat, Sep 3, 2022 at 10:33 AM Richard Shaw
> <hobbes1069(a)gmail.com&gt; wrote:
>
>      On Sat, Sep 3, 2022 at 10:22 AM Sandro Mani <manisandro(a)gmail.com&gt;
>      wrote:
>
>
>          On 03.09.22 17:10, Richard Shaw wrote:
>          > I'm trying to migrate fltk right now and running into an issue:
>          >
>          > Processing files: fltk-debugsource-1.3.8-4.fc38.x86_64
>          >
>          > RPM build warnings:
>          >
>          > RPM build errors:
>          > error: Could not open %files file
>          > /builddir/build/BUILD/fltk-1.3.8/debugsourcefiles.list: No
>          such file
>          > or directory
>          >
>          > Building the mingw packages seems to be interfering with the
>          native build.
>
>
>  I put %{?mingw_package_header} in the %{with mingw} (disabled) 
>  conditional this time and the build completed, so something in there 
>  is causing the issue. 
You actually don't need %{?mingw_package_header} anymore at all (it 
actually should just be a no-op with a current mingw-filesystem).

Sandro

Planning to start unifying native and mingw packages

[Richard Shaw]

On Sat, Sep 3, 2022 at 11:14 AM Sandro Mani <manisandro(a)gmail.com&gt; wrote:

>  On 03.09.22 18:09, Richard Shaw wrote:
>
>  On Sat, Sep 3, 2022 at 10:33 AM Richard Shaw <hobbes1069(a)gmail.com&gt; wrote:
>
> > On Sat, Sep 3, 2022 at 10:22 AM Sandro Mani <manisandro(a)gmail.com&gt; wrote:
> >
> >>
> >> On 03.09.22 17:10, Richard Shaw wrote:
> >> > I'm trying to migrate fltk right now and running into an issue:
> >> >
> >> > Processing files: fltk-debugsource-1.3.8-4.fc38.x86_64
> >> >
> >> > RPM build warnings:
> >> >
> >> > RPM build errors:
> >> > error: Could not open %files file
> >> > /builddir/build/BUILD/fltk-1.3.8/debugsourcefiles.list: No such file
> >> > or directory
> >> >
> >> > Building the mingw packages seems to be interfering with the native
> >> build.
> >>
> >
>  I put %{?mingw_package_header} in the %{with mingw} (disabled) conditional
>  this time and the build completed, so something in there is causing the
>  issue.
>
>  You actually don't need %{?mingw_package_header} anymore at all (it
>  actually should just be a no-op with a current mingw-filesystem).
>  
Ok, removed. Now I'm getting an error on the mingw-debuginfo

RPM build errors:
error: Could not open %files file
/builddir/build/BUILD/fltk-1.3.8/mingw32-debugfiles.list: No such file or
directory

I've uploaded the whole src rpm if you want to take a look:
https://hobbes1069.fedorapeople.org/fltk-1.3.8-4.fc38.src.rpm

Thanks,
Richard

Planning to start unifying native and mingw packages

[Sandro Mani]

On 03.09.22 20:28, Richard Shaw wrote:
>  On Sat, Sep 3, 2022 at 11:14 AM Sandro Mani
> <manisandro(a)gmail.com&gt; wrote:
>
>      On 03.09.22 18:09, Richard Shaw wrote:
>
> >     On Sat, Sep 3, 2022 at 10:33 AM Richard Shaw
> >     <hobbes1069(a)gmail.com&gt; wrote:
> >
> >         On Sat, Sep 3, 2022 at 10:22 AM Sandro Mani
> >         <manisandro(a)gmail.com&gt; wrote:
> >
> >
> >             On 03.09.22 17:10, Richard Shaw wrote:
> >             > I'm trying to migrate fltk right now and running into
> >             an issue:
> >             >
> >             > Processing files: fltk-debugsource-1.3.8-4.fc38.x86_64
> >             >
> >             > RPM build warnings:
> >             >
> >             > RPM build errors:
> >             > error: Could not open %files file
> >             > /builddir/build/BUILD/fltk-1.3.8/debugsourcefiles.list:
> >             No such file
> >             > or directory
> >             >
> >             > Building the mingw packages seems to be interfering
> >             with the native build.
> >
> >
> >     I put %{?mingw_package_header} in the %{with mingw} (disabled)
> >     conditional this time and the build completed, so something in
> >     there is causing the issue.
>
>      You actually don't need %{?mingw_package_header} anymore at all
>      (it actually should just be a no-op with a current mingw-filesystem).
>
>
>  Ok, removed. Now I'm getting an error on the mingw-debuginfo
>
>  RPM build errors:
>  error: Could not open %files file 
>  /builddir/build/BUILD/fltk-1.3.8/mingw32-debugfiles.list: No such file 
>  or directory
>
>  I've uploaded the whole src rpm if you want to take a look:
>  https://hobbes1069.fedorapeople.org/fltk-1.3.8-4.fc38.src.rpm 
You need to add

%mingw_debug_install_post

after %install.

Also, you could use the shorthand

%mingw_make_build (rather than %mingw_make %{?_smp_mflags})

and

%mingw_make_install (rather than %mingw_make_install DESTDIR=%{buildroot})


Sandro

Planning to start unifying native and mingw packages

[Daniel P. Berrangé]

On Sat, Sep 03, 2022 at 06:13:21PM +0200, Sandro Mani wrote:
>  
>  On 03.09.22 18:09, Richard Shaw wrote:
>  > On Sat, Sep 3, 2022 at 10:33 AM Richard Shaw <hobbes1069(a)gmail.com&gt; wrote:
>  > 
>  >     On Sat, Sep 3, 2022 at 10:22 AM Sandro Mani <manisandro(a)gmail.com&gt;
>  >     wrote:
>  > 
>  > 
>  >         On 03.09.22 17:10, Richard Shaw wrote:
>  >         > I'm trying to migrate fltk right now and running into an issue:
>  >         >
>  >         > Processing files: fltk-debugsource-1.3.8-4.fc38.x86_64
>  >         >
>  >         > RPM build warnings:
>  >         >
>  >         > RPM build errors:
>  >         > error: Could not open %files file
>  >         > /builddir/build/BUILD/fltk-1.3.8/debugsourcefiles.list: No
>  >         such file
>  >         > or directory
>  >         >
>  >         > Building the mingw packages seems to be interfering with the
>  >         native build.
>  > 
>  > 
>  > I put %{?mingw_package_header} in the %{with mingw} (disabled)
>  > conditional this time and the build completed, so something in there is
>  > causing the issue.
>  
>  You actually don't need %{?mingw_package_header} anymore at all (it actually
>  should just be a no-op with a current mingw-filesystem). 
FYI, we discovered a minor problem with this - historically the
mingw_package_header macro has redirect strip/objdump to the mingw
versions of those binaries.

That redirection was needed historically because the native versions
only know about the native arch elf format.  Not too long ago though,
the native binutils started getting built with explicit support for
x86 PE format on all arches.

Unfortunately we just learn the hard way last week that there was a
problem with this for the  s390x native build - it enabled both PE
and COFF formats, as a result strip/objdump couldn't decide which
format to use and mangled the mingw DLLs by removing the index.

  https://bugzilla.redhat.com/show_bug.cgi?id=2139143

This would packages with merged mingw changes if the published DLL
was created on the s390x builder. If the packages are noarch, IIUC,
it is random which arch Koji decides to publish the mingw packages
from.

Gnutls mistakenly didn't mark its mingw sub-RPMs as noarch, and so
it always published DLLs built on s390x, and this then prevented
any app using mingw DLLs on s390x. Symptom:

  /bin/ld: /usr/i686-w64-mingw32/sys-root/mingw/lib/libgnutls.dll.a: error
  adding symbols: archive has no index; run ranlib to add one


The binutils / s390x issue is fixed on rawhide now, requested for
F37 too.

GNUTLS also merged a PR to make its mingw sub-RPMs noarch again.

  https://src.fedoraproject.org/rpms/gnutls/pull-request/64

There is a small chance that some other package might have published
DLLs that were built on s390x with the problematic binutils. So if
people see the wierd 'archive has no index' error message on a mingw
build, this is where it comes from. The affect DLLs would just need
a rebuild.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|