Changes between Initial Version and Version 2 of Ticket #27659


Ignore:
Timestamp:
Dec 14, 2010, 12:34:03 AM (13 years ago)
Author:
ryandesign (Ryan Carsten Schmidt)
Comment:

wine-devel is affected as well.

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #27659

    • Property Cc jwa@… added
    • Property Owner changed from macports-tickets@… to ryandesign@…
    • Property Summary changed from wine @1.2.2 winebuild picks the wrong assembler in presence of binutils to wine, wine-devel: winebuild picks the wrong assembler in presence of binutils
    • Property Port wine-devel added
  • Ticket #27659 – Description

    initial v2  
    1818The build is parallel, so several other dll's try to build at the same time, all failing with errors from gas about the -r option. As this error comes from gas, which I believe is provided by binutils (gas from binutils comes from macports, whereas the Apple version from XCode is called as), I've checked that I'm running the current version (2.20.1--scratch that, it appears there's been a recent upgrade to 2.21 that I need to pick up). I notice that the compiler switches from the XCode gcc-4.2 to winegcc, so I'm assuming that it's winegcc (by way of winebuild's get_as_command() from utils.c) that's subsequently calling gas with options it doesn't recognise. I'm not saying that I've got much of a handle on the mechanics, just that they are complex and this is as close as I've got to understanding them thus far. I dug a little further, and it looks to me that the problem is that gas is being called as follows:
    1919
     20{{{
    2021/opt/local/bin/gas -arch i386 -o activeds.ymaQ1t.o activeds.YHUnAl.s
     22}}}
    2123
    2224In fact it should be called via:
    2325
     26{{{
    2427/opt/local/bin/gas -march i386 -o activeds.ymaQ1t.o activeds.YHUnAl.s
     28}}}
    2529
    2630The "-r" option is actually gas breaking out -arch as a series of options.  I only gave winebuild/utils.c a quick read, but it left me with the impression that it looks for gas before as. where the latter accepts -arch, whereas the former requires -march. If it's going to insist on argument parsing that only the former accepts, perhaps it ought to be patched to find it alone in the first place or at least to prefer it?