From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4648 Path: news.gmane.org!not-for-mail From: David Grothe Newsgroups: gmane.linux.lib.musl.general Subject: Static linking of musl with code compiled using GNU header files Date: Fri, 14 Mar 2014 10:47:31 -0500 Message-ID: <53232493.80901@gcom.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------000009010903040503090602" X-Trace: ger.gmane.org 1394812060 3183 80.91.229.3 (14 Mar 2014 15:47:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 14 Mar 2014 15:47:40 +0000 (UTC) Cc: Support at Gcom To: musl@lists.openwall.com Original-X-From: musl-return-4652-gllmg-musl=m.gmane.org@lists.openwall.com Fri Mar 14 16:47:49 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 1WOUKp-00027M-7j for gllmg-musl@plane.gmane.org; Fri, 14 Mar 2014 16:47:47 +0100 Original-Received: (qmail 24144 invoked by uid 550); 14 Mar 2014 15:47:45 -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 24131 invoked from network); 14 Mar 2014 15:47:45 -0000 X-Virus-Scanned: OK User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 Xref: news.gmane.org gmane.linux.lib.musl.general:4648 Archived-At: This is a multi-part message in MIME format. --------------000009010903040503090602 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 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? Thanks, Dave --------------000009010903040503090602 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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

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?

Thanks,
Dave
 --------------000009010903040503090602-- From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4649 Path: news.gmane.org!not-for-mail From: Luca Barbato Newsgroups: gmane.linux.lib.musl.general Subject: Re: Static linking of musl with code compiled using GNU header files Date: Fri, 14 Mar 2014 17:09:06 +0100 Message-ID: <532329A2.8090906@gentoo.org> 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=UTF-8 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1394813358 19987 80.91.229.3 (14 Mar 2014 16:09:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 14 Mar 2014 16:09:18 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4653-gllmg-musl=m.gmane.org@lists.openwall.com Fri Mar 14 17:09:28 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 1WOUfk-0002jx-CD for gllmg-musl@plane.gmane.org; Fri, 14 Mar 2014 17:09:24 +0100 Original-Received: (qmail 6035 invoked by uid 550); 14 Mar 2014 16:09:22 -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 6025 invoked from network); 14 Mar 2014 16:09:22 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 In-Reply-To: <53232493.80901@gcom.com> Xref: news.gmane.org gmane.linux.lib.musl.general:4649 Archived-At: On 14/03/14 16:47, David Grothe wrote: > I really don't want to port my code base to using the musl header > files. There shouldn't be anything to port. > 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 > > 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. Not sure, but those internal symbols are close to implementation details... lu From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4650 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: Static linking of musl with code compiled using GNU header files Date: Fri, 14 Mar 2014 17:29:57 +0100 Message-ID: <20140314162957.GB27448@port70.net> 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 1394814600 4044 80.91.229.3 (14 Mar 2014 16:30:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 14 Mar 2014 16:30:00 +0000 (UTC) Cc: Support at Gcom To: musl@lists.openwall.com Original-X-From: musl-return-4654-gllmg-musl=m.gmane.org@lists.openwall.com Fri Mar 14 17:30:10 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 1WOUzp-0002yt-PP for gllmg-musl@plane.gmane.org; Fri, 14 Mar 2014 17:30:09 +0100 Original-Received: (qmail 15559 invoked by uid 550); 14 Mar 2014 16:30:09 -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 15551 invoked from network); 14 Mar 2014 16:30:09 -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:4650 Archived-At: * David Grothe [2014-03-14 10:47:31 -0500]: > 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 compiling with the gnu headers is broken and it depends on the cflags used > this and link my-huge-program.o with musl libc.a I get the following > list of unresolved externals: > > U __divdi3 comes from libgcc.a, if it's missing you have a toolchain issue > w __fini_array_end > w __fini_array_start i think musl supports init/fini arrays (see src/exit/exit.c) > U __moddi3 libgcc > U __sysv_signal you may want to replace it with signal > U __udivdi3 > U __umoddi3 libgcc > U __vfprintf_chk > U __vsnprintf_chk > U __vsprintf_chk there are many _chk functions for _FORTIFY_SOURCE, musl may provide these eventually, until then you can add your own chk.o with dummy implementations (possibly with the safety checks i omit here): int __vfprintf_chk(FILE *f, int flag, const char *fmt, va_list ap) { return vfprintf(f, fmt, ap); } int __vsnprintf_chk(char *s, size_t n, int flag, size_t size, const char *fmt, va_list ap) { return vsnprintf(s, n, fmt, ap); } int __vsprintf_chk(char *s, int flag, size_t size, const char *fmt, va_list ap) { return vsprintf(s, fmt, ap); } > U __sysv_signal use signal > 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. compiling with glibc headers and then linking to musl cannot be supported in general, because of ABI compat issues (eg glibc headers define PTHREAD_*_INITIALIZER macros that hardcode glibc internal ABI at compile time that does not match musl) if you are sure you don't have such ABI breakage (see glibc vs musl differences on the wiki) then you may get away by adding a glibc-compat.o to your musl build > > Any possibility of that? > > Thanks, > Dave 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 From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4652 Path: news.gmane.org!not-for-mail From: David Grothe Newsgroups: gmane.linux.lib.musl.general Subject: Re: Static linking of musl with code compiled using GNU header files Date: Fri, 14 Mar 2014 13:52:18 -0500 Message-ID: <53234FE2.7040309@gcom.com> References: <53232493.80901@gcom.com> <20140314162957.GB27448@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------070602070300070101020605" X-Trace: ger.gmane.org 1394823144 10181 80.91.229.3 (14 Mar 2014 18:52:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 14 Mar 2014 18:52:24 +0000 (UTC) Cc: Support at Gcom To: musl@lists.openwall.com Original-X-From: musl-return-4656-gllmg-musl=m.gmane.org@lists.openwall.com Fri Mar 14 19:52:34 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 1WOXDd-0001Cq-7m for gllmg-musl@plane.gmane.org; Fri, 14 Mar 2014 19:52:33 +0100 Original-Received: (qmail 28050 invoked by uid 550); 14 Mar 2014 18:52:32 -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 28020 invoked from network); 14 Mar 2014 18:52:32 -0000 X-Virus-Scanned: OK User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 In-Reply-To: <20140314162957.GB27448@port70.net> Xref: news.gmane.org gmane.linux.lib.musl.general:4652 Archived-At: This is a multi-part message in MIME format. --------------070602070300070101020605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Thanks for the suggestions. My musl build did not include a libgcc: linuxsvr:dave:musl-0.9.15> find . -name '*libgcc*' linuxsvr:dave:musl-0.9.15> It is correct that something in the GNU headers changed "signal" into "sysv_signal" without my knowledge. My code base is several million lines of code and I have many other projects to do that are higher priority than porting to another set of header files. It would be a few days worth of effort and I just have other things to do right now. That said I do have a reason for wanting static linking, so maybe I will find the time to do the port some time. (I tried just aiming my build at the musl include directory and it did not "just work".) I can act on the suggestions made and see how that helps. But what about libgcc? Thanks, Dave On 3/14/2014 11:29 AM, Szabolcs Nagy wrote: > * David Grothe [2014-03-14 10:47:31 -0500]: >> 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 > compiling with the gnu headers is broken and > it depends on the cflags used > >> this and link my-huge-program.o with musl libc.a I get the following >> list of unresolved externals: >> >> U __divdi3 > comes from libgcc.a, if it's missing you have a toolchain issue > >> w __fini_array_end >> w __fini_array_start > i think musl supports init/fini arrays > (see src/exit/exit.c) > >> U __moddi3 > libgcc > >> U __sysv_signal > you may want to replace it with signal > >> U __udivdi3 >> U __umoddi3 > libgcc > >> U __vfprintf_chk >> U __vsnprintf_chk >> U __vsprintf_chk > there are many _chk functions for _FORTIFY_SOURCE, musl may provide > these eventually, until then you can add your own chk.o with dummy > implementations (possibly with the safety checks i omit here): > > int __vfprintf_chk(FILE *f, int flag, const char *fmt, va_list ap) > { > return vfprintf(f, fmt, ap); > } > int __vsnprintf_chk(char *s, size_t n, int flag, size_t size, const char *fmt, va_list ap) > { > return vsnprintf(s, n, fmt, ap); > } > int __vsprintf_chk(char *s, int flag, size_t size, const char *fmt, va_list ap) > { > return vsprintf(s, fmt, ap); > } > >> U __sysv_signal > use signal > >> 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. > compiling with glibc headers and then linking to musl > cannot be supported in general, because of ABI compat issues > > (eg glibc headers define PTHREAD_*_INITIALIZER macros that hardcode > glibc internal ABI at compile time that does not match musl) > > if you are sure you don't have such ABI breakage (see glibc > vs musl differences on the wiki) then you may get away by > adding a glibc-compat.o to your musl build > >> Any possibility of that? >> >> Thanks, >> Dave --------------070602070300070101020605 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thanks for the suggestions.

