slibtool: 5018e1a gcc: 10.3.0
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.
libsupc++.so
libsupc++.a
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.
libstdc++-v3/libsupc++/Makefile.am
libsupc++.la
# 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.
LTCXXCOMPILE
CXXLINK
# 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 $@
<img alt="gcc-build.log.xz" src="/cross/slibtool/issue/raw/files/2b5296e8c8ed93cf884b14483ad2c020f0a5108d93c35707904a5539a084941e-gcc-build.log.xz" />
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.
Fixed as of commit c7981ca.
Metadata Update from @orbea: - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.