I was able to verify, btw, that Fedora 19 + Power8 outputs ppc64le for
uname -m so I assume it works correctly on EL7 as well. Testead via an IBM
machine hosted at the OSU Open Source Lab that we can access and use for
testing.
- Chuck
On Wed, Jun 8, 2016 at 10:33 AM, M Kelly wrote:
> Domen Vr
Domen Vrankar writes:
>
> > The strange thing is that CMAKE_HOST_SYSTEM_PROCESSOR (outputed by cmake
> > --system-information) uses the same "uname -m"
> > see Modules/CMakeDetermineSystem.cmake.
> >
> > So there is something odd to have one right and the other wrong...
>
> In that case it's qu
> The strange thing is that CMAKE_HOST_SYSTEM_PROCESSOR (outputed by cmake
> --system-information) uses the same "uname -m"
> see Modules/CMakeDetermineSystem.cmake.
>
> So there is something odd to have one right and the other wrong...
In that case it's quite possible that CPACK_RPM_PACKAGE_ARCHI
2016-06-08 9:45 GMT+02:00 Domen Vrankar :
> > I am working on an IBM Power8 RHEL7.2 system and we installed cmake 3.6
> > (default cmake from repo was 2.8.12?) but it seems when making a package
> > the arch is set incorrectly to x86_64 instead of ppc64le.
>
> I don't have access to a ppc with Lin
> I am working on an IBM Power8 RHEL7.2 system and we installed cmake 3.6
> (default cmake from repo was 2.8.12?) but it seems when making a package
> the arch is set incorrectly to x86_64 instead of ppc64le.
I don't have access to a ppc with Linux but it seems that 'uname -m'
(default that is use
Hi,
I am working on an IBM Power8 RHEL7.2 system and we installed cmake 3.6
(default cmake from repo was 2.8.12?) but it seems when making a package
the arch is set incorrectly to x86_64 instead of ppc64le.
Anyone have a clue if this cpack on this dist could get its arch wrong ?
cmake 3.5.1 on Ub