My musl build did not include a libgcc:

linuxsvr:dave:musl-0.9.15> find . -name '*libgcc*'
linuxsvr:dave:musl-0.9.15>

It is correct that something in the GNU headers changed "signal" into "sysv_signal" without my knowledge.

My code base is several million lines of code and I have many other projects to do that are higher priority than porting to another set of header files.  It would be a few days worth of effort and I just have other things to do right now.

That said I do have a reason for wanting static linking, so maybe I will find the time to do the port some time. (I tried just aiming my build at the musl include directory and it did not "just work".)

I can act on the suggestions made and see how that helps.  But what about libgcc?

Thanks,
Dave
On 3/14/2014 11:29 AM, Szabolcs Nagy wrote:
* David Grothe <dave@gcom.com> [2014-03-14 10:47:31 -0500]:

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

compiling with the gnu headers is broken and
it depends on the cflags used


this and link my-huge-program.o with musl libc.a I get the following
list of unresolved externals:

         U __divdi3

comes from libgcc.a, if it's missing you have a toolchain issue


         w __fini_array_end
         w __fini_array_start

i think musl supports init/fini arrays
(see src/exit/exit.c)


         U __moddi3

libgcc


         U __sysv_signal

you may want to replace it with signal


         U __udivdi3
         U __umoddi3

