I have just found out that cmake-based builds also have this problem,
for example: physfs
On 07/03/2020 14:17, ah via macports-users wrote:
Hi,
this is on OSX 13.6 (High Sierra) on a macbookpro/2012 (which is an
intell 64bit i believe), and XCode 10.1 (build 10861) the last few hours
I am experiencing a new kind of failure using macports. A couple of
weeks ago I have installed successfully opencv. And none of the problems
I describe here arose.
So,
Initially I wanted to do: port -s -v install dosbox
One of its dependencies, "libsdl", failed with lots of symbols undefined
(at linking). One of the messages was "ld: warning: ignoring file
/Library/Frameworks/AudioUnit.framework/AudioUnit.tbd, missing required
architecture i386 in file
/Library/Frameworks/AudioUnit.framework/AudioUnit.tbd" then "Undefined
symbols for architecture i386: ...[lots of symbols]"
and the linking command had this in it:
-arch i386
I have traced this to the "configure" file in libsdl's build dir (where
macports extracted sources and attempted to build), in the following line:
/usr/bin/uname -p = `(/usr/bin/uname -p) 2>/dev/null || echo unknown`
when I replaced the righ-hand expression with just the string
x86_64
all compiled well.
Prior to this, python 3.7 also had similar problems. And I managed to
solve them using the same method with additionally replacing all
occurences of "arch -i386" and "extract i386" from configure script also
(this is from my memory).
I have explicitly set :
export LDFLAGS=
export CFLAGS=
export CXXFLAGS=
before :
port -v -s libsdl
btw,
/bin/uname -p reports i386
and so is
/opt/local/libexec/gnubin/uname -p
whereas
/bin/uname -m reports x86_64
Lately, I did install autotools port, perhaps that broke things somehow,
not being aware about the osx idiotic "uname -p" reporting i386? *(btw
my kernel I believe is 64bit, "About this mac->System
report->Software->Extensions->64-0Bit (Intel): YES"
also :
uname -a
reports x86_64
