From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4651 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Static linking of musl with code compiled using GNU header files Date: Fri, 14 Mar 2014 12:47:20 -0400 Message-ID: <20140314164720.GG184@brightrain.aerifal.cx> References: <53232493.80901@gcom.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1394815650 16850 80.91.229.3 (14 Mar 2014 16:47:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 14 Mar 2014 16:47:30 +0000 (UTC) Cc: Support at Gcom To: musl@lists.openwall.com Original-X-From: musl-return-4655-gllmg-musl=m.gmane.org@lists.openwall.com Fri Mar 14 17:47:39 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1WOVGg-0000Ly-99 for gllmg-musl@plane.gmane.org; Fri, 14 Mar 2014 17:47:34 +0100 Original-Received: (qmail 27745 invoked by uid 550); 14 Mar 2014 16:47:33 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 27737 invoked from network); 14 Mar 2014 16:47:33 -0000 Content-Disposition: inline In-Reply-To: <53232493.80901@gcom.com> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:4651 Archived-At: On Fri, Mar 14, 2014 at 10:47:31AM -0500, David Grothe wrote: > Hello, > > I have a very large code base that I have been compiling on Linux > using the standard GNU C compiler [gcc (Ubuntu/Linaro > 4.6.3-1ubuntu5) 4.6.3]. I have been using shared object libraries, > but for reasons of software support I would now like to link all my > commands (a couple of dozen) and daemons using static libraries so > that the code files are self-contained and can be copied, along with > a core file, to any server back in my shop for analysis. With > dynamic libraries I have to have exactly the same version of libc > installed on the machine that I use to examine the core file as were > present on the machine that generated the core file, or else gdb > will not produce a stack back trace with file and line number > information. So much for the background. > > I really don't want to port my code base to using the musl header > files. I want to keep compiling with the GNU headers. When I do > this and link my-huge-program.o with musl libc.a I get the following > list of unresolved externals: > > U __divdi3 > w __fini_array_end > w __fini_array_start > U __moddi3 > U __sysv_signal > U __udivdi3 > U __umoddi3 > U __vfprintf_chk > U __vsnprintf_chk > U __vsprintf_chk > U __sysv_signal The presence of __divdi3, __moddi3, __udivdi3, and __umoddi3 in this list indicates that you're missing libgcc.a. If you're using -nostdlib, you need to manually add libgcc back to the linker command line. __fini_array_start and __fini_array_end are provided by the linker and are not necessary unless your code has global destructors that the compiler is implementing via fini_array (this is why they're weak). The rest are __sysv_signal and __*_chk. The former looks suspicious: I really doubt you _want_ to be using the sysv version of signal(); it probably got pulled in by glibc's headers due to bad feature test macros or something. As for the latter, these come from _FORTIFY_SOURCE which musl does not yet support. > So, I am wondering if the musl library could at some point provide > these routines to enable users to do what I am trying to do. > > Any possibility of that? Likely for at least some of them, but not right away. And there are at least a few features (e.g. pthread cancellation) that will never work this way. BTW is there a reason you want to use glibc's headers with musl? If your program is having lots of build errors with musl's, it's probably indicative of problems you should fix; some of these problems may become problems with future glibc versions too. Rich