fltk rebuild issue: uname -i "unknown"?

[Richard Shaw]

I haven't paid much attention to the fltk package since Rex is the primary
maintainer but I just attempted to build fldigi and ran into the following
issue:

checking for fltk-config... /usr/bin/fltk-config
/usr/bin/fltk-config: line 3: exec: fltk-config-unknown: not found
configure: error: /usr/bin/fltk-config failed

From a local rebuild attempt of fltk I see:

+ mv /builddir/build/BUILDROOT/fltk-1.3.8-3.fc38.x86_64/usr/bin/fltk-config
/builddir/build/BUILDROOT/fltk-1.3.8-3.fc38.x86_64/usr/bin/fltk-config-unknown
+ install -p -m755 -D /builddir/build/SOURCES/fltk-config.sh
/builddir/build/BUILDROOT/fltk-1.3.8-3.fc38.x86_64/usr/bin/fltk-config

Which seems strange until I took a loot at the FLTK specfile:

# we only apply this hack to multilib arch's
%ifarch x86_64 %{ix86} ppc64 ppc s390x s390 sparc64 sparc
%global arch %(uname -i 2>/dev/null || echo undefined)
mv $RPM_BUILD_ROOT%{_bindir}/fltk-config \
   $RPM_BUILD_ROOT%{_bindir}/fltk-config-%{arch}
install -p -m755 -D %{SOURCE1} $RPM_BUILD_ROOT%{_bindir}/fltk-config
%endif

Obviously this has been in place for a VERY long time but the only use case
I can think of is to have fltk-devel installed from two different arches,
i686 and x86_64 for instance.

Could this have anything to do with the systemd-nspawn change? Could it
have caused `uname -i` to no longer resolve correctly?

Does this really need to be supported at this point?

Thanks,
Richard

[Vincent Mihalkovic]

Hello,

from related https://bugzilla.redhat.com/show_bug.cgi?id=2121153#c1 (fltk
bugzilla):
     "It should use `uname -m` rather than `uname -i`, which has been
documented as non-portable since 2015"

vincent mihalkovic

On Sat, Aug 27, 2022 at 5:44 PM Richard Shaw  wrote:
> I haven't paid much attention to the fltk package since Rex is the primary
> maintainer but I just attempted to build fldigi and ran into the following
> issue:
>
> checking for fltk-config... /usr/bin/fltk-config
> /usr/bin/fltk-config: line 3: exec: fltk-config-unknown: not found
> configure: error: /usr/bin/fltk-config failed
>
> From a local rebuild attempt of fltk I see:
> mv
>
> /builddir/build/BUILDROOT/fltk-1.3.8-3.fc38.x86_64/usr/bin/fltk-config
> /builddir/build/BUILDROOT/fltk-1.3.8-3.fc38.x86_64/usr/bin/fltk-config-unknown
> install -p -m755 -D /builddir/build/SOURCES/fltk-config.sh
>
> /builddir/build/BUILDROOT/fltk-1.3.8-3.fc38.x86_64/usr/bin/fltk-config
>
> Which seems strange until I took a loot at the FLTK specfile:
>
> # we only apply this hack to multilib arch's
> %ifarch x86_64 %{ix86} ppc64 ppc s390x s390 sparc64 sparc
> %global arch %(uname -i 2>/dev/null || echo undefined)
> mv $RPM_BUILD_ROOT%{_bindir}/fltk-config \
>    $RPM_BUILD_ROOT%{_bindir}/fltk-config-%{arch}
> install -p -m755 -D %{SOURCE1} $RPM_BUILD_ROOT%{_bindir}/fltk-config
> %endif
>
> Obviously this has been in place for a VERY long time but the only use
> case I can think of is to have fltk-devel installed from two
> different arches, i686 and x86_64 for instance.
>
> Could this have anything to do with the systemd-nspawn change? Could it
> have caused `uname -i` to no longer resolve correctly?
>
> Does this really need to be supported at this point?
>
> Thanks,
> Richard
> _______________________________________________
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue

[Richard Shaw]

On Sat, Aug 27, 2022 at 1:19 PM Vincent Mihalkovic 
wrote:
> Hello,
>
> from related https://bugzilla.redhat.com/show_bug.cgi?id=2121153#c1 (fltk
> bugzilla):
>      "It should use `uname -m` rather than `uname -i`, which has been
> documented as non-portable since 2015"

I would like to remove its use completely.

Perhaps I should and see if anyone complains? i686/x86_64 is the only
multi-arch left and there can't be that many people developing for both at
the same time on one machine natively (builds in mock would still work
fine).

Thanks,
Richard

[John Reiser]

> ... there can't be that many people developing for both at the same time on one machine natively (builds in mock would still work fine).

I use only one machine (a x86_64) and no 'mock' to develop the same software
for both x86_64 and i686.  For i686 I start with "dnf install glibc-devel.i686"
and "export CC=gcc -m32".  I also replace "$(uname -m)" with "$TARGET_ARCH"
after setting "export TARGET_ARCH=...".

[Richard Shaw]

On Sun, Aug 28, 2022 at 6:08 PM John Reiser  wrote:
> > ... there can't be that many people developing for both at the same time
>
> on one machine natively (builds in mock would still work fine).
>
> I use only one machine (a x86_64) and no 'mock' to develop the same
> software
> for both x86_64 and i686.  For i686 I start with "dnf install
> glibc-devel.i686"
> and "export CC=gcc -m32".  I also replace "$(uname -m)" with "$TARGET_ARCH"
> after setting "export TARGET_ARCH=...".

What I mean is that the only use case would be having both fltk-devel.i686
and fltk-devel.86_64 installed simultaneously.

Thanks,
Richard