[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20241223092522.GC10433@brightrain.aerifal.cx>
Date: Mon, 23 Dec 2024 04:25:22 -0500
From: Rich Felker <dalias@...c.org>
To: lollol222gg@...il.com
Cc: musl@...ts.openwall.com
Subject: Re: Question: How can I mix 32-bit and 64-bit musl headers?
On Sat, Dec 21, 2024 at 01:24:39PM -0500, 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.
clang is natively a universal cross compiler, so it must have some
mechanism for configuring the include and library paths for the target
you select. But I don't regularly use it, just occasionally for
experimentation, so hopefully someone else can fill in the details on
how.
Rich
> > 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.
