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.pur...@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
