Opened 18 months ago

Closed 17 months ago

Last modified 13 months ago

#22748 closed enhancement (fixed)

Provide yasm on i386 + x86_64 systems

Reported by: vdelecroix Owned by:
Priority: major Milestone: sage-8.0
Component: packages: standard Keywords:
Cc: jdemeyer, vbraun, fbissey Merged in:
Authors: Jean-Pierre Flori, Jeroen Demeyer Reviewers: Jean-Pierre Flori, Jeroen Demeyer
Report Upstream: N/A Work issues:
Branch: 3057c79 (Commits) Commit:
Dependencies: Stopgaps:

Description (last modified by jpflori)

yasm is needed to compile MPIR >= 3.0.0 (see #22493)

Upstream tarball at:

Change History (23)

comment:1 follow-up: Changed 17 months ago by jpflori

  • Authors set to Jean-Pierre Flori
  • Branch set to public/yasm130
  • Cc jdemeyer vbraun fbissey added
  • Commit set to 4d723dcf5455ff95d40bfc24a11779efd69589aa
  • Description modified (diff)
  • Status changed from new to needs_review

At the moment yasm won't be built when building Sage...

I'll trigger that when updating MPIR.


New commits:

4d723dcAdd yasm as a standard package.

comment:2 Changed 17 months ago by jpflori

  • Summary changed from Provide yasm when not available to Provide yasm

comment:3 in reply to: ↑ 1 Changed 17 months ago by jdemeyer

Replying to jpflori:

At the moment yasm won't be built when building Sage...

It's a standard package, so it will be built. It just won't be used by anything.

comment:4 follow-up: Changed 17 months ago by jpflori

Ok, I thought that if nothing depended on it, it could get skipped.

comment:5 in reply to: ↑ 4 Changed 17 months ago by jdemeyer

Replying to jpflori:

Ok, I thought that if nothing depended on it, it could get skipped.

No no. Otherwise there would be no difference between standard and optional packages.

comment:6 Changed 17 months ago by fbissey

A more interesting question, to me, would be whether or not it should be rebuilt after gcc is built, like mpir/mpfr/mpc. I'd say it would be overkill but I am ready to hear other opinions.

comment:7 Changed 17 months ago by jdemeyer

I see no reason to rebuild yasm, which is just a build tool.

comment:8 Changed 17 months ago by fbissey

An assembler that outputs object code, just a build tool? We have different opinions.

Anyway since it is to be a standard package we should at least test if it builds on non-x86 architectures where it cannot be used anyway. I am not sure if it could pass its test suite on arm or ppc64. May be we need to do something more subtle in configure.

comment:9 Changed 17 months ago by fbissey

Somewhat surprisingly only 3 tests fail on ppc64

==================================
   yasm 1.3.0: ./test-suite.log
==================================

# TOTAL: 44
# PASS:  41
# SKIP:  0
# XFAIL: 0
# FAIL:  3
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: modules/objfmts/elf/tests/amd64/elf_amd64_test.sh
=======================================================

Test elf_amd64_test: ..O. +3-1/4 75%
 ** O: gotpcrel did not match object file!

FAIL: modules/objfmts/elf/tests/x32/elf_x32_test.sh
===================================================

Test elf_x32_test: O... +3-1/4 75%
 ** O: elf-rip did not match object file!

FAIL: modules/objfmts/elf/tests/gasx32/elf_gasx32_test.sh
=========================================================

Test elf_gasx32_test: O... +3-1/4 75%
 ** O: crosssect did not match object file!

but at the minimum I think we should only allow spkg-check to be run on intel class hardware.

comment:10 Changed 17 months ago by jpflori

Is it really problematic? Remember that at the moment we ship GIAC which is completely broken outside x86*...

You can still modify spkg-check to disable testing on non-x86* if you want.

comment:11 follow-up: Changed 17 months ago by jpflori

I guess there is no need to rebuild yasm: its output won't depend on the compiler used to build it (or do I hope), it "just" takes text and makes binary from it.

comment:12 in reply to: ↑ 11 Changed 17 months ago by fbissey

Replying to jpflori:

I guess there is no need to rebuild yasm: its output won't depend on the compiler used to build it (or do I hope), it "just" takes text and makes binary from it.

You mean, just like a compiler ;)

It is true that at the moment we are borked out on ppc64 and arm64 so it doesn't matter so much I guess.

comment:13 follow-up: Changed 17 months ago by jpflori

So an we get this in? Note that it is really a trivial ticket as yasm was already built before when building mpir.

comment:14 in reply to: ↑ 13 Changed 17 months ago by fbissey

Replying to jpflori:

So an we get this in?

yes

Note that it is really a trivial ticket as yasm was already built before when building mpir.

mpir only built yasm on x86(_64), this will build everywhere it can.

comment:15 Changed 17 months ago by jpflori

True, I did not notice mpir was that smart!

comment:16 Changed 17 months ago by jdemeyer

  • Authors changed from Jean-Pierre Flori to Jean-Pierre Flori, Jeroen Demeyer
  • Status changed from needs_review to needs_work
  • Summary changed from Provide yasm to Provide yasm on i386 + x86_64 systems

comment:17 Changed 17 months ago by git

  • Commit changed from 4d723dcf5455ff95d40bfc24a11779efd69589aa to 3057c797a3230875c26cf2dc4117e61cdd07ecda

Branch pushed to git repo; I updated commit sha1. New commits:

3057c79Add configure check for yasm

comment:18 Changed 17 months ago by jdemeyer

  • Status changed from needs_work to needs_review

comment:19 Changed 17 months ago by jpflori

Jeroen changes look good to me.

comment:20 Changed 17 months ago by jdemeyer

  • Reviewers set to Jean-Pierre Flori, Jeroen Demeyer
  • Status changed from needs_review to positive_review

comment:21 Changed 17 months ago by vbraun

  • Branch changed from public/yasm130 to 3057c797a3230875c26cf2dc4117e61cdd07ecda
  • Resolution set to fixed
  • Status changed from positive_review to closed

comment:22 Changed 16 months ago by vbraun

  • Commit 3057c797a3230875c26cf2dc4117e61cdd07ecda deleted

Followup at #23217

Last edited 16 months ago by jdemeyer (previous) (diff)

comment:23 Changed 13 months ago by rws

Another followup at #23841.

Note: See TracTickets for help on using tickets.