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@xxxxxxxxx> wrote:
> >
> > On Sat, Sep 3, 2022 at 10:22 AM Sandro Mani <manisandro@xxxxxxxxx>
> > 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 :|
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
