F37 Change: MinGW UCRT target (Self-Contained Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/F37MingwUCRT
== Summary ==
This proposal is to add the UCRT target & support from Fedora to the
MinGW cross-toolchains.
== Owner ==
* Name: [[User:elmarco| Marc-André Lureau]]
* Email: marcandre.lureau(a)redhat.com
== Detailed Description ==
The current mingw32 and mingw64 cross-toolchains provided by Fedora
target the MSVCRT (Microsoft Visual C++ Runtime). Since Visual Studio
15 & Windows 10, the default and recommended runtime is UCRT. See also
[https://www.msys2.org/docs/environments/#msvcrt-vs-ucrt MSVCRT vs
UCRT].
A new toolchain target triple `x86_64-w64-mingw32ucrt` and associated
binaries will be added.
Fedora MinGW macros will be provided to target UCRT, with ucrt64-*
prefix (ex: `ucrt64-meson`)
mingw-* libraries will be progressively adjusted to add the produced
ucrt64-* binaries.
Since mingw-*.spec are very repetitive and cumbersome to modify (each
mingw32, mingw64, ucrt package has to be defined manually, and this is
tedious and error-prone), a custom MinGW/Fedora tool or solution will
be proposed. In the meantime, packages can be modified to add manually
the new target.
[https://lists.fedoraproject.org/archives/list/mingw@lists.fedoraproject.o...
UCRT plans on mingw(a)lists.fedoraproject.org ]
== Benefit to Fedora ==
This change will allow to cross-compile projects to Windows with the
up to date C runtime & headers, and better c99 support. This should
allow to more easily mix binaries produced from different versions or
compilers as well.
== Scope ==
* Proposal owners:
** update the mingw filesystem, binutils, headers, gcc & winpthreads packages
** bootstrap the new toolchain
** propose a solution to simplify library packaging with the different targets
** update some common library packages, such as mingw-zlib
* Other developers:
** Progressively adjust the mingw-* packages to produce ucrt64-
packages, following the updated guidelines.
* Release engineering:
* Policies and guidelines:
https://fedoraproject.org/wiki/Packaging:MinGW packaging guideline
will be adjusted.
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
None
== How To Test ==
<pre>
$ x86_64-w64-mingw32ucrt-gcc test.c
$ /usr/bin/mingw-objdump -p a.exe | grep DLL
vma: Hint Time Forward DLL First
DLL Name: KERNEL32.dll
DLL Name: api-ms-win-crt-time-l1-1-0.dll
DLL Name: api-ms-win-crt-math-l1-1-0.dll
DLL Name: api-ms-win-crt-runtime-l1-1-0.dll
DLL Name: api-ms-win-crt-environment-l1-1-0.dll
DLL Name: api-ms-win-crt-private-l1-1-0.dll
DLL Name: api-ms-win-crt-heap-l1-1-0.dll
DLL Name: api-ms-win-crt-locale-l1-1-0.dll
DLL Name: api-ms-win-crt-stdio-l1-1-0.dll
DLL Name: api-ms-win-crt-string-l1-1-0.dll
</pre>
== User Experience ==
Windows binaries produced by Fedora cross-toolchain will target a more
modern and compatible C runtime, bringing hopefully better
compatibility & safety.
== Dependencies ==
None
== Contingency Plan ==
* Contingency mechanism: N/A (not a System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? No (not a System Wide Change)
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
The new MinGW toolchain and tools are available to compile binaries
targeting the Windows UCRT.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 2 months
F36 Change: Wayland by Default for SDDM (Self-Contained Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/WaylandByDefaultForSDDM
= Wayland by Default for SDDM =
== Summary ==
Change the default display server mode for SDDM to use a Wayland-based
greeter rather than an X11-based one.
== Owner ==
* Name: [[User:Ngompa|Neal Gompa]], [[User:Rdieter|Rex Dieter]],
[[User:Jgrulich|Jan Grulich]]
* Email: ngompa13(a)gmail.com, rdieter(a)gmail.com, jgrulich(a)redhat.com
* Product: KDE Spin, Kinoite
* Responsible WG: KDE SIG
== Detailed Description ==
With [https://github.com/sddm/sddm/pull/1393 the work done upstream in
SDDM to support using a Wayland based greeter] and
[[Changes/ReplaceFbdevDrivers|the introduction of SimpleDRM to fix the
broken fallback when platform drivers are unavailable]], it is now
possible for the Fedora KDE variants (the regular spin and Kinoite) to
move to Wayland for the login manager, which effectively completes the
switch to Wayland for these variants.
== Benefit to Fedora ==
As originally detailed in [[Changes/WaylandByDefaultForPlasma|the
Change to switch Plasma to Wayland by default]], Fedora is a leader in
advancing the adoption of the Wayland protocol as part of the overall
strategy to improve the Linux graphical software stack. We have been
successful in helping drive Wayland forward in the Plasma Desktop, and
we intend to do the same for SDDM.
== Scope ==
* Proposal owners:
** Upgrade {{package|sddm}} to the latest snapshot and introduce
mutually exclusive <code>sddm-wayland-generic</code> and
<code>sddm-x11</code> greeter configuration packages.
** Modify {{package|plasma-workspace}} to switch SDDM to Wayland
*** Enable installation of the SDDM Wayland configuration snippet and
ship as <code>sddm-wayland-plasma</code> that is mutually exclusive
with the other sddm greeter configuration packages. This package will
supplement {{package|sddm}} and <code>plasma-workspace-wayland</code>
to be automatically installed together.
** Modify <code>@kde-desktop</code> comps group for Fedora Linux 36 to
include <code>sddm-wayland-plasma</code> for the media.
* Other developers: N/A (not needed for this Change)
* Release engineering: [https://pagure.io/releng/issue/10536 #10536]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A
== Upgrade/compatibility impact ==
On upgrade to Fedora Linux 36, SDDM will be transparently switched
from the X11 greeter to the Wayland one leveraging kwin. In order to
override this, the user can do one of the following:
* Drop in a configuration file in <code>/etc/sddm.conf.d</code> to set
the display server back to X11
* Swap back to X11 with the configuration package: <code>dnf swap
sddm-wayland-plasma sddm-x11</code>
== How To Test ==
Once the SDDM and Plasma Wayland changes are made, Rawhide users can
try this by using nightly KDE ISOs and using them normally to install
and run a Rawhide KDE Plasma environment.
== User Experience ==
Ideally, there should be no noticeable impact on the user experience,
though users may notice that things operate more smoothly and with
slightly lower resources.
== Dependencies ==
This change is dependent on [[Changes/ReplaceFbdevDrivers|the Change
to replace fbdev with SimpleDRM]]. Without that Change, we will need
to keep SDDM using X11 because otherwise the fallbacks are broken when
drivers do not work.
== Contingency Plan ==
* Contingency mechanism: Update comps and {{package|plasma-workspace}}
so that <code>sddm-x11</code> is shipped instead.
* Contingency deadline: beta freeze
* Blocks release? Yes
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
SDDM, the login manager for the Fedora variants using the KDE Plasma
Desktop, now uses the Wayland display system.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 2 months
F37 Change: RetireARMv7 (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/RetireARMv7
== Owner ==
* Name: [[User:pbrobinson| Peter Robinson]]
* Email: <pbrobinson(a)fedoraproject.org>
== Detailed Description ==
The ARMv7 arm architecture was the second variant of the arm
architecture that Fedora has supported, the first was ARMv5, the third
is aarch64. The proposal is to retire ARMv7 as part of the Fedora 37
release. This will allow ARMv7/armhfp to be supported until the Fedora
36 end of life in around June 2023.
Overall arm32 is generally waning with generally few new ARMv7 devices
added to Fedora in recent releases. To add to that a number of newer
Fedora features designed to improve speed and security of the Fedora
release are causing 32 bit architectures in general primarily due to
the process memory limit when linking large applications. The
ARMv7/armhfp is the last fully supported 32 bit architecture, we still
currently build i686 packages, but it's not shipped as artefacts.
== Benefit to Fedora ==
The primary benefit is to maintainers of the ARM architecture, the
various toolchain teams and package maintainers in general.
== Scope ==
* Proposal owners: Work with rel-eng to disable the architecture in
koji, remove all the various pungi pieces and clean up any other
release detritus.
* Other developers: No action required.
* Release engineering: [https://pagure.io/releng/issue/10387 Releng
issue #10387] Disable a bunch of stuff, it's really just one koji
admin command and a PR for pungi config changes
* Policies and guidelines: No initial updates to policies and
guidelines as ARMv7 won't completely disappear until F-36 EOL.
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Any current users of Fedora on ARMv7 devices won't be able to upgrade
to Fedora 37, they will have to stay on Fedora 36 until it's EOL.
== How To Test ==
There's not really anything to test as it's removing the support for
an architecture.
== User Experience ==
Any current users of Fedora on ARMv7 devices won't be able to upgrade
to Fedora 37, they will have to stay on Fedora 36 until it's EOL.
== Dependencies ==
N/A.
== Contingency Plan ==
Continue on as before with the added advantage of the people that
protested the removal of the architecture will be actively
contributing to the maintenance of the architecture
* Contingency mechanism: Leave enabled. We basically won't get to this
if FESCo doesn't approve the change.
* Contingency deadline: Mass rebuild.
* Blocks release? Yes
* Blocks product? Yes
== Documentation ==
N/A
== Release Notes ==
Fedora Linux 37 with the ARMv7 architecture is retired into the
sunset. There will definitely be celebrations, there will likely be
some that shed some tears! Overall for the maintainers it will likely
be seen as a net win, for the few, generally shrinking, users it's
probably a net loss but they can probably just go and buy a Raspberry
Pi Zero 2W for US$15. ¯\_(ツ)_/¯
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 2 months
F36 Change: Enable exclude_from_weak_autodetect by default in LIBDNF
(System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/ExcludeFromWeakAutodetect
== Summary ==
exclude_from_weak_autodetect enables autodetection of unmet weak
dependencies (Recommends or Supplements) of installed packages and
blocks installation of packages satisfying already unmet dependencies.
In other words: When you don't have the recommended package installed,
it won't be automatically installed with future upgrades of the
recommending package.
== Owner ==
* Name: [[User:jmracek| Jaroslav Mracek]]
* Email: jmracek(a)redhat.com
== Detailed Description ==
The feature is designed to prevent an install of removed weak
dependencies from the system by users and to not install weak
dependencies missing after system deployment. It will change the
behavior of DNF, microdnf, and PackageKit. The feature will be
backported to all Fedoras, but in default, the feature will be off.
Additional information: https://bugzilla.redhat.com/show_bug.cgi?id=1699672
The default value for exclude_from_weak_autodetect configuration can
be overridden in `/etc/dnf/dnf.conf`
== Feedback ==
The feature was requested by [[User:Churchyard|Miro Hrončok]] and
supported by many others: See
[https://bugzilla.redhat.com/show_bug.cgi?id=1699672 rhbz#1699672] for
more feedback.
== Benefit to Fedora ==
After the installation of a fresh system, the first upgrade will not
install a lot of weak dependencies. Some of them were excluded from
the kick-start installation set for good reasons (security, image
size, minimal functional set, ...), but after the first update, all
weak dependencies are installed, therefore some features of deployment
simply disappear.
== Scope ==
* Proposal owners:
** The feature is ready in Pull Request -
https://github.com/rpm-software-management/libdnf/pull/1279
** PRs only wait for a release of libsolv
** The Feature will be enabled in upstream as default, therefore from
Fedora 36, we start to release libdnf without a revert patch of
default in comparison to upstream.
* Other developers: The change requires a new release of libsolv.
* Release engineering:
* Policies and guidelines: A packaging guideline should be added that
discourages or forbids weak dependencies on fully versioned
(sub)packages (see
[https://bugzilla.redhat.com/show_bug.cgi?id=1699672#c44 the
details]).
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
No manual changes will be required. After the libdnf update, this
feature will be on by default.
== How To Test ==
1. Install package without satisfied weak dependencies
2. Upgrade the upgrade. With exclude_from_weak_autodetect=true, it
will not install weak dependencies of already installed packages. With
exclude_from_weak_autodetect=false, weak dependencies will be
installed during upgrades.
== User Experience ==
The change in default will help to keep some values for particular
deployments (a minimal system will be still minimal without disabling
weak dependencies).
Users will be able to remove particular weak dependencies and they
will be not installed on the first upgrade.
In case when the feature will not work according to the user
expectation it can be switched off in the dnf configuration file.
== Dependencies ==
libsolv - Required code changes are already in the libsolv upstream.
We only wait for the next libsolv release.
== Contingency Plan ==
There are no external dependencies, therefore we can easily postpone
the feature and the change of default behavior.
* Contingency mechanism: (What to do? Who will do it?)
* Contingency deadline: beta freeze
* Blocks release? No
== Documentation ==
The feature will be documented in dnf man pages.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 2 months
Weirdness with clang and stdatomic.h on Rawhide
by Ron Olson
Hey all,
I’m troubleshooting an issue and came up with this sample program: https://pastebin.com/g9S8Z64q to demonstrate the problem. Basically, clang 13, on Rawhide, won’t compile that program, while on Fedora 35 it does.
The reason why is that on Rawhide, stdatomic.h exists under /usr/include/c++/12 while it does not exist on 35, so clang uses its built-in stdatomic per https://clang.llvm.org/docs/LanguageExtensions.html#c11-atomic-operations. If it uses its internal version, the sample program compiles fine.
Looking at stdatomic.h on Rawhide, I see it’s gated by “#if __cplusplus > 202002L”, so that means C++2b or later, not C++20. This seems to create a problem for clang which, since the file is present, wants to use it, but since it’s effectively empty due to the #ifdef, compiling of the sample program fails.
Is it possible to disable clang’s use of the header file as a flag? I’ve been unable to find anything like that, and obviously renaming the header is out of the question. Also, is it correct to the setting stdatomic.h to only be used by c++2b?
Thanks for any info,
Ron
2 years, 2 months
Why was node_exporter.service renamed to
prometheus-node-exporter.service?
by Barry Scott
I just had to fix a number of my servers that use node exporter.
The service name has been changed. Why was this done and did no one
think about the impact on users?
In the worst case I had a server fail to reboot because I had
Requires=node_exporter.service in the default target.
Barry
2 years, 2 months
Possibly non-responsive maintainer: olem
by Fabio Valentini
Hi everybody,
The Rust SIG and I have been waiting for responses from Olivier (FAS:
olem) for a while. I had noticed that their Rust packages started
accumulating FTBFS / FTI / release-monitoring bugs, as we get CCd on
those bugzillas. According to koji / dist-git / bodhi / pagure.io,
their last activity in Fedora happened on December 6, 2021, but zero
activity since then.
Initially I thought that this might be related to the holidays, so I
waited until January to reach out. A little over two weeks ago, I
tried contacting Olivier directly via the email address associated
with their FAS account, offering help with those Rust packages, but I
have not received a response, either.
Does anybody know how to contact Olivier, or if they're still
interested in maintaining their (Rust) packages?
Fabio
2 years, 2 months
Package notes feature causing build paths to be embedded
by Richard W.M. Jones
https://bugzilla.redhat.com/show_bug.cgi?id=2043092
This is not about the feature itself but about the way it has been
implemented.
During builds LDFLAGS is modified so it contains a build path,
something like:
-Wl,-dT,/builddir/build/BUILD/.package_note-rubygem-nio4r-2.5.2-6.fc36.x86_64.ld
Many builds embed/store LDFLAGS somewhere. For OCaml it gets embedded
in the ocamlopt binary, and in *.cma files. Similar sort of thing
happening in Ruby, Perl, Haskell, Python, ...
But the problem is more general than this too. It also turns up in
some *.pc (pkgconf) files.
I think this change should be reverted until a cleaner way can be
found to implement it.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
2 years, 2 months
hdf5 fortran build failure with gcc 12
by Orion Poplawski
hdf5 is starting to fail to build with gcc 12 in rawhide with:
make[2]: Entering directory
'/builddir/build/BUILD/hdf5-1.12.1/build/fortran/test'
/bin/sh ../../libtool --tag=FC --mode=link gfortran -std=f2008
-Waliasing -Wall -Wcharacter-truncation -Wextra -Wimplicit-interface
-Wsurprising -Wunderflow -pedantic -Warray-temporaries -Wintrinsics-std
-Wimplicit-procedure -Wreal-q-constant -Wfunction-elimination
-Wrealloc-lhs -Wrealloc-lhs-all -Wno-c-binding-type -Wuse-without-only
-Winteger-division -Wfrontend-loop-interchange -fdiagnostics-urls=never
-fno-diagnostics-color -s -O3 -I../../fortran/src -I../../fortran/src
-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches
-pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1
-m64 -mtune=generic -fasynchronous-unwind-tables
-fstack-clash-protection -fcf-protection -I/usr/lib64/gfortran/modules
-Wl,-z,relro -Wl,--as-needed -Wl,-z,now
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1
-Wl,-dT,/builddir/build/BUILD/hdf5-1.12.1/.package_note-hdf5-1.12.1-2.fc36.x86_64.ld
-fPIC -Wl,-z,now -Wl,--as-needed -o fortranlib_test_1_8 tH5O.o
tH5A_1_8.o tH5G_1_8.o tH5MISC_1_8.o tHDF5_1_8.o fortranlib_test_1_8.o
libh5test_fortran.la ../../test/libh5test.la
../../fortran/src/libhdf5_fortran.la ../../src/libhdf5.la -lsz -lz -ldl -lm
libtool: link: gfortran -std=f2008 -Waliasing -Wall
-Wcharacter-truncation -Wextra -Wimplicit-interface -Wsurprising
-Wunderflow -pedantic -Warray-temporaries -Wintrinsics-std
-Wimplicit-procedure -Wreal-q-constant -Wfunction-elimination
-Wrealloc-lhs -Wrealloc-lhs-all -Wno-c-binding-type -Wuse-without-only
-Winteger-division -Wfrontend-loop-interchange -fdiagnostics-urls=never
-fno-diagnostics-color -s -O3 -I../../fortran/src -I../../fortran/src
-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches
-pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1
-m64 -mtune=generic -fasynchronous-unwind-tables
-fstack-clash-protection -fcf-protection -I/usr/lib64/gfortran/modules
-Wl,-z -Wl,relro -Wl,--as-needed -Wl,-z -Wl,now
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1
-Wl,-dT
-Wl,/builddir/build/BUILD/hdf5-1.12.1/.package_note-hdf5-1.12.1-2.fc36.x86_64.ld
-fPIC -Wl,-z -Wl,now -Wl,--as-needed -o .libs/fortranlib_test_1_8 tH5O.o
tH5A_1_8.o tH5G_1_8.o tH5MISC_1_8.o tHDF5_1_8.o fortranlib_test_1_8.o
./.libs/libh5test_fortran.a ../../test/.libs/libh5test.a
../../fortran/src/.libs/libhdf5_fortran.so
/builddir/build/BUILD/hdf5-1.12.1/build/src/.libs/libhdf5.so
../../src/.libs/libhdf5.so -lsz -lz -ldl -lm
../../../fortran/test/tf.F90:169:33: warning: type of 'h5_fixname_c'
does not match original declaration [-Wlto-type-mismatch]
169 | full_name, full_namelen)
| ^
../../../fortran/test/t.c:43:1: note: type mismatch in parameter 6
43 | nh5_fixname_c(_fcd base_name, size_t_f *base_namelen, hid_t_f
*fapl, _fcd full_name, size_t_f *full_namelen)
| ^
../../../fortran/test/t.c:43:1: note: type 'void' should match type
'long int'
../../../fortran/test/t.c:43:1: note: 'h5_fixname_c_' was previously
declared here
../../../fortran/test/tf.F90:220:56: warning: type of 'h5_cleanup_c'
does not match original declaration [-Wlto-type-mismatch]
220 | hdferr = h5_cleanup_c(base_name, base_namelen, fapl)
| ^
../../../fortran/test/t.c:85:1: note: type mismatch in parameter 4
85 | nh5_cleanup_c(_fcd base_name, size_t_f *base_namelen, hid_t_f
*fapl)
| ^
../../../fortran/test/t.c:85:1: note: type 'void' should match type
'long int'
../../../fortran/test/t.c:85:1: note: 'h5_cleanup_c_' was previously
declared here
/usr/bin/ld: /tmp/ccYpA0p7.ltrans1.ltrans.o: warning: relocation against
`minusone.31' in read-only section `.text'
/usr/bin/ld: /tmp/ccYpA0p7.ltrans0.ltrans.o: in function
`__th5a_1_8_MOD_attribute_test_1_8.constprop.0':
/builddir/build/BUILD/hdf5-1.12.1/build/fortran/test/tf_gen.F90:84:
undefined reference to `minusone.46'
/usr/bin/ld: /tmp/ccYpA0p7.ltrans1.ltrans.o: in function
`__th5a_1_8_MOD_test_attr_info_by_idx.constprop.0':
/builddir/build/BUILD/hdf5-1.12.1/build/fortran/test/tf_gen.F90:84:
undefined reference to `minusone.18'
/usr/bin/ld:
/builddir/build/BUILD/hdf5-1.12.1/build/fortran/test/tf_gen.F90:84:
undefined reference to `minusone.18'
/usr/bin/ld:
/builddir/build/BUILD/hdf5-1.12.1/build/fortran/test/tf_gen.F90:84:
undefined reference to `minusone.18'
/usr/bin/ld:
/builddir/build/BUILD/hdf5-1.12.1/build/fortran/test/tf_gen.F90:84:
undefined reference to `minusone.18'
/usr/bin/ld: /tmp/ccYpA0p7.ltrans1.ltrans.o: in function
`__th5a_1_8_MOD_test_attr_delete_by_idx.constprop.0':
/builddir/build/BUILD/hdf5-1.12.1/build/fortran/test/tf_gen.F90:84:
undefined reference to `minusone.31'
/usr/bin/ld:
/builddir/build/BUILD/hdf5-1.12.1/build/fortran/test/tf_gen.F90:84:
undefined reference to `minusone.31'
/usr/bin/ld:
/builddir/build/BUILD/hdf5-1.12.1/build/fortran/test/tf_gen.F90:84:
undefined reference to `minusone.31'
/usr/bin/ld:
/builddir/build/BUILD/hdf5-1.12.1/build/fortran/test/tf_gen.F90:84:
undefined reference to `minusone.31'
/usr/bin/ld: warning: creating DT_TEXTREL in a PIE
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:999: fortranlib_test_1_8] Error 1
I have no idea what is going on here. Any clues?
--
Orion Poplawski
he/him/his - surely the least important thing about me
Manager of NWRA Technical Systems 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 https://www.nwra.com/
2 years, 2 months