8000 Compiling and linking main() with C++ compiler · Issue #42471 · python/cpython · GitHub
[go: up one dir, main page]
Skip to content

Compiling and linking main() with C++ compiler #42471

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
cludwig mannequin opened this issue Oct 12, 2005 · 9 comments
Closed

Compiling and linking main() with C++ compiler #42471

cludwig mannequin opened this issue Oct 12, 2005 · 9 comments
Labels
build The build process and cross-build

Comments

@cludwig
Copy link
Mannequin
cludwig mannequin commented Oct 12, 2005
BPO 1324762
Nosy @loewis, @jackjansen
Files
  • cxx-main.patch: Proposed resolution to url:http://thread.gmane.org/gmane.comp.python.devel/69651>
  • cxx-main.patch2: incorporates jackjansen's suggestion
  • cxx-main.patch3: avoids CC=gcc and CXX=c++
    		•

    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 = None
closed_at = <Date 2006-04-14.14:36:14.000>
created_at = <Date 2005-10-12.11:45:22.000>
labels = ['build']
title = 'Compiling and linking main() with C++ compiler'
updated_at = <Date 2006-04-14.14:36:14.000>
user = 'https://bugs.python.org/cludwig'

    bugs.python.org fields:

    activity = <Date 2006-04-14.14:36:14.000>
