[MacPorts] #27659: wine, wine-devel: winebuild picks the wrong assembler in presence of binutils (was: wine @1.2.2 winebuild picks the wrong assembler in presence of binutils)
MacPorts
noreply at macports.org
Mon Dec 13 16:34:03 PST 2010
#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
More information about the macports-tickets
mailing list