Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#163 drop -m64 hardcoding for targets

closed-fixed
Kent Yoder
5
2012-09-25
2012-09-11
Mike Frysinger
No

having the configure script manually add -m64 doesn't make much sense. if you're building for a 64bit system, the toolchain itself takes care of generating the right output, so the -m64 is redundant. in cases where the target is ambiguous for the output, the -m64 is actually harmful.

i can't see how it serves any purpose, so i'd just delete it from the configure script.

Discussion

  • Kent Yoder
    Kent Yoder
    2012-09-11

    • assigned_to: phreakz --> kyoder
     
  • Kent Yoder
    Kent Yoder
    2012-09-11

    Hi Mike,

    It sounds from your description of AC_CANONICAL_HOST and AC_CACNONICAL_TARGET in the other defect, the case where we'd need -m64 is when $host != $target. Or really, $build != $host. In the case where $host_cpu is 64bit and $build_cpu isn't, we'd need it, right?

    IIRC we added this to cover the case such as rpmbuild --target=x86_64 on an i686 machine. (Which should have been rpmbuild --host=x86_64 if I read your other bug correctly).

    Kent

     
  • Mike Frysinger
    Mike Frysinger
    2012-09-11

    $build is where things are compiled (e.g. your desktop). $host is where the compiled code is run (e.g. where you run `apt-get install foo` or `rpm -i foo.rpm` or `yum install foo`). $target is what the compiled code (when run on the $host) itself produces. since the tpm/trousers/etc... packages, once installed, don't "produce" anything, $target doesn't make sense.

    when i talk about $build/$host/$target settings, i'm speaking in terms of autoconf (configure) and how most build systems relate. i don't know if rpm maps things the same way, so i don't know if that rpmbuild mapping makes sense. i don't do rpms.

    when it comes to your use case (trying to do multilib builds), i can see why you'd want to try and make things simple. but this ends up making other things much harder :(. you can't assume that if $host_cpu is 64bits, the user wants the ABI produced by -m64. for x86_64 targets, there are now 3 ABIs: -m32 -m64 -mx32. $host_cpu for the latter two will be the same. mips64 processors are in the same boat: they've got o32 n64 n32, and the latter two are for mips64 processors.

    perhaps as a compromise, we add a new configure flag ? that way in the rpm spec files you build, you can pass this and get things the way you want, but for everyone else, our toolchain settings will do the right thing (since they've been configured to do the right thing).

    AC_ARG_ENABLE([auto-abi])
    AS_IF([test "$enable_auto_abi" = "yes"], [
    ... current stuff that automatically appends -m64/-m32/whatever ...
    ])

     
  • Kent Yoder
    Kent Yoder
    2012-09-25

    There was a time when we didn't have access to 64bit platforms but needed to conveniently build for them. That's not true anymore so I can pull the hardcoded -m64's. It looks like Solaris is still using $target though so I'll leave AC_CANONICAL_TARGET in.

     
  • Kent Yoder
    Kent Yoder
    2012-09-25

    • status: open --> open-accepted
     
  • Kent Yoder
    Kent Yoder
    2012-09-25

    Fixed in 0.3.10.

     
  • Kent Yoder
    Kent Yoder
    2012-09-25

    • status: open-accepted --> closed-fixed