Re: [ptxdist] Request for comments: CROSS_LIB_DIR handling etc.

[Michael Olbrich <m.olbrich@pengutronix.de>]

Hi,

On Thu, Nov 04, 2021 at 11:06:13AM +0100, Christian Melki wrote:
> Bump.

Right, this got lost on my side, sorry.

> No more comments? Action?
> 
> On 10/15/21 3:34 PM, Christian Melki wrote:
> > On 10/15/21 3:12 PM, Michael Olbrich wrote:
> > > Hi,
> > > 
> > > On Wed, Oct 13, 2021 at 09:29:24AM +0200, Christian Melki wrote:
> > > > I've been correcting various hardcoded paths in ptxdist packages
> > > > and whatnot
> > > > lately. This started with ptxdist not coping well with toolchains that
> > > > adhere to the ABI path for various architectures.
> > > > 
> > > > Yesterday, I dug into the problem that on x86_64 (/lib64), all
> > > > .pc.in -> .pc
> > > > file transformations looked broken with hardcoded paths. At
> > > > first I thought
> > > > it had something to do with autoconf or pkg-config but after a
> > > > while I found
> > > > this.
> > > > 
> > > > scripts/lib/ptxd_make_world_install_mangle_pc.awk
> > > > 
> > > > Which after a while made me realize that there is still a lot of code in
> > > > ptxdist core stuff that assumes that lib-paths are only /lib and nothing
> > > > else.
> > > > 
> > > > So. I'm presenting a two options here.
> > > > 
> > > > 1. Fix all ptxdist core stuff, because really, ptxdist should be more
> > > > flexible than hardcoded paths. Esp. for libs.
> > > > 
> > > > 2. Split ptxd_get_lib_dir, because, ld.so path should not be
> > > > assumed to be
> > > > the same as main library install path. So ptxd_get_ld_lib_dir which does
> > > > what it does today and install ld there and ptxd_get_lib_dir =
> > > > /lib and be
> > > > done with all the userspace library transformations.
> > > 
> > > So, put everything in lib/ and only the ld.so in lib64/, right?
> > > 
> > 
> > Yes. And depending on toolchain configuration.. + glibc, but not the
> > rest of the userspace libs as you say. Since the copy_toolchain routines
> > query the linker by itself afaiu.

Good point about copy_toolchain. I don't mind if glibc (etc.) is installed
in /lib64 as well. Whatever is easier to start with. We can change that
later if necessary.

> > Either way, the important bit is the hardcoded path to ld.so in the ABI
> > declaration. That's the one you have to hit, otherwise you'll have
> > bricked userspace. :) The rest can be solved with ld.so.conf.

So /usr/lib is not in the default search path and /etc/ld.so.conf is
necessary in this case?

> > > > So. Number one probably requires a lot of more work and a lot of
> > > > headache.
> > > 
> > > And we'll probably break it more often.
> > 
> > Pretty much guaranteed, yes.
> > 
> > > > Number two should be rather straightforward, atleast in theory.
> > > 
> > > There will be some packages that will use lib64/ anyways, because they
> > > query the toolchain directly. We have a platform-foo/sysroot-host/lib64
> > > symlink because of that.
> > > 
> > > > Any thoughts?
> > > 
> > > I actually really like option 2. It sounds like a lot less work and
> > > problems in the long run.
> > 
> > While I'd like a more generic solution, I can absolutely value things
> > that works and are simple. So, less problems it is. :)

:-)

> > > If necessary, we could also make lib64/ a symlink to lib/ (in
> > > ptxd_make_world_install_prepare() and in the final rootfs). That way, it
> > > wouldn't matter which one the packages are using.
> > > But I'd like to avoid that if possible.
> > 
> > Mmm. I botched my rules to always include a separate lib64 now, but
> > that's just a hack.

Michael

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de
To unsubscribe, send a mail with subject "unsubscribe" to ptxdist-request@pengutronix.de