[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230213142340.GR4163@brightrain.aerifal.cx>
Date: Mon, 13 Feb 2023 09:23:40 -0500
From: Rich Felker <dalias@...c.org>
To: alice <alice@...ya.dev>
Cc: musl@...ts.openwall.com
Subject: Re: Compile gcc-12 with musl and report errors
On Mon, Feb 13, 2023 at 03:12:38PM +0100, alice wrote:
> On Mon Feb 13, 2023 at 1:17 PM CET, 花静云 wrote:
> > Hi：
> > I installed the Alpine Linux system on the x86_64 platform, and exposed a
> > problem when compiling gcc 12 using musl (master branch) in this system：
> > /usr/lib/gcc/x86_64-alpine-linux-musl/12.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: d/common-outbuffer.o: in function `_D3dmd6common4file__T11FileMappingThZQq6__ctorMFNbNcxPaZSQCdQCcQBy__TQBwThZQCc':
> > outbuffer.d:(.text+0x29f): undefined reference to `mmap64'
> >
> > I uploaded more detailed logs to gcc_ build_ Error.log file，and other information is as follows：
> > 1、linux-lts（kernel）version：6.1.10-r0
> > 2、gcc version：12.2.1_git20220924-r9
> > 3、binutils version：binutils-2.40-r4
> > 4、musl：master branch and commit is f47a8cdd250d9163fcfb39bf4e9d813957c0b187
> >
> > I suspect that the error is caused by the difference of the musl code，When
> > I checked musl source, I found that there was a big difference between the
> > master branch code and the v1.2.3 version code. For example, a large number of
> > weaks_alias were removed during the 246f1c811448f37a44b41cd8df8d0ef9736d95f4
> > commit，include “weak_alias(mmap, mmap64);” in src/mman/mmap.c.
>
> yes, as that commit says, this was intentional. code is _not_ meant to call
> these *64 functions that were removed- code should unconditionally call `mmap`
> and use -D_FILE_OFFSET_BITS=64 (for C) . so, gcc (the D frontend here) needs fixing.
>
> specifically, it's libphobos/libdruntime/core/sys/posix/sys/mman.d ,
>
> where:
>
> else version (CRuntime_Musl)
> {
> static if (__USE_LARGEFILE64) void* mmap64(void*, size_t, int, int, int, off_t);
> static if (__USE_FILE_OFFSET64)
> alias mmap = mmap64;
> else
> void* mmap(void*, size_t, int, int, int, off_t);
> int munmap(void*, size_t);
> }
>
> probably does something like expose the mmap64 symbol (no idea what this code means).
> maybe __USE_LARGEFILE64 has to be unset for it?
Well, it's a bug that they're poking at glibc-internal macros (and
possibly defining these themselves?) rather than performing a
configure test. Especially since they apparently hardcoded as
CRuntime_Musl profile with wrong information about musl...
Assuming they don't want to fix the hard-coding, the above should just
be (and should always have been):
else version (CRuntime_Musl)
{
void* mmap(void*, size_t, int, int, int, off_t);
int munmap(void*, size_t);
}
with no mention of mmap64 or glibc macros.
Anyone up for sending a bug report and patch to gcc (or perhaps dmd
upstream)?
In any case, unless you're using the D language, this entire problem
can be avoided by just not enabling it in --enable-languages.
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.
