Skip to content

SeBa doesn't compile with newer compilers #32

Open

Description

@LourensVeen

I can compile SeBa with gcc 11.4.0, but with 13.3.0 I get a whole bunch of errors of various kinds. Explicitly setting a lower C++ version only helps partially (see also amusecode/amuse#1159).

It looks like there's a lot of old Starlab code here that was written long before C++ got standardised, and that's definitely getting long in the tooth.

I'm going to have a look at this, because I'd like this to work in AMUSE.

Activity

  1. rieder commented on Jul 8, 2025

    @rieder
    Member

    Hi Lourens,
    Could you post the error log?
    Github actions compiles SeBa just fine (see https://github.com/amusecode/SeBa/actions/runs/16069847803), and also locally I have no errors (lots of warnings though). That's with gcc-14.2.0.

  2. LourensVeen commented on Jul 8, 2025

    @LourensVeen
    MemberAuthor
    $ conda list
    
    # packages in environment at /home/lourens/.miniconda3/envs/seba:
    #
    # Name                    Version                   Build  Channel
    _libgcc_mutex             0.1                 conda_forge    conda-forge
    _openmp_mutex             4.5                       2_gnu    conda-forge
    binutils                  2.44                 h4852527_0    conda-forge
    binutils_impl_linux-64    2.44                 h4bf12b8_0    conda-forge
    binutils_linux-64         2.44                 h4852527_0    conda-forge
    c-compiler                1.10.0               h2b85faf_0    conda-forge
    cxx-compiler              1.10.0               h1a2810e_0    conda-forge
    gcc                       13.3.0               h9576a4e_2    conda-forge
    gcc_impl_linux-64         13.3.0               h1e990d8_2    conda-forge
    gcc_linux-64              13.3.0              h6f18a23_11    conda-forge
    gxx                       13.3.0               h9576a4e_2    conda-forge
    gxx_impl_linux-64         13.3.0               hae580e1_2    conda-forge
    gxx_linux-64              13.3.0              hb14504d_11    conda-forge
    kernel-headers_linux-64   3.10.0              he073ed8_18    conda-forge
    ld_impl_linux-64          2.44                 h1423503_0    conda-forge
    libgcc                    15.1.0               h767d61c_3    conda-forge
    libgcc-devel_linux-64     13.3.0             hc03c837_102    conda-forge
    libgomp                   15.1.0               h767d61c_3    conda-forge
    libsanitizer              13.3.0               he8ea267_2    conda-forge
    libstdcxx                 15.1.0               h8f9b012_3    conda-forge
    libstdcxx-devel_linux-64  13.3.0             hc03c837_102    conda-forge
    sysroot_linux-64          2.17                h0157908_18    conda-forge
    tzdata                    2025b                h78e105d_0    conda-forge
    

    Build log (I've replaced a very long path for readability): seba.log

    Maybe it's the conda activation scripts that turn some of those warnings into errors? Then again, I don't immediately see anything that could cause that:

    $ echo $CFLAGS
    -march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2 -ffunction-sections -pipe -isystem /home/lourens/.miniconda3/envs/seba/include
    
    $ echo $CXXFLAGS
    -fvisibility-inlines-hidden -fmessage-length=0 -march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2 -ffunction-sections -pipe -isystem /home/lourens/.miniconda3/envs/seba/include
    

    It does look like it's compiling SeBa as C++17, maybe that's not helping. Then again, that should be the default for gcc 14.2.0 as well.

  3. LourensVeen commented on Jul 22, 2025

    @LourensVeen
    MemberAuthor

    I've been looking into this, and the longer I look at it the more it seems that this isn't right. We're compiling everything with -DTOOLBOX, which seems like it should be used when compiling libraries, and not used when compiling executables. As a result, we get multiple definitions of main() and linking errors, at least if you fix all those main function to have the correct (and therefore the same) signature.

    Could it be that we're using different versions of make, you the old one on macOS and me something newer? Perhaps that causes it to be built differently.

    The build system also doesn't do dependencies correctly and the recursive calls aren't right, so it doesn't build in parallel. But maybe that's worth a separate issue.

    I've been fixing things and I think I have a working build, but with some warnings still that I'm going to eradicate before I make a PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions