[MacPorts] #39786: wxWidgets @2.9.5 universal build fails
MacPorts
noreply at macports.org
Wed Jul 24 01:06:46 PDT 2013
#39786: wxWidgets @2.9.5 universal build fails
---------------------------+-------------------
Reporter: ryandesign@… | Owner: jwa@…
Type: defect | Status: new
Priority: Normal | Milestone:
Component: ports | Version: 2.1.3
Resolution: | Keywords:
Port: wxWidgets30 |
---------------------------+-------------------
Comment (by mojca@…):
One of the problems with current patch is that it skips this test:
{{{
if echo $OSX_ARCH_OPTS | grep -q ","; then
AC_MSG_WARN([Disabling dependency tracking due to universal binary
build.])
disable_macosx_deps=yes
dnl HACK: PCH could be made to work by precompiling for each
architecture into separate directories
dnl and including all architecture directories with each compiler
invocation.
dnl That would require a major rework of Bakefile and at the same
time it would be nice to have
dnl Objective-C++ precompiled headers.
AC_MSG_WARN([Disabling precompiled headers due to universal binary
build.])
bk_use_pch=no
fi
}}}
and possibly some other places like:
{{{
AC_MSG_CHECKING([for architectures to use in universal binary])
AC_MSG_RESULT([$OSX_ARCH_OPTS])
dnl NOTE: Only the compiler driver needs arch flags. The link editor
dnl is incapable of using them but the compiler driver (which we use
dnl as LD when building dynamic libraries) uses them to invoke the
dnl real ld multiple times. If we moved to libtool -dynamic we would
dnl need no arch flags because libtool automatically invokes ld for
dnl every architecture found in the fat input files.
dnl
dnl For static library builds, AR/RANLIB automatically create proper
dnl fat archives although AR is unable to update them once RANLIB has
dnl made them into proper fat archives. Fortunately, our link process
dnl simply removes the .a file before using ar to create a new one.
dnl If we did move to libtool -static we still wouldn't need arch
flags
dnl because libtool automatically figures it out based on input.
retest_macosx_linking=yes
}}}
because it sets {{{OSX_ARCH_OPTS}}} to {{{-arch i386 -arch x86_64}}}
instead of {{{i386,x86_64}}}.
It would be a lot cleaner to specify the flags in command line rather than
patching {{{OSX_ARCH_OPTS}}} in configure script. Apart from this there is
another patch for {{{install_name_too}}}, but I don't understand that one.
--
Ticket URL: <https://trac.macports.org/ticket/39786#comment:4>
MacPorts <http://www.macports.org/>
Ports system for OS X
More information about the macports-tickets
mailing list