Re: [Buildroot] NodeJS, qemu wrapper and ELF interpreter fun

["Yann E. MORIN" <yann.morin.1998@free.fr>]

Thomas, All,

On 2022-10-31 21:39 +0100, Thomas Petazzoni spake thusly:
> I finally took some time to investigate the NodeJS build issue that
> occurs on x86-64:
>   http://autobuild.buildroot.net/results/4f2/4f29c5e663b5d01af20d671baf6504332b8c1f7b/build-end.log
[--SNIP--]
> After adding some traces into this function, I was able to understand
> what happens:

Great explanations, thanks a lot!

> We see 3 possible ideas to resolve this problem:
> 
> (A) Change the behavior of Qemu to not fallback to unprefixed paths:
>     when -L is passed, all path-related system calls should see the
>     paths prefixed by the -L option.
>     Issue with this is that this change is unlikely to get accepted by
>     Qemu upstream. And there might be some side effects we have not
>     really identified.

I am very skeptical of that solution...

> (B) Create an empty $(STAGING_DIR)/etc/ld.so.cache. We have tested
>     this solution and it works: it gets used instead of the host
>     /etc/ld.so.cache. Because $(STAGING_DIR)/etc/ld.so.cache is empty,
>     there's no libc.so.6 match, so the target ELF interpreter goes
>     through its normal library location resolution logic, which falls
>     back to trying in /usr/lib and /lib, which works as those paths
>     ends up being prefixed with $(STAGING_DIR) by Qemu.

You'd also need an empty /etc/ld.so.cache.d/ maybe.

I was looking at the manpage for ld.so, and it has an option to disable
looking in the cache:

    --inhibit-cache
        Do not use /etc/ld.so.cache.

However, we are not calling ld.so directly, so we'd need to pass it via
an environment variable, but there's no such environment variable that
would allow disable the cache.

I'm afraid an empty STAGING_DIR/etc/ld.so.cache might not be enough, but
I have no fact to back this gut feeling...

> (C) Pass LD_LIBRARY_PATH pointing to $(STAGING_DIR)/lib and
>     $(STAGING_DIR)/usr/lib in the Qemu wrapper. This works because
>     LD_LIBRARY_PATH paths have precedence over paths given by
>     ld.so.cache.
> 
>     This is the solution already used by the GOI qemu wrapper in
>     package/gobject-introspection/g-ir-scanner-qemuwrapper.in, and
>     which was suggested in bug
>     https://bugs.busybox.net/show_bug.cgi?id=14366.

We know this has been working pretty well for the GOI wrapper, so if we
were to use LD_LIBRARY_PATH, that would make for consistent wrappers.

> Any opinion? Or other ideas?

I would go for the LD_LIBRARY_PATH solution, if at least because it is
consistent with the GOI wrapper.

Regards,
Yann E. MORIN.


-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot