diff mbox series

[3/5] gcc: Add --nostdlib++ option

Message ID 20211027200505.3340725-4-richard.purdie@linuxfoundation.org
State New
Headers
Series OpenEmbedded/Yocto Project gcc patches |

Commit Message

Richard Purdie Oct. 27, 2021, 8:05 p.m. UTC 
  OpenEmbedded/Yocto Project builds libgcc and the other gcc runtime libraries
separately from the compiler and slightly differently to the standard gcc build.

In general this works well but in trying to build them separately we run into
an issue since we're using our gcc, not xgcc and there is no way to tell configure
to use libgcc but not look for libstdc++.

This adds such an option allowing such configurations to work.

2021-10-26 Richard Purdie <richard.purdie@linuxfoundation.org>

gcc/c-family/ChangeLog:

    * c.opt: Add --nostdlib++ option

gcc/cp/ChangeLog:

    * g++spec.c (lang_specific_driver): Add --nostdlib++ option

gcc/ChangeLog:

    * doc/invoke.texi: Document --nostdlib++ option
    * gcc.c: Add --nostdlib++ option

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
 gcc/c-family/c.opt  | 4 ++++
 gcc/cp/g++spec.c    | 1 +
 gcc/doc/invoke.texi | 8 +++++++-
 gcc/gcc.c           | 1 +
 4 files changed, 13 insertions(+), 1 deletion(-)

Comments

Bernhard Reutner-Fischer Oct. 27, 2021, 8:56 p.m. UTC | #1 
On Wed, 27 Oct 2021 21:05:03 +0100
Richard Purdie via Gcc-patches <gcc-patches@gcc.gnu.org> wrote:

> OpenEmbedded/Yocto Project builds libgcc and the other gcc runtime libraries
> separately from the compiler and slightly differently to the standard gcc build.
> 
> In general this works well but in trying to build them separately we run into
> an issue since we're using our gcc, not xgcc and there is no way to tell configure
> to use libgcc but not look for libstdc++.
> 
> This adds such an option allowing such configurations to work.

But shouldn't it be called --nostdlibc++ then?
thanks,
Jeff Law Oct. 28, 2021, 2:51 p.m. UTC | #2 
On 10/27/2021 2:05 PM, Richard Purdie via Gcc-patches wrote:
> OpenEmbedded/Yocto Project builds libgcc and the other gcc runtime libraries
> separately from the compiler and slightly differently to the standard gcc build.
>
> In general this works well but in trying to build them separately we run into
> an issue since we're using our gcc, not xgcc and there is no way to tell configure
> to use libgcc but not look for libstdc++.
>
> This adds such an option allowing such configurations to work.
>
> 2021-10-26 Richard Purdie <richard.purdie@linuxfoundation.org>
>
> gcc/c-family/ChangeLog:
>
>      * c.opt: Add --nostdlib++ option
>
> gcc/cp/ChangeLog:
>
>      * g++spec.c (lang_specific_driver): Add --nostdlib++ option
>
> gcc/ChangeLog:
>
>      * doc/invoke.texi: Document --nostdlib++ option
>      * gcc.c: Add --nostdlib++ option
Couldn't you use -nostdlib then explicitly add -lgcc?

If that works, that would seem better to me compared to adding an option 
to specs processing that is really only useful to one build 
system/procedure.

jeff
Richard Purdie Oct. 28, 2021, 4:39 p.m. UTC | #3 
On Thu, 2021-10-28 at 08:51 -0600, Jeff Law wrote:
> 
> On 10/27/2021 2:05 PM, Richard Purdie via Gcc-patches wrote:
> > OpenEmbedded/Yocto Project builds libgcc and the other gcc runtime libraries
> > separately from the compiler and slightly differently to the standard gcc build.
> > 
> > In general this works well but in trying to build them separately we run into
> > an issue since we're using our gcc, not xgcc and there is no way to tell configure
> > to use libgcc but not look for libstdc++.
> > 
> > This adds such an option allowing such configurations to work.
> > 
> > 2021-10-26 Richard Purdie <richard.purdie@linuxfoundation.org>
> > 
> > gcc/c-family/ChangeLog:
> > 
> >      * c.opt: Add --nostdlib++ option
> > 
> > gcc/cp/ChangeLog:
> > 
> >      * g++spec.c (lang_specific_driver): Add --nostdlib++ option
> > 
> > gcc/ChangeLog:
> > 
> >      * doc/invoke.texi: Document --nostdlib++ option
> >      * gcc.c: Add --nostdlib++ option
> Couldn't you use -nostdlib then explicitly add -lgcc?
> 
> If that works, that would seem better to me compared to adding an option 
> to specs processing that is really only useful to one build 
> system/procedure.

