search

Linutronix / elbe

Embedded Linux Build Environment
https://elbe-rfs.org
GNU General Public License v3.0
165 stars 59 forks source link

SDK Relocation And Scripts #336

Closed FedericoVaga closed 1 year ago

FedericoVaga commented 2 years ago

I see in the elbepack/makofiles/toolchain-shar-extract.sh.mako file that during relocation, the script is going to fix the interpreter and the rpath on a number of binary files.

Then for ASCII .so the script is going to fix internal paths according to the final SDK location. I'm wondering if this part shouldn't be extended to scripts as well? For example, many scripts have this:

#!/bin/bash
#!/bin/python
#!/bin/env bash
...

This means that if executed from the SDK they will use the host interpreter and not the SDK one.

Is this expected to work like that?

manut commented 2 years ago

Hi,

since the environment Setup script prefixes the path with the host sysroot the proper interpreter should be used.

Manuel

Am 19.05.2022 um 14:01 schrieb Federico Vaga @.***>:

 I see in the elbepack/makofiles/toolchain-shar-extract.sh.mako file that during relocation, the script is going to fix the interpreter and the rpath on a number of binary files.

Then for ASCII .so the script is going to fix internal paths according to the final SDK location. I'm wondering if this part shouldn't be extended to scripts as well? For example, many scripts have this:

!/bin/bash

!/bin/python

!/bin/env bash

... This means that if executed from the SDK they will use the host interpreter and not the SDK one.

Is this expected to work like that?

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.

FedericoVaga commented 2 years ago

I'm referring to other parts of the SDK sysroot, not just the ones related to building C/C++ code.

If, in the SDK I installed some other tools (let's say python) that I want to use for developing, shouldn't these tools call /path-sdk/usr/bin/python instead /usr/bin/python?

If this is not supposed to be the use case, why then not slimming down the SDK and removing whatever does not contribute to build C/C++ code?

I'm naively asking, I'm not requesting any feature nor pretending that what I'm trying is good :smiley:

manut commented 1 year ago

It should be also okay for interpreters:

export PATH="${sdk_path}/sysroots/host/usr/bin:${sdk_path}/sysroots/host/usr/sbin:${sdk_path}/sysroots/host/bin:${sdk_path}/sysroots/host/sbin:$PATH"

In the environment Setup script ensures that the interpreters available in the host sysroot are preferred to the ones in the system

Manuel

Am 19.05.2022 um 17:20 schrieb Federico Vaga @.***>:

 I'm referring to other parts of the SDK sysroot, not just the ones related to building C/C++ code.

If, in the SDK I installed some other tools (let's say python) that I want to use for developing, shouldn't these tools call /path-sdk/usr/bin/python instead /usr/bin/python?

If this is not supposed to be the use case, why then not slimming down the SDK and removing whatever does not contribute to build C/C++ code?

I'm naively asking, I'm not requesting any feature nor pretending that what I'm trying is good 😃

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.

FedericoVaga commented 1 year ago

What you wrote is okay if the script uses

#!/usr/bin/env python

But if the path to the interpreter is hardcoded into the script, then it will not use PATH. For example:

#!/usr/bin/python
FedericoVaga commented 1 year ago

On the same topic (SDK relocation) but a different issue. For example, let's take the file sysroots/host/lib/x86_64-linux-gnu/libc.so (there are others)

/* GNU ld script
   Use the shared library, but some functions are only in
   the static library, so try that secondarily.  */
OUTPUT_FORMAT(elf64-x86-64)
GROUP ( /lib/x86_64-linux-gnu/libc.so.6 <relocation-path>/sysroots/host/usr/lib/x86_64-linux-gnu/libc_nonshared.a  AS_NEEDED ( /lib64/ld-linux-x86-64.so.2 ) )

In this file, the only path that get fixed is the one containing /usr/lib, the others located in /lib and /lib64 do not get update. Therefore, they rely on the SDK host system.

Doesn't the following line need an update? It looks like not enough to replace paths behind /usr

https://github.com/Linutronix/elbe/blob/fe110e8be6b8301103b50c441d6bab549bcb2447/elbepack/makofiles/toolchain-shar-extract.sh.mako#L366

A possible alternative is

sed -i -e "s%\([ (]\)/\(usr\|lib\|lib64\)/%\1$native_sysroot/\2/%g"

The first group is to avoid to recursively apply a /lib64 replacement to /usr/lib64.

FedericoVaga commented 1 year ago

Another thing that might need a fix are symbolic links. Some libraries use an absolute path, therefore when building we end up using the libraries of the host. Here a dump.

  $ find ciao/sysroots/host/ -type l | xargs ls -l | grep "> /"
lrwxrwxrwx 1 me mygroup 21 Nov 23 11:35 ciao/sysroots/host/usr/bin/awk -> /etc/alternatives/awk
lrwxrwxrwx 1 me mygroup 21 Nov 23 11:36 ciao/sysroots/host/usr/bin/c++ -> /etc/alternatives/c++
lrwxrwxrwx 1 me mygroup 21 Nov 23 11:36 ciao/sysroots/host/usr/bin/c89 -> /etc/alternatives/c89
lrwxrwxrwx 1 me mygroup 21 Nov 23 11:36 ciao/sysroots/host/usr/bin/c99 -> /etc/alternatives/c99
lrwxrwxrwx 1 me mygroup 20 Nov 23 11:36 ciao/sysroots/host/usr/bin/cc -> /etc/alternatives/cc
lrwxrwxrwx 1 me mygroup 22 Nov 23 11:35 ciao/sysroots/host/usr/bin/nawk -> /etc/alternatives/nawk                                                                                             
lrwxrwxrwx 1 me mygroup 23 Nov 23 11:35 ciao/sysroots/host/usr/bin/pager -> /etc/alternatives/pager                                                                                           
lrwxrwxrwx 1 me mygroup 14 Dec 16  2021 ciao/sysroots/host/usr/bin/pidof -> /sbin/killall5
lrwxrwxrwx 1 me mygroup 26 Nov 23 11:35 ciao/sysroots/host/usr/bin/pinentry -> /etc/alternatives/pinentry                                                                                     
lrwxrwxrwx 1 me mygroup 21 Nov 23 11:36 ciao/sysroots/host/usr/lib/cpp -> /etc/alternatives/cpp
lrwxrwxrwx 1 me mygroup 31 Feb 28  2021 ciao/sysroots/host/usr/lib/python3.9/sitecustomize.py -> /etc/python3.9/sitecustomize.py                                                              
lrwxrwxrwx 1 me mygroup 42 Aug 26 23:32 ciao/sysroots/host/usr/lib/x86_64-linux-gnu/libBrokenLocale.so -> /lib/x86_64-linux-gnu/libBrokenLocale.so.1                                          
lrwxrwxrwx 1 me mygroup 33 Aug 26 23:32 ciao/sysroots/host/usr/lib/x86_64-linux-gnu/libanl.so -> /lib/x86_64-linux-gnu/libanl.so.1                                                            
lrwxrwxrwx 1 me mygroup 35 Apr 19  2021 ciao/sysroots/host/usr/lib/x86_64-linux-gnu/libcrypt.so -> /lib/x86_64-linux-gnu/libcrypt.so.1                                                        
lrwxrwxrwx 1 me mygroup 32 Aug 26 23:32 ciao/sysroots/host/usr/lib/x86_64-linux-gnu/libdl.so -> /lib/x86_64-linux-gnu/libdl.so.2                                                              
lrwxrwxrwx 1 me mygroup 34 Aug 26 23:32 ciao/sysroots/host/usr/lib/x86_64-linux-gnu/libmvec.so -> /lib/x86_64-linux-gnu/libmvec.so.1                                                          
lrwxrwxrwx 1 me mygroup 40 Aug 26 23:32 ciao/sysroots/host/usr/lib/x86_64-linux-gnu/libnss_compat.so -> /lib/x86_64-linux-gnu/libnss_compat.so.2                                              
lrwxrwxrwx 1 me mygroup 37 Aug 26 23:32 ciao/sysroots/host/usr/lib/x86_64-linux-gnu/libnss_dns.so -> /lib/x86_64-linux-gnu/libnss_dns.so.2                                                    
lrwxrwxrwx 1 me mygroup 39 Aug 26 23:32 ciao/sysroots/host/usr/lib/x86_64-linux-gnu/libnss_files.so -> /lib/x86_64-linux-gnu/libnss_files.so.2                                                
lrwxrwxrwx 1 me mygroup 40 Aug 26 23:32 ciao/sysroots/host/usr/lib/x86_64-linux-gnu/libnss_hesiod.so -> /lib/x86_64-linux-gnu/libnss_hesiod.so.2                                              
lrwxrwxrwx 1 me mygroup 37 Aug 26 23:32 ciao/sysroots/host/usr/lib/x86_64-linux-gnu/libpthread.so -> /lib/x86_64-linux-gnu/libpthread.so.0                                                    
lrwxrwxrwx 1 me mygroup 36 Aug 26 23:32 ciao/sysroots/host/usr/lib/x86_64-linux-gnu/libresolv.so -> /lib/x86_64-linux-gnu/libresolv.so.2                                                      
lrwxrwxrwx 1 me mygroup 32 Aug 26 23:32 ciao/sysroots/host/usr/lib/x86_64-linux-gnu/librt.so -> /lib/x86_64-linux-gnu/librt.so.1                                                              
lrwxrwxrwx 1 me mygroup 39 Aug 26 23:32 ciao/sysroots/host/usr/lib/x86_64-linux-gnu/libthread_db.so -> /lib/x86_64-linux-gnu/libthread_db.so.1                                                
lrwxrwxrwx 1 me mygroup 39 Aug  1 16:26 ciao/sysroots/host/usr/lib/x86_64-linux-gnu/libtirpc.so -> /lib/x86_64-linux-gnu/libtirpc.so.3.0.0                                                    
lrwxrwxrwx 1 me mygroup 34 Aug 26 23:32 ciao/sysroots/host/usr/lib/x86_64-linux-gnu/libutil.so -> /lib/x86_64-linux-gnu/libutil.so.1                                                          
lrwxrwxrwx 1 me mygroup 32 Aug 26 23:32 ciao/sysroots/host/usr/lib64/ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-2.31.so                                                                 
lrwxrwxrwx 1 me mygroup 21 Nov 23 11:35 ciao/sysroots/host/usr/sbin/rmt -> /etc/alternatives/rmt                                                                                              
lrwxrwxrwx 1 me mygroup 26 Nov 23 11:35 ciao/sysroots/host/usr/share/man/man1/awk.1.gz -> /etc/alternatives/awk.1.gz                                                                          
lrwxrwxrwx 1 me mygroup 26 Nov 23 11:36 ciao/sysroots/host/usr/share/man/man1/c89.1.gz -> /etc/alternatives/c89.1.gz                                                                          
lrwxrwxrwx 1 me mygroup 26 Nov 23 11:36 ciao/sysroots/host/usr/share/man/man1/c99.1.gz -> /etc/alternatives/c99.1.gz                                                                          
lrwxrwxrwx 1 me mygroup 27 Nov 23 11:35 ciao/sysroots/host/usr/share/man/man1/nawk.1.gz -> /etc/alternatives/nawk.1.gz                                                                        
lrwxrwxrwx 1 me mygroup 28 Nov 23 11:35 ciao/sysroots/host/usr/share/man/man1/pager.1.gz -> /etc/alternatives/pager.1.gz                                                                      
lrwxrwxrwx 1 me mygroup 31 Nov 23 11:35 ciao/sysroots/host/usr/share/man/man1/pinentry.1.gz -> /etc/alternatives/pinentry.1.gz                                                                
lrwxrwxrwx 1 me mygroup 31 Nov 23 11:35 ciao/sysroots/host/usr/share/man/man7/builtins.7.gz -> /etc/alternatives/builtins.7.gz                                                                
lrwxrwxrwx 1 me mygroup 26 Nov 23 11:35 ciao/sysroots/host/usr/share/man/man8/rmt.8.gz -> /etc/alternatives/rmt.8.gz                                                                          
lrwxrwxrwx 1 me mygroup 14 Aug 14 16:27 ciao/sysroots/host/usr/share/zoneinfo/localtime -> /etc/localtime

And here is a proposed solution, prefixing all targets with the $native_sysroot path.

# Somewhere beforecreating  relocate-sdk.sh
abs_symbolic_links=$($SUDO_EXEC find $native_sysroot -type l \
    -exec sh -c "file \"{}\" | grep -P ': symbolic link to /' > /dev/null" \; \
    -printf "'%h/%f' ")
# Inside the creation of relocate-sdk.sh
for link in $abs_symbolic_links; do
    ln -sf $native_sysroot\$(readlink -f \$link) \$link
done

Unfortunately, I do not have the time to do a proper patch. I've tested it by manipulating directly the setup script.

FedericoVaga commented 1 year ago

Hi, I see I did not receive any feedback. Do you think is wrong what I am suggesting? Do you want me to propose a patch?

bgermann commented 1 year ago

Yes, please propose a patch.

FedericoVaga commented 1 year ago

Hi @bgermann, I found the time to write few patches. However, I'm struggling a bit in doing proper tests. I did the modifications to the mako file. However, how do I test it?

I'm using the container for this development, and I've added a new Dockerfile to copy elbe sources instead of installing the Debian package from linutronix. This is enough to get elbe from git sources running in the container. When the initvm gets created it installs elbe from linutronix while I want to use the one from sources.

So. The question is. What is your development process to validate elbe changes to sources? What am I missing?

bgermann commented 1 year ago

You use the initvm --devel create option.

FedericoVaga commented 1 year ago

Thanks, I did not notice that obvious option :D

On Tue, May 16, 2023 at 08:36:07AM -0700, bgermann wrote:

You use the initvm --devel create option.

-- Reply to this email directly or view it on GitHub: https://github.com/Linutronix/elbe/issues/336#issuecomment-1549908791 You are receiving this because you authored the thread.

Message ID: @.***>

-- Federico Vaga

FedericoVaga commented 1 year ago

Fixed in: https://github.com/Linutronix/elbe/pull/378