GNU bug report logs - #44462
Problem with get_multilibs on macOS

Previous Next

Full log

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Fred Wright <fw <at> fwright.net>
To: bug-dejagnu <at> gnu.org
Subject: Problem with get_multilibs on macOS
Date: Wed, 4 Nov 2020 19:18:30 -0800 (PST)

While investigating some issues in the libffi tests, I came across some 
cases where errors are caused by DejaGnu's get_multilibs function.  For 
some unclear reason, this only seems to get invoked for C++ tests, but 
when it is, there can be a problem, because under some circumstances it 
invokes the compiler with the -dumpspecs option, which is a gcc-only 
option that clang chokes on.  Even when it's using gcc, it bloats the 
logfile with the verbose -dumpspecs output, in order to determine 
something of highly questionable value.

I traced the results of get_multilibs (as used by the libffi tests) in 
many macOS versions, and even the "successful" cases seem to have 
questionably useful results:

	10.4:		/usr/.
	10.5:		/usr/.
	10.6 (x86_64):	/usr/x86_64
	10.6 (i386):	/usr/.
	10.7:		/usr/llvm-gcc-4.2/bin/../x86_64
	10.8:		./x86_64
	10.9:		./x86_64
	10.10:		(fails)
	10.11:		(fails)
	10.12:		(fails)
	10.13:		(fails)
	10.14:		./.
	10.15:		./.

The "/usr/." result returned on 10.4, 10.5, and 32-bit 10.6 is the same as 
what I see on Ubuntu 14.04, CentOS 7, and Fedora 25, though it's not clear 
to me what it's supposed to represent.

Also note that when I build and test a 32-bit version of libffi on 10.9, 
the get_multilibs result is still "./x86_64".

Since get_multilibs already has code to return an empty string in the 
"remote" case (where it assumes this function won't work), I just added 
code to unix.exp to set multitop to "" for all "darwin" targets, thereby 
short-circuiting almost all og get_multilibs.  That certainly fixes the 
problem with the libffi tests, and doesn't change any non-Mac behavior, 
though I don't know if that's the ideal fix.  The whole get_mutilibs 
function looks pretty ugly anyway, and it's generally recognized that 
relying on -dumpspecs is a bad idea.

I primarily tested my patch against the 1.6.2 release, since the current 
master won't install from a non-git directory, and also has multiple 
failures in its own tests (even on Linux).  The patch is nearly identical 
between the 1.6.2 and master cases, anyway.

I can send the current patch, either as a bare email or as an attachment. 
AFAIK, Savannah doesn't have the pull request / merge request concept.

Fred Wright

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.