8000 Failed to build with --with-cxx-main=g++-9.2.0 · Issue #83878 · python/cpython · GitHub
[go: up one dir, main page]
Skip to content

Failed to build with --with-cxx-main=g++-9.2.0 #83878

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
Marco-Sulla mannequin opened this issue Feb 20, 2020 · 15 comments
Closed

Failed to build with --with-cxx-main=g++-9.2.0 #83878

Marco-Sulla mannequin opened this issue Feb 20, 2020 · 15 comments
Labels
3.9 only security fixes build The build process and cross-build type-feature A feature request or enhancement

Comments

@Marco-Sulla
Copy link
Mannequin
Marco-Sulla mannequin commented Feb 20, 2020
BPO 39697
Nosy @vstinner, @jkloth, @tirkarthi, @Marco-Sulla
PRs
  • bpo-39697: unable to compile with --with-cxx-main=g++ #18721
    		•

    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 = None
created_at = <Date 2020-02-20.11:37:58.455>
labels = ['type-feature', '3.9', 'build']
title = 'Failed to build with --with-cxx-main=g++-9.2.0'
updated_at = <Date 2020-08-08.19:52:53.621>
user = 'https://github.com/Marco-Sulla'

    bugs.python.org fields:

    activity = <Date 2020-08-08.19:52:53.621>
actor = 'pablogsal'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Build']
creation = <Date 2020-02-20.11:37:58.455>
creator = 'Marco Sulla'
dependencies = []
files = []
hgrepos = []
issue_num = 39697
keywords = ['patch']
message_count = 14.0
messages = ['362313', '362315', '362545', '363026', '363027', '363064', '363065', '363068', '363069', '363104', '363105', '363227', '363245', '363296']
nosy_count = 5.0
nosy_names = ['cludwig', 'vstinner', 'jkloth', 'xtreak', 'Marco Sulla']
pr_nums = ['18721']
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue39697'
versions = ['Python 3.9']
    @Marco-Sulla
    Copy link
    Mannequin Author
    Marco-Sulla mannequin commented Feb 20, 2020

    I tried to compile Python 3.9 with:

    CC=gcc-9.2.0  ./configure --enable-optimizations --with-lto --with-cxx-main=g++-9.2.0