libgcc


         U __vfprintf_chk
         U __vsnprintf_chk
         U __vsprintf_chk

there are many _chk functions for _FORTIFY_SOURCE, musl may provide
these eventually, until then you can add your own chk.o with dummy
implementations (possibly with the safety checks i omit here):

int __vfprintf_chk(FILE *f, int flag, const char *fmt, va_list ap)
{
	return vfprintf(f, fmt, ap);
}
int __vsnprintf_chk(char *s, size_t n, int flag, size_t size, const char *fmt, va_list ap)
{
	return vsnprintf(s, n, fmt, ap);
}
int __vsprintf_chk(char *s, int flag, size_t size, const char *fmt, va_list ap)
{
	return vsprintf(s, fmt, ap);
}


         U __sysv_signal

use signal


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.

compiling with glibc headers and then linking to musl
cannot be supported in general, because of ABI compat issues

(eg glibc headers define PTHREAD_*_INITIALIZER macros that hardcode
glibc internal ABI at compile time that does not match musl)

if you are sure you don't have such ABI breakage (see glibc
vs musl differences on the wiki) then you may get away by
adding a glibc-compat.o to your musl build


Any possibility of that?

Thanks,
Dave

--------------070602070300070101020605-- From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4653 Path: news.gmane.org!not-for-mail From: Kurt H Maier Newsgroups: gmane.linux.lib.musl.general Subject: Re: Static linking of musl with code compiled using GNU header files Date: Fri, 14 Mar 2014 19:25:16 +0000 Message-ID: <20140314192516.Horde.7BCFl4V_wl108uGGxLgbNA2@ssl.eumx.net> References: <53232493.80901@gcom.com> <20140314162957.GB27448@port70.net> <53234FE2.7040309@gcom.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes X-Trace: ger.gmane.org 1394825121 1533 80.91.229.3 (14 Mar 2014 19:25:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 14 Mar 2014 19:25:21 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4657-gllmg-musl=m.gmane.org@lists.openwall.com Fri Mar 14 20:25:31 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 1WOXjW-0002rf-0j for gllmg-musl@plane.gmane.org; Fri, 14 Mar 2014 20:25:30 +0100 Original-Received: (qmail 16172 invoked by uid 550); 14 Mar 2014 19:25:29 -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 16161 invoked from network); 14 Mar 2014 19:25:29 -0000 In-Reply-To: <53234FE2.7040309@gcom.com> User-Agent: Internet Messaging Program (IMP) H5 (6.1.6) Content-Disposition: inline Xref: news.gmane.org gmane.linux.lib.musl.general:4653 Archived-At: Quoting David Grothe : > My musl build did not include a libgcc: libgcc comes with gcc. http://gcc.gnu.org/onlinedocs/gccint/Libgcc.html khm From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4654 Path: news.gmane.org!not-for-mail From: David Grothe Newsgroups: gmane.linux.lib.musl.general Subject: Re: Static linking of musl with code compiled using GNU header files Date: Fri, 14 Mar 2014 14:35:49 -0500 Message-ID: <53235A15.1030408@gcom.com> References: <53232493.80901@gcom.com> <20140314162957.GB27448@port70.net> <53234FE2.7040309@gcom.com> <20140314192516.Horde.7BCFl4V_wl108uGGxLgbNA2@ssl.eumx.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------060209010901060701000500" X-Trace: ger.gmane.org 1394825753 8168 80.91.229.3 (14 Mar 2014 19:35:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 14 Mar 2014 19:35:53 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4658-gllmg-musl=m.gmane.org@lists.openwall.com Fri Mar 14 20:36:04 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 1WOXtj-00031t-Ae for gllmg-musl@plane.gmane.org; Fri, 14 Mar 2014 20:36:03 +0100 Original-Received: (qmail 21814 invoked by uid 550); 14 Mar 2014 19:36:02 -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 21806 invoked from network); 14 Mar 2014 19:36:02 -0000 X-Virus-Scanned: OK User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 In-Reply-To: <20140314192516.Horde.7BCFl4V_wl108uGGxLgbNA2@ssl.eumx.net> Xref: news.gmane.org gmane.linux.lib.musl.general:4654 Archived-At: This is a multi-part message in MIME format. --------------060209010901060701000500 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Got it. Thanks. -- Dave On 3/14/2014 2:25 PM, Kurt H Maier wrote: > Quoting David Grothe : > >> My musl build did not include a libgcc: > > libgcc comes with gcc. > > http://gcc.gnu.org/onlinedocs/gccint/Libgcc.html > > khm > > > --------------060209010901060701000500 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Got it.  Thanks.
-- Dave
On 3/14/2014 2:25 PM, Kurt H Maier wrote:
Quoting David Grothe <dave@gcom.com>:

My musl build did not include a libgcc:

libgcc comes with gcc.

http://gcc.gnu.org/onlinedocs/gccint/Libgcc.html

khm




