#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