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--