--------------060209010901060701000500-- From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4655 Path: news.gmane.org!not-for-mail From: David Grothe Newsgroups: gmane.linux.lib.musl.general Subject: Re: Static linking of musl with code compiled using GNU header files Date: Fri, 14 Mar 2014 16:04:50 -0500 Message-ID: <53236EF2.4030606@gcom.com> References: <53232493.80901@gcom.com> <20140314162957.GB27448@port70.net> <53234FE2.7040309@gcom.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------060302040108020900000106" X-Trace: ger.gmane.org 1394831097 4601 80.91.229.3 (14 Mar 2014 21:04:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 14 Mar 2014 21:04:57 +0000 (UTC) Cc: Support at Gcom To: musl@lists.openwall.com Original-X-From: musl-return-4659-gllmg-musl=m.gmane.org@lists.openwall.com Fri Mar 14 22:05:05 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 1WOZHs-0001Tb-Jp for gllmg-musl@plane.gmane.org; Fri, 14 Mar 2014 22:05:04 +0100 Original-Received: (qmail 8019 invoked by uid 550); 14 Mar 2014 21:05:03 -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 8005 invoked from network); 14 Mar 2014 21:05:03 -0000 X-Virus-Scanned: OK User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 In-Reply-To: <53234FE2.7040309@gcom.com> Xref: news.gmane.org gmane.linux.lib.musl.general:4655 Archived-At: This is a multi-part message in MIME format. --------------060302040108020900000106 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I built a shim module that defined all the undefined "__" routines that showed up in my link. Then all my programs linked successfully. But when I went to run one of my daemon processes it got a segv in the malloc code, as follows. Program terminated with signal 11, Segmentation fault. #0 0x0811cd5d in unbin (c=0x9b53898, i=8) at src/malloc/malloc.c:242 #1 0x0811d266 in malloc (n=112) at src/malloc/malloc.c:371 #2 0x0804b3ce in ssd_malloc_fcn (nbytes=16, file=0x81348e6 "../pi.c", linenr=2398) at ../pi.c:632 #3 0x0804b597 in ssd_zalloc_fcn (nbytes=12, file=0x81348e6 "../pi.c", linenr=2398) at ../pi.c:687 #4 0x0804b5e2 in ssd_calloc_fcn (n_memb=1, memb_size=12, file=0x81348e6 "../pi.c", linenr=2398) at ../pi.c:696 #5 0x0804ef18 in ss_setup_code_path (size=1024) at ../pi.c:2398 #6 0x080548be in register_connections () at ../pi.c:5074 #7 0x0805a2b8 in main (argc=2, argv=0xbfae15f4) at ../pi.c:7393 (gdb) p *c $1 = {psize = 17, csize = 144, next = 0x81a3990, prev = 0x1} (gdb) p mal $2 = {brk = 163028992, heap = 0x9b53008, binmap = 35184372089088, bins = {{lock = {0, 0}, head = 0x0, tail = 0x0}, {lock = {0, 0}, head = 0x81a3920, tail = 0x81a3920}, {lock = {0, 0}, head = 0x81a3930, tail = 0x81a3930}, {lock = {0, 0}, head = 0x81a3940, tail = 0x81a3940}, {lock = {0, 0}, head = 0x0, tail = 0x0}, {lock = {0, 0}, head = 0x81a3960, tail = 0x81a3960}, { lock = {0, 0}, head = 0x81a3970, tail = 0x81a3970}, {lock = {0, 0}, head = 0x81a3980, tail = 0x81a3980}, {lock = {0, 0}, head = 0x9b53898, tail = 0x9b53898}, {lock = {0, 0}, head = 0x81a39a0, tail = 0x81a39a0}, {lock = {0, 0}, head = 0x81a39b0, tail = 0x81a39b0}, {lock = {0, 0}, head = 0x81a39c0, tail = 0x81a39c0}, {lock = {0, 0}, head = 0x81a39d0, tail = 0x81a39d0}, {lock = {0, 0}, head = 0x81a39e0, tail = 0x81a39e0}, {lock = {0, 0}, head = 0x81a39f0, tail = 0x81a39f0}, {lock = {0, 0}, head = 0x81a3a00, tail = 0x81a3a00}, {lock = {0, 0}, head = 0x81a3a10, tail = 0x81a3a10}, {lock = {0, 0}, head = 0x0, tail = 0x0}, {lock = {0, 0}, head = 0x81a3a30, tail = 0x81a3a30}, {lock = {0, 0}, head = 0x81a3a40, tail = 0x81a3a40}, {lock = {0, 0}, head = 0x81a3a50, tail = 0x81a3a50}, {lock = {0, 0}, head = 0x81a3a60, tail = 0x81a3a60}, {lock = {0, 0}, head = 0x0, tail = 0x0}, {lock = {0, 0}, head = 0x81a3a80, tail = 0x81a3a80}, {lock = {0, 0}, head = 0x81a3a90, tail = 0x81a3a90}, {lock = {0, 0}, head = 0x81a3aa0, tail = 0x81a3aa0}, {lock = {0, 0}, head = 0x0, tail = 0x0}, {lock = {0, 0}, head = 0x81a3ac0, tail = 0x81a3ac0}, {lock = {0, 0}, head = 0x81a3ad0, tail = 0x81a3ad0}, {lock = {0, 0}, head = 0x81a3ae0, tail = 0x81a3ae0}, {lock = {0, 0}, head = 0x81a3af0, tail = 0x81a3af0}, {lock = {0, 0}, head = 0x0, tail = 0x0}, {lock = {0, 0}, head = 0x81a3b10, tail = 0x81a3b10}, {lock = {0, 0}, head = 0x81a3b20, tail = 0x81a3b20}, {lock = {0, 0}, head = 0x81a3b30, tail = 0x81a3b30}, {lock = {0, 0}, head = 0x81a3b40, tail = 0x81a3b40}, {lock = {0, 0}, head = 0x81a3b50, tail = 0x81a3b50}, {lock = {0, 0}, head = 0x81a3b60, tail = 0x81a3b60}, {lock = {0, 0}, head = 0x81a3b70, tail = 0x81a3b70}, {lock = {0, 0}, head = 0x81a3b80, tail = 0x81a3b80}, {lock = {0, 0}, head = 0x81a3b90, tail = 0x81a3b90}, {lock = {0, 0}, head = 0x81a3ba0, tail = 0x81a3ba0}, {lock = {0, 0}, head = 0x81a3bb0, tail = 0x81a3bb0}, {lock = {0, 0}, head = 0x81a3bc0, tail = 0x81a3bc0}, {lock = {0, 0}, head = 0x81a3bd0, tail = 0x81a3bd0}, {lock = {0, 0}, head = 0x9b78888, tail = 0x9b78888}, {lock = {0, 0}, head = 0x81a3bf0, tail = 0x81a3bf0}, {lock = {0, 0}, head = 0x0, tail = 0x0} }, brk_lock = {0, 0}, free_lock = {0, 0}} I can supply more details as needed. Thanks, Dave On 3/14/2014 1:52 PM, David Grothe wrote: > Thanks for the suggestions. > > My musl build did not include a libgcc: > > linuxsvr:dave:musl-0.9.15> find . -name '*libgcc*' > linuxsvr:dave:musl-0.9.15> > > It is correct that something in the GNU headers changed "signal" into > "sysv_signal" without my knowledge. > > My code base is several million lines of code and I have many other > projects to do that are higher priority than porting to another set of > header files. It would be a few days worth of effort and I just have > other things to do right now. > > That said I do have a reason for wanting static linking, so maybe I > will find the time to do the port some time. (I tried just aiming my > build at the musl include directory and it did not "just work".) > > I can act on the suggestions made and see how that helps. But what > about libgcc? > > Thanks, > Dave > > On 3/14/2014 11:29 AM, Szabolcs Nagy wrote: >> * David Grothe [2014-03-14 10:47:31 -0500]: >>> 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 >> compiling with the gnu headers is broken and >> it depends on the cflags used >> >>> this and link my-huge-program.o with musl libc.a I get the following >>> list of unresolved externals: >>> >>> U __divdi3 >> comes from libgcc.a, if it's missing you have a toolchain issue >> >>> w __fini_array_end >>> w __fini_array_start >> i think musl supports init/fini arrays >> (see src/exit/exit.c) >> >>> U __moddi3 >> libgcc >> >>> U __sysv_signal >> you may want to replace it with signal >> >>> U __udivdi3 >>> U __umoddi3 >> libgcc >> >>> U __vfprintf_chk >>> U __vsnprintf_chk >>> U __vsprintf_chk >> there are many _chk functions for _FORTIFY_SOURCE, musl may provide >> these eventually, until then you can add your own chk.o with dummy >> implementations (possibly with the safety checks i omit here): >> >> int __vfprintf_chk(FILE *f, int flag, const char *fmt, va_list ap) >> { >> return vfprintf(f, fmt, ap); >> } >> int __vsnprintf_chk(char *s, size_t n, int flag, size_t size, const char *fmt, va_list ap) >> { >> return vsnprintf(s, n, fmt, ap); >> } >> int __vsprintf_chk(char *s, int flag, size_t size, const char *fmt, va_list ap) >> { >> return vsprintf(s, fmt, ap); >> } >> >>> U __sysv_signal >> use signal >> >>> 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. >> compiling with glibc headers and then linking to musl >> cannot be supported in general, because of ABI compat issues >> >> (eg glibc headers define PTHREAD_*_INITIALIZER macros that hardcode >> glibc internal ABI at compile time that does not match musl) >> >> if you are sure you don't have such ABI breakage (see glibc >> vs musl differences on the wiki) then you may get away by >> adding a glibc-compat.o to your musl build >> >>> Any possibility of that? >>> >>> Thanks, >>> Dave > --------------060302040108020900000106 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I built a shim module that defined all the undefined "__" routines that showed up in my link.  Then all my programs linked successfully.  But when I went to run one of my daemon processes it got a segv in the malloc code, as follows.

Program terminated with signal 11, Segmentation fault.
#0  0x0811cd5d in unbin (c=0x9b53898, i=8) at src/malloc/malloc.c:242
#1  0x0811d266 in malloc (n=112) at src/malloc/malloc.c:371
#2  0x0804b3ce in ssd_malloc_fcn (nbytes=16, file=0x81348e6 "../pi.c", linenr=2398) at ../pi.c:632
#3  0x0804b597 in ssd_zalloc_fcn (nbytes=12, file=0x81348e6 "../pi.c", linenr=2398) at ../pi.c:687
#4  0x0804b5e2 in ssd_calloc_fcn (n_memb=1, memb_size=12, file=0x81348e6 "../pi.c", linenr=2398) at ../pi.c:696
#5  0x0804ef18 in ss_setup_code_path (size=1024) at ../pi.c:2398
#6  0x080548be in register_connections () at ../pi.c:5074
#7  0x0805a2b8 in main (argc=2, argv=0xbfae15f4) at ../pi.c:7393
(gdb) p *c
$1 = {psize = 17, csize = 144, next = 0x81a3990, prev = 0x1}
(gdb) p mal
$2 = {brk = 163028992, heap = 0x9b53008, binmap = 35184372089088, bins = {{lock = {0, 0}, head = 0x0, tail = 0x0}, {lock = {0, 0}, head = 0x81a3920, tail = 0x81a3920}, {lock = {0, 0},
      head = 0x81a3930, tail = 0x81a3930}, {lock = {0, 0}, head = 0x81a3940, tail = 0x81a3940}, {lock = {0, 0}, head = 0x0, tail = 0x0}, {lock = {0, 0}, head = 0x81a3960, tail = 0x81a3960}, {
      lock = {0, 0}, head = 0x81a3970, tail = 0x81a3970}, {lock = {0, 0}, head = 0x81a3980, tail = 0x81a3980}, {lock = {0, 0}, head = 0x9b53898, tail = 0x9b53898}, {lock = {0, 0},
      head = 0x81a39a0, tail = 0x81a39a0}, {lock = {0, 0}, head = 0x81a39b0, tail = 0x81a39b0}, {lock = {0, 0}, head = 0x81a39c0, tail = 0x81a39c0}, {lock = {0, 0}, head = 0x81a39d0,
      tail = 0x81a39d0}, {lock = {0, 0}, head = 0x81a39e0, tail = 0x81a39e0}, {lock = {0, 0}, head = 0x81a39f0, tail = 0x81a39f0}, {lock = {0, 0}, head = 0x81a3a00, tail = 0x81a3a00}, {lock = {0,
        0}, head = 0x81a3a10, tail = 0x81a3a10}, {lock = {0, 0}, head = 0x0, tail = 0x0}, {lock = {0, 0}, head = 0x81a3a30, tail = 0x81a3a30}, {lock = {0, 0}, head = 0x81a3a40, tail = 0x81a3a40},
    {lock = {0, 0}, head = 0x81a3a50, tail = 0x81a3a50}, {lock = {0, 0}, head = 0x81a3a60, tail = 0x81a3a60}, {lock = {0, 0}, head = 0x0, tail = 0x0}, {lock = {0, 0}, head = 0x81a3a80,
      tail = 0x81a3a80}, {lock = {0, 0}, head = 0x81a3a90, tail = 0x81a3a90}, {lock = {0, 0}, head = 0x81a3aa0, tail = 0x81a3aa0}, {lock = {0, 0}, head = 0x0, tail = 0x0}, {lock = {0, 0},
      head = 0x81a3ac0, tail = 0x81a3ac0}, {lock = {0, 0}, head = 0x81a3ad0, tail = 0x81a3ad0}, {lock = {0, 0}, head = 0x81a3ae0, tail = 0x81a3ae0}, {lock = {0, 0}, head = 0x81a3af0,
      tail = 0x81a3af0}, {lock = {0, 0}, head = 0x0, tail = 0x0}, {lock = {0, 0}, head = 0x81a3b10, tail = 0x81a3b10}, {lock = {0, 0}, head = 0x81a3b20, tail = 0x81a3b20}, {lock = {0, 0},
      head = 0x81a3b30, tail = 0x81a3b30}, {lock = {0, 0}, head = 0x81a3b40, tail = 0x81a3b40}, {lock = {0, 0}, head = 0x81a3b50, tail = 0x81a3b50}, {lock = {0, 0}, head = 0x81a3b60,
      tail = 0x81a3b60}, {lock = {0, 0}, head = 0x81a3b70, tail = 0x81a3b70}, {lock = {0, 0}, head = 0x81a3b80, tail = 0x81a3b80}, {lock = {0, 0}, head = 0x81a3b90, tail = 0x81a3b90}, {lock = {0,
        0}, head = 0x81a3ba0, tail = 0x81a3ba0}, {lock = {0, 0}, head = 0x81a3bb0, tail = 0x81a3bb0}, {lock = {0, 0}, head = 0x81a3bc0, tail = 0x81a3bc0}, {lock = {0, 0}, head = 0x81a3bd0,
      tail = 0x81a3bd0}, {lock = {0, 0}, head = 0x9b78888, tail = 0x9b78888}, {lock = {0, 0}, head = 0x81a3bf0, tail = 0x81a3bf0}, {lock = {0, 0}, head = 0x0, tail = 0x0} <repeats 17 times>},
  brk_lock = {0, 0}, free_lock = {0, 0}}


I can supply more details as needed.
Thanks,
Dave
On 3/14/2014 1:52 PM, David Grothe wrote:
Thanks for the suggestions.

My musl build did not include a libgcc:

linuxsvr:dave:musl-0.9.15> find . -name '*libgcc*'
linuxsvr:dave:musl-0.9.15>

It is correct that something in the GNU headers changed "signal" into "sysv_signal" without my knowledge.

My code base is several million lines of code and I have many other projects to do that are higher priority than porting to another set of header files.  It would be a few days worth of effort and I just have other things to do right now.

That said I do have a reason for wanting static linking, so maybe I will find the time to do the port some time. (I tried just aiming my build at the musl include directory and it did not "just work".)

I can act on the suggestions made and see how that helps.  But what about libgcc?

Thanks,
Dave
On 3/14/2014 11:29 AM, Szabolcs Nagy wrote:
* David Grothe <dave@gcom.com> [2014-03-14 10:47:31 -0500]:

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

compiling with the gnu headers is broken and
it depends on the cflags used


this and link my-huge-program.o with musl libc.a I get the following
list of unresolved externals:

         U __divdi3

comes from libgcc.a, if it's missing you have a toolchain issue


         w __fini_array_end
         w __fini_array_start

i think musl supports init/fini arrays
(see src/exit/exit.c)


         U __moddi3

libgcc


         U __sysv_signal

you may want to replace it with signal


         U __udivdi3
         U __umoddi3

libgcc


         U __vfprintf_chk
         U __vsnprintf_chk
         U __vsprintf_chk

there are many _chk functions for _FORTIFY_SOURCE, musl may provide
these eventually, until then you can add your own chk.o with dummy
implementations (possibly with the safety checks i omit here):

int __vfprintf_chk(FILE *f, int flag, const char *fmt, va_list ap)
{
	return vfprintf(f, fmt, ap);
}
int __vsnprintf_chk(char *s, size_t n, int flag, size_t size, const char *fmt, va_list ap)
{
	return vsnprintf(s, n, fmt, ap);
}
int __vsprintf_chk(char *s, int flag, size_t size, const char *fmt, va_list ap)
{
	return vsprintf(s, fmt, ap);
}


         U __sysv_signal

use signal


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.

compiling with glibc headers and then linking to musl
cannot be supported in general, because of ABI compat issues

(eg glibc headers define PTHREAD_*_INITIALIZER macros that hardcode
glibc internal ABI at compile time that does not match musl)

if you are sure you don't have such ABI breakage (see glibc
vs musl differences on the wiki) then you may get away by
adding a glibc-compat.o to your musl build


Any possibility of that?

Thanks,
Dave


