Re: [Buildroot] [PATCH] package/numactl: point to target libs via LDFLAGS

[Thomas Petazzoni via buildroot <buildroot@buildroot.org>]

Hello Alexey,

On Mon, 24 Oct 2022 19:49:11 +0200
Alexey Brodkin via buildroot <buildroot@buildroot.org> wrote:

> In the commit a699a667bd64 ("package/numactl: add -latomic to numa.pc")
> we opted-out from unconditional linking with "-latomic" and made it
> a conditional based on real availability of __atomic_fetch_and_1()
> in the toolchain. I.e. for many targets "-latomic" was not used
> any longer.

We finally looked at this patch today during the on-going Buildroot
hackathon. We understand/recognize the problem, but we don't like the
proposed solution as you can imagine (especially as the proposed
solution is package specific). In addition, and as you have yourself
expressed, your situation is quite a corner case.

Here are the options that we see to resolve this:

(1) Patch libtool so that it doesn't look at LD_LIBRARY_PATH. We are
    already patching libtool to work-around other issues. However, from
    a quick look at the libtool code base (which of course is not the
    most pleasant exercise on earth), it's not trivial to see where
    this logic is taking place.

(2) Unset LD_LIBRARY_PATH entirely in the main Buildroot makefile to
    avoid interference with LD_LIBRARY_PATH being set. This would of
    course prevent people who have special/weird setups that require
    LD_LIBRARY_PATH from using Buildroot.

(3) Warn/error out if LD_LIBRARY_PATH is set, which essentially is a
    variant of (2), but where we are explicit instead of silently
    ignoring LD_LIBRARY_PATH defined in the user's environment.

Regarding the setting of lt_cv_sys_lib_search_path_spec="" that you
have identified, the motivation for this was explained in
6246704008ef219257f30a824903855d0e00cffb:

    package/Makefile.in: ensure libtool doesn't search host dirs for libraries
    
    Commit 7e3e8ec040b (CFLAGS/LDFLAGS: don't add -I / -L args for STAGING_DIR)
    exposed a lingering libtool problem.
    
    Unless instructed otherwise (using -L) libtool will search its built in
    system path for libraries, and use those instead if found. The default
    search path is '/usr/lib, /lib, /usr/local/lib', which is no good for
    cross compilation.
    
    Fix it by setting the system search path to the empty string, effectively
    disabling this feature.
    
    Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>

So this seems to still be relevant. The reason why when you drop this
in your case and it "works" is we believe the following one: due to
-latomic, libtool will search for libatomic. It will find it in your
system in say /lib or /usr/lib, and because that's a standard search
path, libtool will keep -latomic instead of turning into a full
absolute path. So the cross linker gets passed -latomic, which it
properly resolves to the target/sysroot libatomic. When
lt_cv_sys_lib_search_path_spec="" is there, libatomic from /lib or
/usr/lib isn't found, so it finds the one in your LD_LIBRARY_PATH
directory, which isn't a standard path, so our dear libtool replaces
-latomic by the full absolute path to libatomic, and passes that to the
cross-linker, which of course blows up.

Best regards,

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot