From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12062 Path: news.gmane.org!.POSTED!not-for-mail From: Didier Kryn Newsgroups: gmane.linux.lib.musl.general Subject: Re: Successfull build of gnat-6.3.0 with musl-cross-make Date: Sun, 5 Nov 2017 21:35:46 +0100 Message-ID: <17f3b400-9d10-ec43-a086-e89873f8e8f6@in2p3.fr> References: <69c03d16-1946-d4e3-f909-2bd2196afe97@in2p3.fr> <20171105180126.GJ1627@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1509914167 5567 195.159.176.226 (5 Nov 2017 20:36:07 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 5 Nov 2017 20:36:07 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 To: musl@lists.openwall.com Original-X-From: musl-return-12078-gllmg-musl=m.gmane.org@lists.openwall.com Sun Nov 05 21:36:00 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1eBReB-00017J-BS for gllmg-musl@m.gmane.org; Sun, 05 Nov 2017 21:35:59 +0100 Original-Received: (qmail 1487 invoked by uid 550); 5 Nov 2017 20:36:04 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 1460 invoked from network); 5 Nov 2017 20:36:03 -0000 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.99.2 at cczrelay02 In-Reply-To: <20171105180126.GJ1627@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:12062 Archived-At: Le 05/11/2017 =C3=A0 19:01, Rich Felker a =C3=A9crit : > On Thu, Nov 02, 2017 at 10:44:13AM +0100, Didier Kryn wrote: >> I report the successfull build of the cross-compiler >> x86_64-musl-gcc-6.3.0 - understanding Ada - on x86_64 Debian Wheezy. >> >> The toolchain for build was gcc-6.3.0 for Linux-Gnu provided by >> Adacore.The build toolchain to build major version 6 must be at >> least major version 5. >> >> Of course, the language option must be '--enable-languages=3Dada,= c,c++' . > This is very interesting! Thanks for the report. As an aside, I know > there's been some interest in building GHDL, which depends on GNU Ada; > I'm not sure if this gets us closer to making that work but I suspect > it might. > >> Three patches were necessary: >> gnat63-terminals.diff: removes a #include in a C >> source file. >> gnat63-prj-attr.diff: corrects the layout of a record in an >> Ada source file to prevent a warning concerning performance. >> gnat63-xr_tabls.diff: same as the previous. > Are the second and third actually necessary, and are they related to > musl at all? If they're actual improvement regardless of libc, they > should probably go upstream in gcc. But if they're needed for now to > make mcm work with ada out of the box, I don't mind including them in > mcm as a convenience. The second and third are meant to prevent a warning because the=20 compilation is done with option -Werror. They are only related to=20 -Werror. But I think this compiler option is sensible considering this=20 is a single-step build. The patches might be slightly less intrusive: instead of changing=20 the layout of the record, it would be enough to insert a pragma to=20 disable the warning. But, frankly, the original layout of the record=20 only makes the source slightly more readable: a record in Ada is like a=20 struct in C or C++. In this case, the first componant is the name which=20 is a string of variable length. It makes sense to put the name first but = it is better for performance that the fixed-size components of a record=20 are placed first. Hence the warning. This is a tool for which=20 performance isn't critical; this is why the author didn't take care. > >> Note on static linking: >> Compilation of Ada program is often made in one invocation of >> gnatmake, which calls gcc, gnatbind and gnatlink. By default, >> gnatmake links everything statically, except the libc (probably a >> gnuism). If the option -shared is given, then it links everything >> dynamically. The option -static is ignored by gnatmake. >> However, it is possible to produce static executables by >> invoking gcc -c, gnatbind, andgnatlink, because gnatlink honours the >> -static option. >> >> I attach the patches in case someone is interested. >> >> I was able to compile a native x86_64-pc-linux-musl-gcc-6.3.0 >> (with the 3 steps) using this cross-compiler for build. > Seems there's no reason not to static link libc if everything else is > static too, except for glibc issues with static linking. It might make > sense to change the default for musl target tuples. The problem is that it requires a better understanding of the=20 program than I have. HTH Didier