From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 21950 invoked from network); 13 Feb 2023 14:23:57 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 13 Feb 2023 14:23:57 -0000 Received: (qmail 13522 invoked by uid 550); 13 Feb 2023 14:23:54 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 13484 invoked from network); 13 Feb 2023 14:23:53 -0000 Date: Mon, 13 Feb 2023 09:23:40 -0500 From: Rich Felker To: alice Cc: musl@lists.openwall.com Message-ID: <20230213142340.GR4163@brightrain.aerifal.cx> References: <13336ea0.2103f.1864ab522cc.Coremail.huajingyun@loongson.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] 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