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
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:
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
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
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:
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)
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
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
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.
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
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
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.
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
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.
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
>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,
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
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
> 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
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
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
> 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
> 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
> 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
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
> &g
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
>>
>> 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
>> 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
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
> 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.
> 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
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
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
33 matches
Mail list logo
