Re: Fedora 34 Change proposal: Remove make from BuildRoot (System-Wide Change)

[Steven Munroe]

From: https://fedoraproject.org/wiki/Changes/Remove_make_from_BuildRoot
"The packager guidelines will need to
be updated to mention that BuildRequires: make is now required for all
packages that need make."

Seems like using a canon to swat flies. It seems to widely distribute
pain without clearly articulated gain to the community.


Richard Shaw: said Nov 4 12:50pm:
"Or would pulling in autotools/automake/cmake suffice? "

I like this better. Any BuildRequires including libtool and or
autoconf should be able to assume make.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: btrfs and default page sizes (4k vs 64k)

[Steven Munroe]

The correct solution for userland is getpagesize() from .

This API has been there a long time.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Disable LTO for now ?

[Steven Munroe]

Jakub Jelinek writes:

> For targets which do support the target attribute, each
> function should be marked with the right set of options
> before streaming it,

Looking at the source (opencv 4.3.0) I can not find any usage of
__attribute__ ((target)) or #pragma ... optimization associated with ppc
specific code.

What I did find was a blind usage of

// absolute difference
#ifndef vec_absd
#   define vec_absd(a, b) vec_sub(vec_max(a, b), vec_min(a, b))
#endif

ie if vec_absd is defined use it otherwise fake it.

and vec_absd will be defined in altivec,h (for gcc 9/10)  #ifdef
__POWER9_VECTOR__

As I have found (repeatedly) this is not good enough.  PVECLIB Building
Multi-target Libraries
 I suspect
this is another case that does not work when mixing targeted objects in LTO.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Disable LTO for now ?

[Steven Munroe]

Sergio writes:

> Hello opencv [1] build also failed around LTO

Looking at the build logs:

https://koji.fedoraproject.org/koji/taskinfo?taskID=48055082

For the build.log that ends with:

lto1: error: '__builtin_altivec_vadub' requires the '-mcpu=power9' option
lto1: fatal error: target specific builtin not available
compilation terminated.

The build uses a mix of compiler options.

-mcpu=power8 -mtune=power8
and
-mcpu=power9 -mtune=power9
and sometimes
-mcpu=power8 ... -mcpu=power9 -mtune=power9

I suspect this works at the level of individual object (*.o)
generation but this might cause problems when a mix of -mcpu=power8
and -mcpu=power9 objects are combined in LTO optimization.

The compiler might get confused.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Disable LTO for now ?

[Steven Munroe]

Jeff Law wrote:

> For ppc64le is that the build was done with p8, but there is one
> function (__builtin_altivec_vadub) that requires p9. This seems
> like a package bug at first glance, not an LTO issue.

Yup __builtin_altivec_vadub is POWER9_VECTOR only.

For P8/6 use something like this:

  vmin = vec_min (a, b);
  vmax = vec_max (a, b);
  result = vec_sub (vmax, vmin);

executes in 4 cycles.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: How do Fedora developers get access to devtoolset for testing.

[Steven Munroe]

Dave Love writes:

> It surprises me if that's IBM experience, and it's a bit worrying for our
new system.

I no longer speak for IBM (retired) so more of a personal Linux for POWER
opinion. But the Advance Toolchain (AT)

provides
the counter example and as it's on the 13th release (follows GCC releases,
AT14 coming soon) I would say useful and valid. AT does separate builds for
each distro it supports but the RHEL 8 build, installs on Fedora.

Full disclosure, AT was my  idea. The goal was to enable new POWER hardware
feature for customers, who insisted on running old (stable) distributions.

Now it is likely DevToolSet has different and conflicting goals. I am
willing to accept that and move on.

> Really, it isn't necessary, any more than it was for me on the Fedora
development system.

Well it is, as PVECLIB supports BE and LE. And a chroot will not handle
that.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: How do Fedora developers get access to devtoolset for testing.

[Steven Munroe]

Dave Love; writes:
...
> I'm pretty sure I said to do that a while ago, like I did when
> testing the trivial patch that I didn't expect to cause such trouble.

You probably did say so ;)

I come from a different culture and experience. I am not as conversant
in Fedorian as I should be. So I tend to misunderstand what is plain
to you all.

From my experience, installing (something like) devtoolset on Fedora
was not an outlandish idea, Apparently it is.

So installing a centos 7 VM instance on my local power8 seems like a
better option.

Thanks
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: How do Fedora developers get access to devtoolset for testing.

[Steven Munroe]

Jonathan Wakely wrote:
> Why are you asking fedpkg to build for f33 if you are trying to
> package something for el7 and el8?

I am trying to get better turn around for myself as I have local
access to a POWER8 machine. And I was having difficulty debug the
weird failure I was seeing.

> That submits a build to koji, to build it using the packages
> available in the f33 buildroot.

Yup "fedpkg --release epel7 scratch-build".  was also failing because
of some difference in the spelling of "*debug" files, that was unique
to el7 required a change in the spec file. A local build would have
been a lot quicker than koji

