[<prev] [next>] [day] [month] [year] [list]
Message-Id: <A9C1598A-71EF-4345-A88D-09CCA3F98288@gmail.com>
Date: Sat, 21 Dec 2024 13:24:39 -0500
From: lollol222gg@...il.com
To: musl@...ts.openwall.com
Subject: Re: Question: How can I mix 32-bit and 64-bit musl headers?
This is something I have already done with the libs (/lib{arch} symlinked to /lib/{arch target}).
Just need to know if there is a default way to have arch based include directories that LLVM Clang will pickup without patching. If I can't escape patching Clang that won't be the end of the world for me.
Sent from my iPhone
> On Dec 21, 2024, at 7:22 AM, lollol222gg@...il.com wrote:
>
> This is something I have already done with the libs (/lib{arch} symlinked to /lib/{arch target}).
>
> Just need to know if there is a default way to have arch based include directories that LLVM Clang will pickup without patching. If I can't escape patching Clang that won't be the end of the world for me.
>
> Sent from my iPhone
>
>>> On Dec 21, 2024, at 1:32 AM, Rich Felker <dalias@...c.org> wrote:
>>>
>>> On Fri, Dec 20, 2024 at 09:22:00AM +0100, Markus Wichmann wrote:
>>> Am Thu, Dec 19, 2024 at 07:42:00PM -0500 schrieb William Pickard:
>>>> So I'm trying to create my own Linux distribution where musl and LLVM are
>>>> the primary libc, libc++ and compiler instead of gcc/glibc but I ran into
>>>> an issue where bits/alltypes.h is 32-bit specific when trying to compile
>>>> LLVM libc++ suite for 64-bit.
>>>>
>>>> Is there a specific way I should be installing headers for the 32-bit
>>>> version?
>>>
>>> musl does not support multilib in any way. The issue you are reporting
>>> sounds like musl is detecting the wrong architecture, because the
>>> alltypes.h is generated for the target architecture. I'm guessing you
>>> are building it the wrong way somehow, and I don't know how, because the
>>> normal "./configure && make && sudo make install" does the right thing.
>>
>> musl fully supports multiarch, just not the gcc multilib directory
>> layout with a shared include dir. The gcc layout is not compatible
>> with third-party libraries that install headers generated for the
>> particular system, so it's flawed to begin with, and it also doesn't
>> work with how musl treats archs as separate.
>>
>> If you want to do multiarch with musl, just ensure your toolchain for
>> each arch (treating 32-bit and 64-bit as independent archs) uses its
>> own separate include and library paths. The ld-musl-*.so.1 files all
>> go in /lib (they very intentionally have different names for each arch
>> and subarch variant) and each needs a corresponding ld-musl-*.path
>> file in /etc telling it where to look for shared libs for that arch.
>>
>> Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
