Installation path of libstdc++ etc.

[th-otto]

When building other languages like C++, supporting libraries like libstdc++, libsupc++ (and others for other languages) are installed to /usr/lib. In order to support multiple installations of different compiler versions, i have changed my script now to move them to the gcc subdirectory /usr/lib/gcc/m68k-atari-mint/<version>. This also affects cross-compiler toolchains. I think on linux that is not done because incompatible libraries will get a different *.so.version, but with static libraries they would overwrite each other, while using different include headers from /usr/include/c++/<version>

Other small changes: since gdb does not work on atari, i'm removing the libcstdc++.a-gdb.py script now. And you should consider removing the libtool archive (*.la) files, which are useless when installed to default locations, and only cause trouble.

[mikrosk]

I'm not sure how this helps? Now if I have two different (m68k) gcc versions, they wont install their libraries into /usr/lib but into /usr/lib/gcc/m68k-atari-mint instead? How is this any better?

[th-otto]

They should be installed to /usr/lib/gcc/m68k-atari-mint/<version>, ie /usr/lib/gcc/m68k-atari-mint/7.5.0 for the current port (same directory where libgcc.a etc reside)

[mikrosk]

Oh I see. So you are concerned about the fact that if I have the same cross gcc version as native gcc version, they would overwrite each other?

[th-otto]

No, cross and native don't conflict (they will have different triplets as in /usr/lib/gcc/m68k-atari-mint/<version> vs /usr/lib/gcc/x86_64-pc-linux/<version>). But having multiple cross compilers with different versions has the same problem; for those the libraries end up in /usr/m68k-atari-mint/lib

[mikrosk]

Ah so, you should have been more specific - so if I understand it correctly, you changed the location of libstdc++ from non-versioned /usr/m68k-atari-mint/lib/libstdc++.a to versioned /usr/lib/gcc/m68k-atari-mint/<version>/libstdc++.a, right?

[th-otto]

Right. Sorry about the confusion but i forgot to quote the <version> suffix in the original post so in the markup language here it disappeared. Also don't forget that the native compilers (as supplied here in the releases) have the libraries just installed in /usr/lib

[th-otto]

Bump ;) Did you change your scripts already? With the upcoming gcc-13 version, that will be relevant if we backport the changes the to the gcc-7 branch.

[mikrosk]

Sorry, I have totally forgotten about it. Do you have a commit to cherry-pick for this one?

[th-otto]

IIRC, i did not change anything in gcc, and it's just a matter of the configure switches.

These are currently:

$srcdir/configure \
    --target="${TARGET}" --build="$BUILD" \
    --prefix="${PREFIX}" \
    --libdir="$BUILD_LIBDIR" \
    --bindir="${PREFIX}/bin" \
    --libexecdir='${libdir}' \
    CFLAGS_FOR_BUILD="$CFLAGS_FOR_BUILD" \
    CFLAGS="$CFLAGS_FOR_BUILD" \
    CXXFLAGS_FOR_BUILD="$CXXFLAGS_FOR_BUILD" \
    CXXFLAGS="$CXXFLAGS_FOR_BUILD" \
    BOOT_CFLAGS="$CFLAGS_FOR_BUILD" \
    CFLAGS_FOR_TARGET="$CFLAGS_FOR_TARGET" \
    CXXFLAGS_FOR_TARGET="$CXXFLAGS_FOR_TARGET" \
    LDFLAGS_FOR_BUILD="$LDFLAGS_FOR_BUILD" \
    LDFLAGS="$LDFLAGS_FOR_BUILD" \
    --with-pkgversion="$REVISION" \
    --disable-libvtv \
    --disable-libmpx \
    --disable-libcc1 \
    --disable-werror \
    --with-gxx-include-dir=${PREFIX}/${TARGET}/sys-root${gxxinclude} \
    $gcc4_compat \
    --with-gcc-major-version-only \
    --with-gcc --with-gnu-as --with-gnu-ld \
    --with-system-zlib \
    --without-static-standard-libraries \
    --without-stage1-ldflags \
    --disable-libgomp \
    --without-newlib \
    --disable-libstdcxx-pch \
    --disable-threads \
    --disable-win32-registry \
    $enable_lto \
    --enable-ssp \
    --enable-libssp \
    $enable_plugin \
    --disable-decimal-float \
    --disable-nls \
    --with-libiconv-prefix="${PREFIX}" \
    --with-libintl-prefix="${PREFIX}" \
    --with-sysroot="${PREFIX}/${TARGET}/sys-root" \
    --enable-languages="$languages" || fail "gcc"