> There are several ways to build for el7 or el8:

That helps thanks.

> What you're trying to do now seems to be to create a
> frankenstein system containing bits of fedora and bits of el7,

Well to me devtoolset looks a lot like the Advance Toolchain which I
have been using on Linux since 2013 It is available  on various
distros including Ubuntu and Fedora.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: How do Fedora developers get access to devtoolset for testing.

[Steven Munroe]

On 20/07/20 17:08 +0100, Jonathan Wakely wrote:
...
Why can't you install it in an On 20/07/20 17:08 +0100, Jonathan Wakely wrote:
...
Why can't you install it in an EL7 mock chroot, as suggested earlier?
There's nothing special about devtoolset here, EL7 packages just
aren't meant to work on F32.

Then I would have to learn what a "EL7 mock chroot" is. And how it is
different from "rpmbuild " and "fedpkg  --release f33
scratch-build". The documentation is a bit sparse ...
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: How do Fedora developers get access to devtoolset for testing.

[Steven Munroe]

That looks like a more complete list. Still having problems with dependencies:

$ sudo dnf install devtoolset-9-gcc-9.3.1-2.el7.ppc64le.rpm
devtoolset-9-gcc-c++-9.3.1-2.el7.ppc64le.rpm
devtoolset-9-runtime-9.1-0.el7.ppc64le.rpm
devtoolset-9-libstdc++-devel-9.3.1-2.el7.ppc64le.rpm
Last metadata expiration check: 0:11:27 ago on Mon 20 Jul 2020 10:40:31 AM CDT.
Error:
 Problem 1: conflicting requests
  - nothing provides libmpfr.so.4()(64bit) needed by
devtoolset-9-gcc-9.3.1-2.el7.ppc64le
 Problem 2: conflicting requests
  - nothing provides libmpfr.so.4()(64bit) needed by
devtoolset-9-gcc-c++-9.3.1-2.el7.ppc64le

But:

$ sudo dnf install mpfr
Last metadata expiration check: 0:12:04 ago on Mon 20 Jul 2020 10:40:31 AM CDT.
Package mpfr-4.0.2-4.fc32.ppc64le is already installed.
Dependencies resolved.

So devtoolset must want a "special" mpfr but it is not obvious which
devtoolset package provides.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: How do Fedora developers get access to devtoolset for testing.

[Steven Munroe]

Kevin Kofler wrote:
>http://mirror.centos.org/centos/7/sclo/x86_64/rh/

I was looking for ppc64le but I think found a source at:

https://cbs.centos.org/koji/buildinfo?buildID=27175

Thanks.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

How do Fedora developers get access to devtoolset for testing.

[Steven Munroe]

So my project (pveclib) was requested for el7/8 which means building with
devtoolset-9.

With a spec file enabled for el7, the local rpmbuild's fail if you don't
have devtoolset installed. The error message was less than helpful.

So if you can use fedpkg scratch-build devtoolset is preinstalled.

But if you have bugs in your spec file (and as a newbie, I often do) then
you also get failures with less than helpful status.

FAILED: BuildError: error building package (arch ppc64le), mock exited
with status 1; see build.log or root.log for more information

In my case I had to remove all the el7 bits from my spec file and test with
rpmbuild to find the problem.

So having devtoolset installed locally would be helpful.

Thanks in advance
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

PVECLIB version bump (with new IFUNC runtime libraries)

[Steven Munroe]

So I think I am ready to release version 1.0.4 of the Power Vector Library.

The big addition is multiple (128-bit) vector quadword arithmetic
introduced with the new vec_int512_ppc.h. This header actually provides
support for 2048x2048 bit multiplies with all intermediate values held in
(64x128-bit) vector registers.

This eliminates memory side channel exposure which may be of interest to
the crypto folks.

Of course a straight-line implementation of a 2048x2048 bit multiply can
get a little large. So creating callable runtime libraries is appropriate.
As the PowerISA has evolved, the optimum instructions and instruction
sequences vary across power7/8/9

So PVECLIB now builds runtime libraries containing multiple (platform
specific) implementations of the int512 arithmetic operations. Both a
static archive
(with platform specific suffixes) and DSO with IFUNC resolvers are provided.

So working some last minute details for the build system and doxygen for
building the multiple platform libraries.

So guidance on the next steps will be appreciated.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change

[Steven Munroe]

Jeff Law wrote:
> I'd respectfully disagree. There are certain features that GCC supports that 
> Clang does not
> and vice-versa. But broadly they are comparable. What this means is some 
> projects that are
> using bleeding edge features may have a hard need for one toolchain or the 
> other. And the
> proposal I've made accounts for that by allowing the upstream project to 
> select the compiler.
> In your case it would be GCC. For others it could well be Clang/LLVM.

I respectfully disagree with your definition of bleeding edge ...

IEEE-754-2008 (defined both Float128 and Decimal32/64/128.
C11 includes the above in annex F.

It seems like so long ago ;)

Last I checked this is 2020 and GCC/GLIBC has made good progress
implementing these standards. GCC supports several platforms
(including PPC64LE) with hardware  implementations for both types. The
hard work has been done and Clang can leverage the run-time and
standard headers directly.

And while you allow that some packages have good reasons to stick with
GCC. Several others on this list have demanded that clang/LLVM replace
GCC as the default compiler.

I respectfully restate my position that clang/LLVM is incomplete and
not ready for that role.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change

[Steven Munroe]

I would also add that Clang/LLVM is missing some of the newer C
language revisions at least for the pppc64le target.

Both IEEE/ISO  _Float128 and _Decimalxx support is missing. Ie the
type is not supported or if supported basic arithmetic and math.h
support is missing. Also finding bugs for in-line assembly and missing
constraints needed to work around the missing language features.

Also Clang's poor support for constant folding makes using __int128
(and vector __int128) harder than it needs to be.

This is a significant impact for enabling my project (PVECLIB) for
Clang. As-is a number of project features have been disabled for
Clang.

I think Clang needs more time to cook.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: What CPU extensions can we assume are available by arch?

[Steven Munroe]

>Kevin Kofler wrote:
>>Dave Love wrote:
>> As far as I can tell, it doesn't do dynamic dispatch.  Experimentally,
>> if you build with -mavx2 and run on ivybridge (or for skx and run on
>> haswell), the test code generates illegal instruction errors.  It's some
>> time ago since I looked at it, and I don't remember, but that's probably
>> why I thought it wasn't very useful, apart from only having x86 and arm
>> support.
>
>That's because it is a header-only library. It is either hard (and non-
>portable) or impossible to do dynamic dispatch in a header-only library,
>depending on the compiler and compiler version. (At least in past GCC
>versions, it was impossible. This may or may not have improved since.)
>Hence, dynamic dispatch, if desired, is left to the client application.
And
>I agree that this makes the library mostly useless.

Less useful then we would like. But could be part of the larger solution.
Properly structured they could help (not impede) building shared objects
with multiple implementations and dynamic selection for vector codes.

>You need an actual shared object with actual functions to do dynamic
>dispatch nicely and transparently.

I think the problem is lack of good documentation and examples. And perhaps
motivation. GLIBC has been doing this some time, but at the time is was
hard and difficult. But the compiler and runtime infrastructure has
improved since. Perhaps we can make this simple enough for wide application
to higher level libraries.

I am finding for the implementation of pveclib, that vector multiple
quadword (128-bit) precision multiplies are large enough, that you don't
want to expanded them in-line. But the vector multiply quadword itself and
the operations that implement it can and should be inline (for ppc64le). So
I was forced to cross that boundary.

Give me some time and I will have a documentation/examples that might
general useful.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: What CPU extensions can we assume are available by arch?

[Steven Munroe]

Dan writes:
>> Dave Love writes:
>> Well, what I've already said from some experience and research. Where's the 
>> POWER and >>S390 support? All I saw is x86 and arm. We've heard there's 
>> ppc64le compatibility support
>>anyhow, which is rising
>
>gcc provides compat x86 intrinsics via "x86intrin.h", they were successfully 
>used eg.
>by darktable (raw photo sw)

Yes there are some, looks like GCC8 and later. This is what is in GCC9:
$ find /opt/at13.0/ -name '*intrin.h'
/opt/at13.0/lib/gcc/powerpc64le-linux-gnu/9.2.1/include/bmi2intrin.h
/opt/at13.0/lib/gcc/powerpc64le-linux-gnu/9.2.1/include/mmintrin.h
/opt/at13.0/lib/gcc/powerpc64le-linux-gnu/9.2.1/include/x86intrin.h
/opt/at13.0/lib/gcc/powerpc64le-linux-gnu/9.2.1/include/htmintrin.h
/opt/at13.0/lib/gcc/powerpc64le-linux-gnu/9.2.1/include/pmmintrin.h
/opt/at13.0/lib/gcc/powerpc64le-linux-gnu/9.2.1/include/htmxlintrin.h
/opt/at13.0/lib/gcc/powerpc64le-linux-gnu/9.2.1/include/xmmintrin.h
/opt/at13.0/lib/gcc/powerpc64le-linux-gnu/9.2.1/include/tmmintrin.h
/opt/at13.0/lib/gcc/powerpc64le-linux-gnu/9.2.1/include/emmintrin.h
/opt/at13.0/lib/gcc/powerpc64le-linux-gnu/9.2.1/include/bmiintrin.h
/opt/at13.0/lib/gcc/powerpc64le-linux-gnu/9.2.1/include/smmintrin.h

So most of SSE, but not AVX yet.

If course this is compromise. May not be as optimal of a native
PowerISA implementation on POWER (CISC vs RISC out-of-order,
super-scalar ). This is what PVECLIB is for.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: What CPU extensions can we assume are available by arch?

[Steven Munroe]

Kevin Kofler wrote

>>Florian Weimer wrote:
>>...
>> In general, that is not true. You can use the target function attribute
and function
>> multiversioning instead in many cases.

>This may (or may not) have been recently fixed, but last I checked,
intrinsics for a vector
>instruction set XYZ2 were only available with the corresponding -mxyz2
flag, which could
>only be set per compilation unit (attempting to use the recently
introduced flag pragmas for
>this purpose was not supported either), and which would lead to GCC in
some cases
>(out of the library programmer's control) using XYZ2 instructions also in
other functions.
>As a result, the only safe way was to put all XYZ2 code in a separate
compilation unit
>compiled with -mxyz2 (and only that compilation unit can use that flag).
Has that situation
> mproved recently (and how so)?
>
>And that is just for C or non-template C++ code. C++
> template instantiations make the situation even messier.

Yes still true. I encounter this implement vec_int512_ppc.h for pveclib.
There a easy to use work around described here Putting the library in
PVECLIB. I
will not claim this is elegant but it does work.

My goal (pveclib) is to make it easier to write vector codes that CAN be
used in functions that CAN be built for multiple processor targets and
dynamic selection. My case is simpler then x86 (and SIMDE) as for ppc64le I
only have to deal with power8/9.

This a hard problem, and not solution is ease or perfect. But we can improve
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: What CPU extensions can we assume are available by arch?

[Steven Munroe]

> Again it's not the binaries. People need to build with it. But do not need to 
> distribute it for
> each project. For the better user experience, we are promoting the system 
> library for both
> RPM and Debian based Linux distributions.

Again compiling with an "enhanced API" like simde or pveclib is only
the first step to delivering a optimized package library (LPCNet in
this example). Most application developers do not rebuild from source.
They want the package installed from distro to be optimized for their
platform.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: What CPU extensions can we assume are available by arch?

[Steven Munroe]

Jun Aruga writes:

> I recommend using the simde (SIMD Everywhere) library for the packaging
and contribution
> to the upstream. https://github.com/nemequ/simde

This does not help unless the project LPCNet maintainers are willing to
built the fat binaries and support dynamic selection. Otherwise every user
is rebuilding from source.

> You do not need to care about the availability by arch or compiler when
using this library.

This is exactly what the Power Vector Library PVECLIB
 is doing for ppc64le.
PVECLIB provides POWER7/8/9 VMX/VSX operations equivalent to 
while smoothing over compiler version and platform ISA differences. PVECLIB
also provides useful operations beyond the "Power Vector Intrinsic
Programming Reference" defined set (like Multiply 128-bit Quadword). Net
you can write using power9 operation extensions and still compile for
-mcpu=power7/8. PVECLIB provides the appropriate implementation.

Also for GCC (and I think Clang) provide ppc64le equivalent headers to
Intel MMX and SSE intrinsic headers (at least for SSE3 and some SSE4). This
could be more of a performance compromise (vs PVECLIB) but would be a place
to start if you have an existing SSE implementation and want to vectorize
ppc64le.

But again someone needs to build and distribute the fat binaries for each
project.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: What CPU extensions can we assume are available by arch?

[Steven Munroe]

There really two questions here. Will/can  Fedora automatically take
advantage of new instruction set architecture (ISA). And can my
project take advantage to new ISA.

The short answer is yes/maybe.

The longer answer is the mechanisms exist (built into the compilers
and runtime), but not all projects and packages take advantage of
these mechanisms (For example dynamic libraries can use platform based
library search or STTGNUIFUNC symbol type extension), and. The Kernel
and GLIBC usually do. This requires the platform maintainers to do
extra work. I don't think either is commonly used for general library
packages.

The distro/kernel/runtime/community will decide on a "base platform
ISA level" For PowerPC64le that is POWER8 (PowerISA-2.07B). This
includes VMX/VSX but not the POWER9 extensions like Float128 hardware
FP.
See: https://fedoraproject.org/wiki/Architectures/PowerPC

Of course the the distro (will/should) install on newer processors
(like POWER9) which has a larger ISA (more instructions).

The Linux kernel notified each process of the Platform and Hardware
Capabilities it the AUX Vector (Defined in the Application Binary
Interface Document for each platform). The compilers provide a easy to
use interface to interrogate this:
https://gcc.gnu.org/onlinedocs/gcc-9.3.0/gcc/Basic-PowerPC-Built-in-Functions-Available-on-all-Configurations.html#Basic-PowerPC-Built-in-Functions-Available-on-all-Configurations.
Similarly for x86.

This is the mechanism that the dynamic linker / runtime use to select
the best implementation (of for example memcpy or cosf128) based on
the platform (POWER8 vs POWER9).

This CAN be used by any project/package. I am working on documenting
this (implementing dynamic IFUNC selection for platform specific
optimizations) as part of the PVECLIB project. If interested send me a
note.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Something wrong with kernel-headers on fedora 30?

[Steven Munroe]

> To build a module, you need kernel-devel, and it needs to be the same version 
> as the
> kernel you are building against. kernel-devel can be parallel installed, so 
> you can have
> multiple versions. It is highly recommended that you run the 5.3.11 or newer 
> kernel
> packages at this point as well, since they fix a number of security issues.

Well I was able to find kernel-headers for 5.1.20 and 5.3.7 and the
build log (hptdrv.log) a successful build. But fedora is still not
happy with this driver.

[   11.043838] rsnvme: loading out-of-tree module taints kernel.
[   11.043843] rsnvme: module license 'Proprietary' taints kernel.
[   11.043844] Disabling lock debugging due to kernel taint
[   11.043981] rsnvme: module verification failed: signature and/or
required key missing - tainting kernel
[   11.045248] rsnvme:RocketNVMe RAID controller driver v1.2.16 block major fc
[   11.048774] rsnvme:Found PLX upstream port (bus 4) (cmd 100507).
[   11.048970] rsnvme:Mapped Va 784f3ab3 size 690 874710b5

The 5.1.20 kernel will load desipte it pedantic unhappyness. But
something was install at some time that stops the 5.3.7 kernel is
early boot.

I can't get a screen snap of this error message because this is a
workstation install and does not have a root password (at least I
don't remember after all these years). All I can do is power off and
reboot into the 5.1.20 kernel.

Basically in 5.3.7 dracut-pre-udev is extremely unhappy as modprobe
fails for rsnvme.ko in /lib/modules/5.3.7... Put the machine in
emergency mode and demands a root password (Control D to continue does
not help). Again this does not happen with 5.1.20. Something has
changed.

So rsnvme.ko is the scsi driver for the HighPoint RAID adapter. OK I
can uninstall the rsnvme driver and then use the fedora nvme block
drivers and soft-RAID (at 1/2 the performance).

But that does not help with dracut modprobe of rsnvme. The 5.1.20
kernel complains but boots to a logon. The 5.3.7 kernel just dies
every time.

What I can seefind is a /lib/dracut/modules.d/40hptdrv/ directory with
two script files and one does do a modprobe rsnvme. So I can guess
that removing this might help with 5.3.7 problem.

But editing these files directly does not help. So I suspect extreme
cleverness where these files are are not used at boot.

So is there dracut (or something) command that will remove the hptdrv
driver component from dracut and the kernal, so that I can actually
this system.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: fatal error: x86intrin.h: No such file or directory

[Steven Munroe]

> Does it work in mock on non-x86? x86intrin.h is x86-specific header and won't
> be present on other arches, but it looks like it's included unconditionally.

Weill not exactly.
gcc-trunk/trunk$ find ./ -name x86intrin.h
./gcc/config/i386/x86intrin.h
./gcc/config/rs6000/x86intrin.h

PPC has functionally equivalent x86 intrinsic headers for MMX through SSE4,?

./gcc/config/rs6000/htmintrin.h
./gcc/config/rs6000/mmintrin.h
./gcc/config/rs6000/pmmintrin.h
./gcc/config/rs6000/xmmintrin.h
./gcc/config/rs6000/bmi2intrin.h
./gcc/config/rs6000/smmintrin.h
./gcc/config/rs6000/emmintrin.h
./gcc/config/rs6000/htmxlintrin.h
./gcc/config/rs6000/tmmintrin.h
./gcc/config/rs6000/bmiintrin.h
./gcc/config/rs6000/x86intrin.h

So it may work there, but is unlikely to work on any other platform.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Something wrong with kernel-headers on fedora 30?

[Steven Munroe]

> kernel-headers is related to the userspace API and is not tied to a 
> particular kernel version.
> If the userspace API doesn't change there's no need to rebuild. Is there a 
> problem you're
> seeing by not having an updated kernel-headers?

That does not be it works in all cases.

I have Highpoint RSSD 7101A card with 2TB of NVME storage, which I
would like to use!

With the latest Fedora 30 update (5.3.7) the kernel will not boot
because the modprobe can find the driver (rsnvme).

Interestingly the two previous kernels (5.1.19 and 5.1.20) have the
same complaint but boot anyway. The HighPoint storage is not used for
normal Linux OS or /home

So what is different with the 5.3.7 kernel

So I download latest HighPoint RDDS 7101A driver and run there magic
build script.

Which fines three kernels:

compile:default boot kernel: /boot/vmlinuz-5.3.7-200.fc30.x86_64
dumpkernels:kernel installed
kernel-5.1.20-300.fc30.x86_64
kernel-5.1.19-300.fc30.x86_64
kernel-5.3.7-200.fc30.x86_64

And tries to build its driver against each kernel. But that fails because:
kernelver:
compile:kernel file /boot/vmlinuz-5.3.7-200.fc30.x86_64 version
5.3.7-200.fc30.x86_64 [default boot kernel]
installkerndev:install kerneldev 5.3.7-200.fc30.x86_64
installkerndev:install package kernel-core-devel-5.3.7-200.fc30
Error: Unable to find a match: kernel-devel-5.3.7-200.fc30
compile:kernel 5.3.7-200.fc30.x86_64 does not contain kernel headers, active[1].

Ok so I install kernel-devel and get 5.3.11-200.fc30
and install kernel-headers and get 5.3.6-200.fc30

I run the HighPoint driver build again and it fails again because none
of the installed kernels have matching headers.

And I cant find any way to convince the 5.3.7 kernel not to care about
the missing rsnvme driver. And I cant seem to find the matched kernel
headers for the kernel fedora desided to install

I am stuck here. I really don't want to be forced into a clean
reinstall And I really want to be able to use this fast NVME storage.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: [Test-Announce] Fedora 31 Candidate Beta-1.1 Available Now!

[Steven Munroe]

Thanks!

On Thu, Sep 26, 2019 at 10:31 AM Adrian Reber  wrote:

> On Thu, Sep 26, 2019 at 09:34:11AM -0500, Steven Munroe wrote:
> > Wed, 25 Sep 2019 11:38:45 -0700 Kevin Fenzi  wrote
> >
> > >> Can you now try:
> > >>
> > >> curl -v
> > '
> https://download-ib01.fedoraproject.org/pub/fedora-secondary/development/31/Everything/ppc64le/os/
> '
> >
> > Attached file curlv.homer54.txt
> >
> > >> (Note that that mirror has a ipv6 address, so if you have a routable
> > >> ipv6 address and something is messed up with your ipv6 connectivity
> you
> > >> might be trying to hit that)?
> >
> > Not real my area of expertise.
> > Attached file ifcfg-eth0.homer54.txt
> >
> > >> Does 'dnf -v ...your command' give anything more here?
> >
> > perhaps. examples:
> >
> > Unknown configuration value: failovermethod=priority in
> > /etc/yum.repos.d/fedora-updates-modular.repo; Configuration:
> > OptionBinding with id "failovermethod" does not exist
> >
> > and
> >
> > Cannot download
> > '
> https://mirrors.fedoraproject.org/metalink?repo=updates-testing-modular-f31=ppc64le
> ':
> > Cannot prepare internal mirrorlist: file "repomd.xml" was not found in
> > metalink.
> > Failed to download metadata for repo 'updates-testing-modular'
> > Error: Failed to download metadata for repo 'updates-testing-modular'
>
> This (broken updates-testing-modular-f31) should be fixed in the
> MirrorManager database now and these changes should be active in 1 or 2
> hours.
>
> Adrian
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: [Test-Announce] Fedora 31 Candidate Beta-1.1 Available Now!

[Steven Munroe]

Wed, 25 Sep 2019 11:38:45 -0700 Kevin Fenzi  wrote

>> Can you now try:
>>
>> curl -v
'https://download-ib01.fedoraproject.org/pub/fedora-secondary/development/31/Everything/ppc64le/os/'

Attached file curlv.homer54.txt

>> (Note that that mirror has a ipv6 address, so if you have a routable
>> ipv6 address and something is messed up with your ipv6 connectivity you
>> might be trying to hit that)?

Not real my area of expertise.
Attached file ifcfg-eth0.homer54.txt

>> Does 'dnf -v ...your command' give anything more here?

perhaps. examples:

Unknown configuration value: failovermethod=priority in
/etc/yum.repos.d/fedora-updates-modular.repo; Configuration:
OptionBinding with id "failovermethod" does not exist

and

Cannot download
'https://mirrors.fedoraproject.org/metalink?repo=updates-testing-modular-f31=ppc64le':
Cannot prepare internal mirrorlist: file "repomd.xml" was not found in
metalink.
Failed to download metadata for repo 'updates-testing-modular'
Error: Failed to download metadata for repo 'updates-testing-modular'

Attached file dnfv.homer54.txt
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed

  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0* 
  Trying 152.19.134.145:443...
* TCP_NODELAY set
* Connected to download-ib01.fedoraproject.org (152.19.134.145) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [93 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [2862 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [589 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [70 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: C=US; ST=North Carolina; L=Raleigh; O=Red Hat Inc.; 
CN=*.fedoraproject.org
*  start date: Feb  1 00:00:00 2017 GMT
*  expire date: May  1 12:00:00 2020 GMT
*  subjectAltName: host "download-ib01.fedoraproject.org" matched cert's 
"*.fedoraproject.org"
*  issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=DigiCert SHA2 High 
Assurance Server CA
*  SSL certificate verify ok.
} [5 bytes data]
> GET /pub/fedora-secondary/development/31/Everything/ppc64le/os/ HTTP/1.1
> Host: download-ib01.fedoraproject.org
> User-Agent: curl/7.65.3
> Accept: */*
> 
{ [5 bytes data]
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Date: Thu, 26 Sep 2019 14:15:32 GMT
< Server: Apache
< X-Frame-Options: DENY
< X-Xss-Protection: 1; mode=block
< X-Content-Type-Options: nosniff
< Referrer-Policy: same-origin
< Content-Security-Policy: default-src 'none'; img-src 'self'
< Strict-Transport-Security: max-age=31536000; preload
< AppTime: D=12551
< X-Fedora-AppServer: download-ib01.fedoraproject.org
< Content-Length: 1590
< Content-Type: text/html;charset=ISO-8859-1
< 
{ [5 bytes data]

100  1590  100  15900 0   4184  0 --:--:-- --:--:-- --:--:--  4173
* Connection #0 to host download-ib01.fedoraproject.org left intact


 
  Index of 
/pub/fedora-secondary/development/31/Everything/ppc64le/os
 
 
Index of /pub/fedora-secondary/development/31/Everything/ppc64le/os
 Name   
  Last 
modified  Size  Description Parent 
Directory  -   
 Packages/ 
   2019-09-26 09:06-   
 boot/ 
   2019-09-26 08:12-   
 images/ 
 2019-09-26 14:00-   
 media.repo  
 2019-09-25 09:30   95   
 ppc/   
  2019-09-26 08:12-   
 repodata/ 
   2019-09-26 14:00-   


TYPE=Ethernet
PROXY_METHOD=none
BROWSER_ONLY=no
BOOTPROTO=none
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no
IPV6_ADDR_GEN_MODE=stable-privacy
NAME=eth0
UUID=9b07c96c-c612-3fed-a8a7-b62d8a1fb702
DEVICE=eth0
ONBOOT=yes
AUTOCONNECT_PRIORITY=-999
IPADDR=192.168.1.36
PREFIX=24
GATEWAY=192.168.1.1
DNS1=71.10.216.1
IPV6_PRIVACY=no
MTU=1500
DNS2=8.8.8.8
Loaded plugins: builddep, changelog, config-manager, 

Re: [Test-Announce] Fedora 31 Candidate Beta-1.1 Available Now!

[Steven Munroe]

>> In the fedora 31 install? hhhmm don't have browser and cant install one 

> You should be able to use curl just fine...

$ curl 
'https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-31=ppc64le'
# repo = fedora-31 arch = ppc64le country = US
https://download-ib01.fedoraproject.org/pub/fedora-secondary/development/31/Everything/ppc64le/os/
http://mirrors.rit.edu/fedora/fedora-secondary/development/31/Everything/ppc64le/os/
https://pubmirror1.math.uh.edu/fedora-buffet/fedora-secondary/development/31/Everything/ppc64le/os/
http://mirror.math.princeton.edu/pub/fedora-secondary/development/31/Everything/ppc64le/os/
http://mirrors.kernel.org/fedora-secondary/development/31/Everything/ppc64le/os/
https://pubmirror2.math.uh.edu/fedora-buffet/fedora-secondary/development/31/Everything/ppc64le/os/
https://dl.fedoraproject.org/pub/fedora-secondary/development/31/Everything/ppc64le/os/

> Also, what is in /var/log/dnf.librepo.log for that repo?

/var/log/dnf.librepo.log is empty

$ ls -la /var/log/dnf.librepo.log
-rw-r--r--. 1 root root 0 Sep 24 13:22 /var/log/dnf.librepo.log
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: [Test-Announce] Fedora 31 Candidate Beta-1.1 Available Now!

[Steven Munroe]

>> Is it reproducible?

yes all attempts including
#dnf upgrade
#dnf install autoconf
#dnf install automake

all failed

>> Can you paste what you get if you go to:
>>
>> https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-31=ppc64le

In the fedora 31 install? hhhmm don't have browser and cant install one 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: [Test-Announce] Fedora 31 Candidate Beta-1.1 Available Now!

[Steven Munroe]

installed Fedora-Server-dvd-ppc64le-31_Beta-1.1.iso on a power8 PowerVM
instance.

The Installation itself was smooth but any attempt to install additional
packages failed with:

# dnf install gcc
Fedora Modular 31 - ppc64le - Test Updates   80 kB/s |  54 kB 00:00

Failed to download metadata for repo 'updates-testing-modular'
Error: Failed to download metadata for repo 'updates-testing-modular'

I am not sure what is expected at this point in the process.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Donate 1 minute of your time to test upgrades from F30 to F31

[Steven Munroe]

> Do you want to make Fedora 31 better? Please spend 1 minute of your time
and try to run [*]:
>
>   sudo dnf --releasever=31 --setopt=module_platform_id=platform:f31
--enablerepo=updates-testing distro-sync
>
> If you get this prompt:

On ppc64le power8 Fedora 30 server(?) image on PowerVM 2.1.1. install with
dev

Install25 Packages
Upgrade  1135 Packages

Total download size: 627 M
Is this ok [y/N]:

Looks good so far.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: ppc64le Rawhide VM issues

[Steven Munroe]

> My qemu boot command is currently:
> qemu-system-ppc64 -m 2048 -smp 2 -machine pseries -cpu power9 -hda  -cdrom 

Looks like you are running an LE image in the BE machine:

try qemu-system-ppc64le
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Contents of devel Digest, Vol 185, Issue 29... rpmlint: shared-lib-without-dependency-information

[Steven Munroe]

I have a similar problem with the proposed package pveclib. I my case I
have a data only libraries. I can eliminate the rpmlint error by forcing a
link to -lc But I am not sure the the appropriate solution.

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


>
> -- Forwarded message --
> From: Florian Weimer 
> To: "Miro Hrončok" 
> Cc: devel@lists.fedoraproject.org, Marcel Plch 
> Bcc:
> Date: Mon, 08 Jul 2019 15:25:27 +0200
> Subject: Re: rpmlint: shared-lib-without-dependency-information (parts of
> Python stdlib)
> * Miro Hrončok:
>
> > On 05. 02. 19 19:04, Miro Hrončok wrote:
> >> I've just spotted these when working on Python 3.8.0a1. This happens
> >> on 3.7 as well since GCC 9:
> >>
> >> python3-debug.x86_64: E: library-not-linked-against-libc
> >> /usr/lib64/python3.7/lib-dynload/_
> contextvars.cpython-37dm-x86_64-linux-gnu.so
> >> python3-debug.x86_64: E: library-not-linked-against-libc
> >> /usr/lib64/python3.7/lib-dynload/_
> testimportmultiple.cpython-37dm-x86_64-linux-gnu.so
> >>
> >> python3-libs.x86_64: E: library-not-linked-against-libc
> >> /usr/lib64/python3.7/lib-dynload/_
> contextvars.cpython-37m-x86_64-linux-gnu.so
> >> python3-test.x86_64: E: library-not-linked-against-libc
> >> /usr/lib64/python3.7/lib-dynload/_
> testimportmultiple.cpython-37m-x86_64-linux-gnu.so
> >>
> >>
> >> (Note that there are plenty of other extension modules that do not
> >> raise this error.)
> >>
> >> This doesn't happen with latest python3 built prior to the gcc update
> to 9.
> >>
> >> $ rpmlint -I library-not-linked-against-libc
> >> library-not-linked-against-libc:
> >>
> >> That isn't helpful either.
> >>
> >> I found a similar Debian thing [1] that says:
> >>
> >>  > It is theoretically possible to have a library which doesn't use any
> symbols
> >>  > from libc...
> >>
> >> Do I care? Should I fix something? I honestly have no idea.
> >>
> >> [1]
> https://lintian.debian.org/tags/library-not-linked-against-libc.html
> >
> >
> > We have new errors on F30+:
> >
> > python38.x86_64: E: shared-lib-without-dependency-information
> > /usr/lib64/python3.8/lib-dynload/_
> contextvars.cpython-38-x86_64-linux-gnu.so
> > python38.x86_64: E: shared-lib-without-dependency-information
> > /usr/lib64/python3.8/lib-dynload/_heapq.cpython-38-x86_64-linux-gnu.so
> > python38.x86_64: E: shared-lib-without-dependency-information
> > /usr/lib64/python3.8/lib-dynload/_
> testimportmultiple.cpython-38-x86_64-linux-gnu.so
> > python38.x86_64: E: shared-lib-without-dependency-information
> > /usr/lib64/python3.8/lib-dynload/_
> testinternalcapi.cpython-38-x86_64-linux-gnu.so
> >
> > rpmlint doesn't give much info:
> > $ rpmlint -I shared-lib-without-dependency-information
> > shared-lib-without-dependency-information:
> >
> >
> > But lintian again explains the issue:
> >
> https://lintian.debian.org/tags/shared-lib-without-dependency-information.html
> >
> > The listed shared library doesn't include information about which
> > other libraries the library was linked against. (When running "ldd
> > foo.so" ldd should report about these other libraries. In your case,
> > ldd just reports "statically linked".)
> >
> > I again think this is OK for Python extension modules.
> > Thoughts?
>
> It depends on the extension module.  For _contextvars, it's okay because
> it does not link against anything (glibc or otherwise).  Global C++
> destructors will not work because of unfulfilled weak reference to
> __cxa_finalize, but you probably do not care about that.
>
> rpmlint really should have a list of symbols from system libraries that
> need linking, otherwise there's always going to be false positives for
> such plugins.  (Although extension modules could link against libpython
> on Fedora because Fedora doesn't use the fat Python interpreter, unlike
> some other distributions.)
>
> Thanks,
> Florian
>
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Self Introduction: Steven Munroe

[Steven Munroe]

My name is Seven Munroe and have worked on Linux and POWER platform
enablement for the past 18 year. Including contributions to GLIBC and more
recently GCC. Now that I am retired I have some time to pursue development
and ecosystem projects of personal interest. My most recent project is the
Power Vector library which I like to contribute to Fedora and other
distros. I am new to package development but do have extensive knowledge of
PowerISA and vector programming. So I can also server of resource to answer
questions on these topics.

Thanks
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org