From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.2 Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by inbox.vuxu.org (OpenSMTPD) with SMTP id 541dc645 for ; Mon, 3 Feb 2020 22:00:28 +0000 (UTC) Received: (qmail 25872 invoked by uid 550); 3 Feb 2020 22:00:27 -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 25848 invoked from network); 3 Feb 2020 22:00:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1580767215; bh=9YlLfDK4nBrDatvsAW41ve5WmfDsGDyEYUmnZx18mbw=; h=X-UI-Sender-Class:Date:From:To:Subject:References:In-Reply-To; b=H82AyZ9eTgUoPeDJX3ocy4Dqp1kr9yLc5e1bO+aYwtjx7yJ+xAIwYH9jPTvyT4W1z kRzebspJaPDMQ8QPLlqszojKii2syWt5o8SIe/Zi4OjXAlSBwTE9rTeIt7mshS2Zdx 1oB2UVx+Q29F+4A5KMqV6wxY+ERDzY4CWq7/go+U= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Date: Mon, 3 Feb 2020 23:00:13 +0100 From: Sebastian Kemper To: musl@lists.openwall.com Message-ID: <20200203220013.GC19036@darth.lan> Mail-Followup-To: musl@lists.openwall.com References: <20200203204416.GA19036@darth.lan> <20200203214445.GR1663@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200203214445.GR1663@brightrain.aerifal.cx> X-Provags-ID: V03:K1:Xu+4G043sT1WBIDiKyQgEjvkxk0BHBBUsTFhKvviRa7DZawx258 gpJtzjYdLpX1mxqJXLqwp8FQzPiMZDlFOcGIVJi5UK+eRbcNnAxE5O9leR6MYj3nlFMLRtL 3exZ9l5Fa+lB4YsbE84uyjWcKBkt5rGQb0t4DoySQyK4rBsFjGAViE1EVcpbKdwhfFdeZt6 8mDjhtbBrIvaUlYEgy2qg== X-UI-Out-Filterresults: notjunk:1;V03:K0:zCzOD14NTCg=:n6oVsDasgSALm2occJpPrZ QWu0Vu1T7bxeWlOgUKiTVF/XaGvXCYqRfeRVOz1W3dzxJgAfqbL0IUXFw/z+HkwE1moW8tMFa w68UnPQUEFB1CYupuo+9qT75iln43LtOusO5AG6chZIGncUcwRh0HHzYabUXfdmQs8TzTl9FT EAdVUckJR/SIYpIq/Qq6lyT+W1RXvjqFMw2zrLP0nRMO/JU0bBI8iN3DGFkJbUMV+7St7lyww gtVzMLKFaPDq4mhA4DwI0csrAC3NZLq39juFGsNZUcgb8ltxTpLEa4+qHjTp6t9sYYrHxJesU ltIDKuLMttE4LUPRDyW/JMzw5R+0htdcgSgXmGZBIQiufeIfdOS+aHbt9pnLrm5azXZt9MpEQ DpX1CN0Qh6/QbJU0AYMmfghrqhQu6T8b2XspeJ0Vpi/uTmeEIbG8uhcgoq6AGSc5C5n6AxbDD o77glmjsTpfVrk8+yGsf2u2Z5/RZgzG7Tnx3g52cCJn0auVSYpiluCHu5IGenb1V/uO93kMCk O/41y1Zpjpl6R6s1QWp3GDvaUlHJgrzVfoeWvSlbGo6APKPbOCkejEPPAZTTMDaeZyAMH2UFW /PNS1Ai/hrEA/7ji0/5uUp0J+IuGuVOb3CBkED+FNeixNb3KvwdjkM5danKzOlT5sDOlUxYuN 8g5rMMnmxCppKrskqTXYzmx/ui/HdevZIak34LRHd3CiFAZycPNkM/k4imTljAizkk+qlvjKH Mr5PYSo+gjZRoe8yHwsLqHUBr/ApJKJaOPwAckWEYxkQgyyld6sjXHD/ibOfqCrFeyxDFNdG0 nUebGyptNYrexyVKfk4OWK5hNOGzMN4LWM1SHqHRKboEtPTRVAURGOwPekzmntM8ezNNj91Z9 kFIDuFgyItu4hPebjaxLMHz6DtScPxSELIcc9Ceyxvh0xvxP5Am2M8szMX9RLyQB4d8A0hyIg V29acf1zokkT0pNejtMKiDdSuOgEtfxaMhYxTsMprQMYou8FWUdy0aKWLL3goQ/auMOXI1OeD B0NaYxuKuUxg/VpxdmLdxCm0YDgPeX4lk3IFR3qwRtd0Du9izz+aQLq4TKnlSDGgaT8rrVCUL fCtVgezP8wTbbRvSVGs/N34rFBa8j6NthPkV5o506QSl2MYX1Q01k6LYgeR2tVbNMgR0klXHP SKhAXTUZ3u45BYw2PYa51qKHQEojt+H9w1i4gLrvWN99LBiDPMFS2A2RZ08OZ7/rPdAIqOh6+ 2Cqekg6qbxaYshJFk Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] Cross-compiling and -D_LARGEFILE64_SOURCE On Mon, Feb 03, 2020 at 04:44:45PM -0500, Rich Felker wrote: > On Mon, Feb 03, 2020 at 09:44:17PM +0100, Sebastian Kemper wrote: > > Hello list, > > > > I'm working on updating apr in OpenWrt. During configure it uses TRY_R= UN > > a lot, so we have a lot of configure variables defined to point it int= o > > the right direction. > > > > With one variable I have some trouble: apr_cv_use_lfs64=3Dyes. The tro= uble > > is I don't know whether or not to set it. > > Can you clarify where that came from? It sounds like it wasn't > detected by configure but something OpenWrt's build scripts are > forcing. Is that right? Hi Rich! Historically OpenWrt had TARGET_CPPFLAGS +=3D -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=3D64 -D_GNU= _SOURCE _and_ apr_cv_use_lfs64=3Dyes as configure var. I think this was working around some bug or the other, I don't know which. Then these got removed (not by me). A few weeks ago I added myself as maintainer of apr and was poking around, and saw that buildroot also sets apr_cv_use_lfs64=3Dyes. So I thought we should use it too. But afterwards I had some doubts about it and poked around some more. And here we are :D > > > It basically forces -D_LARGEFILE64_SOURCE to be included in the > > CPPFLAGS. So my first impulse was to force it to "yes". But then I saw > > some build logs from Alpine Linux: > > _LARGEFILE64_SOURCE is a horrible horrible thing you never want, so if > you have the opportunity to omit it, do. We're actually trying to get > rid of this stuff completely from the headers. It was originally put > there just as a workaround for a lot of bad GNU software trying to use > the "64"-suffixed symbols based on invalid configure tests (link-only) > which broke things badly when no declaration for the functions > existed. Remove it I shall, thank you very much! > > > https://build.alpinelinux.org/buildlogs/build-edge-x86/main/apr/apr-1.= 7.0-r0.log > > > > > > checking whether the compiler provides atomic builtins... yes > > checking whether to enable -D_LARGEFILE64_SOURCE... no > > configure: Configured for Linux 4.14 > > > > > > So Alpine is not cross-compiling here, and the result is "no". And thi= s > > particular log is for i586 (I thought - before seeing this log - that > > maybe -D_LARGEFILE64_SOURCE is needed for non-64-bit platforms). > > It's not. It's legacy junk that should never be used. It's to make > visible the "64"-suffixed functions on systems where the standard > functions are limited to 32-bit offsets, which is never the case on > musl. > > > The TRY_RUN that apr uses to find out whether to add > > -D_LARGEFILE64_SOURCE is pasted at the bottom of this mail. If I run > > configure on my x86_64 glibc laptop it says "no". In the Alpine logs i= t > > also says "no". If I search the Internet I find some old pastes where > > the outcome was "yes", though. It kind of looks like the answer over > > time changed from "yes" to "no", for no apparent reason (at least for > > me). > > > > If it sets -D_LARGEFILE64_SOURCE it propagates the same flag to its > > users via apr-1-config. In the apr sources I see the define also being > > used occasionally. > > > > include/arch/unix/apr_arch_file_io.h: > > > > #if APR_HAS_LARGE_FILES && defined(_LARGEFILE64_SOURCE) > > #define stat(f,b) stat64(f,b) > > #define lstat(f,b) lstat64(f,b) > > #define fstat(f,b) fstat64(f,b) > > #define lseek(f,o,w) lseek64(f,o,w) > > #define ftruncate(f,l) ftruncate64(f,l) > > typedef struct stat64 struct_stat; > > #else > > typedef struct stat struct_stat; > > #endif > > OK, this is going to break badly. It's also completely bogus (bug in > APR). *All* feature test macros are conveyed *from* the application > *to* libc. #define of them belongs only in the application and > #ifdef/#if defined() of them only in libc headers. > > > file_io/unix/open.c: > > > > #if APR_HAS_LARGE_FILES && defined(_LARGEFILE64_SOURCE) > > oflags |=3D O_LARGEFILE; > > #elif defined(O_LARGEFILE) > > if (flag & APR_FOPEN_LARGEFILE) { > > oflags |=3D O_LARGEFILE; > > } > > #endif > > > > I obviously would like LFS support, but I don't know about this > > configure variable. I guess the correct answer must be one of these: > > > > "Don't use it" > > "Use it" > > "Use it if condition X applies" > > Don't use it. :-) > Thanks Rich! Again I came here for final wisdom and wasn't disappointed ;) Kind regards, Seb > > I guess this is a bit off-topic maybe. But I'm really running out of > > ideas :) So if anybody can share some insight I'd really appreciate it= . > > > > Kind regards, > > Seb > > > > AC_CACHE_CHECK([whether to enable -D_LARGEFILE64_SOURCE], [apr_cv_u= se_lfs64], [ > > apr_save_CPPFLAGS=3D$CPPFLAGS > > CPPFLAGS=3D"$CPPFLAGS -D_LARGEFILE64_SOURCE" > > AC_TRY_RUN([ > > #include > > #include > > #include > > #include > > #include > > #include > > > > void main(void) > > { > > int fd, ret =3D 0; > > struct stat64 st; > > off64_t off =3D 4242; > > > > if (sizeof(off64_t) !=3D 8 || sizeof(off_t) !=3D 4) > > exit(1); > > if ((fd =3D open("conftest.lfs", O_LARGEFILE|O_CREAT|O_WRONLY, 064= 4)) < 0) > > exit(2); > > if (ftruncate64(fd, off) !=3D 0) > > ret =3D 3; > > else if (fstat64(fd, &st) !=3D 0 || st.st_size !=3D off) > > ret =3D 4; > > else if (lseek64(fd, off, SEEK_SET) !=3D off) > > ret =3D 5; > > else if (close(fd) !=3D 0) > > ret =3D 6; > > else if (lstat64("conftest.lfs", &st) !=3D 0 || st.st_size !=3D of= f) > > ret =3D 7; > > else if (stat64("conftest.lfs", &st) !=3D 0 || st.st_size !=3D off= ) > > ret =3D 8; > > unlink("conftest.lfs"); > > > > exit(ret); > > }], [apr_cv_use_lfs64=3Dyes], [apr_cv_use_lfs64=3Dno], [apr_cv_use_lfs= 64=3Dno]) > > CPPFLAGS=3D$apr_save_CPPFLAGS]) > > if test "$apr_cv_use_lfs64" =3D "yes"; then > > APR_ADDTO(CPPFLAGS, [-D_LARGEFILE64_SOURCE]) > > fi > > OK, the configure tests that need to run something are a big problem > if you're cross-compiling, so you probably need to force it to no. The > above should be factored into two tests, one compile-only and the > other execution, so that the compile-only one is all that's needed > when it's sufficient to give a conclusive result. > > Rich