$gcc4_compat is now empty for gcc >= 13, and --with-default-libstdcxx-abi=gcc4-compatible for others

$enable_plugin and $enable_lto are only set for elf toolchains and empty otherwise

If that does not work for you, i have to look again.

[mikrosk]

Hmm, only --with-gcc-major-version-only seems like something related but its description:

Specifies that GCC should use only the major number rather than major.minor.patchlevel in filesystem paths.

Sounds like the exact opposite?

[th-otto]

I think --with-gcc-major-version-only only has an influence about what symlinks are created in the bin directory. However in my scripts i fix them later anyway, because different major versions behaved differently there, and i wanted to have it consistently. Did you try the above configuraton and look where libcstdc++.a is installed?

[th-otto]

Found it :)

I'm doing that manually in my scripts, eg here: https://github.com/th-otto/crossmint/blob/c6af4c2440d80a44ff37d478196bff17cc7dbcbf/gcc-7-build.sh#L622-L632

[mikrosk]

I thought "wow, that looks hacky, there must be a better way" and to my surprise, there doesn't seem to be. Ubuntu/Debian does something similar as you do (in a much scarier way) for their g++-9, g++-10 etc packages and Arch Linux does it in a bit smarter way: it jumps into given folder (e.g. libstdc++) and manually invokes make install with custom DESTDIR.

[th-otto]

I'm not sure whether that "jump into folder" is that smart. When you do a "make install" on the top, they will still be installed to <prefix>/m68k-atari-mint/lib which you still have to remove, otherwise different compilers might pick the wrong version. And depending on the backends you build, there will also be other libraries, like libgfortran.

[mikrosk]

True. I think (I didn't bother studying it in detail) they do it basically for all "subsystems", i.e. they never fire up the full-scale "make install" from toplevel.

It is a solution but not exactly elegant either.

[mikrosk]

Accidentally found --enable-version-specific-runtime-libs:

_Specify that run-time libraries should be installed in the compiler-specific subdirectory (i.e., ${libdir}/gcc-lib/${target_alias}/${gcc_version}) instead of ${libdir}. This option is useful if you intend to use several versions of gcc in parallel. In addition, libstdc++'s include files will be installed in ${libdir}/gcc-lib/${target_alias}/${gccversion}/include/g++, unless you also specify --with-gxx-include-dir=dirname during configuration.

Sounds like exactly what we want to achieve here?

[mikrosk]

Verified, although it's not gcc-lib where the files go as the man page says.

Old locations:

./gnu-tools/m68000/m68k-atari-mintelf/lib/m5475/libstdc++.a ./gnu-tools/m68000/m68k-atari-mintelf/lib/m68020-60/libstdc++.a ./gnu-tools/m68000/m68k-atari-mintelf/lib/libstdc++.a

Locations with --enable-version-specific-runtime-libs:

./gnu-tools/m68000/lib/gcc/m68k-atari-mintelf/13.2.0/m5475/libstdc++.a ./gnu-tools/m68000/lib/gcc/m68k-atari-mintelf/13.2.0/m68020-60/libstdc++.a ./gnu-tools/m68000/lib/gcc/m68k-atari-mintelf/13.2.0/libstdc++.a

C++ includes (like iostream) were already separated (./gnu-tools/m68000/m68k-atari-mintelf/include/c++/13.2.0) but now they are moved to ./gnu-tools/m68000/lib/gcc/m68k-atari-mintelf/13.2.0/include/c++ (i.e. within the ${libdir}) as predicted by the man page.