Skip to content

./configure --enable-framework --enable-universalsdk fails because of change in r63997 #47631

Closed

Description

@trentm
mannequin
BPO 3381
Nosy @birkenfeld, @ronaldoussoren, @benjaminp
Files
  • configure-patch-3381.txt
  • configure-patch-3381-1.txt
  • configure-patch-3381-2.txt
  • issue3381_configure_fix.patch: tweak to svn head to fix "configure-patch-3381-2.txt"
  • Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = 'https://github.com/ronaldoussoren'
    closed_at = <Date 2008-07-22.07:07:20.196>
    created_at = <Date 2008-07-16.17:37:36.913>
    labels = ['deferred-blocker', 'build']
    title = '`./configure --enable-framework --enable-universalsdk` fails because of change in r63997'
    updated_at = <Date 2008-07-22.07:11:19.352>
    user = 'https://bugs.python.org/trentm'

    bugs.python.org fields:

    activity = <Date 2008-07-22.07:11:19.352>
    actor = 'trentm'
    assignee = 'ronaldoussoren'
    closed = True
    closed_date = <Date 2008-07-22.07:07:20.196>
    closer = 'ronaldoussoren'
    components = ['Build']
    creation = <Date 2008-07-16.17:37:36.913>
    creator = 'trentm'
    dependencies = []
    files = ['10912', '10913', '10923', '10956']
    hgrepos = []
    issue_num = 3381
    keywords = ['patch']
    message_count = 16.0
    messages = ['69805', '69817', '69819', '69820', '69823', '69827', '69828', '69832', '69871', '69883', '69935', '69936', '70114', '70115', '70138', '70139']
    nosy_count = 4.0
    nosy_names = ['georg.brandl', 'ronaldoussoren', 'benjamin.peterson', 'trentm']
    pr_nums = []
    priority = 'deferred blocker'
    resolution = 'fixed'
    stage = None
    status = 'closed'
    superseder = None
    type = 'compile error'
    url = 'https://bugs.python.org/issue3381'
    versions = ['Python 2.6']

    Activity

    1. trentm commented on Jul 16, 2008

      trentmmannequin
      MannequinAuthor

      Configuring with "--enable-universalsdk" fails on Mac OS X 10.4/x86
      because of a change in r63997. This in the python trunk (i.e. the 2.6 tree).

      The failure looks like this:

      ----------------------------

      $ ./configure --enable-framework --enable-universalsdk
      ...
      checking for log1p... no
      checking wchar.h usability... yes
      checking wchar.h presence... yes
      checking for wchar.h... yes
      checking for wchar_t... yes
      checking size of wchar_t... configure: error: cannot compute sizeof
      (wchar_t)
      See `config.log' for more details.

      And the appropriate details in config.log are:
      ----------------------------
      ...
      configure:21540: checking size of wchar_t
      configure:21875: gcc -o conftest -arch ppc -arch i386 -isysroot
      /Developer/SDKs/MacOSX10.4u.sdk -g -O2 -arch ppc -arch i386 -isysroot
      /Developer/SDKs/MacOSX10.4u.sdk conftest.c >&5
      /usr/bin/ld: -syslibroot: multiply specified
      collect2: ld returned 1 exit status
      /usr/bin/ld: -syslibroot: multiply specified
      collect2: ld returned 1 exit status
      lipo: can't open input file: /var/tmp//cctmsJ7u.out (No such file or
      directory)
      configure:21878: $? = 1
      configure: program exited with status 1
      configure: failed program was:
      ...
      ----------------------------

      The command being run:

      gcc -o conftest -arch ppc -arch i386 -isysroot
      /Developer/SDKs/MacOSX10.4u.sdk -g -O2 -arch ppc -arch i386 -isysroot
      /Developer/SDKs/MacOSX10.4u.sdk conftest.c

      is "$ac_link". Here is a dump of relevant variables at that point in
      "configure":

      ------------------
      LDFLAGS is "-arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk "
      CFLAGS is "-arch ppc -arch i386 -isysroot
      /Developer/SDKs/MacOSX10.4u.sdk -g -O2"
      CPPFLAGS is ""
      CC is "gcc"
      ac_link is "$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS
      conftest.$ac_ext $LIBS >&5"
      ------------------

      The problem is that r63997
      (http://mail.python.org/pipermail/python-checkins/2008-June/070612.html)
      added this line to "configure.in" for Mac OS X:

      CFLAGS="${UNIVERSAL_ARCH_FLAGS} -isysroot ${UNIVERSALSDK} ${CFLAGS}"
      

      That results in the failure above: "ld" complaining about
      -isysroot/-syslibroot being specified twice on the command line.

      Ronald,
      What was the "build issue on OSX 10.4" that the was meant to be fixed.
      Can it be fixed without that "configure" change to "CFLAGS"?

    2. added
      buildThe build process and cross-build
      on Jul 16, 2008
    3. ronaldoussoren commented on Jul 16, 2008

      @ronaldoussoren
      Contributor

      This is rather annoying, gcc doesn't accept multipe -isysroot flags on
      10.4, yet we need to specify -isysroot during configure to ensure that
      tests are done using the right SDK, otherwise most of configure will use
      the system headers instead of the SDK specified using the --enable-
      universalsdk option.

      I'm currently trying to teach configure to only add -isysroot to the
      configure-time CFLAGS when the OS version is 10.5 or later, because
      that's the only platform where -isysroot is really needed in the
      configure-time CFLAGS.

      The patch should be ready later tonight, I'll post it here instead of
      committing to avoid interfering with the release process.

    4. ronaldoussoren commented on Jul 16, 2008

      @ronaldoussoren
      Contributor

      configure-patch-3381.txt should fix the issue, but I cannot test on 10.4
      as I recently had to convert my only 10.4 machine to 10.5.

    5. ronaldoussoren commented on Jul 16, 2008

      @ronaldoussoren
      Contributor

      Note to self: never rush a patch

      configure-patch-3881-1.txt is the better patch, the other looks right but
      using square brackets which don't survive autoconf.

      BTW. the patch is only for configure.in, run autoconf to update the actual
      configure script.

    6. ronaldoussoren commented on Jul 16, 2008

      @ronaldoussoren
      Contributor

      Yet another version: configure-patch-3381-2.txt is a slight enhancement
      of the first version.

      This version also moves the calculation of MACOSX_DEPLOYMENT_TARGET a
      lot
      earlier in configure.in, to ensure that the right value is active
      whenever
      the compiler is used.

      This turns out to be necessary to build using the 10.4 SDK on OSX 10.5.

      BTW. Feel free to commit if the patch works for you, I'm rather swamped
      at work and won't be able to test on 10.4 anytime soon.

    7. trentm commented on Jul 16, 2008

      trentmmannequin
      MannequinAuthor

      BTW. Feel free to commit if the patch works for you, I'm rather swamped
      at work and won't be able to test on 10.4 anytime soon.

      Thanks for the quick patches. Other than verifying that configure && make works on 10.4 what specifically should I do "to ensure that
      tests are done using the right SDK" (as you said in an earlier
      comment)?

    8. changed the title [-]`./configure --enable-framework --enable-universalsdk` fails because of change in r63997[/-] [+]`./configure --enable-framework --enable-universalsdk` fails because of change in r63997[/+] on Jul 16, 2008
    9. ronaldoussoren commented on Jul 16, 2008

      @ronaldoussoren
      Contributor

      The easiest way to test the configure bits would be to build on 10.5 with
      --enable-universalsdk and --enable-universalsdk=/. Both should work on
      10.5, while using different SDKs (with slightly different unix APIs).

      However: it shouldn't be necessary to test that specific bit, I introduced
      bpo-3381 when I fixed the "configure should use the right CFLAGS" issue
      for 10.5 and my patch for bpo-3381 doesn't change the compiler flags on
      10.5.

    10. trentm commented on Jul 16, 2008

      trentmmannequin
      MannequinAuthor

      Yet another version: configure-patch-3381-2.txt is a slight enhancement
      of the first version.

      Ronald,
      Did that accidentally not get attached?

    11. ronaldoussoren commented on Jul 17, 2008

      @ronaldoussoren
      Contributor

      Forgot to upload updated patch

    12. benjaminp commented on Jul 17, 2008

      @benjaminp
      Contributor

      Ok applied in r65061.

    13. ronaldoussoren commented on Jul 18, 2008

      @ronaldoussoren
      Contributor

      Whoops, bpo-3393 is a duplicate of this issue and notes that
      Mac/IDLE/Makefile.in is also affected.

      I've fixed that makefile in r65091.

    14. trentm commented on Jul 18, 2008

      trentmmannequin
      MannequinAuthor

      Ronald,

      The @ARCH_RUN_32BIT@ also needs to be added to two places in
      Mac/Makefile.in (as indicated in bpo-3393), no? Would you like me to
      make that change?

    15. trentm commented on Jul 21, 2008

      trentmmannequin
      MannequinAuthor

      This bug should be re-opened. The patch to configure.in wasn't quite
      right. I'm attaching a slight fix. autoconfing removes one level of
      square brackets in the 'sed' command to create $tgt.

      (Q about the issue tracker: I'm unable to change the "Status" field on
      this bug. I'm guessing that is "by design", right? I.e., only certain
      people have the privs to change bug status?)

    16. added
      buildThe build process and cross-build
      on Jul 21, 2008
    17. birkenfeld commented on Jul 21, 2008

      @birkenfeld
      Member

      Reopening. Yes, "Status" is settable only by Developers, but as a
      committer, you should certainly have that privilege.

    18. ronaldoussoren commented on Jul 22, 2008

      @ronaldoussoren
      Contributor

      Committed in r65183.

    19. trentm commented on Jul 22, 2008

      trentmmannequin
      MannequinAuthor

      Thanks Ronald.

      Any comment on http://bugs.python.org/msg69936

    20. transferred this issue fromon Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

    Metadata

    Metadata

    Labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions