[MacPorts] #27659: wine @1.2.2 winebuild picks the wrong assembler in presence of binutils
#27659: wine @1.2.2 winebuild picks the wrong assembler in presence of binutils ----------------------------+----------------------------------------------- Reporter: buffyg@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.9.2 Keywords: | Port: wine ----------------------------+----------------------------------------------- 'm trying to build wine and running into compile-time failures. I've gone back and looked at the mail archives to check for recent issues. The only thing I could identify was that wine can only build for i386 (I'm running Snow Leopard 10.6.5 on x86_64), thus all dependencies (or at least all shared object dependencies) need to be universal. After going back to make sure that the dependencies are in fact all built with universal variants, I'm still getting build failures. I haven't check back through all of the bug tickets yet, but, as I've recently upgraded to the latest version of XCode, I wasn't sure if that might cause some issues (although information provided further down makes this seem less plausible). Here's where things start to go wrong in the logs: {{{ :info:build /usr/bin/gcc-4.2 -m32 -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_ADVAPI32_ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wstrict-prototypes -Wwrite-strings -Wpointer-arith -I/opt/local/include -D_DARWIN_NO_64_BIT_INODE -O2 -arch i386 -o cred.o cred.c :info:build /usr/bin/gcc-4.2 -m32 -o wineserver async.o atom.o change.o class.o clipboard.o completion.o console.o debugger.o device.o directory.o event.o fd.o file.o handle.o hook.o mach.o mailslot.o main.o mapping.o mutex.o named_pipe.o object.o process.o procfs.o ptrace.o queue.o region.o registry.o request.o semaphore.o serial.o signal.o snapshot.o sock.o symlink.o thread.o timer.o token.o trace.o unicode.o user.o window.o winstation.o -L../libs/wine -lwine ../libs/port/libwine_port.a -L/opt/local/lib -framework CoreServices -lz -arch i386 && install_name_tool -change @executable_path/`../tools/relpath /opt/local/bin /opt/local/lib`/libwine.1.dylib @executable_path/../libs/wine/libwine.1.dylib wineserver || rm -f wineserver :info:build /usr/bin/gcc-4.2 -m32 -c -I. -I. -I../../../include -I../../../include -DWINE_STRICT_PROTOTYPES -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wstrict- prototypes -Wwrite-strings -Wpointer-arith -I/opt/local/include -D_DARWIN_NO_64_BIT_INODE -O2 -arch i386 -o cred.o cred.c :info:build ../../tools/widl/widl -I. -I. -I../../include -I../../include -D__WINESRC__ -DREGISTER_PROXY_DLL -DPROXY_DELEGATION -p -P actxprxy_activscp_p.c actxprxy_activscp.idl :info:build ../../tools/winegcc/winegcc -m32 -B../../tools/winebuild --sysroot=../.. -shared ./activeds.spec activeds_main.o -o activeds.dll.so -lkernel32 ../../libs/port/libwine_port.a -L/opt/local/lib -framework CoreServices -lz -arch i386 :info:build Assembler messages: :info:build Fatal error: invalid listing option `r' :info:build winebuild: /opt/local/bin/gas -arch i386 failed with status 256 :info:build winegcc: ../../tools/winebuild/winebuild failed :info:build make[1]: *** [acledit.dll.so] Error 2 :info:build make: *** [dlls/acledit] Error 2 :info:build make: *** Waiting for unfinished jobs.... }}} The 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: /opt/local/bin/gas -arch i386 -o activeds.ymaQ1t.o activeds.YHUnAl.s In fact it should be called via: /opt/local/bin/gas -march i386 -o activeds.ymaQ1t.o activeds.YHUnAl.s The "-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? I have succeeded in getting wine to build with the following patch: {{{ const char *get_as_command(void) { if (!as_command) { < static const char * const commands[] = { "gas", "as", NULL }; as_command = find_tool( "as", commands ); if (force_pointer_size) { const char *args = (target_platform == PLATFORM_APPLE) ? ((force_pointer_size == 8) ? " -arch x86_64" : " -arch i386") : ((force_pointer_size == 8) ? " --64" : " --32"); as_command = xrealloc( as_command, strlen(as_command) + strlen(args) + 1 ); strcat( as_command, args ); } } return as_command; } const char *get_as_command(void) { if (!as_command) { static const char * const commands[] = { "as", NULL }; as_command = find_tool( "as", commands ); if (force_pointer_size) { const char *args = (target_platform == PLATFORM_APPLE) ? ((force_pointer_size == 8) ? " -arch x86_64" : " -arch i386") : ((force_pointer_size == 8) ? " --64" : " --32"); as_command = xrealloc( as_command, strlen(as_command) + strlen(args) + 1 ); strcat( as_command, args ); } } return as_command; } }}} -- Ticket URL: <https://trac.macports.org/ticket/27659> MacPorts <http://www.macports.org/> Ports system for Mac OS
#27659: wine @1.2.2 winebuild picks the wrong assembler in presence of binutils ----------------------------+----------------------------------------------- Reporter: buffyg@… | Owner: ryandesign@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.9.2 Keywords: | Port: wine ----------------------------+----------------------------------------------- Changes (by macsforever2000@…): * cc: jwa@… (added) * owner: macports-tickets@… => ryandesign@… -- Ticket URL: <https://trac.macports.org/ticket/27659#comment:1> MacPorts <http://www.macports.org/> Ports system for Mac OS
#27659: wine, wine-devel: winebuild picks the wrong assembler in presence of binutils ----------------------------+----------------------------------------------- Reporter: buffyg@… | Owner: ryandesign@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.9.2 Keywords: | Port: wine, wine-devel ----------------------------+----------------------------------------------- Changes (by ryandesign@…): * port: wine => wine, wine-devel Old description:
'm trying to build wine and running into compile-time failures. I've gone back and looked at the mail archives to check for recent issues. The only thing I could identify was that wine can only build for i386 (I'm running Snow Leopard 10.6.5 on x86_64), thus all dependencies (or at least all shared object dependencies) need to be universal. After going back to make sure that the dependencies are in fact all built with universal variants, I'm still getting build failures. I haven't check back through all of the bug tickets yet, but, as I've recently upgraded to the latest version of XCode, I wasn't sure if that might cause some issues (although information provided further down makes this seem less plausible). Here's where things start to go wrong in the logs:
{{{ :info:build /usr/bin/gcc-4.2 -m32 -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_ADVAPI32_ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wstrict- prototypes -Wwrite-strings -Wpointer-arith -I/opt/local/include -D_DARWIN_NO_64_BIT_INODE -O2 -arch i386 -o cred.o cred.c :info:build /usr/bin/gcc-4.2 -m32 -o wineserver async.o atom.o change.o class.o clipboard.o completion.o console.o debugger.o device.o directory.o event.o fd.o file.o handle.o hook.o mach.o mailslot.o main.o mapping.o mutex.o named_pipe.o object.o process.o procfs.o ptrace.o queue.o region.o registry.o request.o semaphore.o serial.o signal.o snapshot.o sock.o symlink.o thread.o timer.o token.o trace.o unicode.o user.o window.o winstation.o -L../libs/wine -lwine ../libs/port/libwine_port.a -L/opt/local/lib -framework CoreServices -lz -arch i386 && install_name_tool -change @executable_path/`../tools/relpath /opt/local/bin /opt/local/lib`/libwine.1.dylib @executable_path/../libs/wine/libwine.1.dylib wineserver || rm -f wineserver :info:build /usr/bin/gcc-4.2 -m32 -c -I. -I. -I../../../include -I../../../include -DWINE_STRICT_PROTOTYPES -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wstrict- prototypes -Wwrite-strings -Wpointer-arith -I/opt/local/include -D_DARWIN_NO_64_BIT_INODE -O2 -arch i386 -o cred.o cred.c :info:build ../../tools/widl/widl -I. -I. -I../../include -I../../include -D__WINESRC__ -DREGISTER_PROXY_DLL -DPROXY_DELEGATION -p -P actxprxy_activscp_p.c actxprxy_activscp.idl :info:build ../../tools/winegcc/winegcc -m32 -B../../tools/winebuild --sysroot=../.. -shared ./activeds.spec activeds_main.o -o activeds.dll.so -lkernel32 ../../libs/port/libwine_port.a -L/opt/local/lib -framework CoreServices -lz -arch i386 :info:build Assembler messages: :info:build Fatal error: invalid listing option `r' :info:build winebuild: /opt/local/bin/gas -arch i386 failed with status 256 :info:build winegcc: ../../tools/winebuild/winebuild failed :info:build make[1]: *** [acledit.dll.so] Error 2 :info:build make: *** [dlls/acledit] Error 2 :info:build make: *** Waiting for unfinished jobs.... }}}
The 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:
/opt/local/bin/gas -arch i386 -o activeds.ymaQ1t.o activeds.YHUnAl.s
In fact it should be called via:
/opt/local/bin/gas -march i386 -o activeds.ymaQ1t.o activeds.YHUnAl.s
The "-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?
I have succeeded in getting wine to build with the following patch:
{{{ const char *get_as_command(void) { if (!as_command) { < static const char * const commands[] = { "gas", "as", NULL }; as_command = find_tool( "as", commands ); if (force_pointer_size) { const char *args = (target_platform == PLATFORM_APPLE) ? ((force_pointer_size == 8) ? " -arch x86_64" : " -arch i386") : ((force_pointer_size == 8) ? " --64" : " --32"); as_command = xrealloc( as_command, strlen(as_command) + strlen(args) + 1 ); strcat( as_command, args ); } } return as_command; }
const char *get_as_command(void) { if (!as_command) { static const char * const commands[] = { "as", NULL }; as_command = find_tool( "as", commands ); if (force_pointer_size) { const char *args = (target_platform == PLATFORM_APPLE) ? ((force_pointer_size == 8) ? " -arch x86_64" : " -arch i386") : ((force_pointer_size == 8) ? " --64" : " --32"); as_command = xrealloc( as_command, strlen(as_command) + strlen(args) + 1 ); strcat( as_command, args ); } } return as_command; } }}}
New description: 'm trying to build wine and running into compile-time failures. I've gone back and looked at the mail archives to check for recent issues. The only thing I could identify was that wine can only build for i386 (I'm running Snow Leopard 10.6.5 on x86_64), thus all dependencies (or at least all shared object dependencies) need to be universal. After going back to make sure that the dependencies are in fact all built with universal variants, I'm still getting build failures. I haven't check back through all of the bug tickets yet, but, as I've recently upgraded to the latest version of XCode, I wasn't sure if that might cause some issues (although information provided further down makes this seem less plausible). Here's where things start to go wrong in the logs: {{{ :info:build /usr/bin/gcc-4.2 -m32 -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_ADVAPI32_ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wstrict-prototypes -Wwrite-strings -Wpointer-arith -I/opt/local/include -D_DARWIN_NO_64_BIT_INODE -O2 -arch i386 -o cred.o cred.c :info:build /usr/bin/gcc-4.2 -m32 -o wineserver async.o atom.o change.o class.o clipboard.o completion.o console.o debugger.o device.o directory.o event.o fd.o file.o handle.o hook.o mach.o mailslot.o main.o mapping.o mutex.o named_pipe.o object.o process.o procfs.o ptrace.o queue.o region.o registry.o request.o semaphore.o serial.o signal.o snapshot.o sock.o symlink.o thread.o timer.o token.o trace.o unicode.o user.o window.o winstation.o -L../libs/wine -lwine ../libs/port/libwine_port.a -L/opt/local/lib -framework CoreServices -lz -arch i386 && install_name_tool -change @executable_path/`../tools/relpath /opt/local/bin /opt/local/lib`/libwine.1.dylib @executable_path/../libs/wine/libwine.1.dylib wineserver || rm -f wineserver :info:build /usr/bin/gcc-4.2 -m32 -c -I. -I. -I../../../include -I../../../include -DWINE_STRICT_PROTOTYPES -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wstrict- prototypes -Wwrite-strings -Wpointer-arith -I/opt/local/include -D_DARWIN_NO_64_BIT_INODE -O2 -arch i386 -o cred.o cred.c :info:build ../../tools/widl/widl -I. -I. -I../../include -I../../include -D__WINESRC__ -DREGISTER_PROXY_DLL -DPROXY_DELEGATION -p -P actxprxy_activscp_p.c actxprxy_activscp.idl :info:build ../../tools/winegcc/winegcc -m32 -B../../tools/winebuild --sysroot=../.. -shared ./activeds.spec activeds_main.o -o activeds.dll.so -lkernel32 ../../libs/port/libwine_port.a -L/opt/local/lib -framework CoreServices -lz -arch i386 :info:build Assembler messages: :info:build Fatal error: invalid listing option `r' :info:build winebuild: /opt/local/bin/gas -arch i386 failed with status 256 :info:build winegcc: ../../tools/winebuild/winebuild failed :info:build make[1]: *** [acledit.dll.so] Error 2 :info:build make: *** [dlls/acledit] Error 2 :info:build make: *** Waiting for unfinished jobs.... }}} The 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: {{{ /opt/local/bin/gas -arch i386 -o activeds.ymaQ1t.o activeds.YHUnAl.s }}} In fact it should be called via: {{{ /opt/local/bin/gas -march i386 -o activeds.ymaQ1t.o activeds.YHUnAl.s }}} The "-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? I have succeeded in getting wine to build with the following patch: {{{ const char *get_as_command(void) { if (!as_command) { < static const char * const commands[] = { "gas", "as", NULL }; as_command = find_tool( "as", commands ); if (force_pointer_size) { const char *args = (target_platform == PLATFORM_APPLE) ? ((force_pointer_size == 8) ? " -arch x86_64" : " -arch i386") : ((force_pointer_size == 8) ? " --64" : " --32"); as_command = xrealloc( as_command, strlen(as_command) + strlen(args) + 1 ); strcat( as_command, args ); } } return as_command; } const char *get_as_command(void) { if (!as_command) { static const char * const commands[] = { "as", NULL }; as_command = find_tool( "as", commands ); if (force_pointer_size) { const char *args = (target_platform == PLATFORM_APPLE) ? ((force_pointer_size == 8) ? " -arch x86_64" : " -arch i386") : ((force_pointer_size == 8) ? " --64" : " --32"); as_command = xrealloc( as_command, strlen(as_command) + strlen(args) + 1 ); strcat( as_command, args ); } } return as_command; } }}} -- Comment: wine-devel is affected as well. -- Ticket URL: <https://trac.macports.org/ticket/27659#comment:2> MacPorts <http://www.macports.org/> Ports system for Mac OS
#27659: wine, wine-devel: winebuild picks the wrong assembler in presence of binutils ----------------------------+----------------------------------------------- Reporter: buffyg@… | Owner: ryandesign@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.9.2 Keywords: | Port: wine, wine-devel ----------------------------+----------------------------------------------- Comment(by ryandesign@…): binutils @2.21_0 didn't install any "gas" program for me, on Snow Leopard on a 64-bit Mac, and wine-devel built fine with binutils installed and active. -- Ticket URL: <https://trac.macports.org/ticket/27659#comment:3> MacPorts <http://www.macports.org/> Ports system for Mac OS
#27659: wine, wine-devel: winebuild picks the wrong assembler in presence of binutils ----------------------------+----------------------------------------------- Reporter: buffyg@… | Owner: ryandesign@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.9.2 Keywords: | Port: wine, wine-devel ----------------------------+----------------------------------------------- Comment(by buffyg@…): Replying to [comment:3 ryandesign@…]:
binutils @2.21_0 didn't install any "gas" program for me, on Snow Leopard on a 64-bit Mac, and wine-devel built fine with binutils installed and active.
I'm just about to update to 2.21_0 (meant to, than forgot about it as I became engrossed in debugging). For the record, here's what I've got before I now proceed to update: {{{ bayard@precious:~ 01:40:15 [501]$ which gas /opt/local/bin/gas bayard@precious:~ 01:40:20 [502]$ gas -v GNU assembler version 2.20.1 (i386-apple-darwin10.3.0) using BFD version (GNU Binutils) 2.20.1.20100303 bayard@precious:~ 01:41:12 [503]$ port info binutils binutils @2.20.1 (devel) Variants: universal Description: Free Software Foundation development toolchain ("binutils") for native development. Tools are prefixed with g to avoid conflicts with original tools. Homepage: http://www.gnu.org/software/binutils/binutils.html Library Dependencies: zlib, libiconv, gettext Platforms: darwin License: unknown Maintainers: nomaintainer@macports.org bayard@precious:~ 01:41:58 [504]$ port contents binutils | grep -w gas /opt/local/bin/gas /opt/local/share/locale/es/LC_MESSAGES/gas.mo /opt/local/share/locale/fr/LC_MESSAGES/gas.mo /opt/local/share/locale/id/LC_MESSAGES/gas.mo /opt/local/share/locale/rw/LC_MESSAGES/gas.mo /opt/local/share/locale/tr/LC_MESSAGES/gas.mo /opt/local/share/man/man1/gas.1.gz }}} -- Ticket URL: <https://trac.macports.org/ticket/27659#comment:4> MacPorts <http://www.macports.org/> Ports system for Mac OS
#27659: wine, wine-devel: winebuild picks the wrong assembler in presence of binutils ----------------------------+----------------------------------------------- Reporter: buffyg@… | Owner: ryandesign@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.9.2 Keywords: | Port: wine, wine-devel ----------------------------+----------------------------------------------- Comment(by buffyg@…): I don't see gas in binutils after the upgrade. I took a look at the source history, and it appears that configure for binutils was modified a while back to remove gas, ld, and gprof on x86_64-*-darwin targets. Here's the snippet from configure.ac, excerpted down to include only the darwin branches: {{{ case "${target}" in powerpc-*-darwin*) noconfigdirs="$noconfigdirs ld gas gdb gprof" noconfigdirs="$noconfigdirs sim target-rda" ;; i[[3456789]]86-*-darwin*) noconfigdirs="$noconfigdirs ld gprof" noconfigdirs="$noconfigdirs sim target-rda" ;; x86_64-*-darwin[[912]]*) noconfigdirs="$noconfigdirs ld gas gprof" noconfigdirs="$noconfigdirs sim target-rda" ;; *-*-darwin*) noconfigdirs="$noconfigdirs ld gas gdb gprof" noconfigdirs="$noconfigdirs sim target-rda" noconfigdirs="$noconfigdirs ${libgcj}" ;; esac }}} If I'm reading this correctly, the problem will still manifest on i?86-*-darwin machines. If this is correct (and one could test it by building manually and specifying the x86 configuration profile on an x86_64 machines), I expect there are two options: one would be to create a new revision of binutils that modifies configure to exclude gas from being built by default on that system, and the other would be to eliminate any assumptions about whether gas is present or not by patching wine to avoid it. I know that there's a standard disclaimer indicating that binutils can cause problems with other ports, so another option would be to leave it broken, as the expectation should be that anyone installing it should be willing and able to deal with collateral damage. -- Ticket URL: <https://trac.macports.org/ticket/27659#comment:5> MacPorts <http://www.macports.org/> Ports system for Mac OS
#27659: wine, wine-devel: winebuild picks the wrong assembler in presence of binutils ----------------------------+----------------------------------------------- Reporter: buffyg@… | Owner: ryandesign@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.9.2 Keywords: | Port: wine, wine-devel ----------------------------+----------------------------------------------- Comment(by chiisaiu@…): Replying to [ticket:27659 buffyg@…]: Was a solution to this ever decided on? Running up against this on x86 wine & wine-devel, most recent MacPorts. -- Ticket URL: <https://trac.macports.org/ticket/27659#comment:6> MacPorts <http://www.macports.org/> Ports system for Mac OS
#27659: wine, wine-devel: winebuild picks the wrong assembler in presence of binutils ----------------------------+----------------------------------------------- Reporter: buffyg@… | Owner: ryandesign@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.9.2 Keywords: | Port: wine, wine-devel ----------------------------+----------------------------------------------- Comment(by ryandesign@…): None other than the standard response, which is: don't use binutils. {{{ $ port notes binutils binutils has the following notes: Having binutils installed will cause some other ports to fail to build. Consider uninstalling binutils. }}} -- Ticket URL: <https://trac.macports.org/ticket/27659#comment:7> MacPorts <http://www.macports.org/> Ports system for Mac OS
#27659: wine, wine-devel: winebuild picks the wrong assembler in presence of binutils ----------------------------+----------------------------------------------- Reporter: buffyg@… | Owner: ryandesign@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.9.2 Keywords: | Port: wine, wine-devel ----------------------------+----------------------------------------------- Comment(by dluke@…): Although in this case, we could make it work by either patching binutils to skip installation of gas, ld, and gprof on i386 like it does on x86_64 (and ppc, or unknown), or by patching wine to not look for gas. I think it's better if we can make things 'just work' for people whenever possible. -- Ticket URL: <https://trac.macports.org/ticket/27659#comment:8> MacPorts <http://www.macports.org/> Ports system for Mac OS
#27659: wine, wine-devel: winebuild picks the wrong assembler in presence of binutils ----------------------------+----------------------------------------------- Reporter: buffyg@… | Owner: ryandesign@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.9.2 Keywords: | Port: wine, wine-devel ----------------------------+----------------------------------------------- Changes (by ryandesign@…): * cc: macports.org@… (added) Comment: Has duplicate #28899 -- Ticket URL: <https://trac.macports.org/ticket/27659#comment:9> MacPorts <http://www.macports.org/> Ports system for Mac OS
#27659: wine, wine-devel: winebuild picks the wrong assembler in presence of binutils ----------------------------+----------------------------------------------- Reporter: buffyg@… | Owner: ryandesign@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.9.2 Keywords: | Port: wine, wine-devel ----------------------------+----------------------------------------------- Comment(by ryandesign@…): For those wondering, the simplest workaround at the moment is to deactivate binutils for the duration of building wine. You can reactivate binutils afterward (if you must). So for example: {{{ sudo port clean wine sudo port -f deactivate binutils sudo port install wine sudo port activate binutils }}} -- Ticket URL: <https://trac.macports.org/ticket/27659#comment:10> MacPorts <http://www.macports.org/> Ports system for Mac OS
participants (1)
-
MacPorts