public inbox for libstdc++@gcc.gnu.org
 help / color / mirror / Atom feed
From: Patrick Palka <ppalka@redhat.com>
To: Patrick Palka <ppalka@redhat.com>
Cc: gcc-patches@gcc.gnu.org, libstdc++@gcc.gnu.org
Subject: Re: [PATCH] libstdc++: Fix stream initialization with static library [PR107701]
Date: Tue, 15 Nov 2022 23:02:55 -0500 (EST)	[thread overview]
Message-ID: <2aabe052-761c-15d6-e623-4bff2ad0c2db@idea> (raw)
In-Reply-To: <20221116024619.1465996-1-ppalka@redhat.com>

On Tue, 15 Nov 2022, Patrick Palka wrote:

> When linking with a static library, the linker seems to exclude a
> constituent .o object (including its global initializers) if nothing
> from it is referenced by the program (unless e.g. --whole-archive is
> used).  This behavior breaks iostream when linking with static libstdc++.a
> (on systems that support init priorities) because we're defining the
> global initializer for the standard stream objects in a separate TU
> (ios_init.cc) from the stream objects definitions (globals_io.cc).
> 
> Thus in order to ensure that the global initializer for the standard
> stream objects doesn't get wrongly dropped when statically linking,
> we need to perform the initialization from the same TU that actually
> defines the stream objects.
> 
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?

v2 with more comment fixes/additions:

-- >8 --

Subject: [PATCH] libstdc++: Fix stream initialization with static library
 [PR107701]

When linking with a static library, the linker seems to discard a
constituent .o object (including its global initializers) if nothing
from it is referenced by the program (unless e.g. --whole-archive is
used).  This behavior breaks iostream when linking with static libstdc++.a
(on systems that support init priorities) because we define the global
initializer for the standard stream objects in a separate TU (ios_init.cc)
from the stream objects definitions (globals_io.cc).

Thus in order to ensure that the global initializer for the standard
stream objects doesn't get wrongly dropped when statically linking,
we need to perform the initialization from the same TU that actually
defines the stream objects.

Tested on x86_64-pc-linux-gnu, does this look OK for trunk?

	PR libstdc++/107701

libstdc++-v3/ChangeLog:

	* include/std/iostream (__ioinit): Adjust comment.
	* src/c++98/globals_io.cc: Include "io_base_init.h" here
	instead of ...
	* src/c++98/ios_init.cc: ... here.
	* src/c++98/ios_base_init.h (__ioinit): Extend comment.
	* testsuite/17_intro/static.cc: Run the test as well.
---
 libstdc++-v3/include/std/iostream         | 2 +-
 libstdc++-v3/src/c++98/globals_io.cc      | 2 ++
 libstdc++-v3/src/c++98/ios_base_init.h    | 1 +
 libstdc++-v3/src/c++98/ios_init.cc        | 2 --
 libstdc++-v3/testsuite/17_intro/static.cc | 2 +-
 5 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/libstdc++-v3/include/std/iostream b/libstdc++-v3/include/std/iostream
index ff78e1cfb87..0c62e9aeb7f 100644
--- a/libstdc++-v3/include/std/iostream
+++ b/libstdc++-v3/include/std/iostream
@@ -74,7 +74,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   // For construction of filebuffers for cout, cin, cerr, clog et. al.
   // When the init_priority attribute is usable, we do this initialization
-  // in the compiled library instead (src/c++98/ios_init.cc).
+  // in the compiled library instead (src/c++98/globals_io.cc).
 #if !__has_attribute(__init_priority__)
   static ios_base::Init __ioinit;
 #endif
diff --git a/libstdc++-v3/src/c++98/globals_io.cc b/libstdc++-v3/src/c++98/globals_io.cc
index 04fecb22aeb..bfd808b5bbd 100644
--- a/libstdc++-v3/src/c++98/globals_io.cc
+++ b/libstdc++-v3/src/c++98/globals_io.cc
@@ -69,6 +69,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   fake_wostream wclog;
 #endif
 
+#include "ios_base_init.h"
+
 _GLIBCXX_END_NAMESPACE_VERSION
 } // namespace
 
diff --git a/libstdc++-v3/src/c++98/ios_base_init.h b/libstdc++-v3/src/c++98/ios_base_init.h
index 1c71038f4a1..b600ec3298e 100644
--- a/libstdc++-v3/src/c++98/ios_base_init.h
+++ b/libstdc++-v3/src/c++98/ios_base_init.h
@@ -7,6 +7,7 @@
 // sufficiently early (so that it happens before any other global
 // constructor when statically linking with libstdc++.a), instead of
 // doing so in (each TU that includes) <iostream>.
+// This needs to be done in the same TU that defines the stream objects.
 #if __has_attribute(init_priority)
 static ios_base::Init __ioinit __attribute__((init_priority(90)));
 #endif
diff --git a/libstdc++-v3/src/c++98/ios_init.cc b/libstdc++-v3/src/c++98/ios_init.cc
index 4016fcab785..1b5132f1c2d 100644
--- a/libstdc++-v3/src/c++98/ios_init.cc
+++ b/libstdc++-v3/src/c++98/ios_init.cc
@@ -75,8 +75,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   extern wostream wclog;
 #endif
 
-#include "ios_base_init.h"
-
   ios_base::Init::Init()
   {
     if (__gnu_cxx::__exchange_and_add_dispatch(&_S_refcount, 1) == 0)
diff --git a/libstdc++-v3/testsuite/17_intro/static.cc b/libstdc++-v3/testsuite/17_intro/static.cc
index ffa7ecb7077..a0d6ed081f8 100644
--- a/libstdc++-v3/testsuite/17_intro/static.cc
+++ b/libstdc++-v3/testsuite/17_intro/static.cc
@@ -1,4 +1,4 @@
-// { dg-do link { target c++11 } }
+// { dg-do run { target c++11 } }
 // { dg-require-static-libstdcxx }
 // { dg-options "-static-libstdc++" }
 
-- 
2.38.1.436.geea7033409


  reply	other threads:[~2022-11-16  4:02 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-16  2:46 Patrick Palka
2022-11-16  4:02 ` Patrick Palka [this message]
2022-11-16 10:55 ` Jonathan Wakely
2022-11-16 12:40   ` Jonathan Wakely

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2aabe052-761c-15d6-e623-4bff2ad0c2db@idea \
    --to=ppalka@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=libstdc++@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).