make -j 2

    I got this error:

    g++-9.2.0 -c -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -flto -fuse-linker-plugin -ffat-lto-objects -flto-partition=none -g -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-function-declaration -fvisibility=hidden -fprofile-generate -I./Include/internal -I. -I./Include -DPy_BUILD_CORE -o Programs/_testembed.o ./Programs/testembed.c
    cc1plus: warning: ‘-Werror=’ argument ‘-Werror=implicit-function-declaration’ is not valid for C++
    cc1plus: warning: command line option ‘-std=c99’ is valid for C/ObjC but not for C++
    sed -e "s,@exename@,/usr/local/bin/python3.9," < ./Misc/python-config.in >python-config.py
    LC_ALL=C sed -e 's,$(([A-Za-z0-9    ]*)),${\1},g' < Misc/python-config.sh >python-config
    gcc-9.2.0 -pthread -c -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -flto -fuse-linker-plugin -ffat-lto-objects -flto-partition=none -g -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-function-declaration -fvisibility=hidden -fprofile-generate -I./Include/internal -I. -I./Include -DPy_BUILD_CORE
    -DGITVERSION=""LC_ALL=C git --git-dir ./.git rev-parse --short HEAD""
    -DGITTAG=""LC_ALL=C git --git-dir ./.git describe --all --always --dirty""
    -DGITBRANCH=""LC_ALL=C git --git-dir ./.git name-rev --name-only HEAD""
    -o Modules/getbuildinfo.o ./Modules/getbuildinfo.c
    In file included from ./Include/internal/pycore_atomic.h:15,
    from ./Include/internal/pycore_gil.h:11,
    from ./Include/internal/pycore_pystate.h:11,
    from ./Programs/_testembed.c:10:
    /usr/local/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include/stdatomic.h:40:9: error: ‘_Atomic’ does not name a type

    I suppose simply [Programs/_testembed.c](https://github.com/python/cpython/blob/main/Programs/_testembed.c) is a C source file and must not be compiled with g++

    PS: as a workaround, --with-cxx-main=gcc-9.2.0 works, but probably it's not optimal.

    @Marco-Sulla Marco-Sulla mannequin added 3.9 only security fixes build The build process and cross-build type-feature A feature request or enhancement labels Feb 20, 2020
    @tirkarthi
    Copy link
    Member

    See also https://bugs.python.org/issue23644

    @Marco-Sulla
    Copy link
    Mannequin Author
    Marco-Sulla mannequin commented Feb 23, 2020

    I think in this case the error is more trivial: simply [Programs/_testembed.c](https://github.com/python/cpython/blob/main/Programs/_testembed.c) is compiled with g++ but it should be compiled with gcc.

    Indeed, there are much gcc-only options in the compilation of [Programs/_testembed.c](https://github.com/python/cpython/blob/main/Programs/_testembed.c), and g++ complains about them:

    cc1plus: warning: ‘-Werror=’ argument ‘-Werror=implicit-function-declaration’ is not valid for C++
    cc1plus: warning: command line option ‘-std=c99’ is valid for C/ObjC but not for C++

    @vstinner
    Copy link
    Member

    _testembed is build by Makefile:

    Programs/_testembed: Programs/_testembed.o $(LIBRARY) $(LDLIBRARY) $(PY3LIBRARY)
    $(LINKCC) $(PY_CORE_LDFLAGS) $(LINKFORSHARED) -o $@ Programs/_testembed.o $(BLDLIBRARY) $(LIBS) $(MODLIBS) $(SYSLIBS)

    with:

    MAINCC= $(CC)
    LINKCC= $(PURIFY) $(MAINCC)

    I'm not sure how g++ landed in LINKCC or MAINCC.

    @vstinner
    Copy link
    Member

    See also https://bugs.python.org/issue23644

    This issue is unrelated and has been fixed.

    @Marco-Sulla
    Copy link
    Mannequin Author
    Marco-Sulla mannequin commented Mar 1, 2020

    The problem is here:

    Programs/_testembed.o: $(srcdir)/Programs/_testembed.c
    $(MAINCC) -c $(PY_CORE_CFLAGS) -o $@ $(srcdir)/Programs/_testembed.c

    MAINCC in my Makefile is g++-9. Probably, MAINCC is set to the value of ``--with-cxx-main`, if specified.

    I replaced MAINCC with CC at this line, and it works.

    @Marco-Sulla
    Copy link
    Mannequin Author
    Marco-Sulla mannequin commented Mar 1, 2020

    #18721

    @Marco-Sulla
    Copy link
    Mannequin Author
    Marco-Sulla mannequin commented Mar 1, 2020

    Mmmmhhhh... wait a moment. It seems the behavior is intended:

    https://bugs.python.org/issue1324762

    I quote:

    The patch contains the following changes:
    [...]
    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=<compiler> is on the configure command
    line, then MAINCC=<compiler>.

    Honestly I have _no idea_ why this change was made. Unluckily, the link to the discussion is broken.

    @jkloth
    Copy link
    Contributor
    jkloth commented Mar 1, 2020

    What seems to be, at least, the conclusion of the thread:

    https://mail.python.org/archives/list/python-dev@python.org/thread/YXMD5EIHAODRZGTQ3HU74OPGEBAVCSK6/

    @Marco-Sulla
    Copy link
    Mannequin Author
    Marco-Sulla mannequin commented Mar 1, 2020

    Okay... if I have understood well, the problem is with C++ Extensions.

    Some questions:

    1. does this problem exists yet?
    2. if yes, maybe Python have to wrap the python.c and _testembed.c so they can also be compiled with a C++ compiler?
    3. --with-cxx-main is not somewhat misleading? There's no documentation, and I interpreted it as "the _main_ compiler for C++", while it means "the compiler for main()". Should I suggest (maybe in another issue) to deprecate it and use --with-mainfun-compiler ?

    @Marco-Sulla
    Copy link
    Mannequin Author
    Marco-Sulla mannequin commented Mar 1, 2020

    Furthermore, I have not understood a think: if I understood well, --with-cxx-main is used on _some_ platforms that have problems with C++ extensions. What platforms? Is there somewhere a unit test for testing if Python compiled on one of these platforms with -with-cxx-main=<some_c++_compiler> works, and if a C++ extension works with this build?

    @pablogsal
    Copy link
    Member

    This seems like a duplicate of https://bugs.python.org/issue35912

    @vstinner
    Copy link
    Member
    vstinner commented Mar 3, 2020

    I marked bpo-35912 as a duplicate of this issue (which has a longer history).

    @Marco-Sulla
    Copy link
    Mannequin Author
    Marco-Sulla mannequin commented Mar 3, 2020

    I agree with Pablo Galindo Salgado: https://bugs.python.org/issue35912#msg334942

    The "quick and dirty" solution is to change MAINCC to CC, for _testembed.c AND python.c (g++ fails with both).

    After that, _testembed.c and python.c should be changed so they can be compiled with a c++ compiler, and a system test should be added.

    Anyway, I found the original patch:
    https://bugs.python.org/file6816/cxx-main.patch

    In the original patch, the README contained detailed information. I think these informations could be restored, maybe in ./configure --help

    Anyway, I have a question. In README, it's stated:

    There are platforms that do not require you to build Python
    with a C++ compiler in order to use C++ extension modules.
    E.g., x86 Linux with ELF shared binaries and GCC 3.x, 4.x is such
    a platform.

    All x86 platforms? Also x86-64? And what does it means "Linux with ELF"? It means that Linux has shared libraries or that Python is compiled with --enable-shared? And what it means gcc 3 and 4? It means gcc 3+?

    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    @serhiy-storchaka
    Copy link
    Member

    This was already fixed in #93744.

    @serhiy-storchaka serhiy-storchaka closed this as not planned Won't fix, can't repro, duplicate, stale Feb 28, 2024
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Assignees
    No one assigned
    Labels
    3.9 only security fixes build The build process and cross-build type-feature A feature request or enhancement
    Projects
    None yet
    Milestone
    No milestone
    Development

    No branches or pull requests
    5 participants
    @vstinner @serhiy-storchaka @tirkarthi @pablogsal @jkloth
    0