#43 gcc-10.3.0 install fails
Closed 2 years ago by orbea. Opened 2 years ago by orbea.

slibtool: 5018e1a
gcc: 10.3.0

When building gcc-10.3.0 (For Mingw-w64) it fails to install libsupc++.so, but only a libsupc++.a is created.

rdlibtool --mode=install /usr/lib/portage/python3.8/ebuild-helpers/xattr/install -c libsupc++.la /var/tmp/portage/cross-i686-w64-mingw32/gcc-10.3.0/image/usr/i686-w64-mingw32/lib/../lib

rdlibtool: lconf: {.name="libtool"}.
rdlibtool: fdcwd: {.fdcwd=AT_FDCWD, .realpath="/var/tmp/portage/cross-i686-w64-mingw32/gcc-10.3.0/work/build/i686-w64-mingw32/libstdc++-v3/libsupc++"}.
rdlibtool: lconf: fstatat(AT_FDCWD,".",...) = 0 {.st_dev = 65026, .st_ino = 174524034}.
rdlibtool: lconf: openat(AT_FDCWD,"libtool",O_RDONLY,0) = -1 [ENOENT].
rdlibtool: lconf: openat(AT_FDCWD,"../",O_DIRECTORY,0) = 3.
rdlibtool: lconf: fstat(3,...) = 0 {.st_dev = 65026, .st_ino = 81951046}.
rdlibtool: lconf: openat(3,"libtool",O_RDONLY,0) = 4.
rdlibtool: lconf: found "/var/tmp/portage/cross-i686-w64-mingw32/gcc-10.3.0/work/build/i686-w64-mingw32/libstdc++-v3/libtool".
rdlibtool: install: cp .libs/libsupc++.a /var/tmp/portage/cross-i686-w64-mingw32/gcc-10.3.0/image/usr/i686-w64-mingw32/lib/../lib
rdlibtool: error logged in slbt_exec_install_entry(), line 479: path not found: .libs/libsupc++.so.
rdlibtool: < returned to > slbt_exec_install(), line 779.
make[4]: *** [Makefile:701: install-toolexeclibLTLIBRARIES] Error 2
make[4]: Leaving directory '/var/tmp/portage/cross-i686-w64-mingw32/gcc-10.3.0/work/build/i686-w64-mingw32/libstdc++-v3/libsupc++'
make[3]: *** [Makefile:834: install-am] Error 2
make[3]: Leaving directory '/var/tmp/portage/cross-i686-w64-mingw32/gcc-10.3.0/work/build/i686-w64-mingw32/libstdc++-v3/libsupc++'
make[2]: *** [Makefile:563: install-recursive] Error 1
make[2]: Leaving directory '/var/tmp/portage/cross-i686-w64-mingw32/gcc-10.3.0/work/build/i686-w64-mingw32/libstdc++-v3'
make[1]: *** [Makefile:11133: install-target-libstdc++-v3] Error 2
make[1]: Leaving directory '/var/tmp/portage/cross-i686-w64-mingw32/gcc-10.3.0/work/build'
make: *** [Makefile:2397: install] Error 2

In libstdc++-v3/libsupc++/Makefile.am libsupc++.la is set.

# Need this library to both be part of libstdc++.a, and installed
# separately too.
# 1) separate libsupc++.la
toolexeclib_LTLIBRARIES = libsupc++.la

Then the relevant LTCXXCOMPILE and CXXLINK variables are overridden.

# Libtool notes

# 1) In general, libtool expects an argument such as `--tag=CXX' when
# using the C++ compiler, because that will enable the settings
# detected when C++ support was being configured.  However, when no
# such flag is given in the command line, libtool attempts to figure
# it out by matching the compiler name in each configuration section
# against a prefix of the command line.  The problem is that, if the
# compiler name and its initial flags stored in the libtool
# configuration file don't match those in the command line, libtool
# can't decide which configuration to use, and it gives up.  The
# correct solution is to add `--tag CXX' to LTCXXCOMPILE and maybe
# CXXLINK, just after $(LIBTOOL), so that libtool doesn't have to
# attempt to infer which configuration to use.
# 
# The second tag argument, `--tag disable-shared` means that libtool
# only compiles each source once, for static objects. In actuality,
# glibcxx_lt_pic_flag and glibcxx_compiler_shared_flag are added to
# the libtool command that is used create the object, which is
# suitable for shared libraries.  The `--tag disable-shared` must be
# placed after --tag CXX lest things CXX undo the affect of
# disable-shared.

# 2) Need to explicitly set LTCXXCOMPILE so that EXTRA_CXX_FLAGS is
# last. (That way, things like -O2 passed down from the toplevel can
# be overridden by --enable-debug.)
LTCXXCOMPILE = \
        $(LIBTOOL) --tag CXX --tag disable-shared \
        $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
        --mode=compile $(CXX) $(TOPLEVEL_INCLUDES) \
        $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CXXFLAGS) $(CXXFLAGS) $(EXTRA_CXX_FLAGS)

LTLDFLAGS = $(shell $(SHELL) $(top_srcdir)/../libtool-ldflags $(LDFLAGS))

# 3) We'd have a problem when building the shared libstdc++ object if
# the rules automake generates would be used.  We cannot allow g++ to
# be used since this would add -lstdc++ to the link line which of
# course is problematic at this point.  So, we get the top-level
# directory to configure libstdc++-v3 to use gcc as the C++
# compilation driver.
CXXLINK = \
        $(LIBTOOL) --tag CXX --tag disable-shared \
        $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
        --mode=link $(CXX) \
        $(OPT_LDFLAGS) $(SECTION_LDFLAGS) $(AM_CXXFLAGS) $(LTLDFLAGS) -o $@

Confirmed bug. This bug is specific to targets that with a shared library suffix that's different from the .so default. What causes the bug is that with --mode=install, there's no way for slibtool to know for which host libfoo.la was created. To keep slibtool independent (that is, independent of a generated libtool script) and in order to avoid complicated parsing of .la files, this will be handled by way of symlinks -- similar to how things are currently done with .rpath and other pieces of link-time information.

Metadata Update from @orbea:
- Issue status updated to: Closed (was: Open)

2 years ago

Login to comment on this ticket.

Metadata
Attachments 1
Attached 2 years ago View Comment