--------------060302040108020900000106-- From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4656 Path: news.gmane.org!not-for-mail From: John Spencer Newsgroups: gmane.linux.lib.musl.general Subject: Re: Static linking of musl with code compiled using GNU header files Date: Fri, 14 Mar 2014 22:37:08 +0100 Message-ID: <53237684.1070006@barfooze.de> References: <53232493.80901@gcom.com> <20140314162957.GB27448@port70.net> <53234FE2.7040309@gcom.com> <53236EF2.4030606@gcom.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1394833056 26062 80.91.229.3 (14 Mar 2014 21:37:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 14 Mar 2014 21:37:36 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4660-gllmg-musl=m.gmane.org@lists.openwall.com Fri Mar 14 22:37:46 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 1WOZnV-0005Iy-5R for gllmg-musl@plane.gmane.org; Fri, 14 Mar 2014 22:37:45 +0100 Original-Received: (qmail 23597 invoked by uid 550); 14 Mar 2014 21:37:44 -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 23589 invoked from network); 14 Mar 2014 21:37:44 -0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 In-Reply-To: <53236EF2.4030606@gcom.com> Xref: news.gmane.org gmane.linux.lib.musl.general:4656 Archived-At: David Grothe wrote: > I built a shim module that defined all the undefined "__" routines that > showed up in my link. Then all my programs linked successfully. But > when I went to run one of my daemon processes it got a segv in the > malloc code, as follows. on which platform is this ? the linaro bit in your toolchain suggests that it is ARM. is that correct ? and which version of musl ? limited ABI compat is only there for x86 platforms. as for your problem below, it's possible that something else calls sbrk() messing up musl's allocator. you should check strace output to see if sbrk(0) is called more than once. also make sure that nothing pulls in glibc's libc.so. btw did you check your code against the ABI checklist that was pointed out earlier ? to me, it's not very surprising that your broken usage breaks and invokes UB somewhere.. > > Program terminated with signal 11, Segmentation fault. > #0 0x0811cd5d in unbin (c=0x9b53898, i=8) at src/malloc/malloc.c:242 > #1 0x0811d266 in malloc (n=112) at src/malloc/malloc.c:371 > #2 0x0804b3ce in ssd_malloc_fcn (nbytes=16, file=0x81348e6 "../pi.c", > linenr=2398) at ../pi.c:632 > #3 0x0804b597 in ssd_zalloc_fcn (nbytes=12, file=0x81348e6 "../pi.c", > linenr=2398) at ../pi.c:687 > #4 0x0804b5e2 in ssd_calloc_fcn (n_memb=1, memb_size=12, file=0x81348e6 From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4657 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 20:09:09 -0400 Message-ID: <20140315000909.GK184@brightrain.aerifal.cx> References: <53232493.80901@gcom.com> <20140314162957.GB27448@port70.net> <53234FE2.7040309@gcom.com> <53236EF2.4030606@gcom.com> <53237684.1070006@barfooze.de> 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 1394842155 25012 80.91.229.3 (15 Mar 2014 00:09:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 15 Mar 2014 00:09:15 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4661-gllmg-musl=m.gmane.org@lists.openwall.com Sat Mar 15 01:09:25 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 1WOcAE-0000nf-R9 for gllmg-musl@plane.gmane.org; Sat, 15 Mar 2014 01:09:22 +0100 Original-Received: (qmail 7343 invoked by uid 550); 15 Mar 2014 00:09:21 -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 7335 invoked from network); 15 Mar 2014 00:09:21 -0000 Content-Disposition: inline In-Reply-To: <53237684.1070006@barfooze.de> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:4657 Archived-At: On Fri, Mar 14, 2014 at 10:37:08PM +0100, John Spencer wrote: > David Grothe wrote: > >I built a shim module that defined all the undefined "__" routines > >that showed up in my link. Then all my programs linked > >successfully. But when I went to run one of my daemon processes > >it got a segv in the malloc code, as follows. > > on which platform is this ? the linaro bit in your toolchain > suggests that it is ARM. is that correct ? and which version of musl > ? > limited ABI compat is only there for x86 platforms. While it's untested on anything but x86, the ABI compatibility should be comparable on arm, mips, microblaze, and sh. OTOH powerpc is known to be ABI-incompatible for multiple reasons (which basically amount to the glibc powerpc ABI being really bad) and x86_64 has some minor incompatibilities due to glibc bugs (regoff_t being the wrong size) that we'll eventually work around by making the dynamic linker detect glibc-linked callers and redirect calls to regexec to a fixup wrapper (but I don't see an easy way to do the same for static linking). > as for your problem below, it's possible that something else calls > sbrk() messing up musl's allocator. > you should check strace output to see if sbrk(0) is called more than once. > also make sure that nothing pulls in glibc's libc.so. In latest musl, sbrk is dummied out, so it's probably unlikely that this is the issue. > btw did you check your code against the ABI checklist that was > pointed out earlier ? >From nsz's email? If so, I'm not sure that's quite a "checklist". But it's important to be aware that trying to rely on the "ABI compat" will potentially hide problems where your program is using a glibc feature that musl does not provide. (This would likely be caught at compile-time if you were using the musl headers, e.g. due to missing macro constants.) Rich From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4658 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 20:22:09 -0400 Message-ID: <20140315002209.GL184@brightrain.aerifal.cx> References: <53232493.80901@gcom.com> <20140314162957.GB27448@port70.net> <53234FE2.7040309@gcom.com> <53236EF2.4030606@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 1394842933 32661 80.91.229.3 (15 Mar 2014 00:22:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 15 Mar 2014 00:22:13 +0000 (UTC) Cc: Support at Gcom To: musl@lists.openwall.com Original-X-From: musl-return-4662-gllmg-musl=m.gmane.org@lists.openwall.com Sat Mar 15 01:22:22 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 1WOcMo-0003KZ-G0 for gllmg-musl@plane.gmane.org; Sat, 15 Mar 2014 01:22:22 +0100 Original-Received: (qmail 13493 invoked by uid 550); 15 Mar 2014 00:22:21 -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 13482 invoked from network); 15 Mar 2014 00:22:21 -0000 Content-Disposition: inline In-Reply-To: <53236EF2.4030606@gcom.com> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:4658 Archived-At: On Fri, Mar 14, 2014 at 04:04:50PM -0500, David Grothe wrote: > I built a shim module that defined all the undefined "__" routines > that showed up in my link. Then all my programs linked > successfully. But when I went to run one of my daemon processes it > got a segv in the malloc code, as follows. > > Program terminated with signal 11, Segmentation fault. > #0 0x0811cd5d in unbin (c=0x9b53898, i=8) at src/malloc/malloc.c:242 > #1 0x0811d266 in malloc (n=112) at src/malloc/malloc.c:371 > #2 0x0804b3ce in ssd_malloc_fcn (nbytes=16, file=0x81348e6 > "../pi.c", linenr=2398) at ../pi.c:632 > #3 0x0804b597 in ssd_zalloc_fcn (nbytes=12, file=0x81348e6 > "../pi.c", linenr=2398) at ../pi.c:687 > #4 0x0804b5e2 in ssd_calloc_fcn (n_memb=1, memb_size=12, > file=0x81348e6 "../pi.c", linenr=2398) at ../pi.c:696 > #5 0x0804ef18 in ss_setup_code_path (size=1024) at ../pi.c:2398 > #6 0x080548be in register_connections () at ../pi.c:5074 > #7 0x0805a2b8 in main (argc=2, argv=0xbfae15f4) at ../pi.c:7393 > (gdb) p *c > $1 = {psize = 17, csize = 144, next = 0x81a3990, prev = 0x1} The crashing line is: c->prev->next = c->next; Based on this and your gdb print of *c, it looks like the chunk malloc is trying to pull from the bin has had its contents (where it stores its membership in the linked list of free chunks) clobbered, most likely by your program. This is probably a use-after-free error. At the very least, c->prev has been clobbered; it's also possible that c->next was clobbered. You could try printing *c->next to see if it looks like a valid chunk header (i can tell you if you send it to the list). Looking for the code that called free((void *)0x9b538a0) might be a good way to track this down. Rich