actor = 'loewis'
assignee = 'none'
closed = True
closed_date = None
closer = None
components = ['Build']
creation = <Date 2005-10-12.11:45:22.000>
creator = 'cludwig'
dependencies = []
files = ['6816', '6817', '6818']
hgrepos = []
issue_num = 1324762
keywords = ['patch']
message_count = 9.0
messages = ['48849', '48850', '48851', '48852', '48853', '48854', '48855', '48856', '48857']
nosy_count = 4.0
nosy_names = ['loewis', 'jackjansen', 'cludwig', 'jholg']
pr_nums = []
priority = 'normal'
resolution = 'accepted'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue1324762'
versions = ['Python 2.5']
    @cludwig
    Copy link
    Mannequin Author
    cludwig mannequin commented Oct 12, 2005

    The attached patch proposes a resolution to the discussion
    started in
    <url:http://thread.gmane.org/gmane.comp.python.devel/69651\>
    regarding the compiler (C vs. C++) used to compile python's
    main() and to link the executable.

    The patch contains the following changes:

    1. The configure option --with-cxx is renamed
      --with-cxx-main. This was done to avoid surprising the user
      by the changed meaning. Furthermore, it is now possible
      that CXX has a different value than provided by
      --with-cxx-main, so the old name would have been
      confusing.

    2. The compiler used to translate python's main() function is
      stored in the configure / Makefile variable MAINCC. By
      default, MAINCC=$(CC). If --with-cxx-main is given (without
      an appended compiler name), then MAINCC=$(CXX). If
      --with-cxx-main=<compiler> is on the configure command
      line, then MAINCC=<compiler>. Additionally, configure sets
      CXX=<compiler> unless CXX was already set on the
      configure command line.

    3. The command used to link the python executable is (as
      before) stored in LINKCC. By default, LINKCC='$(PURIFY)
      $(MAINCC)', i.e. the linker front-end is the compiler used to
      translate main(). If necessary, LINKCC can be set on the
      configure command line in which case it won't be altered.

    4. If CXX is not set by the user (on the command line or via
      --with-cxx-main), then configure tries several likely C++
      compiler names. CXX is assigned the first name that refers
      to a callable program in the system. (CXX is set even if
      python is built with a C compiler only, so distutils can build
      C++ extensions.)

    5. Modules/ccpython.cc is no longer used and can be
      removed.

    @cludwig cludwig mannequin closed this as completed Oct 12, 2005
    @cludwig cludwig mannequin added the build The build process and cross-build label Oct 12, 2005
    @cludwig cludwig mannequin closed this as completed Oct 12, 2005
    @cludwig cludwig mannequin added the build The build process and cross-build label Oct 12, 2005
    @jackjansen
    Copy link
    Member

    Logged In: YES
    user_id=45365

    One question: is step 4 a wise idea? Picking a random C++ compiler if
    multiple are available may result in picking a vendor C++ when the user
    has specified CC=gcc, for example.

    OTOH, actually doing the configure magic to determine that the selected
    C++ works together with the c-compiler selected for Python may be
    overkill too.

    Maybe try only standard combinations cc/c++ gcc/g++ and otherwise
    require --with{out}-cxx?

    @cludwig
    Copy link
    Mannequin Author
    cludwig mannequin commented Nov 10, 2005

    Logged In: YES
    user_id=1266029

    I am going to upload a revision of my patch that addresses
    jackjansen's comment: It sets CXX to g++ or c++ if CC is gcc or
    cc, respectively. Additionally, it writes a warning if configure had to
    "guess" the C++ compiler and tells the user how to override this
    guess.

    The change is in lin with jackjansen's second suggestion. It is
    pretty straight forward and avoids fragile configure magic.

    @jackjansen
    Copy link
    Member

    Logged In: YES
    user_id=45365

    Well, as I commented on this patch and you quickly followed my suggestions I
    felt obliged to test your fix, but I'm not sure about the outcome.

    I built a C++ extension on MacOSX 10.4, gcc 4, framework Python. The good
    news is that it worked fine, everything built and worked as before. BUT: both
    with and without your mods my C++ modules are compiled with "gcc", not "g
    ++" or "c++". Linking is done with "c++", in both cases. I looked at distutils
    and it seems that it could indeed be the case that CXX is only used for linking
    and never for compilation, but I'm not 100% sure.

    Additionally, the Makefile has
    CC= gcc
    CXX= c++
    which is technically fine on my machine (g++ == c++), but may not work
    always.

    Maybe someone who has a machine with both cc/c++ and gcc/g++ installed,
    and preferrably incompatible compilers, could give this patch a try too?

    @cludwig
    Copy link
    Mannequin Author
    cludwig mannequin commented Nov 25, 2005

    Logged In: YES
    user_id=1266029

    distutils behaves the same way in Python 2.4.1, as I
    mentioned
    <url:http://article.gmane.org/gmane.comp.python.devel/69817\>.
    My patch does not address this problem at all. (It should
    be fixed in distutils, but I did not the time to look into
    it yet.)

    I am surprised that, on your machine, CC=gcc and CXX=c++. I
    will look into this next week.

    @cludwig
    Copy link
    Mannequin Author
    cludwig mannequin commented Nov 30, 2005

    Logged In: YES
    user_id=1266029

    My second patch was indeed broken since it referred to $CC
    before the call to AC_PROG_CC in configure.in. That caused
    CC=gcc and CXX=c++ if neither --with-cxx-main nor CC was
    given on the command line.

    I am going to upload a third version (cxx-main.patch3) that
    fixes this problem by moving the code that evaluates
    --with-cxx-main below AC_PROG_CC.

    To repeat what I wrote in my last comment: This patch does
    not address the issue that distutils calls $CC in order to
    compile C++ source files and calls $CXX in the linking step
    only. Howevr, the patch tries to ensure that CXX is always
    set to a sensible value in the Makefile - even if Python is
    built exclusively with $CC. Thus, distutils has a fighting
    chance to do the right thing (whatever that is) when
    building C++ extensions since it uses the value of CXX
    found in Python's Makefile.

    @jholg
    Copy link
    Mannequin
    jholg mannequin commented Apr 10, 2006

    Logged In: YES
    user_id=1315684

    I can confirm cxx-main.patch3 fixes build problems with gcc
    3.4.4 on Solaris 8, enabling me to _not_ link to libstdc++.
    I also think the patched README text is clearer than the
    original.
    Just my +1 for this patch.

    @jholg
    Copy link
    Mannequin
    jholg mannequin commented Apr 10, 2006

    Logged In: YES
    user_id=1315684

    Forgot to mention the python version: I used it for both
    2.4.2 and 2.4.3.

    I can confirm cxx-main.patch3 fixes build problems with gcc
    3.4.4 on Solaris 8, enabling me to _not_ link to libstdc++.

    @loewis
    8000
    Copy link
    Mannequin
    loewis mannequin commented Apr 14, 2006

    Logged In: YES
    user_id=21627

    Thanks for the patch, committed as 45387. I modified it
    slightly, dropping the PROG_CXX_WORKS part, as selection of
    the C++ compiler is now entirely in the hands of the user.

    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    @vstinner vstinner mentioned this issue Jun 21, 2022
    Closed
    @vstinner vstinner mentioned this issue Aug 4, 2022
    Merged
    vstinner added a commit that referenced this issue Aug 5, 2022
    @vstinner
    gh-93744: Remove configure --with-cxx-main option (#95651)
    398ed84 
    Remove the "configure --with-cxx-main" build option: it didn't work
for many years. Remove the MAINCC variable from configure and
Makefile.

The MAINCC variable was added by the issue gh-42471: commit
0f48d98. Previously, --with-cxx-main
was named --with-cxx.

Keep CXX and LDCXXSHARED variables, even if they are no longer used
by Python build system.
    iritkatriel pushed a commit to iritkatriel/cpython that referenced this issue Aug 11, 2022
    @vstinner @iritkatriel
    pythongh-93744: Remove configure --with-cxx-main option (python#95651)
    0e2c20b 
    Remove the "configure --with-cxx-main" build option: it didn't work
for many years. Remove the MAINCC variable from configure and
Makefile.

The MAINCC variable was added by the issue pythongh-42471: commit
0f48d98. Previously, --with-cxx-main
was named --with-cxx.

Keep CXX and LDCXXSHARED variables, even if they are no longer used
by Python build system.
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Assignees
    No one assigned
    Labels
    build The build process and cross-build
    Projects
    None yet
    Milestone
    No milestone
    Development

    No branches or pull requests
    1 participant
    @jackjansen
    0