All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Ash <richard@audacityteam.org>
To: Alex <earthquake.de@freenet.de>
Cc: busybox@busybox.net, buildroot@buildroot.org
Subject: Re: [Buildroot] libstdc++ DSO missing
Date: Fri, 16 Sep 2022 22:08:49 +0100	[thread overview]
Message-ID: <20220916220849.59cd518a@audacityteam.org> (raw)
In-Reply-To: <a5f78f21-7b6e-6e68-0104-d51879d82e35@freenet.de>

On Sun, 11 Sep 2022 11:41:51 +0200
Alex <earthquake.de@freenet.de> wrote:

> Thank you for your detailed explanation.
> > On 09/09/2022 14:34, Alex wrote:  
> >> Hi,
> >>
> >> I intergrated my application to buildroot. Complie is successfull
> >> by when linking I get errors:
> >>
> >> x86_64-buildroot-linux-gnu/sysroot/usr/lib64/libstdc++.so.6: error
> >> adding symbols: DSO missing from command line  
> >
> > This error means that:
> > - the linker found a library with a DT_NEEDED dependency on 
> > libstdc++.so.6
> > - the linker found libstdc++.so.6
> > - the linker is missing symbols
> > - the linker found the missing symbols in libstdc++.so.6
> > - but the linker command line does not include libstdc++.so.6
> > - so the linker is not sure if the user actually intended to link
> > with libstdc++.so.6.
> > - so it refuses to link.
> >
> > Since libstdc++.so.6 is the C++ runtime library, this either mean
> > that:
> > - you are linking a C++ program with ld or gcc instead of g++  
> 
> Yap, outside of buildroot, linking calls the g++ but when linking
> inside buildroot,  calls the x86_64-buildroot-linux-gnu-ld,
> because $(LD) in the makefile is set to x86_64-buildroot-linux-gnu-ld 
> within buildroot.

I don't think it's ever been normal usage to use $(LD) when trying to
link anything involving dynamic linkage. As far as I'm aware, your
Makefile shouldn't be using $(LD) if you are linking dynamically. As
you are linking a C++ application, the link command should be using
$(CXX) (make doesn't seem to have a built in rule for linking C++, but
it's what I have always used and not had this sort of problem).
$(CXX) will be pointing to the correct g++, which will then call out to
the correct ld as required, with the correct options.

If you make this change to your Makefile you shouldn't need your kludge.

Richard
 
> Inside the package .mk file of the BUILD_CMDS calls make:
> 
> $(MAKE) $(TARGET_CONFIGURE_OPTS)  -C $(@D)
> 
> So (a kludge to test), i replaced in the Makefile
> $(LD)
> by
> $(HOST_DIR)/bin/x86_64-linux-g++
> Now linking is successfull...
> Is there a more "elegant" way to do this...? Not so a kludge like
> that, mean setting this within the mk file before calling the projekt
> make... And how to specifey $(CC) also to g++??
> 
> 
> > - you are linking a C program with a C++ library that requires 
> > libstdc++.so.6, in this case you may need -lstdc++ on the linker 
> > command line.
> >  
> >> Are libraries missing from buildroot environment?  
> >
> > No, only the linker command line is incorrect.
> >  
> >> Additional I get warnings that some .so files not found, but they
> >> are available in output/build/<Tool>/lib  
> >
> > The compiler will only search libraries in output/staging/lib or 
> > output/staging/usr/lib.
> > The package for <Tool> should install the libraries there, so that 
> > other programs can link with them. This is done by putting
> >
> > <TOOL>_INSTALL_STAGING = YES
> >
> > in its .mk file.  If <Tool> is a generic-package (and not a 
> > autotools/meson/cmake package), then you also need to manually
> > explain how to install libraries to $(STAGING_DIR)/lib:  
> 
> Indeed I forgot one of the .so to be  installed to staging. After
> adding this and append to the $(MAKE) call the
> LD_LIBRARY_PATH="$(@D)../<Tool>/lib" compile and linking is
> successfull.
> 
> >
> > https://nightly.buildroot.org/manual.html#_infrastructure_for_packages_with_specific_build_systems 
> >
> >  
> >> But I included this path by $(@D)/../<Tool>/lib  
> >
> > While it may work, this is a kludge.  
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

  reply	other threads:[~2022-09-16 21:09 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-09 12:34 [Buildroot] libstdc++ DSO missing Alex
2022-09-09 15:40 ` Nicolas Cavallari
2022-09-11  9:41   ` Alex
2022-09-16 21:08     ` Richard Ash [this message]
2022-09-17 12:41       ` Edgar Bonet

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=20220916220849.59cd518a@audacityteam.org \
    --to=richard@audacityteam.org \
    --cc=buildroot@buildroot.org \
    --cc=busybox@busybox.net \
    --cc=earthquake.de@freenet.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.