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

[Christian Melki <christian.melki@t2data.com>]

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.

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. 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
> 

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