Hello team,
Upstream ispc updated to 1.10.0. Unfortunately, the build failed with broken clang++ compiler according to koji (https://koji.fedoraproject.org/koji/taskinfo?taskID=32150411)
Can someone investigate the issue? This package is needed by embree, a dependency for both Blender, luxcorerender and Yafaray.
Thanks
Luya
On Sun, Jan 20, 2019 at 11:36:22AM -0800, Luya Tshimbalanga wrote:
Hello team,
Upstream ispc updated to 1.10.0. Unfortunately, the build failed with broken clang++ compiler according to koji (https://koji.fedoraproject.org/koji/taskinfo?taskID=32150411)
Can someone investigate the issue? This package is needed by embree, a dependency for both Blender, luxcorerender and Yafaray.
Thanks
Luya
Hi Luya,
Clang does not support the -fstack-clash-protection flag. We used to silently ignore that flag but it's no longer the case. Why are you using clang to compile the package? The safe step is to use gcc, ot if clang is needed, to strip -fstack-clash-protection from the flags passed to clang, but that's not future-proof (clang may end up supporting that flag).
Hope it helps,
Serge
On 2019-01-22 8:17 a.m., Serge Guelton wrote:
Hi Luya,
Clang does not support the -fstack-clash-protection flag. We used to silently ignore that flag but it's no longer the case. Why are you using clang to compile the package? The safe step is to use gcc, ot if clang is needed, to strip -fstack-clash-protection from the flags passed to clang, but that's not future-proof (clang may end up supporting that flag).
Hope it helps,
Serge
Upstream reason. Trying to build with gcc will fail. See the attacked CMakeLists.txt from ispc-1.10.0
Luya
On 25/01/19 08:36 -0800, Luya Tshimbalanga wrote:
On 2019-01-22 8:17 a.m., Serge Guelton wrote:
Hi Luya,
Clang does not support the -fstack-clash-protection flag. We used to silently ignore that flag but it's no longer the case. Why are you using clang to compile the package? The safe step is to use gcc, ot if clang is needed, to strip -fstack-clash-protection from the flags passed to clang, but that's not future-proof (clang may end up supporting that flag).
Hope it helps,
Serge
Upstream reason. Trying to build with gcc will fail. See the attacked CMakeLists.txt from ispc-1.10.0
That says it wants to build with clang, but doesn't say why building with GCC will fail. Is it due to a GCC bug? Is it something we can fix?
On 2019-01-25 9:02 a.m., Jonathan Wakely wrote:
Upstream reason. Trying to build with gcc will fail. See the attacked CMakeLists.txt from ispc-1.10.0
That says it wants to build with clang, but doesn't say why building with GCC will fail. Is it due to a GCC bug? Is it something we can fix?
My bad as I quickly wrote before leaving to work. Here is the updated spec file and the result scratch build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=32250196
Luya
On Saturday, 26 January 2019 at 02:20, Luya Tshimbalanga wrote:
On 2019-01-25 9:02 a.m., Jonathan Wakely wrote:
Upstream reason. Trying to build with gcc will fail. See the attacked CMakeLists.txt from ispc-1.10.0
That says it wants to build with clang, but doesn't say why building with GCC will fail. Is it due to a GCC bug? Is it something we can fix?
My bad as I quickly wrote before leaving to work. Here is the updated spec file and the result scratch build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=32250196
Well, obviously existing CMakeLists file enforces the use of clang. The developers seem to have a strong preference for clang. The issue tracker has a couple of closed issues around this topic:
https://github.com/ispc/ispc/issues/1355 https://github.com/ispc/ispc/issues/1352
I would try patching out the clang requirement from CMakeLists and building with system gcc.
Regards, Dominik
On 2019-01-26 12:24 a.m., Dominik 'Rathann' Mierzejewski wrote:
I would try patching out the clang requirement from CMakeLists and building with system gcc.
Regards, Dominik
Done. Unfortunately, the build failed as the compiler still remains clang and finding the cause is beyond my knowledge. Here is the resulted scratch build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=32277096
Luya
* Luya Tshimbalanga:
On 2019-01-26 12:24 a.m., Dominik 'Rathann' Mierzejewski wrote:
I would try patching out the clang requirement from CMakeLists and building with system gcc.
Regards, Dominik
Done. Unfortunately, the build failed as the compiler still remains clang and finding the cause is beyond my knowledge. Here is the resulted scratch build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=32277096
Which sources are you building? Nothing like this is on the master branch on src.fedoraproject.org.
Thanks, Florian
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2019-01-27 2:00 p.m., Florian Weimer wrote:
- Luya Tshimbalanga:
On 2019-01-26 12:24 a.m., Dominik 'Rathann' Mierzejewski wrote:
I would try patching out the clang requirement from CMakeLists and building with system gcc.
Regards, Dominik
Done. Unfortunately, the build failed as the compiler still remains clang and finding the cause is beyond my knowledge. Here is the resulted scratch build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=32277096
Which sources are you building? Nothing like this is on the master branch on src.fedoraproject.org.
Thanks, Florian
I avoided committing the update as I preferred to do a scratch-build hence the link from koji. Realizing the change can be seen on the master branch on src.fedoraproject.org, I applied the update for view: https://src.fedoraproject.org/rpms/ispc/blob/master/f/ispc.spec
I figured that gcc parameter was missing on %make_build and the failure occurred on python line despite the available dependency: https://koji.fedoraproject.org/koji/taskinfo?taskID=32307602
Luya
* Luya Tshimbalanga:
On 2019-01-27 2:00 p.m., Florian Weimer wrote:
- Luya Tshimbalanga:
On 2019-01-26 12:24 a.m., Dominik 'Rathann' Mierzejewski wrote:
I would try patching out the clang requirement from CMakeLists and building with system gcc.
Regards, Dominik
Done. Unfortunately, the build failed as the compiler still remains clang and finding the cause is beyond my knowledge. Here is the resulted scratch build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=32277096
Which sources are you building? Nothing like this is on the master branch on src.fedoraproject.org.
Thanks, Florian
I avoided committing the update as I preferred to do a scratch-build hence the link from koji. Realizing the change can be seen on the master branch on src.fedoraproject.org, I applied the update for view: https://src.fedoraproject.org/rpms/ispc/blob/master/f/ispc.spec
Sorry, the rawhide build now fails for me with:
m4 -Ibuiltins/ -DLLVM_VERSION=LLVM_7_0 -DBUILD_OS=UNIX builtins/dispatch.ll | python bitcode2cpp.py builtins/dispatch.ll > objs/builtins-dispatch.cpp BUILDSTDERR: /bin/sh: python: command not found BUILDSTDERR: make: *** [Makefile:330: objs/builtins-dispatch.cpp] Error 127
This looks completely unrelated to clang.
Thanks, Florian
Please if possible. I attempt to use gcc to build it but some dependecies are linked to clang which is beyond my skill. This compiler blocks both embree and luxcorerender. See https://src.fedoraproject.org/rpms/ispc
Luya
On 2019-01-25 9:02 a.m., Jonathan Wakely wrote:
On 25/01/19 08:36 -0800, Luya Tshimbalanga wrote: >> On 2019-01-22 8:17 a.m., Serge Guelton wrote: >>> >>> Hi Luya, >>>
Clang does not support the -fstack-clash-protection flag. We used to
silently ignore that flag but it's no longer the case. >>> Why are you using clang to compile the package? The safe step is to use gcc, ot if clang is needed, to strip -fstack-clash-protection >>> from the flags passed to clang, but that's not future-proof (clang may end up supporting that flag). >>> >>> Hope it helps, >>> >>> Serge >>> >> >> Upstream reason. Trying to build with gcc will fail. See the attacked >> CMakeLists.txt from ispc-1.10.0 > > That says it wants to build with clang, but doesn't say why building > with GCC will fail. Is it due to a GCC bug? Is it something we can > fix? > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-leave@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
I managed to resolve some issue but now the problem is related to the hardened part:
https://koji.fedoraproject.org/koji/taskinfo?taskID=32324093
Here is the following lines for the failure:
BUILDSTDERR: /usr/bin/ld: kernels_ispc_sse2.o: relocation R_X86_64_32 against symbol `RenderTile___uniuniREFs_5B_unInputHeader_5D_REFs_5B_unInputDataArrays_5D_uniun_3C_unT_3E_un_3C_unT_3E_un_3C_unT_3E_sse2' can not be used when making a PIE object; recompile with -fPIC BUILDSTDERR: /usr/bin/ld: kernels_ispc_sse4.o: relocation R_X86_64_32S against `.rodata.cst16' can not be used when making a PIE object; recompile with -fPIC BUILDSTDERR: /usr/bin/ld: kernels_ispc_avx.o: relocation R_X86_64_32 against symbol `RenderTile___uniuniREFs_5B_unInputHeader_5D_REFs_5B_unInputDataArrays_5D_uniun_3C_unT_3E_un_3C_unT_3E_un_3C_unT_3E_avx' can not be used when making a PIE object; recompile with -fPIC BUILDSTDERR: /usr/bin/ld: kernels_ispc_avx2.o: relocation R_X86_64_32S against `.rodata.cst32' can not be used when making a PIE object; recompile with -fPIC BUILDSTDERR: /usr/bin/ld: kernels_ispc_avx512knl.o: relocation R_X86_64_32 against symbol `RenderTile___uniuniREFs_5B_unInputHeader_5D_REFs_5B_unInputDataArrays_5D_uniun_3C_unT_3E_un_3C_unT_3E_un_3C_unT_3E_avx512knl' can not be used when making a PIE object; recompile with -fPIC BUILDSTDERR: /usr/bin/ld: kernels_ispc_avx512skx.o: relocation R_X86_64_32 against symbol `RenderTile___uniuniREFs_5B_unInputHeader_5D_REFs_5B_unInputDataArrays_5D_uniun_3C_unT_3E_un_3C_unT_3E_un_3C_unT_3E_avx512skx' can not be used when making a PIE object; recompile with -fPIC BUILDSTDERR: /usr/bin/ld: final link failed: nonrepresentable section on output BUILDSTDERR: collect2: error: ld returned 1 exit status BUILDSTDERR: make[2]: *** [examples/deferred/CMakeFiles/deferred_shading.dir/build.make:204: bin/deferred_shading] Error 1 BUILDSTDERR: make[1]: *** [CMakeFiles/Makefile2:370: examples/deferred/CMakeFiles/deferred_shading.dir/all] Error 2 BUILDSTDERR: make: *** [Makefile:133: all] Error 2
Luya
On Tue, Jan 29, 2019, 05:21 Luya Tshimbalanga <luya@fedoraproject.org wrote:
I managed to resolve some issue but now the problem is related to the hardened part:
https://koji.fedoraproject.org/koji/taskinfo?taskID=32324093
Here is the following lines for the failure:
BUILDSTDERR: /usr/bin/ld: kernels_ispc_sse2.o: relocation R_X86_64_32 against symbol
`RenderTile___uniuniREFs_5B_unInputHeader_5D_REFs_5B_unInputDataArrays_5D_uniun_3C_unT_3E_un_3C_unT_3E_un_3C_unT_3E_sse2' can not be used when making a PIE object; recompile with -fPIC BUILDSTDERR: /usr/bin/ld: kernels_ispc_sse4.o: relocation R_X86_64_32S against `.rodata.cst16' can not be used when making a PIE object; recompile with -fPIC
I've seen this errror before. It's uusally caused by upstream accidentally overriding CFLAGS instead appending to already set CFLAGS, which breaks fedora builds. Look for something like "set *CFLAGS* (foo bar)" in CMakeLists.txt files, and change it to *append* to the already existing value (coming from fedora settings), instead of overriding it.
Fabio
BUILDSTDERR: /usr/bin/ld: kernels_ispc_avx.o: relocation R_X86_64_32
against symbol
`RenderTile___uniuniREFs_5B_unInputHeader_5D_REFs_5B_unInputDataArrays_5D_uniun_3C_unT_3E_un_3C_unT_3E_un_3C_unT_3E_avx' can not be used when making a PIE object; recompile with -fPIC BUILDSTDERR: /usr/bin/ld: kernels_ispc_avx2.o: relocation R_X86_64_32S against `.rodata.cst32' can not be used when making a PIE object; recompile with -fPIC BUILDSTDERR: /usr/bin/ld: kernels_ispc_avx512knl.o: relocation R_X86_64_32 against symbol
`RenderTile___uniuniREFs_5B_unInputHeader_5D_REFs_5B_unInputDataArrays_5D_uniun_3C_unT_3E_un_3C_unT_3E_un_3C_unT_3E_avx512knl' can not be used when making a PIE object; recompile with -fPIC BUILDSTDERR: /usr/bin/ld: kernels_ispc_avx512skx.o: relocation R_X86_64_32 against symbol
`RenderTile___uniuniREFs_5B_unInputHeader_5D_REFs_5B_unInputDataArrays_5D_uniun_3C_unT_3E_un_3C_unT_3E_un_3C_unT_3E_avx512skx' can not be used when making a PIE object; recompile with -fPIC BUILDSTDERR: /usr/bin/ld: final link failed: nonrepresentable section on output BUILDSTDERR: collect2: error: ld returned 1 exit status BUILDSTDERR: make[2]: *** [examples/deferred/CMakeFiles/deferred_shading.dir/build.make:204: bin/deferred_shading] Error 1 BUILDSTDERR: make[1]: *** [CMakeFiles/Makefile2:370: examples/deferred/CMakeFiles/deferred_shading.dir/all] Error 2 BUILDSTDERR: make: *** [Makefile:133: all] Error 2
Luya _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
I've seen this errror before. It's uusally caused by upstream accidentally overriding CFLAGS instead appending to already set CFLAGS, which breaks fedora builds. Look for something like "set *CFLAGS* (foo bar)" in CMakeLists.txt files, and change it to *append* to the already existing value (coming from fedora settings), instead of overriding it.
Actually, upstream should prepend its own CFLAGS et al to give precedence to user-defined flags.
Dridi
* Dridi Boukelmoune:
I've seen this errror before. It's uusally caused by upstream accidentally overriding CFLAGS instead appending to already set CFLAGS, which breaks fedora builds. Look for something like "set *CFLAGS* (foo bar)" in CMakeLists.txt files, and change it to *append* to the already existing value (coming from fedora settings), instead of overriding it.
Actually, upstream should prepend its own CFLAGS et al to give precedence to user-defined flags.
The ispc compiler unfortunately has a completely different command line syntax from what we use in CFLAGS, so this is not going to work anyway.
Thanks, Florian
* Luya Tshimbalanga:
I managed to resolve some issue but now the problem is related to the hardened part:
https://koji.fedoraproject.org/koji/taskinfo?taskID=32324093
Here is the following lines for the failure:
BUILDSTDERR: /usr/bin/ld: kernels_ispc_sse2.o: relocation R_X86_64_32 against symbol `RenderTile___uniuniREFs_5B_unInputHeader_5D_REFs_5B_unInputDataArrays_5D_uniun_3C_unT_3E_un_3C_unT_3E_un_3C_unT_3E_sse2' can not be used when making a PIE object; recompile with -fPIC BUILDSTDERR: /usr/bin/ld: kernels_ispc_sse4.o: relocation R_X86_64_32S against `.rodata.cst16' can not be used when making a PIE object; recompile with -fPIC BUILDSTDERR: /usr/bin/ld: kernels_ispc_avx.o: relocation R_X86_64_32 against symbol `RenderTile___uniuniREFs_5B_unInputHeader_5D_REFs_5B_unInputDataArrays_5D_uniun_3C_unT_3E_un_3C_unT_3E_un_3C_unT_3E_avx' can not be used when making a PIE object; recompile with -fPIC BUILDSTDERR: /usr/bin/ld: kernels_ispc_avx2.o: relocation R_X86_64_32S against `.rodata.cst32' can not be used when making a PIE object; recompile with -fPIC BUILDSTDERR: /usr/bin/ld: kernels_ispc_avx512knl.o: relocation R_X86_64_32 against symbol `RenderTile___uniuniREFs_5B_unInputHeader_5D_REFs_5B_unInputDataArrays_5D_uniun_3C_unT_3E_un_3C_unT_3E_un_3C_unT_3E_avx512knl' can not be used when making a PIE object; recompile with -fPIC BUILDSTDERR: /usr/bin/ld: kernels_ispc_avx512skx.o: relocation R_X86_64_32 against symbol `RenderTile___uniuniREFs_5B_unInputHeader_5D_REFs_5B_unInputDataArrays_5D_uniun_3C_unT_3E_un_3C_unT_3E_un_3C_unT_3E_avx512skx' can not be used when making a PIE object; recompile with -fPIC BUILDSTDERR: /usr/bin/ld: final link failed: nonrepresentable section on output BUILDSTDERR: collect2: error: ld returned 1 exit status BUILDSTDERR: make[2]: *** [examples/deferred/CMakeFiles/deferred_shading.dir/build.make:204: bin/deferred_shading] Error 1 BUILDSTDERR: make[1]: *** [CMakeFiles/Makefile2:370: examples/deferred/CMakeFiles/deferred_shading.dir/all] Error 2 BUILDSTDERR: make: *** [Makefile:133: all] Error 2
I tried to build with --pic, using the attached patch, but got this:
[ 68%] Generating perfbench_ispc.h, perfbench_ispc.o, perfbench_ispc_sse2.h, perfbench_ispc_sse2.o, perfbench_ispc_sse4.h, perfbench_ispc_sse4.o, perfbench_ispc_avx.h, perfbench_ispc_avx.o, perfbench_ispc_avx2.h, perfbench_ispc_avx2.o, perfbench_ispc_avx512knl.h, perfbench_ispc_avx512knl.o, perfbench_ispc_avx512skx.h, perfbench_ispc_avx512skx.o cd /builddir/build/BUILD/ispc-1.10.0/examples/perfbench && ../../bin/ispc /builddir/build/BUILD/ispc-1.10.0/examples/perfbench/perfbench.ispc --pic --target=sse2-i32x4,sse4-i32x4,avx1-i32x8,avx2-i32x8,avx512knl-i32x16,avx512skx-i32x16 --arch=x86-64 -h /builddir/build/BUILD/ispc-1.10.0/examples/perfbench/perfbench_ispc.h -o /builddir/build/BUILD/ispc-1.10.0/examples/perfbench/perfbench_ispc.o make[2]: Leaving directory '/builddir/build/BUILD/ispc-1.10.0' BUILDSTDERR: /builddir/build/BUILD/ispc-1.10.0/src/main.cpp(353): FATAL ERROR: Unhandled signal sent to process; terminating. BUILDSTDERR: *** BUILDSTDERR: *** Please file a bug report at https://github.com/ispc/ispc/issues BUILDSTDERR: *** (Including as much information as you can about how to reproduce this error). BUILDSTDERR: *** You have apparently encountered a bug in the compiler that we'd like to fix! BUILDSTDERR: *** BUILDSTDERR: make[2]: *** [examples/perfbench/CMakeFiles/perfbench.dir/build.make:65: examples/perfbench/perfbench_ispc.h] Aborted (core dumped)
This looks like something upstream needs to investigate. 8-(
Thanks, Florian
-----BEGIN PGP MESSAGE----- Charset: UTF-8
hQEMAyZZ5X4GTmHqAQgA3r4Bs+wCUHFsVqpIPN5v0tFnaioogOKYTrDgA9MTKzzV GuEEdfFctzFOZw9eAiu7lIYZn41Ajpx7pGDjgxXJYsnhBKmL/n5BLrQ+hlG4FYcM LcT/O5DQjwgndjwsx9QlsHoCrk12lMCcGZLPX+w0Gjc1d8uMofQ3F9iZpr71zq99 6FF/hmpEghytBTnqL/0BPMu2tJOpdcVxeO8hYzFZoM/906GjLJMqOFXSa9Szlxib weoQg667E7i0J3p/GS0r5hU8g35M0pTjvHHlwh30lhQad/BBH6ry7Y/8J37Sh6XL whdSLi7xZMEOnV7RuBbiFjwF4FruHYvNi8Ph2JvLtNLqASL7zJZbPjgZh1VeUxbL lnQoJbcyiFM+hBxLCqJvnlzatMiwya63GqbEQwTOyU+kHFWoNSgQTtz3kwcSnahq q+A0ILXxLt5Sz0tKHRw7C7DwNFqrAj9Pr5MSbllm1AkLu+dAa5AW3CCdohz20iEH g+TaVMJjiPhyPaaWjrSkPl1Qbkd/Amy9jisHSBSQVWigviQjphkuFGDzLJByiWQe HCS5y4tx3q9ZTmT3RugU/Y4cm9IHHmODfI+B4fHMWubFVlos8i7Eu0lC4tWAo9nL MCrJkhJidFZguutfYwGS+/oznV8CkB3MiRkooH77FfLpLMwCtEiMoSSTsHDMVrFZ FqqsZXCDa8bZB+A5kb2eQLHDjAv6Y0Uv4l+oxxuz7AaAzgoCKHDe/2zFY/ZPguoV aM5CW+W4bKlDLKK3XzmtYqQYxcQcFWwHWDbrbunWFuS9/RlCcW6W4x9ARXkGY+26 X4483yHxNA9kG+DyDqA3vvNUEgDcTPHe3rOr/ViUvFZZWnsfd7y+fO/wpVJNFywn xrzwmpjSI75z/n5kp22ckokm0sJz2NNX+N8ZRRWmsDyve8OgmS2wd61CGPoJ0cY3 zRh4MJL+2Ly/u7BBocOxBdrlf0gSgBxBGmOQHAcbSgAYultgw4BWgs5UXr1OaEvx dFXWbNyfrWpwubl8f96fujQKgV64xi73Y9obSq6AjmWajKWnZFRSph+rV6CkoZqO FvUOPlFAbZmuaRb+9mU/8b8u3AhY1Xh8e50g5IW+Hqt8gw/Dz4vWPhaddJlc5o8A LR5O3v+CcJq1y+BzJ1GBymrUkuPJCxjRO/RctQbtTopUqMdiGx8jTy7y0mESFvAD Ojjc2W0gN9cfP6itGeB/27aeynRP/xSXw8xvg1bN+JW0fqnFidGdsrHahX5nPYRw MmVJsUyaIZbQSyD7TUbqzl30eIjPM92XNCXA7Jy+1Zi0lvdPDRvgQW3L0DijQVqu fhjvKPELPD+/L4kKDoJhSlaFSAyrd/pWfr2oKXJ8tiRqFShalFv/i2+fmxf18hqb AZMHqb3zDFFUQLopk4wf/668HHZVRxzyq4uUshEDAp36Eubtdrc8hMzmv2XfoxuM bs41OChDVTzdiekq+vj0hjftUNI/zMdFLYV3LilfI4e0XVF87uBzu6zFNZtjhxQN PBf05oA6dd3IaEgiomZOs3XLpZ8L1VjZhPo8EuJBvfgBz6jkGJKIt3vr9Ju2+t3a SJs/zIUC1tBcDtU5ZVBV9N2cfmpat6ISqaifB67afJN3APq+h3ZHgzaGc0QrGLW1 QQY3t4+vdjt+a+Tx3HW+RYwa2IHclZk/L0yA4oa0yj3DRc6s53E3ZSQ4ZxD4jjkI KumR7OQ2NsV6zp4iCPgDT9dbO2z5hCkU1B9rAohTc0pqvFeXMlP3O8LOHbv/0j+Z rvvPvzuJlXlW0wfF+QEiD0SgNhCdcoeuiC74V4LIKsm1CF6+QRI/QcVH+xFZPJi0 VorJ+I7BtsklvqmXS6Yc05ujJLvYyaWZhof3fwPf+40IV7BqKdZ9j9o4fa0LOgQD wzWw3FgMAL/WDFuPyzu7RZMxwQwqpxDffo/rCUfB61wZ+CAUCipX4kgugl6ZPRIs oVs4O4XW9eDaboBuQe/XfWZ3dEFVjIYQ17LMgu2tsMAShAMhtgZD+Giq4dUmKsHv D+pM2OPAeON+HF6sOAseocgShprB0t2NQzdnNT+FtW3+H/sw1VY7NoyW1pheC1KS aPbygQTcIkj0zDX9pZoCbGa3XkPqflqnViWSMZY8Ap7v4QcZnBWzAkQ8yFdovUtE XQ3CRrPX4aMvFL4GHg2CQRpCLCuz7Qab0WUP4v6v0/FvOP+poDKxZdahVreed1DZ LSiih/piAz1GG3imiIr20uxRgyBWo7Kt0jL6JthYszWGerkgwQeH8wAlfG5fQWZp gUZzaywXQ7EWD9HpA69IeNhblBxrxpTJEya15WORLZtk/1qk47c0cQfgkS+1Rd1e wSxs/IZyV+voAkTbHIWG7QCSHIP/ifg/Q/vHe6LBJN/ATqkvryqQDS/Lr32jbRP4 3sg2UroeWoYFjsb+2XjxyTWNXiFJ1RE2uQNnO7el5K58w+ROhJd120XQV6kAULaV Dswb7M6l/9qbcOQyC1kGz4axc3QeNVdlFSUcyMTmNN8tMXHMNwgpeWeRqiNNc7/j zVELKN42l3VP0bDFVEwK0elbU2IFqE8EMuOmVRlldDB8RmO0oqrtTwZVZb7CCLE8 7SHqLkIzAnXGASl9 =a/zz -----END PGP MESSAGE-----
On Tue, Jan 29, 2019 at 6:03 PM Luya Tshimbalanga luya@fedoraproject.org wrote:
-----BEGIN PGP MESSAGE----- Charset: UTF-8
I guess the encrypted garble garble below happened by accident - you might want to send your message again without encrypting it.
Fabio
hQEMAyZZ5X4GTmHqAQgA3r4Bs+wCUHFsVqpIPN5v0tFnaioogOKYTrDgA9MTKzzV GuEEdfFctzFOZw9eAiu7lIYZn41Ajpx7pGDjgxXJYsnhBKmL/n5BLrQ+hlG4FYcM LcT/O5DQjwgndjwsx9QlsHoCrk12lMCcGZLPX+w0Gjc1d8uMofQ3F9iZpr71zq99 6FF/hmpEghytBTnqL/0BPMu2tJOpdcVxeO8hYzFZoM/906GjLJMqOFXSa9Szlxib weoQg667E7i0J3p/GS0r5hU8g35M0pTjvHHlwh30lhQad/BBH6ry7Y/8J37Sh6XL whdSLi7xZMEOnV7RuBbiFjwF4FruHYvNi8Ph2JvLtNLqASL7zJZbPjgZh1VeUxbL lnQoJbcyiFM+hBxLCqJvnlzatMiwya63GqbEQwTOyU+kHFWoNSgQTtz3kwcSnahq q+A0ILXxLt5Sz0tKHRw7C7DwNFqrAj9Pr5MSbllm1AkLu+dAa5AW3CCdohz20iEH g+TaVMJjiPhyPaaWjrSkPl1Qbkd/Amy9jisHSBSQVWigviQjphkuFGDzLJByiWQe HCS5y4tx3q9ZTmT3RugU/Y4cm9IHHmODfI+B4fHMWubFVlos8i7Eu0lC4tWAo9nL MCrJkhJidFZguutfYwGS+/oznV8CkB3MiRkooH77FfLpLMwCtEiMoSSTsHDMVrFZ FqqsZXCDa8bZB+A5kb2eQLHDjAv6Y0Uv4l+oxxuz7AaAzgoCKHDe/2zFY/ZPguoV aM5CW+W4bKlDLKK3XzmtYqQYxcQcFWwHWDbrbunWFuS9/RlCcW6W4x9ARXkGY+26 X4483yHxNA9kG+DyDqA3vvNUEgDcTPHe3rOr/ViUvFZZWnsfd7y+fO/wpVJNFywn xrzwmpjSI75z/n5kp22ckokm0sJz2NNX+N8ZRRWmsDyve8OgmS2wd61CGPoJ0cY3 zRh4MJL+2Ly/u7BBocOxBdrlf0gSgBxBGmOQHAcbSgAYultgw4BWgs5UXr1OaEvx dFXWbNyfrWpwubl8f96fujQKgV64xi73Y9obSq6AjmWajKWnZFRSph+rV6CkoZqO FvUOPlFAbZmuaRb+9mU/8b8u3AhY1Xh8e50g5IW+Hqt8gw/Dz4vWPhaddJlc5o8A LR5O3v+CcJq1y+BzJ1GBymrUkuPJCxjRO/RctQbtTopUqMdiGx8jTy7y0mESFvAD Ojjc2W0gN9cfP6itGeB/27aeynRP/xSXw8xvg1bN+JW0fqnFidGdsrHahX5nPYRw MmVJsUyaIZbQSyD7TUbqzl30eIjPM92XNCXA7Jy+1Zi0lvdPDRvgQW3L0DijQVqu fhjvKPELPD+/L4kKDoJhSlaFSAyrd/pWfr2oKXJ8tiRqFShalFv/i2+fmxf18hqb AZMHqb3zDFFUQLopk4wf/668HHZVRxzyq4uUshEDAp36Eubtdrc8hMzmv2XfoxuM bs41OChDVTzdiekq+vj0hjftUNI/zMdFLYV3LilfI4e0XVF87uBzu6zFNZtjhxQN PBf05oA6dd3IaEgiomZOs3XLpZ8L1VjZhPo8EuJBvfgBz6jkGJKIt3vr9Ju2+t3a SJs/zIUC1tBcDtU5ZVBV9N2cfmpat6ISqaifB67afJN3APq+h3ZHgzaGc0QrGLW1 QQY3t4+vdjt+a+Tx3HW+RYwa2IHclZk/L0yA4oa0yj3DRc6s53E3ZSQ4ZxD4jjkI KumR7OQ2NsV6zp4iCPgDT9dbO2z5hCkU1B9rAohTc0pqvFeXMlP3O8LOHbv/0j+Z rvvPvzuJlXlW0wfF+QEiD0SgNhCdcoeuiC74V4LIKsm1CF6+QRI/QcVH+xFZPJi0 VorJ+I7BtsklvqmXS6Yc05ujJLvYyaWZhof3fwPf+40IV7BqKdZ9j9o4fa0LOgQD wzWw3FgMAL/WDFuPyzu7RZMxwQwqpxDffo/rCUfB61wZ+CAUCipX4kgugl6ZPRIs oVs4O4XW9eDaboBuQe/XfWZ3dEFVjIYQ17LMgu2tsMAShAMhtgZD+Giq4dUmKsHv D+pM2OPAeON+HF6sOAseocgShprB0t2NQzdnNT+FtW3+H/sw1VY7NoyW1pheC1KS aPbygQTcIkj0zDX9pZoCbGa3XkPqflqnViWSMZY8Ap7v4QcZnBWzAkQ8yFdovUtE XQ3CRrPX4aMvFL4GHg2CQRpCLCuz7Qab0WUP4v6v0/FvOP+poDKxZdahVreed1DZ LSiih/piAz1GG3imiIr20uxRgyBWo7Kt0jL6JthYszWGerkgwQeH8wAlfG5fQWZp gUZzaywXQ7EWD9HpA69IeNhblBxrxpTJEya15WORLZtk/1qk47c0cQfgkS+1Rd1e wSxs/IZyV+voAkTbHIWG7QCSHIP/ifg/Q/vHe6LBJN/ATqkvryqQDS/Lr32jbRP4 3sg2UroeWoYFjsb+2XjxyTWNXiFJ1RE2uQNnO7el5K58w+ROhJd120XQV6kAULaV Dswb7M6l/9qbcOQyC1kGz4axc3QeNVdlFSUcyMTmNN8tMXHMNwgpeWeRqiNNc7/j zVELKN42l3VP0bDFVEwK0elbU2IFqE8EMuOmVRlldDB8RmO0oqrtTwZVZb7CCLE8 7SHqLkIzAnXGASl9 =a/zz -----END PGP MESSAGE----- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Contacting upstream about the issue, a suggestion is use the built-in script alloy.py to manually build llvm instead of using the stock model i.e. llvm-devel.
https://github.com/ispc/ispc/issues/1413#issuecomment-458654316
Any feedback?
Luya
On 2019-01-29 12:26 p.m., Luya Tshimbalanga wrote:
Contacting upstream about the issue, a suggestion is use the built-in script alloy.py to manually build llvm instead of using the stock model i.e. llvm-devel.
https://github.com/ispc/ispc/issues/1413#issuecomment-458654316
Any feedback?
Luya
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Added spec file with suggested alloy.py script.
Luya