It sounds great in principle but I've never been able to get it to work. With 
"-nostdinc++ -nostdlib" I miss the startup files so I also tried "-nostdinc++ -
nodefaultlibs -lgcc". The latter gets further and I can build libstdc++ but the
resulting library doesn't link into applications correctly.

Cheers,

Richard
Richard Purdie Oct. 28, 2021, 4:41 p.m. UTC | #4 
On Wed, 2021-10-27 at 22:56 +0200, Bernhard Reutner-Fischer wrote:
> On Wed, 27 Oct 2021 21:05:03 +0100
> Richard Purdie via Gcc-patches <gcc-patches@gcc.gnu.org> wrote:
> 
> > OpenEmbedded/Yocto Project builds libgcc and the other gcc runtime libraries
> > separately from the compiler and slightly differently to the standard gcc build.
> > 
> > In general this works well but in trying to build them separately we run into
> > an issue since we're using our gcc, not xgcc and there is no way to tell configure
> > to use libgcc but not look for libstdc++.
> > 
> > This adds such an option allowing such configurations to work.
> 
> But shouldn't it be called --nostdlibc++ then?

Maybe :). There are already --nostdinc++ and nostdlib options so --nostdlib++
matches those but I'm happy to use --nostdlibc++ if that is preferred.

Cheers,

Richard
Jeff Law Dec. 3, 2021, 3:04 a.m. UTC | #5 
On 10/28/2021 10:39 AM, Richard Purdie wrote:
> On Thu, 2021-10-28 at 08:51 -0600, Jeff Law wrote:
>> On 10/27/2021 2:05 PM, Richard Purdie via Gcc-patches wrote:
>>> OpenEmbedded/Yocto Project builds libgcc and the other gcc runtime libraries
>>> separately from the compiler and slightly differently to the standard gcc build.
>>>
>>> In general this works well but in trying to build them separately we run into
>>> an issue since we're using our gcc, not xgcc and there is no way to tell configure
>>> to use libgcc but not look for libstdc++.
>>>
>>> This adds such an option allowing such configurations to work.
>>>
>>> 2021-10-26 Richard Purdie <richard.purdie@linuxfoundation.org>
>>>
>>> gcc/c-family/ChangeLog:
>>>
>>>       * c.opt: Add --nostdlib++ option
>>>
>>> gcc/cp/ChangeLog:
>>>
>>>       * g++spec.c (lang_specific_driver): Add --nostdlib++ option
>>>
>>> gcc/ChangeLog:
>>>
>>>       * doc/invoke.texi: Document --nostdlib++ option
>>>       * gcc.c: Add --nostdlib++ option
>> Couldn't you use -nostdlib then explicitly add -lgcc?
>>
>> If that works, that would seem better to me compared to adding an option
>> to specs processing that is really only useful to one build
>> system/procedure.
> It sounds great in principle but I've never been able to get it to work. With
> "-nostdinc++ -nostdlib" I miss the startup files so I also tried "-nostdinc++ -
> nodefaultlibs -lgcc". The latter gets further and I can build libstdc++ but the
> resulting library doesn't link into applications correctly.
Can you be more specific about "doesn't link into applications 
correctly".  I'm still hesitant to add another option if we can 
reasonably avoid it.

jeff
Jeff Law Dec. 3, 2021, 3:05 a.m. UTC | #6 
On 10/28/2021 10:41 AM, Richard Purdie via Gcc-patches wrote:
> On Wed, 2021-10-27 at 22:56 +0200, Bernhard Reutner-Fischer wrote:
>> On Wed, 27 Oct 2021 21:05:03 +0100
>> Richard Purdie via Gcc-patches <gcc-patches@gcc.gnu.org> wrote:
>>
>>> OpenEmbedded/Yocto Project builds libgcc and the other gcc runtime libraries
>>> separately from the compiler and slightly differently to the standard gcc build.
>>>
>>> In general this works well but in trying to build them separately we run into
>>> an issue since we're using our gcc, not xgcc and there is no way to tell configure
>>> to use libgcc but not look for libstdc++.
>>>
>>> This adds such an option allowing such configurations to work.
>> But shouldn't it be called --nostdlibc++ then?
> Maybe :). There are already --nostdinc++ and nostdlib options so --nostdlib++
> matches those but I'm happy to use --nostdlibc++ if that is preferred.
Given the existing options, if we go forward, I'm OK with --nostdlib++.

jeff
Richard Purdie Dec. 5, 2021, 11:43 a.m. UTC | #7 
On Thu, 2021-12-02 at 20:04 -0700, Jeff Law wrote:
> 
> On 10/28/2021 10:39 AM, Richard Purdie wrote:
> > On Thu, 2021-10-28 at 08:51 -0600, Jeff Law wrote:
> > > On 10/27/2021 2:05 PM, Richard Purdie via Gcc-patches wrote:
> > > > OpenEmbedded/Yocto Project builds libgcc and the other gcc runtime libraries
> > > > separately from the compiler and slightly differently to the standard gcc build.
> > > > 
> > > > In general this works well but in trying to build them separately we run into
> > > > an issue since we're using our gcc, not xgcc and there is no way to tell configure
> > > > to use libgcc but not look for libstdc++.
> > > > 
> > > > This adds such an option allowing such configurations to work.
> > > > 
> > > > 2021-10-26 Richard Purdie <richard.purdie@linuxfoundation.org>
> > > > 
> > > > gcc/c-family/ChangeLog:
> > > > 
> > > >       * c.opt: Add --nostdlib++ option
> > > > 
> > > > gcc/cp/ChangeLog:
> > > > 
> > > >       * g++spec.c (lang_specific_driver): Add --nostdlib++ option
> > > > 
> > > > gcc/ChangeLog:
> > > > 
> > > >       * doc/invoke.texi: Document --nostdlib++ option
> > > >       * gcc.c: Add --nostdlib++ option
> > > Couldn't you use -nostdlib then explicitly add -lgcc?
> > > 
> > > If that works, that would seem better to me compared to adding an option
> > > to specs processing that is really only useful to one build
> > > system/procedure.
> > It sounds great in principle but I've never been able to get it to work. With
> > "-nostdinc++ -nostdlib" I miss the startup files so I also tried "-nostdinc++ -
> > nodefaultlibs -lgcc". The latter gets further and I can build libstdc++ but the
> > resulting library doesn't link into applications correctly.
> Can you be more specific about "doesn't link into applications 
> correctly".  I'm still hesitant to add another option if we can 
> reasonably avoid it.

I took a step back and had another look at what our build is doing and why we
need this. Our build builds the different components separately in many cases so
libstdc++ is built separately since that allows us to tune it to specific
targets whilst the core gcc is architecture specific.

When we run configure for libstdc++, we have to configure CXX. We can configure
it as:

CXX="${HOST_PREFIX}g++ -nostdinc++"

however that gives errors about a missing libstdc++ during configure tests (e.g.
the atomic ones) since the library isn't present yet and we're trying to build
it. When I last ran into this I added the nostdlib++ option to mirror the
stdinc++ one and this solved the problem.

Adding -lgcc doesn't seem to work, binaries using libstdc++ segfault on some
architectures (mips64 and ppc). I suspect this is a link ordering issue which we
have little control of from the CXX variable but I haven't got deeply into it as
I got the feeling it would be a pain to try and correct, we need the compiler's
automatic linking behaviour which you can't emulate from one commandline.

I did also try -nostdlib and -nodefaultlibs with various libraries added in but
it never seems to work well giving segfaults, again as I suspect the linking is
order specific.

Thinking about the problem from scratch again, I wondered if a dummy libstdc++
would be enough to make the configure tests work correctly. I've found that I
can do something like:

mkdir -p XXX/dummylib
touch XXX/dummylib/libstdc++.so
export CXX="${CXX} -nostdinc++ -LXXX/dummylib"

and the configure works correctly and the resulting libs don't segfault on
target.

This is a bit of a hack but probably no worse than some of the other things we
have to do to build so if you're not keen on the patch we could go with this. It
did seem at least worth discussing our use case though! :)

Cheers,

Richard
Fangrui Song Dec. 6, 2021, 6:10 a.m. UTC | #8 
On Sun, Dec 5, 2021 at 6:43 AM Richard Purdie via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
>
> On Thu, 2021-12-02 at 20:04 -0700, Jeff Law wrote:
> >
> > On 10/28/2021 10:39 AM, Richard Purdie wrote:
> > > On Thu, 2021-10-28 at 08:51 -0600, Jeff Law wrote:
> > > > On 10/27/2021 2:05 PM, Richard Purdie via Gcc-patches wrote:
> > > > > OpenEmbedded/Yocto Project builds libgcc and the other gcc runtime libraries
> > > > > separately from the compiler and slightly differently to the standard gcc build.
> > > > >
> > > > > In general this works well but in trying to build them separately we run into
> > > > > an issue since we're using our gcc, not xgcc and there is no way to tell configure
> > > > > to use libgcc but not look for libstdc++.
> > > > >
> > > > > This adds such an option allowing such configurations to work.
> > > > >
> > > > > 2021-10-26 Richard Purdie <richard.purdie@linuxfoundation.org>
> > > > >
> > > > > gcc/c-family/ChangeLog:
> > > > >
> > > > >       * c.opt: Add --nostdlib++ option
> > > > >
> > > > > gcc/cp/ChangeLog:
> > > > >
> > > > >       * g++spec.c (lang_specific_driver): Add --nostdlib++ option
> > > > >
> > > > > gcc/ChangeLog:
> > > > >
> > > > >       * doc/invoke.texi: Document --nostdlib++ option
> > > > >       * gcc.c: Add --nostdlib++ option
> > > > Couldn't you use -nostdlib then explicitly add -lgcc?
> > > >
> > > > If that works, that would seem better to me compared to adding an option
> > > > to specs processing that is really only useful to one build
> > > > system/procedure.
> > > It sounds great in principle but I've never been able to get it to work. With
> > > "-nostdinc++ -nostdlib" I miss the startup files so I also tried "-nostdinc++ -
> > > nodefaultlibs -lgcc". The latter gets further and I can build libstdc++ but the
> > > resulting library doesn't link into applications correctly.
> > Can you be more specific about "doesn't link into applications
> > correctly".  I'm still hesitant to add another option if we can
> > reasonably avoid it.
>
> I took a step back and had another look at what our build is doing and why we
> need this. Our build builds the different components separately in many cases so
> libstdc++ is built separately since that allows us to tune it to specific
> targets whilst the core gcc is architecture specific.
>
> When we run configure for libstdc++, we have to configure CXX. We can configure
> it as:
>
> CXX="${HOST_PREFIX}g++ -nostdinc++"
>
> however that gives errors about a missing libstdc++ during configure tests (e.g.
> the atomic ones) since the library isn't present yet and we're trying to build
> it. When I last ran into this I added the nostdlib++ option to mirror the
> stdinc++ one and this solved the problem.
>
> Adding -lgcc doesn't seem to work, binaries using libstdc++ segfault on some
> architectures (mips64 and ppc). I suspect this is a link ordering issue which we
> have little control of from the CXX variable but I haven't got deeply into it as
> I got the feeling it would be a pain to try and correct, we need the compiler's
> automatic linking behaviour which you can't emulate from one commandline.
>
> I did also try -nostdlib and -nodefaultlibs with various libraries added in but
> it never seems to work well giving segfaults, again as I suspect the linking is
> order specific.
>
> Thinking about the problem from scratch again, I wondered if a dummy libstdc++
> would be enough to make the configure tests work correctly. I've found that I
> can do something like:
>
> mkdir -p XXX/dummylib
> touch XXX/dummylib/libstdc++.so
> export CXX="${CXX} -nostdinc++ -LXXX/dummylib"
>
> and the configure works correctly and the resulting libs don't segfault on
> target.
>
> This is a bit of a hack but probably no worse than some of the other things we
> have to do to build so if you're not keen on the patch we could go with this. It
> did seem at least worth discussing our use case though! :)
>
> Cheers,
>
> Richard
>

Drive-by: is -nostdlib++ is implemented, hope its semantics are
similar to clang -nostdlib++ (https://reviews.llvm.org/D35780 since
2017)
diff mbox series

Patch

diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index 06457ac739e..ee742c831fd 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -2190,6 +2190,10 @@  nostdinc++
 C++ ObjC++
 Do not search standard system include directories for C++.
 
+nostdlib++
+Driver
+Do not link standard C++ runtime library
+
 o
 C ObjC C++ ObjC++ Joined Separate
 ; Documented in common.opt
diff --git a/gcc/cp/g++spec.c b/gcc/cp/g++spec.c
index 3c9bd1490b4..818beb61cee 100644
--- a/gcc/cp/g++spec.c
+++ b/gcc/cp/g++spec.c
@@ -159,6 +159,7 @@  lang_specific_driver (struct cl_decoded_option **in_decoded_options,
       switch (decoded_options[i].opt_index)
 	{
 	case OPT_nostdlib:
+	case OPT_nostdlib__:
 	case OPT_nodefaultlibs:
 	  library = -1;
 	  break;
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 71992b8c597..d89b08b3080 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -239,6 +239,7 @@  in the following sections.
 -fno-weak  -nostdinc++ @gol
 -fvisibility-inlines-hidden @gol
 -fvisibility-ms-compat @gol
+-nostdlib++ @gol
 -fext-numeric-literals @gol
 -flang-info-include-translate@r{[}=@var{header}@r{]} @gol
 -flang-info-include-translate-not @gol
@@ -638,7 +639,7 @@  Objective-C and Objective-C++ Dialects}.
 -pie  -pthread  -r  -rdynamic @gol
 -s  -static  -static-pie  -static-libgcc  -static-libstdc++ @gol
 -static-libasan  -static-libtsan  -static-liblsan  -static-libubsan @gol
--shared  -shared-libgcc  -symbolic @gol
+-shared  -shared-libgcc  -symbolic -nostdlib++ @gol
 -T @var{script}  -Wl,@var{option}  -Xlinker @var{option} @gol
 -u @var{symbol}  -z @var{keyword}}
 
@@ -16134,6 +16135,11 @@  Specify that the program entry point is @var{entry}.  The argument is
 interpreted by the linker; the GNU linker accepts either a symbol name
 or an address.
 
+@item -nostdlib++
+@opindex nostdlib++
+Do not use the standard system C++ runtime libraries when linking.
+Only the libraries you specify will be passed to the linker.
+
 @item -pie
 @opindex pie
 Produce a dynamically linked position independent executable on targets
diff --git a/gcc/gcc.c b/gcc/gcc.c
index 506c2acc282..abb900a4247 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -1167,6 +1167,7 @@  proper position among the other output files.  */
     %(mflib) " STACK_SPLIT_SPEC "\
     %{fprofile-arcs|fprofile-generate*|coverage:-lgcov} " SANITIZER_SPEC " \
     %{!nostdlib:%{!r:%{!nodefaultlibs:%(link_ssp) %(link_gcc_c_sequence)}}}\
+    %{!nostdlib++:}\
     %{!nostdlib:%{!r:%{!nostartfiles:%E}}} %{T*}  \n%(post_link) }}}}}}"
 #endif